Telefonica - new protocol (Sejin)

[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

Code: Select all

LEARNED SIGNALS:
LEARNED CODE DATA
# 	Btn	Key   	Protocol     Dev  Sub OBC   Hex  EFC   Misc
1 	CBL	Power 	Sejin-1-38	16	0	8  	08	082	E=0	
2 	CBL	Up    	Sejin-2-38	2 	 	0  	  	   	delta = (0,6); E=0, RMOBC=4102	
3 	CBL	Down  	Sejin-2-38	2 	 	0  	  	   	delta = (0,-6); E=0, RMOBC=4346	
4 	CBL	Left  	Sejin-2-38	2 	 	0  	  	   	delta = (-6,0); E=0, RMOBC=6394	
5 	CBL	Right 	Sejin-2-38	2 	 	0  	  	   	delta = (6,0); E=0, RMOBC=6150	
6 	CBL	Select	Sejin-2-38	2 	 	1  	  	   	Btn down (OBC=Btn nbr); E=0, RMOBC=256	
7 	CBL	Menu  	Sejin-2-38	2 	 	2  	  	   	Btn down (OBC=Btn nbr); E=0, RMOBC=512	
8 	CBL	VOL+  	Sejin-1-38	16	0	88 	58	208	E=0	
9 	CBL	VOL-  	Sejin-1-38	16	0	104	68	081	E=0	
10	CBL	CH+   	Sejin-1-38	16	0	56 	38	211	E=0	
11	CBL	CH-   	Sejin-1-38	16	0	72 	48	080	E=0	
12	CBL	1     	Sejin-1-38	16	0	89 	59	200	E=0	
13	CBL	2     	Sejin-1-38	16	0	105	69	073	E=0	
14	CBL	3     	Sejin-1-38	16	0	121	79	201	E=0	
15	CBL	4     	Sejin-1-38	16	0	28 	1C	178	E=0	
16	CBL	5     	Sejin-1-38	16	0	44 	2C	051	E=0	
17	CBL	6     	Sejin-1-38	16	0	60 	3C	179	E=0	
18	CBL	7     	Sejin-1-38	16	0	76 	4C	048	E=0	
19	CBL	8     	Sejin-1-38	16	0	92 	5C	176	E=0	
20	CBL	9     	Sejin-1-38	16	0	108	6C	049	E=0	
21	CBL	Mute  	Sejin-1-38	16	0	27 	1B	218	E=0

Rather obviously (I hope!), "delta" gives the (X,Y) coordinates of the cursor movement.

I've tested the RM re-creation of these signals on my URC-7781 (HCS08 based) and all seems well. DecodeIR gives the same decode for the re-created signals as the above data from the original NightHawk. We don't have a "button up" learned signal, but it does show up when the RM re-created signals are used with Tommy's IR Widget.
____________________
Graham

[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.

[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]

I presume the 130m that the Learned Signals raw timings show is simply the longest time that IR.exe can record.

Correct

[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 ... le_id=7877

[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.

[mathdon]

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

Yes, I did. Two of them. See the first post on this page. It is posted as Sejin.ini

________________
Graham

[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:

Code: Select all

Device=16.0
Function=0..10
Time Base=310
Frequency=38800
First Bit=MSB
Zero=-1
One=1
Prefix=8:4,4:4,2:4,1:4
Suffix=-77
Define C=(D:4)+(D:4:4)+(S:4)+(S:4:4)+(F:4)+(F:4:4)+0
Form=;*3,3:2,D:8,S:8,F:8,0:4,C:4,_

But I must be misreading the IRP notation somehow.. From this IRP file, Makehex generates 10 equal hex codes. Certainly somethings wrong with my definitions (either in the definition of C, or the Form).

The IRP notation seems quite different from the other protocols, and I don't understand the <> notation being used twice (all other protocols seems to use this once, to define zero and one)..

So, are there any kind souls out there that could help me in the direction of generating a .IRP file that I can use with Makehex to create the needed hex codes?

I would be ever so grateful!

/polsat

[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

[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

Code: Select all

Zero=-1
One=1 

and instead using

Code: Select all

Zero=1,-3
One=-1,1,-2
Two=-2,1,-1
Three=-3,1 

There might be a few other tweaks needed to that .irp that I couldn't figure out myself short of testing it against Graham's decode routine.

BTW, if you prefer, you can use the numbers rather than their names for the left side of makehex bit specs. That is optional for a four way choice, such as used in this thread, but required for a sixteen way choice, such as in xmp.irp

[mathdon]

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.

To me, the nested form shows the logical structure of this base-4 encoding in a better way than does the expanded, non-nested form. But then, I'm a mathematician and my brain seems to work differently to most other people . I understand that others may prefer the expanded form.

The IRP notation seems quite different from the other protocols, and I don't understand the <> notation being used twice (all other protocols seems to use this once, to define zero and one).

There is a specification of IRP notation in the Help section, here.