Page 3 of 5
Posted: Sun Apr 12, 2009 11:56 am
by zaldwaik
The Robman wrote:Could you do me a favor and learn all the buttons that you skipped, just in case the next person needs them.
Sure, let me work on that in a seperate file. I ran out of buttons on the 8910, so I will have to use generic buttons.
Posted: Sun Apr 12, 2009 12:05 pm
by The Robman
You can use any buttons you like, just write in the "Notes" box what each button is.
Posted: Sun Apr 12, 2009 12:13 pm
by zaldwaik
File 5
https://www.hifi-remote.com/forums/dload ... le_id=6545
(e)---------1
Mouse-Left button---------2
Mouse-Right button---------3
Cicular pad
up-----4
dn-----5
L------6
R------7
up-L-----8
dn-L----9
up-R----0
dn-R----L1
Posted: Sun Apr 12, 2009 12:19 pm
by zaldwaik
Posted: Sun Apr 12, 2009 4:26 pm
by The Robman
I've added all the missing buttons except for the mouse and pad buttons as those will require a new executor.
Here's the KM file...
https://www.hifi-remote.com/forums/dload ... le_id=6526
And the RM file...
https://www.hifi-remote.com/forums/dload ... le_id=6543
If you understand what they do, could you give a better description of the four "pic" buttons and the extra "left arrow" button. I'm also curious what buttons like E and START do.
Posted: Sun Apr 12, 2009 9:02 pm
by zaldwaik
According to the manual
First row color buttons
My Tv, My Music, My Pictures, My Videos
Next row
Record TV, Guide, Live TV, DVD Menu
All the above are mapped to different keyboard keys, or key combination
e starts the default web browser
Power sleep computer (does not work)
Left Arrow- Backspace
i- Information (does not work)
start- open MCE application (mapped to Alt-Ctrl-Enter)
Posted: Sun Apr 12, 2009 9:15 pm
by The Robman
Thanks, I'll update the files with those descriptions. Do you think you'll need the mouse or pad buttons at any point? If so, I'd like to see a new set of learns from them just to be sure that what I'm seeing is consistent (these signals have a different format to the others). If you could, could you also verify that the learns work.
Posted: Mon Apr 13, 2009 10:47 am
by zaldwaik
I plan to check all learns once I update my 6131n. I do not really plan to use the mouse buttons given that it I am using a universal remote with limited number of buttons. The mouse functionality has so many buttons it would be a challenge to use it with another remote. I may just need the left and right mouse buttons.
On another topic, I am looking for a replacement for one of my 6131n remotes, I need one with the same, or smaller, size, at least 3 devices with JP1 interface. I am considering URC-6960 you have on sale, I am just wondering if it is similar in size to 6131n.
Also, if you have suggestions for a small (3-4 devices) JP1 remote available for sale, I would really appreciate it.
Finally, I want to thank you for your help. I am wondering if you accept donations, I could not find anything on the web site.
Posted: Mon Apr 13, 2009 11:20 am
by The Robman
What I meant by "checking the learns" is, once you've learned the buttons from the OEM remote, test them right away to verify that you've captured enough of the signal to make it work.
The latest batch of learns were a lot harder to decode than the earlier batches. This was further complicated by the fact that the mouse and pad buttons use a slightly different format. Plus, the data for some of the pad buttons changes mid-way through and then changes back. I suspect that this is because your finger moved slightly causing the pad to send the signal for a slightly different "direction" but I would need to see a 2nd set of learns to be sure.
As for using the pad buttons, there are tricks available using JP1 that could facilitate that. For example, you could create a 2nd upgrade where the arrow buttons are programmed with the pad controls, and all the buttons around the arrow buttons could be the diagonal pad buttons. Then, you could use the Device Multiplexor to switch between the two upgrades. You could program the L1 button to switch to pad mode and the L2 button to switch back, for example. Or, being a bit more creative, maybe the MENU button would switch to pad mode and the EXIT button would switch back. Pick whatever seems the most intuitive to you.
As for getting a new remote, are you really looking for another 6131n if one were available? If so, I can check to see if I have any more. I doubt that the URC-6960 is really what you're looking for as it's a Kameleon remote. The URC-8820 is also exactly the same size as the URC-6131n, but it's a JP1.2 remote, so it would need a separate cable.
I don't solicit for donations, but I'm happy to accept them, just use one of my regular Paypal accounts (as listed in my "for sale" thread).
Posted: Sun Apr 19, 2009 10:06 am
by zaldwaik
Sorry for the delay, been busy at work. I already have a 6131n which works fine. However, I am looking for a replacement that might be smaller but still JP1 programmable as I only need 3 devices for my setup. I only use URC-8910 for learning purposes, it is too bulky for daily use.
I was considering URC-6960 as an alternative since I never used a Kameleon remote and I read good reviews about it and it is JP1 compatible. Otherwise I can just stick with my 6131n.
Just sent you a little thank you.
Posted: Sun Apr 19, 2009 10:10 am
by The Robman
Much appreciated.
As for a new remote, the best I can think of would be the old version of the 6131, it's not as long as the 6131n, but it's a little chubbier, which I think makes it sit in your hand better. If you want one, let me know, as I may still have some more somewhere.
Posted: Fri Jul 24, 2009 8:31 am
by mathdon
As you didn't give your description of this protocol, I've followed your very helpful instructions
here. I see why you wanted those new buttons in the Learning tab! It seems that this is yet another variant of the TDC protocol. I've called it OrtekMCE as there is already an MCE protocol that is the official Microsoft one. This remote seems to work with its own plug-in USB receiver, and presumably its own software. I've decoded it as
OrtekMCEn {38.6k,480,msb}<-1,1|1,-1>(4,-1,D:5,S:5,F:6,C:1,^48m)+
where as before, n is XOR of C with right-most bit of F. I've split the fixed data this time into a 5-bit device code and a 5-bit subdevice code, as only 5 bits appear to be fixed throughout all the signals. Zaldwaik's data seems to decode OK but I can make neither head nor tails of the result. You commented on the signals having three parts, but I expected to see something more systematic that I found, which is:
Code: Select all
LEARNED SIGNALS:
LEARNED CODE DATA
# Btn Key Protocol Dev Sub OBC Hex EFC
1 VCR Power OrtekMCE1 10 9 59 3B 219
OrtekMCE1 10 9 59 3B 219
OrtekMCE1 10 17 59 3B 219
2 VCR Up OrtekMCE1 10 26 43 2B 091
OrtekMCE1 10 10 45 2D 043
3 VCR Down OrtekMCE1 10 31 48 30 147
OrtekMCE1 10 15 55 37 123
OrtekMCE1 10 15 55 37 123
4 VCR Right OrtekMCE1 10 27 55 37 123
OrtekMCE1 10 11 51 33 155
5 VCR Left OrtekMCE1 10 24 45 2D 043
OrtekMCE1 10 8 41 29 075
6 VCR Select OrtekMCE1 10 29 55 37 123
OrtekMCE1 10 13 51 33 155
7 VCR Play OrtekMCE1 10 25 27 1B 218
OrtekMCE1 10 9 29 1D 170
8 VCR FWD OrtekMCE1 10 27 31 1F 186
OrtekMCE1 10 11 27 1B 218
9 VCR F.Fwd OrtekMCE1 10 27 47 2F 059
OrtekMCE1 10 11 43 2B 091
10 VCR Rew OrtekMCE1 10 26 27 1B 218
OrtekMCE1 10 10 29 1D 170
11 VCR F.Rew OrtekMCE1 10 31 24 18 210
OrtekMCE1 10 15 31 1F 186
OrtekMCE1 10 15 31 1F 186
12 VCR Stop OrtekMCE1 10 31 40 28 083
OrtekMCE1 10 15 47 2F 059
OrtekMCE1 10 15 47 2F 059
13 VCR Pause OrtekMCE1 10 30 47 2F 059
OrtekMCE1 10 14 43 2B 091
14 VCR REC OrtekMCE1 10 25 43 2B 091
OrtekMCE1 10 9 45 2D 043
15 VCR CH+ OrtekMCE1 10 24 17 11 138
OrtekMCE0 10 8 22 16 130
16 VCR CH- OrtekMCE1 10 27 35 23 027
OrtekMCE1 10 11 37 25 235
17 VCR VOL+ OrtekMCE1 10 29 35 23 027
OrtekMCE1 10 13 37 25 235
18 VCR VOL- OrtekMCE1 10 25 37 25 235
OrtekMCE1 10 9 33 21 011
19 VCR Mute OrtekMCE1 10 31 39 27 251
OrtekMCE1 10 15 35 23 027
1 VCR 1 OrtekMCE1 10 30 35 23 027
OrtekMCE1 10 14 37 25 235
2 VCR 2 OrtekMCE1 10 30 55 37 123
OrtekMCE1 10 14 51 33 155
3 VCR 3 OrtekMCE1 10 24 9 09 074
OrtekMCE0 10 8 14 0E 066
4 VCR 4 OrtekMCE1 10 26 37 25 235
OrtekMCE1 10 10 33 21 011
5 VCR 5 OrtekMCE1 10 25 51 33 155
OrtekMCE1 10 9 53 35 107
6 VCR 6 OrtekMCE1 10 28 13 0D 042
OrtekMCE1 10 12 9 09 074
7 VCR 7 OrtekMCE1 10 26 21 15 106
OrtekMCE1 10 10 17 11 138
8 VCR 8 OrtekMCE1 10 26 51 33 155
OrtekMCE1 10 10 53 35 107
9 VCR 9 OrtekMCE1 10 28 51 33 155
OrtekMCE1 10 12 53 35 107
10 VCR 0 OrtekMCE1 10 29 19 13 154
OrtekMCE1 10 13 21 15 106
11 VCR Menu OrtekMCE1 10 28 21 15 106
OrtekMCE1 10 12 17 11 138
12 VCR Enter OrtekMCE1 10 30 19 13 154
OrtekMCE1 10 14 21 15 106
13 VCR TV/Vid OrtekMCE1 10 24 53 35 107
OrtekMCE1 10 8 49 31 139
14 VCR Info OrtekMCE1 10 29 47 2F 059
OrtekMCE1 10 13 43 2B 091
15 VCR Guide OrtekMCE1 10 28 43 2B 091
OrtekMCE1 10 12 45 2D 043
16 VCR L1 OrtekMCE1 10 28 63 3F 187
OrtekMCE1 10 12 59 3B 219
17 VCR L2 OrtekMCE1 10 24 59 3B 219
OrtekMCE1 10 8 61 3D 171
18 VCR L3 OrtekMCE1 10 30 56 38 211
OrtekMCE1 10 14 63 3F 187
OrtekMCE1 10 14 63 3F 187
19 VCR L4 OrtekMCE1 10 29 56 38 211
OrtekMCE1 10 13 63 3F 187
OrtekMCE1 10 13 63 3F 187
1 VCR PIP OrtekMCE1 10 12 29 1D 170
2 VCR MOVE OrtekMCE1 10 24 29 1D 170
OrtekMCE1 10 8 25 19 202
3 VCR SWAP OrtekMCE1 10 30 31 1F 186
OrtekMCE1 10 14 27 1B 218
4 VCR Sleep OrtekMCE1 10 13 27 1B 218
I don't even understand there being two or three different frames for each signal, never mind the complexity of the data. Can you please help me make some sort of sense of it?
BTW There are two occurrences of OrtekMCE0, corresponding to the last two bits being equal rather than complements!
_________________
Graham
Posted: Fri Jul 24, 2009 10:39 am
by The Robman
Here's what I determined from looking at the signals.
The freq is 38.6 kHz
The round-to number is 500
The leadin is +2000 -500
The leadout is 48,500
A ONE pair is +500 -500
A ZERO pair is -500 +500
There are 17 bits of data and the signal is sent in three parts:
There is a "first time" string, followed by a repeating string, followed by a final string sent when the button is released.
The executor that I wrote treats the first 7 bits as fixed, followed by 10 variable bits, which are split into a 6-bit byte and a 4-bit byte. The last 2 bits of the 7 "fixed" bits are different in each of the three parts, but the changes are the same each time, so the assembler code handles this. The 6-bit portion of the variable data remains the same in each of the 3 parts, but the 4-bit portion changes between the 1st and 2nd parts (the 3rd part is the same as the 2nd), so nibble-1 of the 2nd variable byte is the first 4-bit pattern, and nibble-2 is the 2nd, then in the assembler, I swap them between the 1st and 2nd send.
I didn't notice any patterns in the data, so I can't really tell is the data is LSB or MSB and I couldn't tell if the data is encrypted or if there's a checksum, but to be honest I don't think I spent much time looking.
Here's the data in a spreadsheet:
https://www.hifi-remote.com/forums/dload ... le_id=6972
Posted: Fri Jul 24, 2009 11:23 am
by mathdon
The Robman wrote:The executor that I wrote treats the first 7 bits as fixed, followed by 10 variable bits, which are split into a 6-bit byte and a 4-bit byte. The last 2 bits of the 7 "fixed" bits are different in each of the three parts, but the changes are the same each time, so the assembler code handles this. The 6-bit portion of the variable data remains the same in each of the 3 parts, but the 4-bit portion changes between the 1st and 2nd parts (the 3rd part is the same as the 2nd), so nibble-1 of the 2nd variable byte is the first 4-bit pattern, and nibble-2 is the 2nd, then in the assembler, I swap them between the 1st and 2nd send.
I didn't notice any patterns in the data
Well, if that's "not noticing any patterns", I'm a monkey's uncle! I had a spreadsheet of the bits, but stupidly I didn't mark which were the First, Repeat and Extra frames. That would have helped, but I'm still doubtful I would have seen the relationships you saw.
One final question about this protocol. Does your executor cope with the fact that in some signals either the Once or the Extra frame is missing? Or is this a red herring, an artefact of these particular learnings? If you have all three parts in all signals, what do you do when the Once part is missing, so you don't know its final 4 bits?
_________________
Graham
Posted: Fri Jul 24, 2009 11:50 am
by The Robman
I am assuming that the missing parts are due to errors in the learning rather than the signal should be that way.
As for getting the 2nd byte when the first part is missing, if you look at all of the signals as a whole, you'll notice that there are just five possible values for the 2nd byte, those being:
1E
2C
6A
A2
E6
Now, let's look at the 2nd byte for the two signals where the first part was missing:
_6
_A
Based on the 5 byte2 values posted above, _6 should be E6 and _A should be 6A.
What I meant by not noticing a pattern was that I wasn't able to figure out if the protocol is MSB or LSB, I wasn't able to determine the true OBC and I wasn't able to figure out if the signal is encrypted (in a "Lutron" fashion") or if there's a checksum in there.