JP1 Remotes

hate to butt into your beautiful hijack attempt, but i got some more interesting information.

after unsuccessfully making several sling bins using custom code 0140, i decided to ask my R&D team to directly read the codes into an existing set-top-box using the debugging output. here are the raw results:

KEY VALUE : fc031004 (Button "3")
KEY VALUE : fb041004 (Button "4")
KEY VALUE : fa051004 (Button "5")
KEY VALUE : f9061004 (Button "6")

it does appear the information i got from the RCU supplier might be incorrect or reversed in some manner. as you can see from the output, the bits should be read in reverse (LSB?). the last 2 bits are the custom code. the third bit from right to left is the key code.

should the custom code be: 04 10? also, can the exact protocol name be identified with the output sample given?
thanks.

gosu wrote: should the custom code be: 04 10?
thanks.

I think that would be 04:16 (decimal from Hex)

It certainly looks like it from those examples, doesn't it ?

Incidentally, the last byte (right to left) seems to be a complement of the command code (FF - code)

gosu wrote:after unsuccessfully making several sling bins using custom code 0140,

What did you try as protocol, device and subdevice? Did you try NEC1, 1 and 64 as we suggested?

gosu wrote:i decided to ask my R&D team to directly read the codes into an existing set-top-box using the debugging output. here are the raw results:

KEY VALUE : fc031004 (Button "3")
KEY VALUE : fb041004 (Button "4")
KEY VALUE : fa051004 (Button "5")
KEY VALUE : f9061004 (Button "6")

Unfortunately, we know even less about that "raw" format than about the manufacturer's documentation, regarding the key question of the relationship between the bit sequence transmitted and the bit sequence displayed.

In NEC protocol, each byte is transmitted LSB first, and the four bytes are in sequence: Device, Subdevice, Function, Check.

If it is really NEC protocol, we can clearly see that your "raw" format has the 4'th byte (FC) on the left, and the 3'rd byte (03) second from the left.

That leads me to guess that your raw format has all 32 bits in simple sequence from right to left. If that is true then the Device number is 4 and the subdevice is 16.

TEST THAT.

gosu wrote:it does appear the information i got from the RCU supplier might be incorrect or reversed in some manner. as you can see from the output, the bits should be read in reverse (LSB?). the last 2 bits are the custom code. the third bit from right to left is the key code.

Something is seriously reversed. But we don't yet see enough to know what.

If the above guess isn't right, you could try sending some known NEC signal to your raw capture system and see what the bit sequence is. Do you have any universal remote handy that includes the standard Toshiba TV code set? That's easy to recognise even under unknown bit sequence.

gosu wrote: should the custom code be: 04 10?

That is my current best guess: Device 4, Subdevice 16. Though I can't guess why they would document that as 0140.

gosu wrote:can the exact protocol name be identified with the output sample given?

No, but the difference between NEC1 and NEC2 would be pretty subtle in slingbox usage. If you got that choice wrong, it would probably work anyway. If it fails due to that choice wrong, it would probably partially work in a way we would recognise as having NEC1 vs. NEC2 wrong.

johnsfine wrote: What did you try as protocol, device and subdevice? Did you try NEC1, 1 and 64 as we suggested?

I tried the following combinations:
Protocol: NEC1
Device / Subdevice: 1/64

Protocol NEC2
Device / Subdevice 1/64

johnsfine wrote: That leads me to guess that your raw format has all 32 bits in simple sequence from right to left. If that is true then the Device number is 4 and the subdevice is 16.

TEST THAT.

OK. I will do so and report back.

gosu wrote: Protocol NEC3

Capn Trips wrote:

gosu wrote: Protocol NEC3

fixed