Hello,
I can't seem to get any communication with two separate Atlas 1056B01 JP1.3 remotes. I am using a cable from ebay claiming to be for both JP1.2 and JP1.3 remotes:
http://cgi.ebay.ca/ws/eBayISAPI.dll?Vie ... 1375253919
This interface cable uses the older Prolific driver (at least that's what my Windows 7 32 bit machine detects it as). Note that I successfully used this cable to communicate with and upgrade my parents' Atlas-5 Device PVR Day 1025 JP 1.2 remote.
Both of my Atlas JP 1.3 remotes return a 3033 remote signature using the manual 983 setup command. For both remotes, the jp1xtest.exe test returns "NO JP1.2/3 COMPATIBLE REMOTE FOUND!", although the indicator lights on the remotes do flash a few times during this test. I have also tried testing them with Realterm as described by Tommy Tyler's guide, and they won't return their signatures and don't seem to go into the communication mode at all.
Did I just get bad luck with both of of these JP1.3 remotes (for example, maybe their ROM data was corrupted, as suggested in this thread). Or do you think something is wrong with the cable? I don't see a connection coming from the pin 5 location on the cable, so that shouldn't be the issue here. Would it be smarter for me to just purchase a new JP1.2 remote that will probably work with my cable, or should I first try out a newer FTDI interface cable?
Thanks in advance for any advice!
Can't communicate with two Atlas 1056B01 JP1.3 remotes
Moderator: Moderators
Tommy has written a couple of documents which can help. Look at page 3 of this document: it explains how to definitively tell if the remotes are entering communications mode. By design, interface cables are supposed to be made so the the RTS line is connected to pin 2. However, some interfaces have been made with DTR connected instead. RMIR and IR use JP12Serial.dll to communicate with these remotes, and JP12Serial will typically also work with interface cables which use DTR. However, this is just a side effect of trying to handle some older interfaces which were designed when the JP1 community was first learning about flash remotes. It may be worthwhile to try Tommy's test involving the RTS line instead by manipulating DTR. It really is necessary to see two flashes when clearing the RTS or DTR lines, since that shows that a reset signal is reaching the microprocessor.
In case the JP1 connector isn't labeled, hold the remote so that the JP1 connector is above the batteries. For the Atlas 1056B01, pin 1 is on the upper right, and the top row of pins is 5 3 1. The bottom row is 6 4 2. I mention this since an incorrect orientation will keep the remote from communicating.
Some Prolific chips have difficulty providing a Break signal, and Break is necessary to put JP1.3/JP1.4 remotes into communications mode. But I would expect that your interface cable should have chips for which Break does work.
I have trouble believing that you have two Atlas remotes, both of which have corrupted bootloaders. This kind of corruption is pretty rare, and the odds of two being bad is "pretty rare" squared.
I think in general it is better to get a FTDI based interface than to get JP1.2 remotes. It is much easier to find existing custom executors for JP1.3/1.4 remotes, because they use the same Samsung micros as are used in Slingboxes. Designs done by UEI since 2008 use a different communications protocol than the JP1.2/1.3 remotes, and additionally use a Maxim micro. I don't know of any Prolific-based interface which will work with JP2/3 remotes, but any FTDI one (if it implements RTS) will. The newest Atlas (1056B03) and Comcast remotes look cosmetically identical to the millions of JP1.3 ones already in use, but they are JP2. This thread offers several ways to get FTDI interfaces.
In case the JP1 connector isn't labeled, hold the remote so that the JP1 connector is above the batteries. For the Atlas 1056B01, pin 1 is on the upper right, and the top row of pins is 5 3 1. The bottom row is 6 4 2. I mention this since an incorrect orientation will keep the remote from communicating.
Some Prolific chips have difficulty providing a Break signal, and Break is necessary to put JP1.3/JP1.4 remotes into communications mode. But I would expect that your interface cable should have chips for which Break does work.
I have trouble believing that you have two Atlas remotes, both of which have corrupted bootloaders. This kind of corruption is pretty rare, and the odds of two being bad is "pretty rare" squared.
I think in general it is better to get a FTDI based interface than to get JP1.2 remotes. It is much easier to find existing custom executors for JP1.3/1.4 remotes, because they use the same Samsung micros as are used in Slingboxes. Designs done by UEI since 2008 use a different communications protocol than the JP1.2/1.3 remotes, and additionally use a Maxim micro. I don't know of any Prolific-based interface which will work with JP2/3 remotes, but any FTDI one (if it implements RTS) will. The newest Atlas (1056B03) and Comcast remotes look cosmetically identical to the millions of JP1.3 ones already in use, but they are JP2. This thread offers several ways to get FTDI interfaces.
I tried Tommy's test using the Realterm program again. I am able to get two blinks after clearing the RTS line, so the reset signal is reaching the microprocessor.
When I tried this part of the test:
I get this exact same behavior for both of the remotes. Should I conclude then that this interface cable can't provide the Break signal, and therefore it can only communicate with JP1.2 remotes?
When I tried this part of the test:
The remote's indicator did NOT flash twice after clearing the RTS signal. However, the remote still responds to key presses after doing this. Also, after a key press on the remote, a red light comes on next to "Error" in the Status box on the right side of the program, and "UART receiver framing error" displays in the lower left bar in the program.With the green RTS indicator OFF, press the TXD Set Break button, then the RTS Set button, then the RTS Clear button, and finally the TXD Clear Break button, in that exact order.
You're looking for two indications that this sequence switches the remote out of normal operation mode and into serial communications mode. The first indication is that the remote's indicator DOES NOT flash twice when reset is removed by clearing the RTS signal (green RTS indicator turns off). The second indication is that the remote is inoperable and does not respond to pressing any of its keys.
I get this exact same behavior for both of the remotes. Should I conclude then that this interface cable can't provide the Break signal, and therefore it can only communicate with JP1.2 remotes?
I'm not able to get a 1056B01 to generate a Framing error under any sequence of RTS/Break, but I'm using a FTDI interface.
JP1.2 remotes also use the Set/clear Break approach to go into communications mode, but they use a Motorola HCS08 micro instead of a Samsung, so the timing and coordination of the Break signal may be different. So, I'm not sure if the Break signal is a problem, but it does seem the most likely cause.
JP1.2 remotes also use the Set/clear Break approach to go into communications mode, but they use a Motorola HCS08 micro instead of a Samsung, so the timing and coordination of the Break signal may be different. So, I'm not sure if the Break signal is a problem, but it does seem the most likely cause.