read 433Mhz weather sensor - Lacrosse TX7NU

Projects Discussion and Showcase Device Hacking
#1

I've gone as far as I know how in trying to research ways to read the temperature and humidity from the 433Mhz broadcast from my Lacrosse TX7NU weather sensors. I know how to find and decode the transmission from the sensor using Audicity and a spreadsheet to input the bits. But I'm feeling quite intimidated by trying to go to the next step of figuring out how to code something that will monitor the transmissions, detect when a pulse is sent, and then find the bits of that pulse that contain the temperature or humidity.

I found an example of how to do something like this and it's looking it will be quite involved:
Practical Arduino - The Book - WeatherStationReceiver

I was naively hoping that this going to be a much easier project because there would be libraries that would take care of most of the low level work. But now I'm not so sure. I've played around with a few of those libraries like VirtualWire, RadioHead, and RCSwitch but they all failed to return any data.

Is there a 'library' way of doing this? If not could anyone offer some general general guidance on how to go about doing this? I've written plenty of C# code but this C+ is a whole brave new world and I'm not so sure how deep I can go without getting in over my head. So to some extent I'm trying to gauge if this might be overly ambitious for my skills.

Used the poor mans 'scope' to figure out what is going on. Discovered that about every 57 seconds a one second pulse is sent.

Here is a closer view of that pulse with the sections that contain the data bits of interest:

1769×194 9.08 KB

Here is further zoom of the temperature section showing the 44 bits that Lacrosse is known to send:

1510×192 9.15 KB

And here is getting the 44 bits from that section:

1066×192 6.48 KB

Here is a spreadsheet I made that takes in those bits and calculates either the temperature or
humidity:

1109×336 13.1 KB

I can provide more detail on how the decoding works if that will help.

Thank you.

#2

Might be going to far in explaining this but if you look at the radio signal it starts with a long off period (this is the sync pulse) and then a bunch of on/off periods to denote the zero/one bits. Luckily the only difference between a one bit (equal on/off period) and a zero bit (on for half the off period) is the on time so you can use code to measure the time between successive rising/falling edges you can usually decode the signal.
Attached is code I wrote for decoding my own sensor, it is not the same as yours but the principle is the same so hopefully you can enter the bit count, needed timings to match your signal and maybe invert the logic to decode it.

WeatherRF_me.ino (6.51 KB)

#3

Thank you. This is an easier piece of code to work with and learn from than the larger examples I was looking at before.

There is a ton of stuff out on the boards about 433Mhz and for someone with a very little EE background sifting through all it to come up with a coherent big picture view is not easy.

I just discovered something that I hope will be useful for that learning:
RF Basics, RF for Non-RF Engineers - Texas Instruments

I'm going to start diving into some of the details. It is looking more and more like the 'easy' (i.e. lazy) way to accomplish this task does not exist.

#4

@Riva: which sensor uses the protocol decoded in reply #1?

#5

TX7U Wireless Temperature and Humidity Sensor

Not much technical detail here
LA CROSSE TECHNOLOGY TX7U USER MANUAL

This looks like one of the better resources for Lacrosse sensors.
http://www.f6fbb.org/domo/sensors/

Here is says "Signals are transmitted on 433MHz, AM (Amplitude Modulation), OOK (On/Off Keying)":
http://www.f6fbb.org/domo/sensors/tx_signals.php. But I have no idea if this also holds true for the TX7U.

It also gives invaluable insight into how to do the decoding.
http://www.f6fbb.org/domo/sensors/tx3_th.php

But it was not exactly matching up with what I saw on the TX7.

This post decoded LaCrosse TX2U temperature sensor 433MHz showed how to decode the temp from the data bits for my TX7. And I just took some guesses to figure out how to get the humidity.

Hope this is at least a partial answer to your question. I can attach a *.wav file of the signal if that helps.

#6

jremington:
@Riva: which sensor uses the protocol decoded in reply #1?

Sorry to say but I have no idea what model it is. It is just a cheap thing like this I bought from ebay.

#7

This blog seems to detail the process you need to go through to capture & decode the RF data. The signal type/layout will not be the same but the principle is.
I had to capture a load of signals and note the temperature & humidity they transmitted. To get a good range of readings this was helped by putting the sensor in the freezer for a while and then start recording values as it warmed up after taking it out.
Also replace the batteries as this might generate a new random sensor number.

#8

Thanks for the link Riva and your interest in helping me. I've been trying to honor that interest by spending hours and hours over the past few days trying to learn up on RF.

This is going to sound crazy but a few hours ago this gentleman Emanuele Iannone just created a library that works for my TX7NU!! He build an impressive .Net project that works with the Lacrosse WS8610 base unit. A few days ago I contacted him about trying to decode the TX7NU sensor units which come with the base unit. Several days later he had it figured it all out.

Library: GitHub - eiannone/WS8610Receiver: Arduino libary for decoding RF signals of WS-8610 Lacrosse wheater station sensors

It's not supposed to be this easy. Saved me days if not weeks of trying to figure this out on my own. Hope that others can benefit from this work.

#9

Glad you got there in the end though for me most of the fun was capturing and decoding the signal. :slight_smile:

#10

Emanuele initially sent me a sketch he came up with for the Lacrosse TX3 sensor and I studied it really hard. It was very mind bending exercise to try and grasp some of the programming concepts I’ve never been exposed to before. All sorts of bit shifting and binary manipulations that I’ve never run into all my years of coding business applications. I added a bunch of comments to it try help and bring it down to my level. I also renamed a bunch of the variables but not because I was trying to take over the code but instead to help with my exercise of trying to learn the code.

Im thinking this code works differently than some the other decoding techniques because it is triggered by a long delay in the signal. That delay is the marker sent by the weather sensor to indicate that it’s data has been sent. When the delay occurs then the contents of the buffer is evaluated by the code. The buffer is 88 bits long with each item of the buffer being loaded with the time value in microseconds when the 433Mhz receiver data pin interrupt occurs. This buffer is continuously written to and is constantly being rolled over.

When the buffer gets evaluated the starting index is what ever index it was being loaded when triggering delay occurred. If that delay is occurred when when index 12 was being loaded then indexes 12 to 87 and then 0 to 11 are evaluated in order. This concept of what I’m calling a rolling buffer is not something I’m used to. I’d expect to see an array filled up from index 0 until the end and then read from position 0 to the end. And then I’d expect that array to be cleared out each time it’s filled up again. But not so here. And it works brilliantly.

I’m guessing this is good coding practices for embedded systems where lightweight and speed are primary considerations?

It took me awhile to understand that the code was evaluating all the time intervals for a certain pattern. That pattern is that a LONG or SHORT interval must be followed by a FIXED interval. A LONG followed by FIXED = 0 and a SHORT followed by a FIXED = 1. LONG, SHORT and FIXED are the microsecond intervals between the data pin interrupt changes. This pattern must exist across all 88 timings in the buffer. The microsecond length of time for these three intervals is not exact and have an allowable plus/minus fudge factor. I was not getting good results with the sketch until I started playing around with this fudge factor, PW_TOLERANCE in the code, and increased it. Then I everything started falling in place.

The breakthrough for me occurred when I dumped the entire buffer each time the triggering interval occurred. Dumping it the console was very wrong as there is no way the processor could keep up with the interrupts blasting away while also displaying the huge stream of data to the console. I’m guessing some other badness was also happening here with threading and memory that I don’t even understand. But the dumping made it clear what pattern needs to be. Then I just commented that dumping code out.

I have mention I running this Photon so you’ll need to fix the interrupt to get it working on Arduino again. Photon has built in wifi and can handle more libraries so it’s alot easier for my skill level to post the weather data to a url.

attachInterrupt(RF_PIN, storePulse, CHANGE); //Photon
//attachInterrupt(digitalPinToInterrupt(RF_PIN), storePulse, CHANGE); //arduino

This is cool stuff to lean but boy is it tricky. Also should mention that Emanuele’s code has now been tested on my side with TX4 and TX7 sensors in addition to his TX3.

WS8610Receiver.ino (9.69 KB)

#11

Riva:
Might be going to far in explaining this but if you look at the radio signal it starts with a long off period (this is the sync pulse) and then a bunch of on/off periods to denote the zero/one bits. Luckily the only difference between a one bit (equal on/off period) and a zero bit (on for half the off period) is the on time so you can use code to measure the time between successive rising/falling edges you can usually decode the signal.
Attached is code I wrote for decoding my own sensor, it is not the same as yours but the principle is the same so hopefully you can enter the bit count, needed timings to match your signal and maybe invert the logic to decode it.

Hi,
I have a problem with the specific example with an OEM 433 sensor. The readings is correct but are not getting every time the device is transmiting the data. I think that it has to do with the sync period but is there a way to find theese tresholds.

Thanks in advance.

#12

GeorgeAn:
Hi,
I have a problem with the specific example with an OEM 433 sensor. The readings is correct but are not getting every time the device is transmiting the data. I think that it has to do with the sync period but is there a way to find theese tresholds.

Capture the signal into Audacity and then you can zoom in and measure the timings.

#13

Here is a tutorial: Reverse Engineer Wireless Temperature / Humidity / Rain Sensors — Part 1 « RAYSHOBBY.NET

Bad idea to tack a new post onto a thread dead for 2 years.

#14