After a LOT of investigation of the La Crosse TX20, I’ve managed to fully decode the complete datagram from the La Crosse TX20 INCLUDING the Checksum.
Here’s everything you’ll ever want to know about the pin out and the communications protocol of the La Crosse TX20.
I’ve been running my unit on 5volts DC without a problem. The TX20 will transmit data every two seconds when DTR (Pin 3, Green) is pulled low.
If you connect the GND and TxD to a oscilloscope, you’ll see a waveform similar to the following.
The datagram is 41 bits long and contains six data sections. Each bit is almost exactly 1.2msec, so the datagram takes 49.2 msec to transmit nd uses Inverted logic (0v = 1, +Vcc = 0).
|A||5||Yes||LSB first||Start Frame||Always 00100|
|B||4||Yes||LSB first||Wind Direction||0-15, see table below|
|C||12||Yes||LSB first||Wind Speed||0-511|
|D||4||Yes||LSB first||Checksum||See below|
|E||4||No||LSB first||Wind Direction||0-15, see table below|
|F||12||No||LSB first||Wind Speed||0-511|
A – Start Frame and Triggering / Detecting start of data
If you hold the DTR line low permanently, the TxD line will be held low unless the unit is transmitting data.
The start frame is always 00100, but due to being inverted logic (making it detected as 11011), you can use a rising edge trigger / interrupt to detect the start of the datagram.
B – Wind Direction
The wind direction is supplied as a 4 bit value. It requires inverting and needs it’s endianness swapped. Once this is done it’s a value of 16th’s of a revolution from North. Thus it can be multiplied by 22.5 to get a direction in Degrees, or a 16 value array can be used to return the direction.
In the example image above, the Wind direction is read as 0011, Inverted to 1100 and then it’s endianness is swapped to 0011, which is ENE, or 67.5 degrees.
Table of the directions is below.
C – Wind Speed
The wind speed is a 12 bit value. It requires inverting and needs it’s endianness swapped.
Once this is done it’s a value in units of 0.1 metre/sec. The 3 MSB’s are always 000, so only 9 bits are used. With a max value of 511, this relates to 51.1 metres per second, or 183.96 km/h (114.31 miles per hour).
From the example image above, the wind speed is read as 111010101111, Inverted to 000101010000, then endianness swapped to 000010101000, which is 168, or 16.8 metres per second.
D – Checksum
The checksum is a 4 bit value. it requires inverting and needs it’s endianness swapped.
This is a 4 bit value of the four least significant bits of the SUM of the wind direction and the three nibbles of the 12 bit windspeed.
The checksum in the datagram above is read as 0101, Inverted to 1010, then endianness swapped to 0101.
For the datagram image above, the checksum would be calculated by:
|Wind Direction||1 – 4||0011|
|Wind Speed||1 – 4||0000|
|Wind Speed||5 – 8||1010|
|Wind Speed||9 – 12||1000|
As the Checksum received matches the calculated Checksum, the received data is likely to be correct.
E – Wind Direction (Inverted)
The wind direction (Inverted) is supplied as a 4 bit value. It doesn’t require inverting, but still needs it’s endianness swapped. It can then be interpreted like section “B” above.
In the example image above, the Wind direction is read as 1100 and it’s endianness is swapped to 0011, which is ENE, or 67.5 degrees.
F – Wind Speed (Inverted)
The wind speed (Inverted) is a 12 bit value. It doesn’t require inverting, but still needs it’s endianness swapped. It can then be interpreted like section “C” above.
From the example image above, the wind speed is read as 000101010000 and it’s endianness is swapped to 000010101000, which is 168, or 16.8 metres per second.
The checksum calculation is very simple and could easily be prone to errors where noise in the line results in invalid data which still matches the checksum.
As both the wind direction and the wind speed are sent twice, I suggest the following checks before a result is considered to be read correctly:
- Check that the start frame is 00100 (0x04)
- Check received checksum matches calculated checksum
- Check that Wind Direction matches Wind Direction (Inverted)
- Check that Wind Speed matches Wind Speed (Inverted)
Very usefully post! I think to buy one TX20 and make converter TX20 protocol to 1-wire .. Because my meteo station using 1-wire sensors…
With your information I’ve managed to build myself a working interface to connect the TX20 to a PLC
I’ve programmed a PIC16F1825 to poll the information from a TX20 and also talking RS485 Modbus RTU with the PLC
I’m using the PLC to control the temperature in a building using the TX20 to compensate for windchill depending on windirection.
Thank you for a very usefull post 🙂
is it possible to plug the tx20 into the rapberry pi board?
How can I get it working?
I just bought a TX20 and connecting Vcc-3.3v DTR-GND and GND-GND doesn’t give me any data on the TXD pin… I tried the TX20 on the original weatherstation and it’s working fine.
Do you have an idea which could help me ?
Thanks in advance
Do you know if it is possible to interface this unit with a Heathkit ID4001 Weather Computer?
Hello guys! At first I would like to thank for this great info, I’m building my own station with web server and protocol description came very handy. But I ran into interesting problem. Wind direction works exactly as described, but wind speed is not zero while no wind is blowing, anemometer gives out very strange numbers. I’m using TX20 from Technoline, looks exactly the same, but data are strange. Anyone else got similar results? Thanks.
Hello, getting strange values when no wind. Did you by chance found thé original of this ? Thanks Noel
I’m not quite sure what you mean by original. I reverse engineered the protocol myself. *This* is the original
Got the same result with my TX20 from Technoline.
Did someone find a solution for that problem?
same problem here, any suggestions?
I have the same problem as Pierre.
Is there any solution for this ?
Thank you in advance
ok… nevermind… I figured it out.
I adjusted the oscilloscope to the following settings:
Volt/ div = 1V
Time/ div = 5ms
Trigger level = 200mV
After freezing the signal on the screen, I can see the Section A of the diagram clearly and section B. After decoding section B as per the instructions above, I indeed do get the corresponding wind direction.
Thank you John for this very useful information.
PS. I am using WS 2307 WIND sensor
I connected a TX20 at the Printer port LPT on a PC based PLC
and your Protocol was very usefull.
greetings to the other side of the World
Great work, i have a TX20 harvested from a gifted weather station, I want to connect this to a Raspberry Pi, i see you wrote a library for the TX23 when your TX20 broke, did you ever write anything for the TX20?
Actually one bit is 1220 microsec, with 1200 (=1.2msec) you got errors.
Here is my ESP8266 solution with code:
My TX20 from Technoline has 1880 microseconds
thanks to your effort and a few steps from others, it is possible, among other sensors for light, temperature, air pressure, humidity … now oh with the TX20 wind speed and wind direction with the Tasmota firmware on a sonoff evaluate and using mqtt for home automation send
My TX20 sends only Direction no Speed, any ideas?