Page 2 of 2
Posted: Tue Jul 01, 2008 11:38 am
by dinomight
Cool, i didn't even look at the predata. But yeah thats what i saw (with a little help of RM (and knowing what you had already came up with it made seeing the significant data easier). By the way how do you know that it's the LSB-comp and not the LSB. You suggested using the values of the lsb-comp (not the lsb). the predata is nice since lsb-comp of xFE = lsb x01 but the values for the 1 (lsb-comp xBF != lsb x40)
Oh and i'm very impressed you can do those conversions in your head.
-D
Posted: Tue Jul 01, 2008 11:53 am
by The Robman
If the NEC upgrade doesn't work, try this...
Upgrade Code 0 = 08 80 (Cable/0128) HDMI switch (KM v9.10)
FF 00 81 FE 00 BF DF 5F 9F EF 00 00 00 00
End
Upgrade protocol 0 = 01 FF (S3C8+) HMDI switch (PB v4.00)
43 8C 11 8B 12 E5 4D 08 08 00 96 01 EC 00 96 04
20 4F 04 00 96 1A 30 8D 01 46
End
Posted: Tue Jul 01, 2008 12:25 pm
by johnsfine
dinomight wrote:how do you know that it's the LSB-comp and not the LSB.
Code: Select all
begin remote
one 300 1025
zero 300 2152
In most protocols, including nec1, "one" is the larger value and "zero" is the smaller value.
LIRC gets that backwards in the majority of cases, including this time.
UEIC executors also get that backwards in the majority of cases including NEC1.
When "one"/"zero" is backwards, the OBC to hex conversion is comp. So for this example, it is comp for both the LIRC file and the NEC1 executor.
For an unknown protocol (which this might be) I also look at which pattern of OBC numbers is most plausible in selecting LSB vs. MSB and selecting whether "one" is the larger or smaller burst. In this case, the OBC numbers are more plausible for LSB with "one" as the larger burst.
lsb-comp xBF != lsb x40
I think you are mistaken.
Posted: Tue Jul 01, 2008 12:44 pm
by dinomight
johnsfine wrote:
dinomight wrote:lsb-comp xBF != lsb x40
I think you are mistaken.
Your right, i was doing the conversion wrong, sorry.
-D
Thanks
Posted: Tue Jul 01, 2008 6:31 pm
by dinomight
So the NEC1 protocol, device 128 with codes 2,4,5,6,8 did the trick. i will post an upgrade file to the devices upgrades tonight. Thanks so much for the help. I'm so excited this works. I can finally hook all of my hdmi appliances up. This is awesome.
Posted: Tue Jul 01, 2008 6:55 pm
by johnsfine
I'm curious whether the timing difference was in LIRC and the original protocol really was nec1, or whether the original protocol really was different and the device just isn't very picky about timing.
If it isn't too hard, please do the lirc capture of the nec1 upgrade to see how similar it is to the original lirc capture.
Posted: Wed Jul 02, 2008 5:48 pm
by dinomight
Ok so here is the winlirc config for the nec1 upgrade that i created. Let me know what you think... is the timing problem an issue with the reciever or is the hdmi switch just not picky
Code: Select all
begin remote
name nec1
bits 16
flags SPACE_ENC
eps 25
aeps 100
header 300 13360
one 300 1018
zero 300 2136
ptrail 300
repeat 300 11138
pre_data_bits 16
pre_data 0xFE01
gap 40745
toggle_bit 0
begin codes
1 0x000000000000BF40
2 0x000000000000DF20
3 0x0000000000005FA0
4 0x0000000000009F60
5 0x000000000000EF10
end codes
end remote
Posted: Wed Jul 02, 2008 5:57 pm
by Evan_s
The timing for both learns look pretty close to me so I'd say the device is probably just NEC and the learns are a little off on the timing.
Posted: Wed Jul 02, 2008 6:29 pm
by johnsfine
The match is nearly perfect. So nec1 is correct.
I'm not sure why the numbers are this far from what I'd expect for nec1. I guess there things about the logitech/ast ir sensor and/or winlirc that I don't understand.
I guess, when looking at lirc data, I should pay more attention to the signal structure and less to the time scale, so I don't repeat this mistake of thinking I am seeing a new protocol, when it is really the most common old one.
Posted: Wed Jul 02, 2008 9:03 pm
by The Robman