JP1 Remotes

Capn Trips wrote:Uhhh, I've pretty much learned that you really have to read stuff carefully in this JP1 world, UQ....

johnsfine wrote:I hoped to find time to do the important test of learning this Streamzap upgrade from one JP1 remote to another to see if KM is computing everything right. I haven't had time yet.

But just looking at what KM is doing and making my best guess at what it would send, I think KM is getting the fixed data wrong.

I think adding 192 to the device number would correct the fixed data. Use 226 instead of 34 for device and get 1D instead of DD for the fixed data.

You ALSO want to keep that frequency change (don't recopy the protocol from KM to IR). Girder can't see the frequency, but the actual device can.

You also should test each key twice in a row. Real Streamzap protocol alternates between two different signals for each key. If your device expects that, the streamzap upgrade should get that right and the learned signals shouldn't. If your device doesn't expect that, only every other keypress will be right (we'll need to tweak the upgrade some more after finding that).

I can't see the pattern in Girder's numbers. I expect Girder doesn't know how 1's and 0's are encoded in this protocol and I failed to deduce what aspect of the signal it is decoding as 1's and 0's.

I would expect Girder to see a difference in the alternating signals.

Edit: I just remembered that we already know the original remote does alternate (as a normal Streamzap remote would). That is shown by the T=0 and T=1 alternating in the sequence of learned signals you posted.

I think adding 192 to the device number would correct the fixed data. Use 226 instead of 34 for device and get 1D instead of DD for the fixed data.

You ALSO want to keep that frequency change