JP1 Remotes

[mathdon]

I have been puzzling over the Sejin NightHawk learned signals for some time. The bottom 6 rows on Rob's spreadsheet decode, but very strangely, with my Sejin addition to DecodeIR. The first clue as to what is going on came from Rob's notes on the UEI 0161 protocol, where I saw a mention of it producing two styles of signal. Sure enough, the bottom 6 rows of the spreadsheet correspond to a different signal style than the other rows.

The conclusive evidence for this isn't actually in the spreadsheet, it is in the raw timings that IR shows up. The leadout time is far shorter for four of these signals than for all the others, down by a factor of 20. The alternate signal style in 0161 does use an alternate leadout, down by this factor of 20. The two other strange signals in fact have a third leadout time that UEI hasn't bothered to handle, but otherwise they fit the alternate profile.

I've studied what UEI does with this alternate signal style, combining that with the examples we have from the Sejin NightHawk signals, and light has finally dawned. I've called the normal style Sejin-1 and this unusual style Sejin-2 (which I think is the other way round from Rob's notes). Both styles have a common structure with two frequency variants:

Sejin-M-38 {38.8k,310,msb}<-1|1>(<8:4|4:4|2:4|1:4>(3,3:2,Dx:8,Fx:8,Fy:8,E:4,C:4,-L))+
Sejin-M-56 {56.3k,310,msb}<-1|1>(<8:4|4:4|2:4|1:4>(3,3:2,Dx:8,Fx:8,Fy:8,E:4,C:4,-L))+

where E is a checksum seed (0 in all known examples) and C is the checksum given by

C = (Dx:4 + Dx:4:4 + Fx:4 + Fx:4:4 + Fy:4 + Fy:4:4 + E) & 15.

The styles differ in the interpretation of the signal parameters Dx, Fx and Fy. Dx should be considered as an 8-bit signed integer, ie range -128 to +127. If Dx >= 0 the style is Sejin-1 and the leadout time L is 77m. This style is used for normal remote-control buttons. If Dx < 0 the style is Sejin-2 and the leadout time L is the much shorter 3.6m. This style is used for signals corresponding to a pointing device with up to 3 buttons. The short leadout allows for much faster repeat action.

The data parameters in Sejin-1 are 7-bit device and subdevice codes D and S, an 8-bit function code F and a toggle bit T. The signal repeats as long as the key is held, with T=0 for all frames except the last, T=1 for the last frame. The corresponding signal parameters are:

Dx = D, Fx:1:7 = T, Fx:7 = S, Fy = F.

Sejin-2 has a 5-bit device code D and no subdevice code. It further divides into two sub-styles, 2A corresponding to movement of the pointing device, and 2B corresponding to movement of its buttons. In Sejin-2A the data parameters are the coordinates (X,Y) of the displacement of a cursor and the signal parameters are:

Dx:6:2 = (-D):6, Dx:2 = 0, Fx = X:8, Fy = Y:8.

Note that X and Y can be negative, so Fx and Fy are signed 8-bit integers. The signal repeats indefinitely.

Sejin-2B corresponds to down and up movements of the buttons of the pointing device. A "down" signal is sent exactly once on button down (distinct for each button) and an "up" signal is sent exactly once on button up (same for each button). There is one data parameter, B. When B = 1, 2 or 3 it denotes button B down, when B = 0 it denotes button up. The signal parameters are:

Dx:6:2 = (-D):6, Dx:2 = B:2, Fx = 0, Fy = 0.

There are two differences, one of which may not be real, between the behavior of the UEI executor and the signal samples we have. The definitely real one is that Sejin-2B should have an extra-long leadout of 130m rather than the extra-short one of 3.6m, but presumably the UEI executor works anyway. The other is that the UEI Sejin-1 style always has a toggle that is 0 until the last frame, when it is 1. We have seen this toggle in the ADB signals in this thread but not in the Sejin NightHawk or Telefonica signals. Either they didn't get learned or they don't do any harm if they are not required, because again I presume the UEI executor works for these cases.

The UEI 0161 Rob has studied is present in RM as 0161:5. It can generate Sejin-1 and Sejin-2 signals in a common upgrade, but only Sejin-2 signals in which either Fx or Fy is zero (which is the case in the NightHawk learnings). For Sejin-2 it uses (-D)*4 as a device byte and has two function bytes. The first is the nonzero one of Fx and Fy (or 0 if both are 0). The second has B in bits 0 and 1 (0 for Sejin-2A), bit 4 is set for Sejin-2A and clear for Sejin-2B and bit 3 flags which of X or Y is nonzero in Sejin-2A (set for X, clear for Y).

I have put together two "front ends" for the existing 0161:3 and 0161:5 protocols in RM. You can find it in a file called Sejin.ini which you need to paste to the end of protocols.ini. The 0161:3 front end is called Sejin-1-N and can only generate Sejin-1 signals. The 0161:5 front end is called Sejin-M-N and can generate both styles in the same upgrade. The choice of Sejin-1 or Sejin-2 is made separately for each signal on the Function page. For Sejin-2 the Misc field in the DecodeIR output includes a 13-byte integer RMOBC which you enter into the column of the same name on the Function page. It is the two-byte function code in decimal form. For Sejin-1, RMOBC is just the usual OBC, the second function byte being 0.

I've put this new Sejin interpretation into DecodeIR and the output for the Sejin NightHawk signals is now

[The Robman]

Wow, that's some heavy duty diagnosis Graham. I'll have to re-read it with my spreadsheet open and the PB file up.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[mathdon]

I realise I said a silly thing about the leadout in Sejin-2B. I said UEI gave it a leadout of 3.6m when it should be 130m. But the Sejin-2B frames are sent exactly once, so the leadout in the executor is irrelevant. The OFF lasts until the next signal is sent! I presume the 130m that the Learned Signals raw timings show is simply the longest time that IR.exe can record.
_______________
Graham

[The Robman]

[The Robman]

Just FYI, here are some learns where the E variable is 1 (rather than the 0 we've seen so far):
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7877
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[The Robman]

Did anybody every develop a protocols.ini entry for this Sejin protocol?

This is another example (like the XMP protocol) where the official UEI version uses 2 variable bytes, so when it's not present in the remote we should use our own 1-byte version.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[mathdon]

[polsat]

Hi all,

I've read this thread and tried to understand what has been discussed.. but I think I'm failing miserably.

What I need is to generate Pronto Hex codes for the Sejin-M-38 protocol.. I've tried creating a Sejin.irp file to use with MakeHex, since this doesn't seem to exist already.

My attempt looks like this:

[The Robman]

Due to the structure of this signal, I don't know how you'd represent it using IRP in such a way that MakeHex would understand, but if you look at the first post in this thread, you'll see there's a zip file that contains IR files that have samples of this protocol in both Sejin-1-38 and Sejin-1-56 formats.

If you open the IR files using IR.exe, you can "edit" the learns and then select "Pronto" to get the code in Pronto hex format.

Here are two samples of the "number 1" button.

Sejin-1-38 dev 16 obc 89
0000 006B 0000 0011 0025 0023 0019 0030 000C 0018 000C 0024 000C 0024 000C 0024 000C 0024 000C 0024 000C 0030 000C 0024 000C 0030 000C 0018 000C 0018 000C 0024 000C 0048 000C 0024 000C 0BA6

Sejin-1-56 dev 16 obc 89
0000 004A 0000 0011 0037 0035 0023 0048 0012 0024 0012 0036 0012 0036 0012 0036 0012 0036 0012 0036 0012 0048 0012 0036 0012 0048 0012 0024 0012 0024 0012 0036 0012 006D 0012 0036 0012 1100
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[johnsfine]

I'm very happy with the choice I made to include nested bit specs in the definition of the concise irp notation, so that

{msb}<-1|1>(<8:4|4:4|2:4|1:4>( ... ) )
means the same as
{msb}<1,-3|-1,1,-2|-2,1,-1|-3,1>( ... )

I'm not quite as happy with using the nested bit spec in this specific protocol. There are a few protocols in which using a nested bit spec makes the whole irp string a lot shorter and simpler. But in this case, I think the irp string is about the same in length and complexity with or without using the nested bit spec.

However, Graham seems to like the nested bit spec for this protocol and I won't argue against the significant work he has put in.

I don't think I put any support for nested bit specs into MakeHex. I don't have time now to dig around in the source code and/or experiment to see if I put in features I may have forgotten.

I did put in support for more than two bit encodings, which seems to be the significant issue in this protocol. Again, I don't have time to experiment now and I also didn't completely follow some of the details in the above discussion, but the key missing piece in polsat tried above would be dumping

[mathdon]