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:
- This work by joob, marf and Rinie here.
- WS1600 logging by Götz Romahn which is based on this work by Fred B.
- 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, …