JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Support for OneForAll URC-7962 Smart Control Motion
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
MikeT



Joined: 28 Oct 2010
Posts: 115

PostPosted: Mon Aug 27, 2012 4:45 pm    Post subject: Support for OneForAll URC-7962 Smart Control Motion Reply with quote

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:
Code:
E114501
URC 11-7962 R00
MAXQ612X-2049+ E


A bit deeper in the battery compartment, printed on the PCB:
Code:
SMART CONTROL
11-7962R00
12446 REV D
SEP 15, 2011
00-07630000-00
REV 2

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:
Code:
Starting normal download
Interface Name = JP1.X Serial
Port Name = NULL
Testing interface: JP1.X Serial
Interface matched.  Trying to open remote.
Opened
Interface opened successfully
Base address = $0
Interface type = 0
Read first -1 bytes: 00 00 00 00 00 00 00 00 00 00
Searching for RDF
Final signature sought = null

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
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

PostPosted: Mon Aug 27, 2012 4:55 pm    Post subject: Reply with quote

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

Michael
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3219

PostPosted: Mon Aug 27, 2012 5:14 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

PostPosted: Wed Aug 29, 2012 4:33 am    Post subject: Reply with quote

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:
Code:
ReadFile( hSerial, buffer, 10, &bytesRead, NULL );  //try to clear out spurious bytes seen with transistor based serial interface
// the above line will cause a delay of 50+10*10 mS = 150mS


Michael
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3219

PostPosted: Wed Aug 29, 2012 10:59 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

PostPosted: Wed Aug 29, 2012 4:24 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

PostPosted: Wed Aug 29, 2012 6:44 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3219

PostPosted: Wed Aug 29, 2012 11:57 pm    Post subject: Reply with quote

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:
Code:
Sent: 00 02 51 53  // request to enter programming mode
Rcvd: 00 02 00 02  // reply 00 02 bytes following this length specifier, error 0, XOR check sum
Sent: 00 02 50 52  // request signature block address
Rcvd: 00 08 00 03 15 00 00 C4  // expected 00 06 00 xx xx xx xx checkbyte.  03 15 is probably the remote type; the Atlas 1056B03 gives 02 14
Sent: 00 06 01 00 00 00 2C 2B  // incorrect request to read sign block
Rcvd: 4E 94 00 02 03 01//4E is last byte of C4 4E address, 94 is correct checksum 

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.
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

PostPosted: Thu Aug 30, 2012 3:01 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

PostPosted: Thu Aug 30, 2012 6:56 am    Post subject: Reply with quote

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


Last edited by MikeT on Thu Aug 30, 2012 4:57 pm; edited 1 time in total
Back to top
View user's profile Send private message
MikeT



Joined: 28 Oct 2010
Posts: 115

PostPosted: Thu Aug 30, 2012 6:58 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2825
Location: Cambridge, UK

PostPosted: Thu Aug 30, 2012 4:41 pm    Post subject: Reply with quote

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.
_________________
Graham
Back to top
View user's profile Send private message
mathdon
Expert


Joined: 22 Jul 2008
Posts: 2825
Location: Cambridge, UK

PostPosted: Sun Sep 23, 2012 9:52 am    Post subject: Reply with quote

Prototype support for the URC-7962 SmartControl Motion is now available in RM/RMIR v2.02 Beta 1.5v.
_________________
Graham
Back to top
View user's profile Send private message
deerewright



Joined: 30 May 2012
Posts: 23
Location: United States

PostPosted: Mon Apr 14, 2014 8:30 pm    Post subject: urc-7962 any updates? Reply with quote

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.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3219

PostPosted: Mon Apr 14, 2014 9:09 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central