Connecting a JP1.1 remote via USB

[mathdon]

My FTDI cable arrived today, and with it I have been able to download Randy's (HamburgerHelper1) TimeWarner-badged remote. It identifies as a URC-1047C with signature CS400102. Here is a .rmir file of the download. It downloads as a JP1.1 remote but for some reason the RDF gives its processor as a 6805 RC16/18 with an appended note saying the processor is actually an SST. Because of that processor being given in the RDF, RMIR identifies it (on the Raw Data tab) as JP1, which (coincidentally?) is how the 6-pin socket is labelled in the battery compartment .

I used a kludged version of jp12serial to do the download, one which supports JP1.1 and JP1.2 with pin2=DTR, pin5=RTS on the connector. I tested it first with a JP1.2 remote before trying Randy's one. After more testing I will turn it into a new interface type for RMIR, one which needs to be specifically selected. Rob, I intended to make a comment in my post about the FTDI cable about it being expensive but somehow posted it without the comment. Since I have it working with the FTDI cable, though, I have every expectation that it will work also with the board I have on order from the US, which is about $13. Although it is not a cable, it needs nothing other than patch cables to connect it to the remote, so that will make a reasonable-priced JP1.1 interface.

[The Robman]

I don't recall if the SST 65P542R chip is a Motorola chip that uses the same assembler as the 6805 RC16/18, or if we just didn't bother to add SST to RMIR so we chose 6805 RC16/18 just to have a valid entry, kinda like how we enter S3C8 for the TI remotes.

I'll try to keep an eye out for other boards and cables on eBay just in case something else pops up that is cheaper, but I guess we can view JP1.1 remotes as "boutique", lol, so their users should expect to pay a little bit more for a working cable, though $13 isn't bad at all.

[mathdon]

I don't recall if the SST 65P542R chip is a Motorola chip that uses the same assembler as the 6805 RC16/18, or if we just didn't bother to add SST to RMIR so we chose 6805 RC16/18 just to have a valid entry, kinda like how we enter S3C8 for the TI remotes.

It is nothing like the entry S3C8 for the TI remotes. That is to prevent older versions of RMIR crashing if they do not recognize TI2541 as a valid processor. These RDFs also have a Processor+ entry that overrides the Processor entry and which gives the correct processor. The Processor+ entry is not recognized by such older RMIR versions, so they see S3C8. They do not crash, but of course they do not work, either, with such remotes.

You are probably right, however, about RMIR not recognizing SST at that time, as the other remote that Randy gave me, the Comcast, is labelled JP1.1 and downloads as JP1.1. It identifies as a Comcast URC-1058 and its RDF says its processor is an HCS08, which is different yet again. RMIR does now recognize SST, so I will amend the RDFs and test that they still work. I cannot remember if it was me or Greg that added the SST processor type. If it was me, I had no way of testing it so my testing will be of whether RMIR needs amending rather than whether SST is the correct processor.

[mathdon]

I changed the processor in the RDF for the Comcast URC-1058 from HCS08 to SST. I then created a device upgrade for the Dish Network (PID=0002) protocol, which is not built in to the Comcast, uploaded it and tested it with IRScope and it works. There is no code for the SST processor for this protocol in protocols.ini. RMIR creates it from the code for the 6805-RC16/18. I checked that there was indeed something changed from the 6805-RC16/18 code. This test indicates to me (a) that the change of processor from HCS08 to SST is not just "for show", it is actually necessary for upgrades with protocols that are not built in to actually work, and (b) RMIR already handles JP1.1 remotes correctly, so no need for further changes.

[The Robman]

So, you've got improved RDFs for the 3 JP1.1 remotes (CS300103, CS300105, CS301009) out of this exercise, and we know what's needed for JP1.1 users if they need new cables, so that's a good outcome.

[mathdon]

So, you've got improved RDFs for the 3 JP1.1 remotes (CS300103, CS300105, CS301009)

If those three are all JP1.1 then there are four, not three, JP1.1 remotes as the Atlas that started this is CS400102. Is that right, all four are JP1.1? And I see there is an extender for the CS301009, so five RDFs to change?

[The Robman]

I just grabbed those 3 signatures from the remote chart.

[mathdon]

I have now added a new interface type, JP11USB, to RMIR. It has to be selected specifically, so is not tested by AutoDetect, and when selected it displays a confirmation message that explains the nature of the cable that it requires. It supports JP1.1, JP1.2 and JP1.3 (and I have tested it on all three). The only reason it does not support JP1.4 and JP2 is that as far as I am aware, we do not know whether a connection to pin 5 is harmful to those remotes, in the way that pin 5 high is to JP1.3 as it causes it to go into TOOL mode.

To implement this new interface, I have updated jp12serial to version 0.26. This implements both JP1.x Serial and JP11USB interfaces. The JP1.x Serial interface is unchanged from v0.25, the new version just adds the JP11USB support.

I will post a development build that includes this shortly.

[The Robman]

Good work Graham.

[HamburgerHelper1]

I think it's really cool all the info that was discovered in this endeavor.
Hopefully I will run across some more "unique" remotes in the future.

Great job Graham.

[mathdon]

I think it's really cool all the info that was discovered in this endeavor.

It has been great fun and a great learning experience for me, so many thanks again for the remotes. Here's something even more cool . Although I said it was impossible, I have now found how to communicate with JP1.1 remotes with a standard USB interface cable . It helps to have one like the Chip Partner cables that have loose wires, as the trick is to connect both pins 3 and 5 to GND. The change is simply that pin 5 is now connected to pin 3, which was already GND, instead of being left unconnected. You then use JP1.x Serial, or simply AutoConnect, for the interface type.

DO NOT TRY THIS YET, THOUGH. It has required a further addition to jp12serial in addition to that for the new JP11USB interface. This too will be in jp12serial v0.26 when it it finally issued. I have tested it with every type of processor that we have come across, to make sure the addition has no ill effects on remotes other than JP1.1. I am still glad that I created JP11USB, as that works with all of JP1.1, JP1.2 and JP1.3 (and was a big part of the learning experience). You need to be sure that a remote is JP1.1 before using the new trick, as it could harm other remotes.

Hopefully I will run across some more "unique" remotes in the future.

I will be interested in anything else you find .

[HamburgerHelper1]

If I understand you correctly, then perhaps the average person could construct
an adapter on a small piece of perfboard connecting pins 3 and 5
and i would suggest a very large warning label for JP1.1 ONLY

[The Robman]

You need to be sure that a remote is JP1.1 before using the new trick, as it could harm other remotes.

Can you think of any kind of test that you could do to determine whether a non JP1.1 type of JP1.x remote is connected, before you do something that might damage a JP1.x remote? Is there any harmless command where a JP1.1 would respond differently than say a JP1.3?

[mathdon]

If I understand you correctly, then perhaps the average person could construct an adapter on a small piece of perfboard connecting pins 3 and 5

Indeed, but mine was even easier than that. Here's a pic of my lash-up:



I simply used patch cables to convert the black (GND) wire of the Chip Partner cable into two GND wires. The blue bit at the end is just a 6-pin extender. I find it much easier to assemble the connections on to that, so that I can then just plug the extender on to the remote.

[mathdon]

Can you think of any kind of test that you could do to determine whether a non JP1.1 type of JP1.x remote is connected, before you do something that might damage a JP1.x remote? Is there any harmless command where a JP1.1 would respond differently than say a JP1.3?

No, I don't think there is such a test. Tests as to what type a remote is rely first on being able to communicate with it, and the starting point here is a remote that we can't do that with. I think the simplest thing is just to try doing a raw download with a standard USB cable. Everything except JP1 and JP1.1, or possibly a new type of remote that we have never seen before, should download. I don't know if a JP1 remote would come to any harm. I suspect not, the remotes with EEPROMs seem pretty robust. Randy did the reverse, trying a JP1 adapter on what turned out to be a JP1.1 remote and it is still absolutely fine. So I think that if a remote doesn't download with a standard USB cable, then it should be pretty safe to try it with pins 3 and 5 connected together. I gave the warning simply because no remotes other than JP1.1 need this trick and I don't want to take responsibility if someone does mess up their remote by trying it on an inappropriate remote.