JP1 Remotes

Tommy Tyler · Posted: Fri Dec 17, 2010 10:57 am Post subject: NEW JP1.4 (OARI06G) REMOTE

Rob provided me with a sample of this remote to see what could be learned. I've posted a complete report HERE . This new model continues to elude all our attempts to program it or communicate with it, and this is a call for help and ideas.

Tommy

Thomas · Joined: 16 Feb 2008 Posts: 87

Hmmm, 26 bucks from Amazon.

I would suppose you have tried holding down various buttons/combinations while sending JP1.3 'program' command? Any new 9xx setup possibilities?

Gonna have to grab the CC and contact Amazon........
_________________
Tom Carlson

mdavej · Expert Joined: 08 Oct 2003 Posts: 4501

HERE's the manual.

3FG · Expert Joined: 19 May 2009 Posts: 3367

Don't know what you've tried, so here is the way I would go after it.

I'd try to get the remote to send some data without needing to send data to it. If that can be done, then we would know the characteristics of the serial signal (most likely 115Kbaud "RS-232" or I2C). It may also be possible to get a flavor of the messaging scheme.

There has to be a reason why the interface has been changed. It could be simply that UEI wishes to confound people like us. More likely, UEI wants to improve the interface, probably by making it faster and perhaps making communication semi-automatic when a cable is attached.

For example, UEI may want to load new firmware at the manufacturing line. Perhaps they have a download/diagnostic station set up that will take a new remote (no batteries) and power the remote through the 6 pin header, and then download to the remote. This could be done automatically as soon as the cable is attached, if the wakeup sequence of the micro sends a wakeup string. Once the station receives a valid wakeup string, it could start the download. Probably at the end of the download, the remote will need to send a check sum or other confirmatory message, and perhaps it does that as part of a reset sequence.

Or possibly the station pulls one of the pins away from quiescent as a signal to the remote, which then can send an acknowledgement mesage.

Assuming that it is practical to look at the 6 pin header with an oscilliscope, try a 981 reset while looking at each pin except ground (or Vcc, if it is directly connected to the battery). Similarily, watch for a signal when reconnecting the batteries. Or look for a signal after pulling non-ground/power pins to a different level.

pH7_jp1 · Posted: Sat Dec 18, 2010 8:47 am Post subject:

I noticed one thing reading the manual that would be a problem for me. UEI designs all its remotes to be "device" controllers. Using JP1 tools, I always set mine up to be "activity" based. That is, one press of the button labeled DVD does all the commands for watching the DVD player.

This remote does not have separate buttons, just a left and right arrow to switch device in a circular fashion. Toggling through as many as 3 "activities" would mean devices turning on and off all over the place, plus delays to allow all the macros to complete.

As beautiful as this remote is, I can't see it would meet my needs, even if we get our software working with it.

andyross · Joined: 13 Jun 2004 Posts: 261 Location: Aurora, IL

Could it be USB-based instead of normal serial?

xnappo · Expert Joined: 30 Dec 2003 Posts: 861

Before a lot of time is spent on this - are we sure that this isn't a one off and JP2 is what UEI is moving to?

http://www.hifi-remote.com/forums/viewtopic.php?t=12356&highlight=

As far as USB goes, some microcontroller companies (*cough*) are offering USB for very little cost difference. Samsung does not seem to being doing that with the S3 line though. Even putting cost aside, the software overhead of a USB stack is overkill for this application UNLESS UEI was going to let end-users use it. I wouldn't totally write off the idea, but I think it is unlikely.

It is possible that they did something mean like require a 64-bit sequence to be sent before communication can be established...

xnappo

Kevin Timmerman · Posted: Sat Dec 18, 2010 9:33 am Post subject:

cauer29 · Joined: 03 Feb 2010 Posts: 236

Once upon a time, reverse-engineering electronics was my day job. You may find it more fruitful to employ a little social engineering, to advance understanding of how this remote works. I'm sure that there are folks on this forum with contacts inside UEI. Failing that, given access to facilities to remove the epoxy blob, leaving the circuit in tact, you may be able to learn more.

There is a technique that has been used very effectively to figure out the protocols for communicating with automotive on-board computer systems and that is to install some monitoring circuitry inside the car (remote in this case) that records what happens on the interface, while it's being serviced. In this case "service" would be sending the remote in for upgrade. That is, assuming that you get back the same remote that you send in. I didn't miss the comments about it being impossible to disassemble the remote without damaging it. So, perhaps this method isn't possible.

A.A.

The Robman · Posted: Sat Dec 18, 2010 12:14 pm Post subject:

Kevin Timmerman · Posted: Sat Dec 18, 2010 12:29 pm Post subject:

Yes, but for SAM8 chips not PIC.

ICSP (In Circuit Serial Programming) is a (chip) manufacturer specific protocol. It may be based on some standard like IIC, SPI, or JTAG, but will use a proprietary command set.

The protocol used by JP1.1/1.2/1.3 is a user (UEIC) specific protocol.

MikeT · Joined: 28 Oct 2010 Posts: 115

With the following SAM8 capable flash programmers, it should be possible to reprogram the flash of the SAMSUNG S3F80K MCU:

Does anyone have access to one of these?

Using these programmers, the protocol can be reverse engineered. It must be the standard SAMSUNG SAM8 serial protocol format and not a One-For-All specific protocol because the code in the MCU is not running when the TEST pin is set to 1.

There is a very little chance, that the read-protect switch is not set.

Michael