JP1 Remotes

[gates668]

I am wondering how easy it would be to modify the jp12serial dll so that the DTR signal CLR/SET sequences were reversed.

After almost a decade of building and using parallel and serial interfaces to program jp1 remotes, I finally built a USB interface. I had a Nokia CA-50 cable which I had been using for hacking routers using the only availble lines (tx/rx/gnd). Upon opening the connector there was a pad marked DTR (no RTS seems to be available) so I added the wire and connector.

I was unsuccessful in communicating with the remote but reading the forums revealed that some Chinese cables had inverted signals. http://www.hifi-remote.com/forums/viewtopic.php?t=9087&postdays=0&postorder=asc&&start=0 I used Realterm and comtest and Tommy's writeup on testing signals to determine that DTR was being CLRed when resetting the remote (giving two blinks) and SET to put it into program mode. Exactly the opposite of what was required.

I breadboarded an inverter for the DTR signal out of discrete components and sure enough, success! Before i go ahead and start soldering this cable (and at least one other), I thought, if it was just a signal being SET vice being CLRed, that it might be relatively easy to modify the dll rather than build hardware. Especially if you consider that others have likely run across this issue. I have no knowledge of cables with inverted RTS signals but it might be beneficial to reverse the RTS SET/CLR in the same dll as well in case there are some of those in the wild. (Has anyone run across one of these?)

In my dreams, it would be awesome to have the signal used (RTS/DTR, standard/inverted) be selectable in the software program in some advanced user mode (DD-WRT does this for gpio pins for router SD card access). But that is asking a lot!

An easier solution I thought might be a quick recompile of the dll which could then be swapped in or out with the standard one as required (proper caveats in the "invert" file would ensure the average user would not use it by accident). Initial investigation would seem to indicate that changes would be required in the connection and escape sections. However, as with all programming, as well-documented as it is, there is always the danger of messing something up. Not to mention one of the authors could likely do something like that in a fraction of the time I could.

So, does this seem like a valid idea and would anyone familiar with the source be willing to make a few changes and recompile. I feel confident that this would benefit not just me but others who may have a similar cable variant.

Thanks,
gates668

[gates668]

Over the past month I have been slowly picking away at this issue. Here is the update (yes there is a bit of hardware stuff in here)

My breadboarded inverter circuit used a separate 5V USB source. Partway through building the actual circuit, I went to check to see if the USB-TTL converter provided 5V or 3.3 on the Vcc pad so I would know if I needed to drop the voltage or not. When I opened it back up to measure the voltage, I noticed some unmarked pads on the underside. I metered each pad while toggling RTS in Realcomm and sure enough on the final pad (as if to build movie-style tension) there was a proper RTS signal. So, for me, no need for an inverter and no need to modify the dll.

However, I was well underway on the project and figured maybe someone else could benefit who didn't have an RTS signal.

I already had DTR_N wired and my inverter (with bypass jumper) was mostly built, so I finished the job. With the inverter in place using DTR_N, IR would successfully download. (I also wired RTS so when I was done I could go back to using everything stock without the inverter)

Then I turned to software. I started out by trying to compile a working stock dll using suggestions on the site. I downloaded MiniGW and tried to compile. I then discovered I needed to download the JDK for includes/libraries. After that was done I did succeed in compiling a stock dll that worked (with the inverter). However, this required having several JDK libraries in the same directory (or in the path)

I then went ahead and swapped the order of SETDTR and CLRDTR in six places in the cpp file (some of them were for jp1.1 and 1.2) Recompile. Disable inverter but still using DTR_N. Success! Instead of a hardware inverter, the dll was reversing the order so that the remote was in the right mode for programming. At least for my jp1.3 remote.

So my plan in to wait a bit for feedback and then upload what I have in case someone out there runs across the same problem I did. This will be well documented in source and the dll will be clearly marked so there is no mix up.

So here is the question:
Does anyone out there know how to compile the dll so that the libraries are not required? I could take out the includes for JDK but the souce file seemed to indicate that would break it for RMIR. I suspect there is a way as the standard dll (aside from being smaller) doesn't complain when the libraries aren't there.

Thanks,
gates668