On September 20, 2006 at 01:12, Luis de Leon said...
Is this the right way to do this codes?:
Close.
900A 006D 0000 0001 EE87 09F2
900A 006D 0000 0001 => use NEC1.irp
Usually correct.
EE87 => Device 238
No, Device=238.135
09F2 => Funtion number 09
Oops! The function number is 09, but if it were really NEC1 protocol that would have been 09F6 not 09F2
385E => Funtion number 56
Similarly that would have been 38C7
If the 5'th number had been EE11 that would be device 238.
NEC can have a one part device number, such as 238, or a two part device number, such as 238.135.
When it has a one part device number, the hex byte that would have held the second part is a check byte constructed so that the two hex bytes of device information add up to FF (EE + 11 = FF), (40 + BF = FF), etc.
NEC1 does not have two part function numbers. The two hex bytes of the function always add up to FF. Your examples don't.
There are a few devices such as Tivo that use a protocol similar to NEC1, but with different rules for those last two digits. To generate those signals you need a .irp file slightly different from NEC1.irp.
But with just the two samples you gave it already contradicts each of the possible alternate rules I recall for those last two digits. To generate more than one signal at a time with MakeHex you would need to know the rule for the last two digits. (For one signal at a time, you could replace the ~F in the .irp file with the decimal value of the last two digits).
Were those samples real? Or did you just make something up to test your understanding of the translation process?
Last edited by johnsfine
on September 20, 2006 08:30.
