 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
 Posted: Fri Jul 24, 2009 12:57 pm Post subject: |
 |
|
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 |
|
| Back to top |
|
 |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Fri Jul 24, 2009 2:32 pm Post subject: |
|
|
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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Fri Jul 24, 2009 4:17 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Fri Jul 24, 2009 4:28 pm Post subject: |
|
|
Now see if you can make sense of the OBCs! 
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Sun Jul 26, 2009 11:49 am Post subject: |
|
|
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: | 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 |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Sun Jul 26, 2009 10:55 pm Post subject: |
|
|
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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Mon Jul 27, 2009 2:46 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Mon Jul 27, 2009 3:12 am Post subject: |
|
|
| The Robman wrote: | | 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 |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Mon Jul 27, 2009 6:51 am Post subject: |
|
|
| Quote: | | 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. |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Mon Jul 27, 2009 7:59 am Post subject: |
|
|
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: | 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 |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Mon Jul 27, 2009 8:32 am Post subject: |
|
|
| Quote: | | 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. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Mon Jul 27, 2009 9:52 am Post subject: |
|
|
| mathdon wrote: | | 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?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Mon Jul 27, 2009 11:12 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Mon Jul 27, 2009 12:34 pm Post subject: |
|
|
| mathdon wrote: | | 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".
| mathdon wrote: | | 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. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Mon Jul 27, 2009 12:52 pm Post subject: |
|
|
| mathdon wrote: | | 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).
| mathdon wrote: | | 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.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
