Receiving Lacrosse TX22U (IT+) weather station data using Arduino and RFM12B

I purchased a Lacrosse WS-1610 weather station a few years ago.  It uses a TX22U sensor/transmitter to send outdoor temperature, humidity, and also data from rain and wind sensors to its base stations inside home. It is still working very well.

This year I decided that I want to somehow receive its weather data directly and transfer them to a computer (eventually a RaspberryPI) for storage and creating more interesting records, graphs and reports. I started by searching the web to see if somebody has already done this and to gather information about the specifications of transmission  protocols that TX22U sensor uses. Unfortunately I could not find a similar work with my exact type of sensor i.e. TX22U. It seemed that this transmitter is a little different from other Lacrosse transmitters.   Everything that I developed and explain here is based on the information that I found on the following pages:

  1. This work by joob, marf and Rinie here.
  2. WS1600 logging by Götz Romahn which is based on this work by Fred B.
  3. How to connect Arduino to RFM12B.

First of all I should mention that I am working with the north America version of sensors which use the 915MHz band. I started my tests with a TX40U temperature sensor that I also have. Both my TX22U and TX40U sensors use newer Lacrosse technology which is called IT+. In north America they are on the 915MHz band and use FSK for modulation.

Here are my discoveries:

1)It seems that all these transmitters (TX40, TX22 that I tested and TX29, TX25 mentioned here) transmit their information around every 4 to 4.5 seconds.

2)They actually perform a frequency hopping between 910MHz, 915MHz, and 920MHz. So they change their transmitter frequency every 4 seconds. Lets say first 910 then jump to 915 then 920 and back to 910MHz. So if you want to receive all transmissions from these sensors you need to change your receiver’s frequency and hop to the next frequency after each successful reception.

3)Differences between TX22U and other sensors/transmitters: These tested sensors transmit their data at a bit rate of 17.241 kbps and their data frames begin with a “9″. But TX22U transmits its information with a bit rate of: 8.621 kbps. It sends a varying data frame up to 13 bytes and its frames begin with an “A” rather than “9″.

TX22U frame decoding is explained very well  by  Götz Romahn which I just copy and paste here for ease of use and reference:


BY Götz Romahn:

Data - organized in nibbles - are structured as follows
(example with blanks added for clarity):

a 5a 5 0 628 1 033 2 000 3 e00 4 000 bd
data always start with "a"
from next 1.5 nibbles (here 5a) the 6 msb are identifier of
transmitter,bit 1 indicates acquisition/synchronizing phase
(so 5a >> 58 thereafter) bit 0 will be 1 in case of error
(e.g. no wind sensor 5a >> 5b)
next nibble (here 5) is count of quartets to betransmitted
up to 5 quartets of data follow
each quartet starts with type indicator (here 0,1,2,3,4)
0: temperature, 3 nibbles bcd coded tenth of °c plus 400
(here 628-400 = 22.8°C)
1: humidity, 3 nibbles bcd coded (here 33 %rH), meaning of 1st nibble still unclear
2: rain, 3 nibbles, counter of contact closures
3: wind, first nibble direction of wind vane (multiply by 22.5 to obtain degrees,
here 0xe*22.5 = 315 degrees) next two nibbles wind speed in m per sec
(i.e. no more than 255 m/s; 9th bit still not found)
4: gust, speed in m per sec (yes, TX23 sensor does measure gusts and data are transmitted
but not displayed by WS1600), number of significant nibbles still unclear
next two bytes (here bd) are crc.
During acquisition/synchronizing phase (abt. 5 hours) all 5 quartets are sent,
see example above. Thereafter data strings contain only a few ( 1 up ton 3) quartets,
so data strings are not! always of equal length.

After powering on, the complete set of data will be transmitted every 4.5 secs for 5 hours
during acquisition phase. Later on only selected sets of data will be transmitted.

Stream of received data follows:

1st line: raw data in hex format as received from sensors
2nd line: meteorological data from outdoor sensors decoded, Same values
are displayed on basestation (last duet is "calculated crc" - always 00).

a1250444109120003808401b89 00
Temp  044 Humi 91 Rain 000 Wind 028  Dir 180 Gust 097
( 4.4 °C, 91 %rH, no rain, wind 2.8 km/h from south, gust 9.7 km/h)
a1250444109120003709401b41 00
Temp  044 Humi 91 Rain 000 Wind 032  Dir 157 Gust 097 

Acquisition phase is finished after 5 hours. 
( transmitter had been restarted meanwhile, therefore new address had been generated!)

a3832005380c401d59 00
Rain 025 Wind 043  Dir 180 Gust 104 
a3822005380fbe 00
Temp  042 Rain 025 Wind 068  Dir 157 
a38320053512400b66 00
Rain 025 Wind 064  Dir 112 Gust 039 
a383109120053712bc 00
Humi 91 Rain 025 Wind 064  Dir 157 
a382200532103d 00

Now here is my Arduino code whitch is based on the code by joob and some functionality from  Götz Romahn.  You can find the information on how to connect an RFM12B module to an Arduino here. But I also post their diagram here:

The following code receives TX22U transmissions without any error checking and prints out (On serial monitor) the frequency, raw data, and weather data:


After successfully receiving weather data from my TX22U sensor with an Arduino, I decided to try to read the data with my RaspberryPI.

Unfortunately, all my attempts failed and I decided to use a small micro-controller (AVR) to communicate with the RFM12B and read weather data from the TX22U sensor. The AVR can then also average the data over periods of 30 seconds or 60 seconds and RaspberryPI can read the data any time e.g. every 1 minute without any overload. This is important for me as I want my RaspberryPI also run other things like a web page, MySQL, …

Read the rest of this entry »

Third party firmware for Linksys WRT160Nv3

A couple of weeks before I decided to change my Linksys WRT160N router firmware to add some extra features to its functionality.

Here I will explain the procedure that I followed and then a little about the experience that I had with different Firmware versions.

After a little research I decided to use a modification of tomatousb by Toastman.

So I downloaded tomato-K26-1.28.7501.3MIPSR2Toastman-RT-Std.

I decided to follow installation instruction from DD-WRT and then use that firmware to upgrade to the Toastman firmware.

I used dd-wrt.v24-13575_NEWD-2_K2.6_mini_wrt160nv3 to begin with.

OK, This is the procedure:

1)Do a hard 30/30/30 reset.

2)Then connect to the router web interface at, you should see the management page. It takes some time until the router actually boots to the management mode . Do not reboot the router. Use the upload link to load dd-wrt.v24-13575_NEWD-2_K2.6_mini_wrt160nv3.bin to your router. Do not touch anything until router’s power and wireless lights are steady, it may take a couple of minutes.

3)Navigate to again and you should see DD-WRT password change page.

4)Without entering any password perform another 30/30/30 reset, go to and now click on reboot.

5)Navigate to again and you should see DD-WRT password change page, and now enter whatever password you want.

6)Now you can use DD-WRT firmware upgrade option to change your firmware to anything that you want. It is a sub-tab under the Administration Tab. To upgrade to Tosatman choose the firmware file which is  tomato-K26-1.28.7501.3MIPSR2Toastman-RT-Std.bin and also choose “After  flashing reset to default settings” option.

7)After the router reboots again you should be able to login using the default ID/password which is admin/admin. If you can’t login press the reset button on the back of your router for a couple of seconds and it should be reset to default ID/password.

OK, now the problems that I had with this firmware:

It worked for a couple of days very well but then it began to slow down wireless connections to the point that it basically was not working. So I decided to change it to something else I tested the following DD-WRT versions:

  • dd-wrt.v24-13575_NEWD-2_K2.6_openvpn_small
  • dd-wrt.v24-14896_NEWD-2_K2.6_std_nokaid_small
  • dd-wrt.v24-16773_NEWD-2_K2.6_std_nokaid_small

But all of them had wireless issues. The last one seemed to be the best. I later discovered that they use a higher wireless TX power than the default value and that might have lead the problems as I could see transmit errors but not receive errors. So I decided to use the original usbtomato to see how it works. I upgraded again to tomato-K26-1.28.9054MIPSR2-beta-vpn3.6. It is now running for more than a week without any problem. It is fast and very stable.