On April 10, 2007 at 18:57, kharan5876 said...
First off, everytime I push a button lirc receives its
code 2 times.
That may be an unavoidable feature of the way the MX-950 handles repeating codes. I'll test a little with the MX-850, but I doubt there is anything I could fix.
For example, here is mode2's output when I press the 0
button
code: 0x11119bbf
code: 0x11119bbf
I meant to encode 91b7 as the end of every signal, not 9bbf. I'll try to look into why that is happening.
I tried increasing the Message Time variable to
200m and even up to 800m and it did not change the repeat
speed. I must be doing it the wrong way?
That doesn't make much sense, but it should be easy for me to check with the MX-850. Maybe the universal browser trashes the repeat rate when importing Pronto Hex.
The next problem is that the codes are not consistent.
The first 16 bits usually work as planned but the last
16 are unstable.
Learning signals distorts timing a little. Translating a captured signal to Pronto Hex forces much of the timing to be rounded to inexact values. Then translation from Pronto Hex by the universal browser rounds again. Most IR protocols have enough redundancy to resynchronize on every edge so even timing errors as large as 20% don't matter.
If the true version of THIS protocol matches what LIRC decodes, it doesn't have that redundancy and would need very accurate timing to work correctly. Even if the true version has some redundancy I haven't identified, your LIRC IR sensor apparently doesn't take that into account and needs better timing.
Once I figure out why you're getting 9bbf instead of 91d7 the variations of a given signal should tell me which direction the timing is off.
I already observed with my capture device that the MX-850 sent the signals from my CCF slightly faster than it sent your learned signals. But it was by such a small amount that after rounding, slowing it down in the IRP file would either do nothing or too much. Maybe the info you just gave me will be enough for a more informed tweak.
Sometimes the 0 key gives me these outputs:
0x1119bbf
0x1119bff
0x11193bf
Really? Just seven digits instead of eight? Or did you miss a 1 and you're just telling me the incorrect bbf is unstable?
This is more of a problem with the 2 button because the
unstable signal seeps into the 3rd byte. Here is some
of the output I get from pressing 2.
code: 0x1117dbff
code: 0x11159bff
code: 0x11179bff
The 2 button should be 1115. I have a general idea what sort of timing problem would make a 5 sometimes turn into a 7 and I think I can tweak the irp to make that less likely.
I did notice my original remote sometimes sends incorrect
commands. Perhaps the 255 functions from this new protocol
are too packed together to allow for errors?
Not sure what you mean. If the sensor doesn't use the available redundancy then it will get wrong strings sometimes, even if the code set is spaced better. Maybe you mean that with a better spaced code set you could include the wrong values of each real signal and they would be distinct, so you could make several different hex codes all map to the same function. I could do that if we can't tweak the timing to improve things more directly.
Another problem is that if I hold a button down it doesnt
repeat forever.
That sounds like another feature of the MX-950 that I can't do anything about.
Once 0x7ffffff is spit out the receiver no longer accepts
the repeated input until I let go of the button and press
again. Perhaps this is also related to the repeat rate
being too fast. Could the sensor be getting overloaded?
Are you saying the MX-950 didn't stop sending? The sensor stopped receiving? I wouldn't have guessed that, but maybe.
