JP1 Remotes

i'm having trouble finding how to use the data from digitrace to program my jp1 remote

I didn't recognize "digitrac" until yesterday when I actually used "digitrace" myself. You are talking about the program discussed in this thread: https://www.hifi-remote.com/forums/viewtopic.php?t=3569, right?

It's not going to be easy to explain in a few sentences (or even several paragraphs.) You would have to wait for someone writing a program that either bridges the output from digitrace or reads the data directly from the device through the parallel port and pass down the data to the decoding dll.

Hal

Ryan,
I take it that this means you have created a working device then, and if so, did you make the RF, IR or IR&RF version. Also, which OS are you using?

Btw, I edited the thread to say "digitrace".

mtakahar wrote:I didn't recognize "digitrac" until yesterday when I actually used "digitrace" myself. You are talking about the program discussed in this thread: https://www.hifi-remote.com/forums/viewtopic.php?t=3569, right?

Hal

that is the program im talking about.

The Robman wrote:Ryan,
I take it that this means you have created a working device then, and if so, did you make the RF, IR or IR&RF version. Also, which OS are you using?

Btw, I edited the thread to say "digitrace".

Actually when i first made the thread i used digitrace but then noticed the file was named digitrac so i edit it. I ordered the parts on the list for both the rf and ir. the ir portion couldnt have been any easier so i did that first. it worked with digitrace but when it started to look like it wasnt going to work to learn with it I stopped putting together the rf portion but i still have everything for it.
My OS is xp.

mtakahar wrote:You would have to wait for someone writing a program that either bridges the output from digitrace or reads the data directly from the device through the parallel port and pass down the data to the decoding dll.

Actually, I ended up writing one myself and now adding some GUI stuff to it. I can post a portotype if you are interested.

Hal

That would be great

I've uploaded it here.

This is working on my 1.3GHz Celeron laptop running XP SP2, so it probably works for you, too. (Not sure if this works on 98/Me.)

You need the porttalk driver (perhaps you've already had it for the digitrace program) and JRE or JDK 5.0 (1.5.0) installed.

Anything other than the "Start Capture" button haven't been implemented yet.

Hal

Thanks. I've been meaning to try building something like that myself. I really need some sort of tool on a PC that calls DecodeIr for directly received IR signals.
Hopefully I can find the time very soon to use what you did (I assume much less time than inventing it myself).

Yeah, I figured you didn't have time, and it's way too bad if this Tommy's great creation had to go waste because of lack of a software.

I forgot to mention about the I/O port setting. It'll use whatever you set up for IR.exe. I'll add explicit port settings along with other tweaking options, though.

Hal

mtakahar wrote:It'll use whatever you set up for IR.exe.

Looks like IR.exe doesn't store the I/O port address in the registry if you never had to touch the setting, and CaptureIR will crash if there's' no entry.

I've updated the archive with a fix so it defaults to 0x378 if it doesn't find the setting. Please download it again if it was throwing an exception. I also included the source code.

It would be very cool if it become possible to import the decoded signals automatically either as external functions or device upgrades in RM some day.

Hal

I'm crawling toward being able to try this.

1) I tried http://java.com (as directed by Hal's directions) and it locked up my internet access, hung part way through loading that page and both before and after I tried closing that browser instance I had no internet access even through other programs. Rebooted and tried a different browser, same results. It was starting some sort of Java applet that did something seriously wrong with my older version of Java.

2) Tried Hal's program with my existing older Sun Java. It failed.

3) I went instead to java.sun.com (where I got the Java SDK long ago). After a few wrong clicks from their confusing top level page, I found the link to get the newest Windows Java SDK. I installed that.

4) Hal's program now starts.

Following Tom's instructions I measured some printer port pin voltages with and without a 1K load.
Control pins 1 and 14 both went from 3.37 down to 3.20
Data pin 5 went from 3.32 down to 3.15
Data pin 8 went from 3.32 down to 3.16

That makes pin 8 the lowest resistence by Tom's formula and his instructions taken literally would say to pick that one. But I'm sure I'm better off with the slightly higher voltage rather than slightly lower resistence.

Next I need to solder three wires to connect the IR sensor to a DB25 connector. I think it's easiest to add it to my JP1 cable's DB25 connector so I don't need to plug and unplug things. (I never got around to soldering the whole RF sensor kit and at this point I'm more interested in IR than RF). Given my lack of soldering skills, who knows what will happen.

johnsfine wrote:1) I tried http://java.com (as directed by Hal's directions) and it locked up my internet access, hung part way through loading that page and both before and after I tried closing that browser instance I had no internet access even through other programs. Rebooted and tried a different browser, same results. It was starting some sort of Java applet that did something seriously wrong with my older version of Java.

2) Tried Hal's program with my existing older Sun Java. It failed.

3) I went instead to java.sun.com (where I got the Java SDK long ago). After a few wrong clicks from their confusing top level page, I found the link to get the newest Windows Java SDK. I installed that.

I've just changed the reference to http://java.com/ to http://java.sun.com/j2se/1.5.0/download.jsp in the file description. I hope this makes downloading slightly easier for others...

Hal

I hope I didn't confuse anyone by saying "Java SDK". Most people will only need the smaller JRE.

I got the larger JDK because I occasionally do RemoteMaster development and I hope to understand and tweak Hal's code in this project.

If you only want to run it, not modify it, you only need the JRE.

Also, I'm on a different computer now than the one I had that problem on and I just tried java.com and it went right through that applet, no problem, played some annoying music and gave me access to the download buttons. I hate web pages with sound when I just want information or a download. But anyway it worked (despite the same obsolete Sun Java previously installed on this machine as the other). So the problem might have been very specific to that machine.

I wasted money on one of those "cold heat" soldering tools. I couldn't get it to melt more than a spec of solder, and none at all when in contact with the wires I wanted to solder. There were no instructions, so maybe I was using it entirely wrong.

I then switched to my old soldering iron and did a really sloppy job of soldering the 6 connections (both ends of three wires). But somehow it works.

Then I had lots of confusion over how to get PortTalk installed in a way that Hal's program could use it.

Then it all worked.

I misunderstood the UI and thought I needed to start and stop capture for each signal, but soon discovered otherwise.

It's pretty inconvenient as it stands now because it's too slow and it doesn't seem to deal with macros.

After you press and release the remote key, there is a long pause before the result appears. I need to dig through Hal's code and figure out how to tighten that.

I was really hoping PC decoding would show me whole macros, even when they're too long for an OFA remote to learn, maybe even if the frequency shifts within the macro. I'd also like to see how many frames there were of each signal. A big part of my purpose for direct PC capture and decode is to find out exactly what a remote is sending when a tricky macro doesn't perform as expected and/or I'm debugging some tricky protocol executor.

IIUC, Hal's program detects and reduces the first clear repeat pattern and then loses the rest.

I realize other people may just want to know what some original remote is sending, so they will prefer it the way it is (detect and reduce a repeat pattern just as a learning remote would).

Hopefully I can customize my copy, now that Hal has gotten me started.

I also have a bunch more soldering to do. My JP1 cable was too messy (from past inept kludging) to add 3 wires to, and I didn't want to risk it. So I started with another DB25 connector. But plugging and unplugging it will be too much trouble. I have resistors and diodes and a 10 pin header (that I think I can cut to JP1 size) so I'm going to try to solder JP1 components onto the DB25 I used for this.

johnsfine wrote:Then I had lots of confusion over how to get PortTalk installed in a way that Hal's program could use it.
...

I misunderstood the UI and thought I needed to start and stop capture for each signal, but soon discovered otherwise.

I'll add some notes on these points by the time of official release.

It's pretty inconvenient as it stands now because it's too slow and it doesn't seem to deal with macros. After you press and release the remote key, there is a long pause before the result appears. I need to dig through Hal's code and figure out how to tighten that.

In the first prototype I posted, I tried not to add any extra code within the parallel port monitoring loop. Capturing, demodulation and decoding are done each step at a time. In this model, the capturing part has to wait until it sees many enough sample (raw on/off cycles) or timeout occurs (I set it to 3 sec for now). So, it takes longer if the signal has relatively long gaps. It's probablly better setting the timeout for off time that is long enough to catch button release but not too long.

Another thing is the way I'm setting the thread priorities. I gave 7 (on the scale of 1 - 10 with the default 5) to the capturing thread and 3 to the thread that monitors the capturing thread. It looks that lowering the monitor thread wasn't necessary (at least on my PC) and running it on the default priority seems to give better response time.

I was really hoping PC decoding would show me whole macros, even when they're too long for an OFA remote to learn, maybe even if the frequency shifts within the macro. I'd also like to see how many frames there were of each signal. A big part of my purpose for direct PC capture and decode is to find out exactly what a remote is sending when a tricky macro doesn't perform as expected and/or I'm debugging some tricky protocol executor.

I haven't looked into DecodeIR much enough to understand what the "context" array is exactly for, but my guess is that I can call it repeatedly with the same contents of the array and it'll decode each detected subsequence continuously?

IIUC, Hal's program detects and reduces the first clear repeat pattern and then loses the rest.

No, it doesn't detect repeating patterns, at least yet. Perhaps it makes sense to have a checkbox for specifying whether you want to keep the duplicates or not.

Hopefully I can customize my copy, now that Hal has gotten me started.

There are some additional stuff you may need to get to rebuild the program yourself. Please let me know if you find something still missing.

- Java JDK 5.0 (1.5.0) or higher.

- GNU Make. There are various kinds of ports that work on the
Windows platforms. Perhaps most of them work just fine.
I used the standalone Mingw version (as opposed to cygwin mingw.)

You can download it from here: http://mingw.sourceforge.net/

- GNU C compiler (gcc) if you want to rebuild the JNI (Java Native
Interface) program files written in C. You can download this from
the Mingw site mentioned above. Cygwin version may work, but not
tested. It should not be hard to make it work with MSVC, however,
again, it is untested and you may need to make some minor changes.

- The following source files are included in porttalk22.zip
mentioned earlier in this document:

PortTalk_IOCTL.h
pt_ioctl.c

- Java utility classes from the Java Tutorials:

TableSorter.java:
version 2.0 02/27/04 by Philip Milne, Brendon McLean,
Dan van Enckevort, Parwinder Sekhon

http://java.sun.com/docs/books/tutorial ... orter.java


Hal