Connecting a JP1.1 remote via USB

[mathdon]

When it was tried and tested, we were using cables designed for JP1.1 remotes. When JP1.3 came along, we found that we had to cut the wire going to pin5 to make our JP1.1 cables with with our JP1.3 remotes. This was long before we could get ready made FTDI cables on eBay.

Do I take it that these were transistor cables rather than home-made FTDI ones? Do we know if the supposed JP1.1/1.2 FTDI cables were ever tested with JP1.1? I have looked at Tommy's JP1.1 transistor design and sort of understand what it does, but I note that he says it does not work with either JP1.2 or JP1.3. This makes me believe that the FTDI cables that have pin 5 connected to CTS, which work with JP1.2 but not JP1.3, do something different to Tommy's JP1.1 design and may never have worked with JP1.1, however they were marketed.

Another possibility in my mind is that JP1.1 needs 5v signals. I am using a Chip Partner loose-lead cable which I assume is a 3.3v one, but I have no way of testing that. What I have found, by adding debug messages into JP12serial, is that there is no difference at any stage in the communication attempt between trying to connect to these JP1.1 remotes and trying to connect without a remote connected at all. This is with pin 5 connected to CTS (blue wire). So at present I am at a loss as to how to proceed further.

[The Robman]

My recollection is that JP1.1 and JP1.3 cables both work with JP1.2.

So here's how I think it played out:
1. First, we invented the JP1.1 cables, and these worked with JP1.2
2. When JP1.3 came along, we discovered that our JP1.1/2 cables didn't work. Tommy invented a new JP1.2/3 cable that did not work with JP1.1 He also let us know that, if we had a JP1.1/2 cable but only had JP1.2 and JP1.3 remotes, we could cut the wire to pin5 (as close to the remote as possible) and it would work.

This was all long before FTDI entered the picture. By the time FTDI came along, we'd long forgotten about JP1.1 remotes, as there were so few of them anyway, the main one being a Comcast remote, and Comcast replaced it with a JP1.2/3 model anyway. So we've never tried to connect a JP1.1 remote using an FTDI cable.

I don't know enough about electronics to know why that 4th transistor was needed for JP1.1 and not needed for JP1.3, so I don't know what modifications (if any) would be needed to an FTDI cable to make it work with JP1.1. There is a circuit diagram in the FTDI doc that I was hoping to compare to the JP1.1 doc and the JP1.3 doc to see if any of it makes sense.

[mathdon]

From a study of the circuit diagrams posted by Rob, together with info from the JP12serial source code, it seems to me that it is not possible to connect to a JP1.1 remote with the USB cables such as those from Chip Partner. Besides power on VCC and GND, these cables have four wires, of which two are outputs to the remote (RTS and TXD) and two are inputs from the remote (CTS and RXD). As we normally connect them, VCC and CTS are left unconnected and the others by pin number are 2=RTS, 3=GND, 4=TXD, 6=RXD. This corresponds to Tommy's JP1.2/1.3 transistor interface, except that has 1=VCC for pull-up purposes.

The pin 2 connection to RTS is used for reset. Tommy's JP1.1 transistor interface uses DTR to control pin 2 for reset and RTS on pin 5 as what he labels JP1.1 START. DTR and RTS are both outputs but the only free wire on the Chip Partner and similar interfaces is CTS which is an input. Connecting CTS to pin 5 does no harm, but it does no good, either. So such cables do not seem capable of use with JP1.1.

Does anyone know if there are other USB interface cables or other devices that support both DTR and RTS? I know that JP1.1 remotes are obsolete, but so are JP1 remotes and we still support those, so it would be a pity if JP1.1 remains the only interface that we cannot support with a USB connection.

[HamburgerHelper1]

It appears that it may be possible to find a USB interface that support both DTR and RTS
but i only did a quick search and and found this

https://www.xanthium.in/ft232-based-usb ... plications

https://www.xanthium.in/controlling-dtr ... xx-library

more research would be needed before considering any purchase
but there must be other suppliers and perhaps FTDI already has a different cable
that would work

[3FG]

If you're willing to connect from the pins on a DB9 connector to the JP1 connector:
Tera Grand FTDI
Also if you're willing to solder in some pins Sparkfun Breakout
Do be careful. Attaching this JP1.1 cable assembly to a JP1.3 remote runs the chance of overwriting the program flash. For example I believe the RCRP05B is sucseptible to this kind of damage.

[mathdon]

If you're willing to connect from the pins on a DB9 connector to the JP1 connector:
Tera Grand FTDI

Many thanks, Dave, for the links. Do you have any experience of these products? I am unclear about the polarity (and voltage) of the signals and whether or not I would need a Tommy-style transistor interface connected to the DB9 connector. My distant recollection of DB9 serial is that the signals are active high, or perhaps even switch between +10v and -10v as the comments in jp12serial code suggest, and the Tommy circuit that Rob posted seems to convert them to being active low, if I understand it correctly. If so, I would not be able to make a direct connection from the DB9 connector to a JP1 one. I can find no info on this on the links you posted. Do you have any such info?

On jp12serial, I am pretty sure that the JP1.1 code survives intact.

[HamburgerHelper1]

The schematic for the Comcast 1057BGO is in the file section

http://www.hifi-remote.com/forums/dload ... le_id=3073

[mathdon]

I don't know if it will work or not, but after a web search I have ordered this CP2102N USB 2.0 Micro to UART Module Serial Converter Adapter. It has RTS, DTR, RXD and TXD and uses a CP2102N chip. The chip specs show that RTS and DTR are active low, and as I can see no other active components on the board, I presume that applies also to the adapter itself. It has to come to me in the UK from the US and may be up to four weeks arriving, but I will post further news when I have it. If anyone knows of anything that might be better, I will be happy to order that too. At $10 plus carriage, I won't have wasted a lot if something better comes along.

[The Robman]

Tommy reminded me that this document chronicles the history of JP1.x interfaces.

UEI has produced two distinct classes of remotes, EEPROM-based (JP1) and flash-based (JP1.x). Flash-based remotes have used four different types of processors:

• JP1.1 uses SST 65P542R
• JP1.2 uses Motorola (Freescale) MC9S08RG60
• JP1.3 uses Samsung S3F80J8
• JP1.4 and JP2 use Maxim MAXQ610

With respect to the 6-pin connector, all four types of JP1.x remotes have the following in common:

• pin 1 = +3V to +3.3V from remote's power supply
• pin 2 = RESET
• pin 3 = GND
• pin 4 = Serial data to remote (Rx)
• pin 6 = Serial data from remote (Tx)

All four communicate at 38400 baud using pins 4 and 6. The main difference between the four, as far as the interface is concerned, is in the method of initializing the remote into serial mode for uploading and downloading with IR.

• JP1.1 is initialized by holding pin 5 low while releasing RESET.
• JP1.2 is initialized by holding pin 4 low while releasing RESET.
• JP1.3 is initialized in the same way as JP1.2.
• JP1.4 and JP2 involve precise timing in the initialization routine.

At least two of the four have special modes that must be avoided:

• JP1.2 is switched into BKGD mode if pin 5 is low when RESET is released.
• JP1.3 is switched into TOOL mode whenever pin 5 is high.

Our interface designs have evolved as we learned about the JP1.x remotes one by one:

March 2006 - The first interface design for JP1.2 only was released. It used two mechanical switches (RESET and Rx) for manually initializing the remote. The DTR handshake signal was used to provide pull-up voltage for Rx, and the RTS signal was not used.

April 2006 - The first "switchless" interface design was released, still for JP1.2 only. We used the RTS signal to control a third transistor that eliminated the manual RESET switch, and the other switch was found unnecessary because Rx could be driven low with software. That used up all the available outgoing handshake signals of the serial port.

May 2006 - The first JP1.x interface design was released, for JP1.1 as well as JP1.2. We changed the way the RTS signal was used. Instead of controlling RESET, it was used to control a fourth transistor for holding pin 5 low in order to initialize JP1.1. That meant we needed a new method for controlling RESET. Since the DTR signal did not have to be held high ALL the time, just while receiving data, we added a circuit that generated a momentary reset pulse whenever we switched DTR from low to high.

June 2006 - The discrete transistor interface design was upgraded with a few circuit improvements, and was still a viable interface for the three current types of JP1.x remotes. Many "JP1.2-only" variations of this design have been built by omitting three components. Since then a number of iterations of the JP1.x interface design have been released that use various integrated circuits for improving reliability and reducing cost, but the fundamental principals of operation and the method of using DTR and RTS handshake signals to initialize remotes has not changed.

November 2007 - We learned about the TOOL mode in JP1.3, and suggested it be avoided by either (1) making sure the interface can't put any signal voltage on pin 5, or (2) making pin 5 inaccessible by bending it over or cutting it off inside the remote.

August 2011 - We began to put together the JP1.4/JP2 protocol from access to an EasyLoader.

IR.exe has a crude but simple way of dealing with the fact that it never knows which type of JP1.x remote it is talking to. First it executes the initialization sequence for JP1.2 to see if the remote will communicate. If that fails, it tries the sequence for JP1.1. If that fails it should mean the interface is not a working JP1.x. But we didn't know how many members had already built JP1.2 interfaces using the April 2006 design before we changed the method of reset. So to maintain backward compatibility with them, IR makes a final attempt at JP1.2 initialization using RTS to control RESET.

[mathdon]

Many thanks, Rob, for Tommy's document. It has clarified a lot for me, and helped me better understand the jp12serial code. I am on a steep learning curve with this, as the communication side of things is not one I have needed before to get involved with.

The situation in fact seems to be quite different from my preconceptions. The current jp12serial attempts to connect in five different ways in sequence. These, together with their assumptions about the use of pins 2 and 5 of the 6-pin connector, are

1. JP1.4/JP2 with pin 2 = RTS, pin 5 not connected.
2. JP1.3 with pin 2 = DTR, pin 5 = RTS set low throughout to avoid TOOL mode.
3. JP1.2 with pin 2 = DTR, pin 5 = RTS set high throughout to avoid BKGD mode.
4. JP1.1 with pin 2 = DTR, pin 5 = RTS, both used during the connection attempt.
5. JP1.2/JP1.3 with pin 2 = RTS, pin 5 not connected.

So not only does the code not know which interface type it is trying to connect to, it also doesn't know what interface ciruit it is using. The program runs through these in order, until it connects. The order is chosen to avoid harm to JP1.2 and JP1.3 remotes with interfaces that have pin 5 connected.

Tommy's document says "Since then a number of iterations of the JP1.x interface design have been released ... but the fundamental principles of operation and the method of using DTR and RTS handshake signals to initialize remotes has not changed." It implies that only the first switchless design had pin 2 = RTS, pin 5 not connected, with all subsequent design having pin 2 = DTR, pin 5 = RTS. With the coming of USB, however, this is no longer the case. As far as I can tell, all USB interface cables, from Tommy or elsewhere, have pin 2 = RTS and pin 5 not connected, so reverting in effect to the original design. With such interfaces, connection attempts 2, 3 and 4 all fail but do no harm so JP1.4 and higher connect on attempt 1, JP1.2 and JP1.3 on attempt 5.

For JP1.1, I will need to mimic the "new" design with pin 2 = DTR, pin 5 = RTS, but I suspect I will need to make some code changes (for this purpose, not permanent changes to jp12serial). It looks as if I will need to skip attempt 1 and will need to change the DTR code to mimic what Tommy's transistor interface does with it. I will not know until I try it whether it will work or not, but one way or another I really do want to get JP1.1 to be supported.

[The Robman]

Glad to see your accepting the challenge Graham. You could consider forcing JP1.1 users to actually select JP1.1 from the Remote > Interface menu, if it makes things easier for you.

Would any new code that you develop require the user to have a Tera Grand FTDI cable, or similar, or have you thought of a way to do it with just the connections available on a standard FTDI cable?

[3FG]

Rob,
I'm not sure if the Tera Grand is a suitable cable or not, because it is possible that it actually outputs +/-12V. Most cables of this sort only output 0V and 5V, because that's what USB supplies. But some especially more expensive ones have a typically Maxim chip that can boost the voltage to +/-12V.

Graham found a suitable board that we can be sure has the desired output voltage, although one with a FTDI chip would be even better.

http://hifi-remote.com/forums/viewtopic ... 892#142892

[mathdon]

You could consider forcing JP1.1 users to actually select JP1.1 from the Remote > Interface menu, if it makes things easier for you.

Yes, that may well be necessary.

Would any new code that you develop require the user to have a Tera Grand FTDI cable, or similar, or have you thought of a way to do it with just the connections available on a standard FTDI cable?

I am still convinced that it is not possible to connect to a JP1.1 remote with a standard FTDI cable. My hope, however, is that the board I identified (see 3FG's post) will be all that is required, other than patch cables to connect it to the remote. That is not significantly different from the need to buy an adapter to connect to a JP1 remote, so would be a perfectly acceptable solution as far as I am concerned.

one with a FTDI chip would be even better

I know, but I could not find one. If you can, I am happy to buy and test with that as well.

This sentence in Tommy's document had me worried for a time: "Since the DTR signal did not have to be held high ALL the time, just while receiving data, we added a circuit that generated a momentary reset pulse whenever we switched DTR from low to high". I presume that the serial interfaces in PCs at that time did a proper implementation of the DTR (Data Terminal Ready) signal, so that data could not be exchanged unless DTR was high (=set). The RESET pin (pin 2) of the remotes required only a pulse, so Tommy devised this circuit that created a pulse on a state transition of the DTR pin.

I could see no way to do something similar with any available ready-built board. My hope, however, was that since most USB to Serial boards do not expose the DTR line, they also do not implement its original functionality. In that case there would be no need to maintain DTR set during the data exchange, enabling it just to be pulsed as required by the jp12serial software. I have now confirmed this with Tommy's cable, and so presumably with any FTDI cable, by clearing DTR in the software before communication with the remote (JP1.2, in this test) is initiated. Although Tommy's cable does not expose DTR, this will send the CLRDTR signal to the FTDI chip and the chip itself has a DTR output pin even though the cable does not expose it. This is enough to convince me that the FTDI chip, at least, does not implement DTR functionality but just leaves it as a signal for users to use as they wish. I see no reason to doubt that the chip in the board I have identified will do the same, though only time will tell.

[mathdon]

I have finally found an FTDI do-everything cable, from FTDI itself . Not sure how I missed it in previous searches. It is like the Chip Partner cable, but with 10 free ends rather than 6, so with all possible signals exposed. As FTDI is in the UK, I will get it quickly, too, well before the board from the US arrives.

[The Robman]

Good find, but damn that's pricey, I also tried checking ebay to see if there are cheap ones available from China but no luck.