Building a variant of the serial interface

[dirkt]

Hi!

I have an URC 7950 remote (JP 1.3 connector), and I would like to build a serial interface. I have already looked at the "BUILDING A SERIAL INTERFACE FOR JP1.2 AND JP1.3 (FLASH) REMOTES" document. However, there are two complications: The serial interface should also be useable for a Pioneer DV player (see schematics at http://www.pioneerfaq.info/english/dv41 ... ead_Player), and I'm using Linux, not Windows.

So, some questions:

1) What's the purpose of the three diodes in the JP1.2/JP1.3 schematics? If RTS or Tx goes negative, Q1 resp. Q2 should switch off no matter if the base is negative or at ground level. Rx shouldn't ever be negative, so D3 should never become active. Or should the diodes offer protection against plugging in one of the connectors incorrectly? But how?

2) From the document "A REFRESHER ON HOW JP1.x INTERFACES COMMUNICATE WITH THEIR REMOTES", I gather the RESET (remote pin 2) only needs to be pulled down once during initialization. Since the remote operates fine if no cable is connected, wouldn't it be enough use Q2 with open collector, leaving out R2 in the JP1.2/JP1.3 schematics?

3) So the plan so far is to basically use the schematics for the Pioneer cable, because it purposely doesn't make use of the 3V source on the non-PC side, and then add an extra driver for the RESET line with open collector (i.e. R4 and Q2 in the JP1.2/JP1.3 schematics). Any potential problems with that?

4) What's the exact protocol for the connection? I sort of understand how to do the initialization (any special meaning of the character 'E'?), but what kind of ACK signal should I be looking for? The repitition of 'E' on the Rx line? And if the initialization is successful, how do I communicate with the remote? The S3F80 docs don't mention a serial RS232-style interface, so I assume it is handled in firmware? Any documents I could read for that?

I probably could try using the offered software with Wine and pray that it works with the serial ports, but I would prefer to do the communication myself, if possible. Reading the MCU ROM would be enough for a start

Thanks in advance for any help,

- Dirk

[classicsat]

1. The diodes clamp negative voltages that may occur on the line, to protect the transistors and what the interface connects to.

2. I'd pull up Q2.

3. I'd build the Jp1.x interface, add the 3.3V zener diode per the Pioneer programmer schematics, and have two connector dongles. It is less "kludgy" than adding the reset line to the Pioneer design, IMO.

4. I cannot help you with that. I program my Jp1/Jp1.x remotes from a Windows PC with available apps.

[WagonMaster]

Welcome to the forums, Dirk! Always glad to see a fellow Linux user here!

4) What's the exact protocol for the connection? I sort of understand how to do the initialization (any special meaning of the character 'E'?), but what kind of ACK signal should I be looking for? The repitition of 'E' on the Rx line?

Putting the remote into serial communication mode for JP1.2/JP1.3 remotes is straightforward. Merely hold JP1 pin #p4 ('/Rx') low while releasing JP1 pin #p2 ('/Reset'). The current library/DLL software basically sets and holds the UART 'break' condition to drive JP1 pin #p4 low, then pulses (high then low) JP1 pin #p2, then releases the UART 'break' condition.

To confirm that the remote control has successfully entered serial communication mode, you send it a single character 'E' (think of it as a ping/'E'cho) and the remote should respond with a single ASCII 0x06 ('ACK') character. (This can be done repeatedly, although there is no reason to do so.)

In reality, there can be some "garbage" data in the read queue under some ill-defined circumstances, so the software currently flushes the read queue before sending the 'E' character. (But more on this below.)

And if the initialization is successful, how do I communicate with the remote? The S3F80 docs don't mention a serial RS232-style interface, so I assume it is handled in firmware? Any documents I could read for that?

There is a protocol that (as far as I know) is undocumented except by examining the 'jp12serial' library/DLL source code. It's not hard to fathom, but I cannot explain it all in this short post.

I probably could try using the offered software with Wine and pray that it works with the serial ports, but I would prefer to do the communication myself, if possible. Reading the MCU ROM would be enough for a start

Actually, the 'IR.exe' utility works fine under Linux+Wine. And since the 'Remote Master' (RM/RMIR) utilities run under Java, they run fine natively under Linux. However, there is a serious bug in the current 'jp12serial' library that will probably cause problems (unreliable or possibly non-existent communication with the remote control) if you run RMIR under Linux. See bullet point #p2 in my earlier post about this issue.

As for the hardware questions, I'm no hardware guru, but I've successfully built and tested all 3 of Tommy's currently supported interface designs for JP1.1/JP1.2/JP1.3 remote controls. With regard to that particular 3-transistor design you refer to, I've been meaning to play around with it a bit but I've had no time. I have a particular piece of hardware (an old Toshiba Satellite 2100CDT laptop) with an RS-232 port. Whenever I use that laptop with Tommy's 3-transistor interface design, it floods the serial line with thousands of characters of garbage data (usually mostly ASCII zero [0x00] data bytes) in such a manner that it prevents the 'E' ping/echo test from succeeding! It only happens with a JP1.2 remote (URC-8820 and URC-10820 to be specific) and never with a JP1.3 remote (Radio Shack 15-135 and RCA 'RCRP05B' to be specific). It also never happens when using Tommy's quad-XNOR interface design. It also never happens with any other PC I've tested with to date. And yet I use the RS-232 port on that PC with all sorts of other devices with no problems at all.

I've written an application of my own that proves (when running on that particular laptop) that the JP1.2 remotes succeed in the command to enter 'serial comm' mode. It's the current serial library code (used by 'IR.exe' and RMIR) that gets fooled into thinking the 'enter serial comm' process has failed because the current library code only flushes 20 bytes of data from the read queue before sending the 'E' ping/test command.

Hope this is somewhat helpful... Don't hesitate to holler if you need more.

Regards,
Bill

[dirkt]

Thanks for the info so far.

There is a protocol that (as far as I know) is undocumented except by examining the 'jp12serial' library/DLL source code. It's not hard to fathom, but I cannot explain it all in this short post.

Cool. Stupid question: Where can I find the source code? I don't find it very easy to navigate this site, the sticky threads help, but if there was some index or table of contents or some sort of wiki it'd probably be quicker to find. But very probably there is, and I haven't come across it yet...

have a particular piece of hardware (an old Toshiba Satellite 2100CDT laptop) with an RS-232 port. Whenever I use that laptop with Tommy's 3-transistor interface design, it floods the serial line with thousands of characters of garbage data (usually mostly ASCII zero [0x00] data bytes) in such a manner that it prevents the 'E' ping/echo test from succeeding!

Hm. Maybe the laptop has a different signal level? Did you measure the voltages (both the laptop and your other computer)? Depending on the transistors/resistors used, a different voltage input might cause an ambigous output level that might be read as "there's a signal" on the other side, while it's just garbage.

- Dirk

[WagonMaster]

Where can I find the source code?

Unfortunately, it's not made public at this point in time. That's one of the things (right after I discovered JP1 remotes and this forum) that I was dealing with (working towards making it public) when I got sidetracked by the nasty library bug, which in turn got me sidetracked writing new library code addressing a series of other issues/problems, which led to writing a test utility for that new code. Then I got sidetracked by the odd behavior of that particular combination of PC and JP1.x interface, which took some time to even characterize. Then I ran out of time.

have a particular piece of hardware (an old Toshiba Satellite 2100CDT laptop) with an RS-232 port. Whenever I use that laptop with Tommy's 3-transistor interface design, it floods the serial line with thousands of characters of garbage data (usually mostly ASCII zero [0x00] data bytes) in such a manner that it prevents the 'E' ping/echo test from succeeding!

Hm. Maybe the laptop has a different signal level? Did you measure the voltages (both the laptop and your other computer)? Depending on the transistors/resistors used, a different voltage input might cause an ambigous output level that might be read as "there's a signal" on the other side, while it's just garbage.

Thanks for the suggestion, Dirk. I actually did measure the voltage levels on the problematic hardware and found them lower than a desktop PC. But, from what I've read, that seems quite common on laptops. And, on my other newer laptop, I found similar lower voltage levels and that one (a Toshiba Tecra A8-EZ8412) works fine with the JP1.2 remotes and Tommy's 3-transistor interface. It's a mystery that I just haven't had time to investigate any further.

Bill

[Tommy Tyler]

What's the purpose of the three diodes in the JP1.2/JP1.3 schematics? If RTS or Tx goes negative, Q1 resp. Q2 should switch off no matter if the base is negative or at ground level.

The base-emitter junction of a transistor will zener avalanche when the base tries to go more than about 6V lower than the emitter (for an NPN transistor) and the breakdown can reportedly cause deterioration of gain over time.

Rx shouldn't ever be negative, so D3 should never become active.

D3 is to protect if DTR goes negative.

Since the remote operates fine if no cable is connected, wouldn't it be enough use Q2 with open collector, leaving out R2

The Q2 pullup helps minimize the effects of noise on the RESET line when the cable is connected.

So the plan so far is to basically use the schematics for the Pioneer cable, because it purposely doesn't make use of the 3V source on the non-PC side, and then add an extra driver for the RESET line with open collector (i.e. R4 and Q2 in the JP1.2/JP1.3 schematics). Any potential problems with that?

Should work fine if you add the R2 pullup to the remote's (and Pioneer's) 3.3V Vdd at pin 1. I don't see how that can harm or interfere with the DVD.

if the initialization is successful, how do I communicate with the remote? The S3F80 docs don't mention a serial RS232-style interface, so I assume it is handled in firmware?

That is correct. Once initialized, a remote will talk to anybody at 38400/N/8/1 using standard RS232 protocol.

[WagonMaster]

when I got sidetracked by the nasty library bug

This bug (and a couple other nasty ones) are now fixed.

I've just uploaded an improved version of the 'libjp12serial.so' library file. If you're still having problems (or even if you're not or are using some work-around but are willing to help test some of these issues), I'd like for you to download it and test it, please. Please see my post about how to use this new library file. Any feedback is very much appreciated!

Regards,
Bill