JP1 Remotes

Hi!

I bought a OneForAll Smart Control Motion URC-7962 remote. It almost looks identical to the URC-7960. The only visible differences from outside are:

• the color of the upper side of the URC-7962 is anthracite instead of black
  the OK button is silver
  the key below "menu" is labeled "www" instead of "pop op X"
  the buttons make a clicking noise
  some functions are controlled by motion gestures (like the Wii controller)

The official description can be found here.

In the battery compartment, there is a label with the following information: A bit deeper in the battery compartment, printed on the PCB: The 6-pin header is at the same place as in the URC-7960, but it has no label, not even the pin numbers.

The remote is not detected by RemoteMaster 2.02 Beta 1.5u. When I try to download from the remote, RemoteMaster hangs indefintely, like there is no RC connected.
When I start the upload of a URC-7960 configuration to the URC-7962, RemoteMaster complains, that the signature is wrong (which is correct) and I cancel the download.

A RAW download only contains 0x00 bytes, even after learning some codes.

In the rmmaster.error log, there are the following entries: The URC-7962 blinks twice, when the JP1.x cable is disconnected, like the URC-7960.

The only post about the URC-7962 model in the forum and files is from GeoffT, but I think he is actually referring to the URC-7960 "SmartControl PS3" instead of the URC-7962 "SmartControl Motion".

What can I do to make the URC-7962 supported?

Michael

The text in the battery compartment "MAXQ612X-2049+ E" probably refers to this microcontroller: MAXQ612-MAXQ622.pdf

Michael

The MaxQ processor comes in remotes that we call JP2 or JP2.1. The URC-7960 uses a Samsung processor and we refer to it as a JP1.4 remote.

I suppose that you are using a Mac; we have to date not tried communicating with a Mac to a JP2 remote. And I agree that we probably have no experience with a Smart Control Motion. So plausibly there is some aspect of JP12Serial that isn't playing correctly.

Can you get a serial sniffer to record the data transmission and receives from the remote? Then I can probably tell where things are going wrong.

3FG wrote:I suppose that you are using a Mac

Yes, but I also have Windows XP, Windows 7 and Windows 8 so it would be no problem to use one of these.

3FG wrote:The MaxQ processor comes in remotes that we call JP2 or JP2.1.
we have to date not tried communicating with a Mac to a JP2 remote.
Can you get a serial sniffer to record the data transmission and receives from the remote? Then I can probably tell where things are going wrong.

What is the difference between the JP1.4 and the JP2 interface? What kind of cable is needed?

For the JP1.4 I used a direct FTDI cable (no capacitor, no transistor) which connects the pins RX, TX, GND and DTR# (on IDC-2) at 3.3V signal level. Pin 5 and 1 are not connected.
Looking at the source code, I should have used RTS# on pin IDC-2 instead of DTR#, but with RTS# it doesn't work.

The problem I have is that the second ReadFile() in JP2_14StartOrStopComm() ( the one that reads real data) always returns bytesRead=0.

What is the sequence that is required to go into programming mode?
From the comment in the source code I can see that IDC-2 should be put low for 35ms. This assumes two things:
1. RTS is CLEARED and IDC-2 is high after opening the port and before jp2_14connect() is called
2. the voltage of RTS is 0 volt when RTS is SET and 3,3V when RTS is CLEARED.

The FTDI chip FT232R normally uses positive logic for TX and RX, but negative logic for the handshake lines. Therefore the pins are called DTR#, RTS#, etc. It can be programmed to use positive logic for the handshake lines as well, then it would match the expectation "2".

On Mac OS X, RTS# is 0 volt before opening the port, 3.3V after opening the port because DTR and RTS are automatically set when opening the port.

What I need is the expected behaviour of the voltage at the pins and which cable types it should work with.

For example the code assumes a capacitor attached to DTR which I haven't seen in the build instructions of the latest FTDI cable. As long as you don't connect pin 5, this doesn't matter. The Arduino reset logic uses such a capacitor, because they rely on the standard behaviour of the DTR signal, that a low-high of DTR transition causes a short low reset pulse at the capacitor, but this isn't recessary with when DTR and RTS can be directly controlled by a custom application or interface library like jp12serial.

The calculation about the delay caused by following read in JP2_14StartOrStopComm() is only correct on Win32: Michael

I'll be able to look at the actual voltages sent by my Tommy Tyler (FTDI) cable tonight. It is possible that the comments associated with the JP1.4/2 sections of the code are wrong: I wrote them. For what it is worth, I think some of the comments written for earlier versions of the interfaces are wrong.

In principle, JP1.4 and JP2 use the same interface and protocol, but in reality JP2 has a more stringent timing requirement. The required voltages are the same.

I think it would be a good idea to try using a Windows based computer to verify that the interface/remote combination are working in the same way as Tommy's interface does with other JP2 remotes. I also think it is desirable to use a RS232 sniffer with the Mac so that we can see the actual timing.

3FG wrote:I also think it is desirable to use a RS232 sniffer with the Mac so that we can see the actual timing.

I haven't found a sniffer for the Mac, so I added tracing to the lib itself. Here the current output:
================================================================================
Trace start time: 2012-08-29T23:20:47.778
000000ms EscComm [jp12Init:794] rc=1 fct=SETDTR# (3.3V)
000000ms EscComm [jp12Init:795] rc=1 fct=SETRTS# (3.3V)
000050ms EscComm [jp2_14Connect:882] rc=1 fct=CLRRTS# (0 V)
000086ms EscComm [jp2_14Connect:885] rc=1 fct=SETRTS# (3.3 V)
000122ms Write [JP2_14StartOrStopComm:859] rc=1 bytesWritten=4 len=4 data=00 02 51 53
000125ms Read [JP2_14StartOrStopComm:867] rc=1 bytesRead=4 len=4 data=00 02 00 02
000125ms Write [jp2_14GetInfoAndSig:1059] rc=1 bytesWritten=4 len=4 data=00 02 50 52
000131ms Read [jp2_14GetInfoAndSig:1062] rc=1 bytesRead=8 len=8 data=00 08 00 03 15 00 00 c4
000131ms Write [jp2_14GetInfoAndSig:1067] rc=1 bytesWritten=8 len=8 data=00 06 01 00 00 00 2c 2b
002147ms Read [jp2_14GetInfoAndSig:1070] rc=0 bytesRead=6 len=48 data=4e 94 00 02 03 01
002148ms EscComm [jp13Connect:899] rc=1 fct=CLRRTS#
002149ms EscComm [jp13Connect:901] rc=1 fct=CLRBREAK
002249ms EscComm [jp13Connect:905] rc=1 fct=SETDTR#
002261ms EscComm [jp13Connect:908] rc=1 fct=SETBREAK
002263ms EscComm [jp13Connect:912] rc=1 fct=CLRDTR#
002364ms EscComm [jp13Connect:916] rc=1 fct=CLRBREAK
004378ms Read [jp12Test:969] rc=0 bytesRead=0 len=20 data=
004378ms EscComm [jp12Connect:820] rc=1 fct=SETRTS#
004379ms EscComm [jp12Connect:822] rc=1 fct=CLRBREAK
004481ms EscComm [jp12Connect:826] rc=1 fct=SETDTR#
004493ms EscComm [jp12Connect:829] rc=1 fct=SETBREAK
004494ms EscComm [jp12Connect:832] rc=1 fct=CLRDTR#
004595ms EscComm [jp12Connect:836] rc=1 fct=CLRBREAK
006913ms Read [jp12Test:969] rc=1 bytesRead=20 len=20 data=00 02 05 07 00 07 00 03 00 03 00 03 00 03 00 07 00 03 00 03
006913ms Write [jp12Test:974] rc=1 bytesWritten=1 len=1 data=45
006914ms Read [jp12Test:978] rc=1 bytesRead=1 len=1 data=00
006915ms EscComm [jp11Connect:927] rc=1 fct=SETDTR#
006927ms EscComm [jp11Connect:930] rc=1 fct=CLRRTS#
006928ms EscComm [jp11Connect:932] rc=1 fct=CLRDTR#
006954ms EscComm [jp11Connect:935] rc=1 fct=SETRTS#
009336ms Read [jp12Test:969] rc=1 bytesRead=20 len=20 data=00 03 00 07 00 03 00 03 00 03 00 07 00 07 00 07 00 03 00 07
009336ms Write [jp12Test:974] rc=1 bytesWritten=1 len=1 data=45
009337ms Read [jp12Test:978] rc=1 bytesRead=1 len=1 data=00
009338ms EscComm [jp12OriginalConnect:946] rc=1 fct=SETBREAK
009339ms EscComm [jp12OriginalConnect:948] rc=1 fct=CLRRTS#
009350ms EscComm [jp12OriginalConnect:951] rc=1 fct=SETRTS#
009451ms EscComm [jp12OriginalConnect:954] rc=1 fct=CLRBREAK
011732ms Read [jp12Test:969] rc=1 bytesRead=20 len=20 data=00 03 00 07 00 07 00 03 00 03 00 03 00 03 00 07 00 03 00 03
011732ms Write [jp12Test:974] rc=1 bytesWritten=1 len=1 data=45
011733ms Read [jp12Test:978] rc=1 bytesRead=1 len=1 data=00

The "#" postfix in EscComm calls like "SETRTS#" means "CLRRTS" has been called, but because the handshake lines are negated it has been automatically translated to "SETRTS".
'rc' is the return-code of the function.

3FG wrote:I think it would be a good idea to try using a Windows based computer to verify that the interface/remote combination are working in the same way as Tommy's interface does with other JP2 remotes. I also think it is desirable to use a RS232 sniffer with the Mac so that we can see the actual timing.

I will do this as next step.

Michael

On Windows 7 x64 I have exactly the same result as under Mac OSX (using the same source with inverted RTS/DTR).

I could not use the original binary DLL from the files section, because it is a 32 Bit DLL and my development machines are all 64 Bit, so I had to build it myself.

Michael

Well, let's take care of the simple stuff first. Using Tommy Tyler's flash interface, IDC pin 2 is normally high, even with the COM port not open. Sending SetRTS causes pin 2 to go to low voltage.

I think this is expected behavior for FTDI chips. The RS-232 "standard" calls for the RTS signal to be positive when it is set. But FTDI provides inverted RTS, and RTS# should go low by design when RTS is set. This seems to be opposite to your understanding, but I think (at least for the Windows computers) that the existing JP12Serial code should work as written.

The more complicated issue is that you seem to have a JP3 remote. It is using (apparently) the MAXQ612 processor, while the other JP2 remotes we have seen use the MAXQ610. The most obvious difference is 128K versus 64K of flash, and that may be the problem. From the serial log you recorded:
We expect a reply of 8 bytes, including the length, but the remote is sending 10 bytes, probably because two bytes aren't enough to describe a 128K address. So JP12Serial gets the wrong address and things go downhill from there.

I'd like to take this to direct email to discuss the next steps.

3FG wrote:Well, let's take care of the simple stuff first. Using Tommy Tyler's flash interface, IDC pin 2 is normally high, even with the COM port not open. Sending SetRTS causes pin 2 to go to low voltage.

The confusion with the inversion was my fault. The FTDI chip I was using was not in the default configuration. It was configured to invert the handshake lines.

3FG wrote:We expect a reply of 8 bytes, including the length, but the remote is sending 10 bytes

That was the hint I was missing. After adapting the code, I was able to read the whole 48 bytes:
Trace start time: 2012-08-30T09:56:13.168
000000ms EscComm [jp12Init:795] rc=1 fct=CLRDTR
000000ms EscComm [jp12Init:796] rc=1 fct=CLRRTS
000051ms EscComm [jp2_14Connect:883] rc=1 fct=SETRTS
000089ms EscComm [jp2_14Connect:886] rc=1 fct=CLRRTS
000125ms Write [JP2_14StartOrStopComm:860] rc=1 bytesWritten=4 len=4 data=00 02 51 53
000129ms Read [JP2_14StartOrStopComm:868] rc=1 bytesRead=4 len=4 data=00 02 00 02
000129ms Write [jp2_14GetInfoAndSig:1060] rc=1 bytesWritten=4 len=4 data=00 02 50 52
000133ms Read [jp2_14GetInfoAndSig:1063] rc=1 bytesRead=8 len=8 data=00 08 00 03 15 00 00 c4
003733ms Read [jp2_14GetInfoAndSig:1069] rc=1 bytesRead=2 len=2 data=4e 94
007821ms Write [jp2_14GetInfoAndSig:1079] rc=1 bytesWritten=10 len=10 data=00 08 01 00 00 c4 4e 00 2c af
010280ms Read [jp2_14GetInfoAndSig:1093] rc=1 bytesRead=48 len=48 data=00 2e 00 32 30 34 39 30 37 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00 00 0a 00 00 00 c4 4d 00 00 c4 86 00 01 db ff 00 01 c3
041377ms Write [JP2_14StartOrStopComm:863] rc=1 bytesWritten=4 len=4 data=00 02 52 50
041382ms Read [JP2_14StartOrStopComm:868] rc=1 bytesRead=4 len=4 data=00 02 00 02

Michael

Comparing what I get back from URC-7960 and URC-7962 it should be possible to adapt the further code. Some sizes and addresses are now 32 bits instead of 16 bit. I don't know anything about the memory map, so maybe you can help.
Each line begins with the decimal offset. For the URC-7962, I have read some more bytes because the table is be a bit longer.

URC-7960
========
0: 00 2e
2: 00
3: 33 32 32 34 30 33 42 56 20 4f 46 41 20 49 6e 66 20 20 20 20 20 20 20 20 20 20 // Signature "322403BV OFA Inf "
29: 05 00
31: 4b 7f
33: 4b 80
35: df ff
37: e0 00 EEPROM Begin
39: ef ff EEPROM End
41: ff ff ff ff
45: ff ff
47: 1d // Checksum


URC-7962
========
0: 01 2e // len
2: 00
3: 32 30 34 39 30 37 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 Signature "204907 "
29: 00 00 0a 00
33: 00 00 c4 4d
37: 00 00 c4 86
41: 00 01 db ff
45: 00 01 dc 00 // EEPROM Begin
49: 00 01 ff ff // EEPROM End (128kb - 1)
53: 02 00 ff ff ff ff 62 4c 66 11 6a fc 6f e6 6f eb 70 50 70 b4 72 e4 70 be fc f8 f4 f0 ec e8 e4 e0 dc d8 64 f4 74 b4 34 d4 54 94 14 e4 9b 0b 8b 4b cb 2b ab 6b eb 1b cf 3f df 5f 9f 1f ef 6f af 2f 90 00 80 40 c0 20 a0 60 e0 10 ff 7f bf 3f df 5f 9f 1f ef 6f 00 01 02 03 04 05 06 07 08 09 1d 00 59 00 69 00 79 00 1c 00 2c 00 3c 00 4c 00 5c 00 6c 00 0c 02 03 04 05 06 07 08 09 0a e2 fe ee de fc ec dc fa ea da 00 80 40 c0 20 a0 60 e0 10 90 2a 04 0a 0c 12 14 1a 1c 22 24 77 df 5f 9f ef 6f af cf 4f 8f 00 00 01 00 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09 00 15 02 05 06 09 0a 0d 0e 11 12 1d 59 69 79 1c 2c 3c 4c 5c 6c 31 11 33 38 33 11 33 18 33 81 33 88 33 c1 33 c8 31 31 31 38 1e b6 36 cc 8e 0e ec ae 2e dc 8f 3f bf 7f 1f 9f 5f 2f af 6f f7 77 b7 37 d7 57
c3 // Checksum

Michael

mathdon wrote:Could there be two different remotes called URC-7962? See this post which refers to a URC-7962 that works with RMIR and has the same signature as the URC-7960.

It's possible. See also my first post in this thread: The only post about the URC-7962 model in the forum and files is from GeoffT, but I think he is actually referring to the URC-7960 "SmartControl PS3" instead of the URC-7962 "SmartControl Motion".

Michael

Michael, you must have been quick off the mark! I deleted the post that you have quoted from within a few minutes of posting it, as I then spotted your first post in the thread in which you explained that there were two remotes apparently both called URC-7962. GeoffT must have got that number from somewhere.

Prototype support for the URC-7962 SmartControl Motion is now available in RM/RMIR v2.02 Beta 1.5v.

I have searched all over and have tried getting remote master to work with the urc-7962, but I keep getting "No Remotes Found".

Is there a way to get this to work? I am tying to install on Vista 64bit.

If it will work, is there a step by step I can follow?

I have updated my 7960, but cant seem to get this to work. I am using a usb /jp1.2/1.3 cable from diygadgets.

The URC-7962 is a JP2 remote which uses a MAXQ612 processor. DIYgadget interface cables, and apparently other cables based on the Prolific chipset, do not work with MAXQ processors. We aren't sure why they don't work (typically they can write to the remote, but not accurately read from the remote), but there is some indication that the Prolific chipsets don't handle 2 stop bits correctly.

Get a FTDI based cable. Here's a cable with a convenient form factor. You can also buy cheaper ones that either require individually attaching each wire or doing some light assembly work.