MCE Remote learned codes

[mathdon]

Aha! I've found a pattern! The last 4 bits are always the lsb forms of one of 8, 7, 6, 5, 4, 3 and the value decreases by one between Once frame and the common value for the Repeat and Extra frames.

You observed that the last 2 of the 7 fixed bits are always the same for each frame type, ie Once or Repeat or Extra. These bits are the lsb forms of 3, 2, 1 respectively, so again there is a decrease of 1. So any one of the Once, Repeat and Extra frames determines the others.
_____________
Graham

[The Robman]

I've been looking at this one a lot closer today and I've cracked the checksum. You are correct that the last 4 bits are a decimal number in LSB format, but that's not the whole story.

The checksum is a count of the number of 1s in the whole signal. There are two 1s in the 5-bit fixed portion. The next 2 bits are "11" for the first part, "10" for the second and "01" for the third, so that explains why the checksum is the same for the 2nd and 3rd parts but different for the first part.

Unfortunately, even though we now know that the signal is LSB, I'm still not able to make any sense out of the OBC codes, so I guess we'll just have to accept that the OEM didn't use a logical pattern for the OBCs.

[mathdon]

You beat me to it! I had written down the 6-bit variable values underneath the values (ie 3 to 8) of the last 4 bits for the repeat frame but was then called for dinner (UK time!). I intended to look for a pattern after dinner, and having just come back to do so, I saw your message. The pattern, of course, is that all the values in each column have the same number of 1's. So I think I would have got there in the end.
____________
Graham

[The Robman]

Now see if you can make sense of the OBCs!

[mathdon]

I've made no headway with making sense of the OBCs, Rob, but I think the decode is better with the bits complemented, ie take

A ONE pair as -500 +500
A ZERO pair as +500 -500

instead of the other way round. This gives the 2-bit values that identify First, Repeat and Extra frames as 0, 1, 2, which makes more sense than 3, 2, 1. It has an effect on the checksum, which becomes 3 more than the number of 1's. Uncomplemented, it is 1 less than the number of 1's (rather than equal to it, which you had). Since neither give equality, I don't think this says anything about whether to use complemented or uncomplemented values. I'm also using a base time of 480 rather than 500 as this seems to fit the raw data better.

This gives the IRP as

OrtekMCE {38.6k,480}<1,-1|-1,1>(4,-1,D:5,P:2,F:6,C:4,^48m)+

where P is a position code:

0 for first frame of repeat sequence
1 for all repeats up to last one
2 for last repeat

and C is the checksum, 3 more than the number of 1 bits in D, P, F together.

I've sorted out how to make DecodeIR check the multiple frames with different P and C values and report a single decode for each signal. As far as I can tell, there are no other protocols handled by DecodeIR that have this behaviour of multiple different frames for the same signal. The output now looks a great deal nicer. Here it is.

Code: Select all

LEARNED SIGNALS:
LEARNED CODE DATA
# 	Btn	Key	   Protocol	Dev Sub OBC  Hex  EFC	
1 	VCR	Power 	OrtekMCE	21		3 	C0	012		
2 	VCR	Up    	OrtekMCE	21		21	A8	079		
3 	VCR	Down  	OrtekMCE	21		32	04	242		
4 	VCR	Right 	OrtekMCE	21		33	84	238		
5 	VCR	Left  	OrtekMCE	21		23	E8	077		
6 	VCR	Select	OrtekMCE	21		34	44	240		
7 	VCR	Play  	OrtekMCE	21		11	D0	140		
8 	VCR	FWD   	OrtekMCE	21		9 	90	142		
9 	VCR	F.Fwd 	OrtekMCE	21		17	88	078		
10	VCR	Rew   	OrtekMCE	21		13	B0	143		
11	VCR	F.Rew 	OrtekMCE	21		8 	10	146		
12	VCR	Stop  	OrtekMCE	21		16	08	082		
13	VCR	Pause 	OrtekMCE	21		20	28	083		
14	VCR	REC   	OrtekMCE	21		19	C8	076		
15	VCR	CH+   	OrtekMCE	21		47	F4	109		
16	VCR	CH-   	OrtekMCE	21		49	8C	046		
17	VCR	VOL+  	OrtekMCE	21		50	4C	048		
18	VCR	VOL-  	OrtekMCE	21		51	CC	044		
19	VCR	Mute  	OrtekMCE	21		48	0C	050		
1 	VCR	1     	OrtekMCE	21		52	2C	051		
2 	VCR	2     	OrtekMCE	21		36	24	243		
3 	VCR	3     	OrtekMCE	21		31	F8	205		
4 	VCR	4     	OrtekMCE	21		53	AC	047		
5 	VCR	5     	OrtekMCE	21		35	C4	236		
6 	VCR	6     	OrtekMCE	21		30	78	209		
7 	VCR	7     	OrtekMCE	21		45	B4	111		
8 	VCR	8     	OrtekMCE	21		37	A4	239		
9 	VCR	9     	OrtekMCE	21		38	64	241		
10	VCR	0     	OrtekMCE	21		42	54	112		
11	VCR	Menu  	OrtekMCE	21		46	74	113		
12	VCR	Enter 	OrtekMCE	21		44	34	115		
13	VCR	TV/Vid	OrtekMCE	21		39	E4	237		
14	VCR	Info  	OrtekMCE	21		18	48	080		
15	VCR	Guide 	OrtekMCE	21		22	68	081		
16	VCR	L1    	OrtekMCE	21		6 	60	017		
17	VCR	L2    	OrtekMCE	21		7 	E0	013		
18	VCR	L3    	OrtekMCE	21		4 	20	019		
19	VCR	L4    	OrtekMCE	21		2 	40	016		
1 	VCR	PIP   	OrtekMCE	21		14	70	145		
2 	VCR	MOVE  	OrtekMCE	21		15	F0	141		
3 	VCR	SWAP  	OrtekMCE	21		12	30	147		
4 	VCR	Sleep 	OrtekMCE	21		10	50	144		

________________
Graham

[The Robman]

I'm inclined to believe that there is no rhyme or reason for their use of OBCs so I'm not surprised that you weren't able to make any headway with them. I agree with your inclination to think that the 1/2/3 codes imply that I have the 1s and 0s reversed (ie, the signal should be LSB-COMP) but the checksum proves conclusively that it isn't comp'd, so it really is 3/2/1.

[mathdon]

Rob, I would agree with you about the checksum if with the uncomplemented values it equalled the number of 1's, but it does not. It is one less than the number of 1's. This seems no different in principle than the complemented form, where it is three more than the number of 1's. So I don't see that the checksum proves either version conclusively, but I do think 0/1/2 versus 3/2/1 does so.

What feature of the checksum do you think is conclusive?
_____________
Graham

[mathdon]

I'm inclined to believe that there is no rhyme or reason for their use of OBCs so I'm not surprised that you weren't able to make any headway with them.

I've always thought that there has to be some reason behind OBCs as the keypad in the remote is read as a matrix determined by the PCB layout. So the software starts out with row and column values and constructs the OBC from that. Sometimes that construction makes the values look more logical in lsb form, sometimes in msb form (maybe whether it is the row or column that is put first when they are concatenated?), but there seems no inherent reason why either lsb or msb should seem "nicer". Nevertheless, unless a deliberate encryption has been imposed (is there ever a reason why that might be done?) it should be possible to reconstruct the original matrix and so see the reason behind the OBCs. In the URC-7781 the OBC = 8 x (row_num – 1) + col_num, where the row number is 1..6 and the column number is 1..8.
_______________
Graham

[vickyg2003]

I've always thought that there has to be some reason behind OBCs

I don't get all the math stuff involved in signals. It actually took me YEARS to finally get the hang of signals at all, but OBC's have always seemed like the most obvious thing on the planet. To me, its not how these things look on the PCB's, but rather where tests need to be performed to enhance the responsiveness of the program (equipment). OBC's tend to be grouped into logical functions. They seem to be grouped so that a simple bit testd can send you to the proper subroutine in the firmware for processing as quickly as possible. This holds true for equipment that has multiple subdevices too. The subdevice tends to go with the type of function to be performed.

[mathdon]

Whether Vicky is right or not, here's a key matrix that generates the OBC values (my form, ie lsb comp) as (8 * row + col) for the Ortek MCE, where row is 0..6 and col is 0..7, and which has the keys in roughly the same sort of areas as the picture Zaldwaik provided. There can never be a direct correspondence between buttons and matrix positions as the the buttons are not arranged in an appropriate neat rectangular array, but I would expect there to be a rough correspondence in general area. The matrix is

Code: Select all

    0       1       2       3       4       5       6       7
0                   L4      Power   L3              L1      L2     
1   F.Rew   FWD     Sleep   Play    SWAP    Rew     PIP     MOVE   
2   Stop    F.Fwd   Info    REC     Pause   Up      Guide   Left   
3                                                   6       3      
4   Down    Right   Select  5       2       8       9       TV/Vid 
5                   0               Enter   7       Menu    CH+    
6   Mute    CH-     VOL+    VOL-    1       4

and all the OBC values are < 7*8 (which is not so in uncomp form). To me, at any rate, this supports the lsb comp interpretation. But in the end, of course, it is irrelevant. It doesn't affect the hex code for the function and the only "real" answer is the one that was in the heads of the remote's developers.

I don't actually agree with Vicky's interpretation as there are not enough bits in the OBC to do as she suggests. The values are grouped because the buttons on the keypad are grouped. Keypads are read as a matrix. The row and column values are then converted into a single keycode by software, and I see no reason why that should be done in anything other than a simple manner.
_______________
Graham

[vickyg2003]

I don't actually agree with Vicky's interpretation as there are not enough bits in the OBC to do as she suggests. The values are grouped because the buttons on the keypad are grouped. Keypads are read as a matrix.

Well I could be totally offbase on this, but it seems to me that the keypad is arranged with like functions together. I guess its which came first, the chicken or the egg. Think about it, I have had 8 Philips TVs that have all used the same codes, and the keypad layouts are all different. I don't know about this particular manufacturer, and have no understanding of the MCE protocol and have not looked at the actual remote or PCB, but just in the general pecking order of life, I would think that the engineers that design the firmware for the TV are going to carry more weight than the guys that design the remote.

[The Robman]

Rob, I would agree with you about the checksum if with the uncomplemented values it equalled the number of 1's, but it does not. It is one less than the number of 1's. This seems no different in principle than the complemented form, where it is three more than the number of 1's. So I don't see that the checksum proves either version conclusively, but I do think 0/1/2 versus 3/2/1 does so.

I thought the checksum count was indeed equal, but I do see now that it's off by one, so I no longer think it's conclusive.

I've taken another look at the OBCs to see if they're scrambled or something but I'm really not seeing a pattern. Looking at just the binary for the numeric buttons, you would expect to see one of the columns display a 1-0-1-0-1-0 etc pattern but they don't.

As for the matrix issue, while you would expect all OBCs to follow a pattern, we have found that while most do, there are plenty that don't, so that's not conclusive either. After all, look at how we can arrange the buttons in our upgrades, there's nothing stopping us from arranging our buttons in a totally random fashion, we're not bound by the matrix, so if the OEM remote has a similar setup to our JP1 remotes, they're not bound by the matrix either.

Bottom line, I don't see a compelling case to say that this signal is COMP'd or not, in which case my preference would be to say that it isn't. Why complicate matters when we don't have to?

[mathdon]

Rob, I don't see it as a complication. We're only calling it Comp as you started out taking 1 as +500, -500, 0 as -500, +500. If you take 1 as -500, +500 and 0 as +500, -500, it's not Comp. There doesn't seem to be a particular convention that says 1 is ON/OFF and 0 is OFF/ON, as John Fine lists the RC6 protocol as 1 = ON/OFF, 0 = OFF/ON but the RC5 protocol as 1 = OFF/ON, 0 = ON/OFF. I may be missing something here, like a connection with Odd or Even biphase signals, so please correct me if I'm wrong, but all I'm proposing is to follow the order used for RC5. I agree that if one has to say Comp explicitly then it is a complication that is perhaps unnecessary.
_____________
Graham

[johnsfine]

if one has to say Comp explicitly then it is a complication that is perhaps unnecessary.

Maybe I missed some context, but I'll comment anyway.

We often want to decide LSB vs. MSB to make the OBC values more reasonable when we reverse engineer a protocol.

We also want to decide the 0/1 polarity for the same reason. But we don't want to represent that (especially in any IRP format) as a "comp" or not characteristic. We want to directly represent it as a bit encoding rule.

When we take that protocol and represent it via a JP1 executor, we do want to introduce the concept of "comp". If we are using or being consistent with a UEI executor that is "comp" we want to be consistent with it. Even if we invent the executor, a choice of comp for the bits often simplifies the generation of the lead out pulse(s).

We do not want the JP1 executor issues to drive the polarity choice in the bits of the OBC number. That choice should be our best guess at what fits the collection of known signals. Then some executor is opposite that choice, we want to tag it as "comp".

John Fine lists the RC6 protocol as 1 = ON/OFF, 0 = OFF/ON but the RC5 protocol as 1 = OFF/ON, 0 = ON/OFF.

That is one of the rare cases in which the inventors of the protocol have published the intent of the bits, so we know the mapping of 0/1 for sure. We aren't guessing.

It also is one of the common cases in which the OBC numbers are arranged very consistently, so there would be no risk of guessing wrong.

The polarity is opposite between rc5 and rc6 because the inventor of rc6 explicitly decided to revers it.

[The Robman]

There doesn't seem to be a particular convention that says 1 is ON/OFF and 0 is OFF/ON

It's not a convention, it's a limitation of the IR engine when it comes to bi-phase signals.

We don't have the flexibility when writing bi-phase executors that we have when we write PWM executors. With a PWM signal, if I were to conclude that my original guess regarding the 1s and 0s was backwards, rather than treat my executor as COMP, I would reverse the timings in the code itself, thus un-COMPing it. But with bi-phase, I only have the option of sending the zero pair reversed (ie, with the off time first).

John Fine lists the RC6 protocol as 1 = ON/OFF, 0 = OFF/ON but the RC5 protocol as 1 = OFF/ON, 0 = ON/OFF. I may be missing something here, like a connection with Odd or Even biphase signals, so please correct me if I'm wrong, but all I'm proposing is to follow the order used for RC5. I agree that if one has to say Comp explicitly then it is a complication that is perhaps unnecessary.

Why follow RC5 rather than RC6? If the signal really were comp'd I'd have no problem treating it as such, but as the OBCs don't make any sense whichever way you look at them, I don't see a compelling case one way or another. Therefore my preference would be to not treat it as comp. The only reason we treat some executors as comp is so that we can get the correct OBCs to display.

As this seems to be important to you, I'm certainly willing to let this one go, so if you want to treat it as comp, go ahead.