fixes for irtext2udp, and for UDP protocol documentation
Paul Fox <[email protected]> Sat, 05 Mar 2022 14:55:44 -0500
| Newsgroups | gmane.comp.hardware.lirc |
|---|---|
| Message-ID | <[email protected]> |
It turns out that the UDP protocol has been misdocumented, on both the
website and in the code, since 2015. In addition, the irtext2udp tool
matches the broken documentation, and doesn't work as a result.
(Perhaps it's not used much?)
The current documentation (https://lirc.org/html/udp.html) says:
"Received UDP packets consist of a number of little endian 16-bit
integers. The high bit signifies the state of the received
signal; set indicates a mark, clear a space. The low 15 bits
specify how long the signal lasted."
So the docs clearly say that the high bit set means "pulse".
This text likely came from the top of plugins/udp.c, which says much
the same thing. But the receiving code, further down in plugins/udp.c
(https://sourceforge.net/p/lirc/git/ci/master/tree/plugins/udp.c#l279 )
which interprets the meaning of the high bit, looks like this:
/* Low indicates that the receiver has detected the marking state
* i.e. is receiving IR pulses.
*/
data = (packed[1] & 0x80) ? 0 : PULSE_BIT;
So lircd clearly interprets the high bit as meaning "space".
I've use the UDP protocol for a long time, and have implemented the
client side of it a couple of times, including avrlirc. (See
(https://github.com/foxharp/avrlirc#readme) I've been reimplementing
some of my lirc devices on the RaspberryPi, and I'm using a clone of
irtext2udp to help me do that. That's how I found the problem.
irtext2udp contains this snippet:
if parts[0].startswith('pulse'):
payload += (1 << 15)
This matches the documentation, but not the lircd UDP code.
I've created a set of patches to fix all this, for both the documentation
and in irtext2udp. In addition, I've implemented a "--invert" flag
for irtext2udp which will restore the previous behavior, in case it's
needed.
I've created a ticket for all of this, and attached my patches there.
It's ticket #370. https://sourceforge.net/p/lirc/tickets/370
(BTW, I learned today, from old mail messages, that I've been running
lirc for about 25 years (!), starting somewhere around 0.3.6.)
paul
=----------------------
paul fox, [email protected] (arlington, ma)