Intercepting 433mHz Signals from Bios CE1177 Weather Station

News Flash: Bios WS Anemometer dropped a bearing, so now posting solution to Oregon Scientific sensors.
Pls search Forum (reason could not buy direct Bios replacement in Australia) Adieu Bios!!!!

Hi Folks,
I use a Bios weather station to link into my Web Server in my garage to add real time local weather information to my website. Currently the system has a wind direction, wind speed, temperature and rainfall sensor information being radio relayed 433mHz off the roof to a receiver inside the shed. The Bios receiver has a USB interface that is currently interfaced into my Ubuntu server with a piece of code that produces a serial interface which is interrogated by a complicated Python program (mainly due to processing the Bios format that I want to bypass) I wrote. This Python program produces 12 hour graphs and other nice things, see : http://www.laketyersbeach.net.au/weather.html.

  1. Our Mains Power is lost due to occasional outages, or batteries dying, and re-establishing the link with the transmitter is tedious.
  2. Sniffing the signal with a Uno+433MhzRx is easy (see images below).
  3. Demodulating the signal using Manchester Encoding to a stream of 1&0's is under way and now working correctly, rock solid.
  4. Four types of data structures are sent alternatively every 40secs approx. Sync, Wind, Temp and Rainfall
  5. Data is repeated 4 times over for error detection, though length of data changes for the four different data types, sync, wind, temp, rain.
  6. Binary version can be used to calculate, Wind Speed, Wind Direction, Temperature and Rainfall.
  7. CSV values exported to Ubuntu Web Server at exactly 1 minute intervals

This is the final version of the code for the moment, it works extremely well.

I note with a little pleasure that quite a few people have followed this post up, though I expected it to be a rather specialist area, while not too intellectually challenging, maybe of little interest to so many, however I will continue to post my progress with my code so far in the hope that maybe some other enthusiast will build on what I have done and maybe figure out how they do the "wind gusts" and "battery condition" and "Signal strength" in their transmissions.

Also I believe I have a really good handle on Manchester En/Decoding in this program and even that maybe of use others decoding other brands of weather stations.

I am looking forward to a much simplified data transfer format. Ahh blisss!!! I can then simplify the Python program and update it as well.

Cheers, Rob

PS Please read later postings for improved Arduino Code

Hiya Rob,

I just picked up a weather station today with the aims of doing exactly the same thing as you have.
I've got some Arduino gear but no 433Mhz rx yet. Can you point me to where you got yours?

I'll add any info I find about my station to your page.

Thanks!
-Dan

hi Dan,
Just be aware I have updated this page a few times and the latest Arduino sketch should be #17. I finally cracked a very good Manchester decoding routine in #17 that I am very pleased with. I have also got a simple Python program below to demonstrate how easy is it to get Arduino serial data back through the USB into a Linux machine running Ubuntu and Python.

import serial
ser = serial.Serial('/dev/ttyACM0', 115200)
print " ii, pp, Quad, Speed, Rain, ExTemp, InTemp, Press,Humi  @115200" 
while True:
   print ser.readline()

A Rx at 433mHz that might interest you is http://www.jaycar.com.au/productView.asp?ID=ZW3102.

Plus my weather Station is badged a "BIOS BW972", however a similar looking one is the Thermor DG950 Wireless Home Weather Station (see photo below). I suspect the internals are exactly alike (the externals are!) so the code should work on these as well. I have tried to find my Bios on the web and it looks as if it getting low in numbers. I had to buy a whole new system about 2 years ago because a cup broke off the anemometer and the same storm damaged the input from anemometer/direction unit to the transmitter.

I would be very interested to hear of what brand station you are using, as the data protocols differ from brand to brand.

Cheers, Rob

ThermorDG950.jpg

Cheers Rob,

The one I got is this one:
http://www.jaycar.com.au/productView.asp?ID=XC0348

I've ordered what looks to be the same receiver as you mentioned. I also took a punt on a couple of cheap ones from china. They were only about $1.30 each with free shipping so I figured it was worth a gamble.

When they get here I'll see what I can do with the arduino.

With the data stream that you got, how did you know what it was? I mean, did you filter it for ascii conversion or was it just a stream of numbers?

Aha Dan,
That was the one I was considering if I couldn't find a Bios replacement. So that could be good if I swap brands. I particularly like the compact nature, ie they all fit on the one pole and there is a solar power option (I think?) as well. My code will be very unlikely to transfer straight into it but the general principles could help heaps. However I suggest you don't immediately bolt it to your roof but keep it in your lounge room so that can set up the direction etc in a trial situation and see how the number you find change. Mine is on the roof right now and I am just guessing a fair bit of the time, and seeing how it correlates with what the console tells me.

The data stream will probably be Manchester encoding so that part of the program will help heaps, however once you have the binary data samples you will need to tease them apart to find what binary relates to which readings. This can be a pain and any research you can do on that before the RX's turn up the better, it could save hours of frustration and after all, why did they invent the internet if it was not for these major IT discoveries to be shared :slight_smile:

The Bios machine uses a mixture of simple 4 bit binary to integer (wind direction), rain is 12 bits integer, temp is 3 bits of BCD and speed is an integer with about 12 bits again. Rather messy. If you are going to do any maths with them you maybe converting them all the time backwards and forwards as it suits. There are quite a few other binary bits I have no idea what they mean, maybe things such as battery condition but I don't know where it is in the data patterns. :slight_smile: There maybe a CRC there but as yet I have not decoded it.

I have changed my program slightly, I was truncating the air pressure and there was only zeroes after the decimal point. I will post it probably tomorrow night, I am momentarily distracted by getting it to work on my python program. Not so easy either (NB fixed by subtracting the LF/CR from the imported serial string in python).

Cheers, Rob

Thanks Rob,

Yeah the solar battery recharger is standard on this unit. I noticed that there was some discharge from one of the rechargable batteries so I'll probably buy some new ones rather than let it corrode the system.

I'll definitely check to see is anyone else has decoded the stream before me :wink: Then when the rx units arrive I'll have to dive back into arduino/electronics. The arduino programming side does not phase me but I'm a pretty big newb when it comes to circuits.

Stay tuned....

Forgot to add, Dan, that the detect a header part of my Manchester en/decoding should be Ok with a little tweaking of the delays, this can be debugged pretty easily and once that far, knocking out some binary dumps of the data is pretty easy. Assuming that it is Manchester. Then the fun detective work will begin.

I hope those Rx's are quick. I can help on the circuit side, I taught Electronics from yr8-yr12's in local secondary school for 12 years :cold_sweat: Nearly all Picaxe for them as it was easier, but Arduino is lovely as it is not so dumbed down, and I feel like I can spread my wings. I retired 18months ago.

Cheers, Rob

Hi Dan,

Progress has been excellent if not smooth. Usual bumps and grind, however I now have a functioning superior replacement for my old set up. So the Bios BW972 Weather Station or Thermor DG950 should yield to this 433mHz and Arduino interception. The BMP085 air pressure detector is excellent and no more corrections required, just read it and plot it. I have also had a go at calibrating the rain gauge by pouring 250ml of water into a container with a small hole to drain into it, calculated collecting area, and found #tips*0.183 = mm rain. The wind speed is still a problem as I do not have a good anemometer to check it properly. I have ordered the humidity detector and I will add it in soon. At the moment the Arduino just generates a dummy value to keep my python program happy.

I am now ready to solder up a permanent shield and make an installation. It has taken me 3-4weeks of hard slog (ie on and off, depending on inspiration and perspiration), but has been about 6 years in the searching phase, so to speak. Thank you Arduino team!! Brilliant!!

I have also been able to clean out my python code of all the cruddy compensation code that tried to make up for the linux/USB interface I previously used. This pathway simplifies the task and puts real control back in the hands of the designer. I am very pleased with the outcome so far.

Enjoy, Rob

PS I wish I could modify the heading of this posting as the CE1177 actually refers to the RF Interference certification and not the model number of the Weather Station!!! =( :cold_sweat:

PPS Please see above postings for improved listing

Hi Dan

Working really nicely at the moment, rock solid!!! http://www.laketyersbeach.net.au/weather.html

I am now working on a rainfall page now that I have complete control over the data, I was hesitant to develop the python side of things these last few years, but now I am a lot more confident of the accuracy and source of the data.

Have you got your 433-RX's yet?

Rob

Hi Dan,

I have built and tested the shield with the RX and Barometer attached. I intend to use the patch board version until the Humidity detector arrives and mount it straight to the permanent shield, get it working, and then swap the permanent board into service with a bells and whistles.

I have also made some good progress with the Linux/Python set up as well but that is another story.

Rob

Hi Dan,
Wouldn't you know it? I post a picture this morning and the Humidity detector arrives in the mail. Out with the soldering iron and on she goes. Only took a few minutes to add in the library, then copy in a half dozen lines from the supplied example, re-jig the python and hey presto I now have humidity on my WWW as well. Lovely.

The latest program is MyOwnEX22.ino is attached with latest photo of final (?) shield version.

I also stripped the broken wind/temp sensor apart and will post the Bios internals on a later post (not much interest to you but it does reveal a few design strategies).

Cheers, Rob

MyOwnEX22.ino (19.4 KB)

This could be interesting Dan, from Sourceforge ie http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf

But I am not sure what brand your weather station is? The Altronics link did not mention a brand?

Rob

Hi Dan,

So you have an Ambient. It looks a good machine, I particularly like the solar charging of the batteries. I have looked up the three articles, but not the first. Both Manchester and OOK use ASK in these Weather Station cases. ie the 433 carrier totally disappears in between bursts. How this is interpreted is up to the way it is encoded. That one Ambient article would indicate that they probably use OOK for all their machines and probably vary the packet structure accordingly. So assuming OOK and the timings given would be a very good starting point.

Check this guy's article too, not Arduino but Raspberry-Pi but he makes very good observations that back up your articles
http://www.susa.net/wordpress/2012/08/raspberry-pi-reading-wh1081-weather-sensors-using-an-rfm01-and-rfm12b/

My Manchester code may not be that useful in its present form as Manchester has a standard data pattern length, whereas other OOK's can vary. This one has variable lengths for 1 (high 05.ms, low 1ms) and a 0 (high 1.5ms, low 1ms) but has the same the underlying concept of

  • getting the status of the line, waiting and
  • re-sampling to check it's not noise ( ie polarity has stayed the same) and then
  • wait some more to see if polarity has reversed, ie it is a 1, or has stayed the same, it is a 0, then
  • test similarly for the 1ms "low" separator and
  • try again.

You might like to use timer interrupts, but I prefer simple delays, conceptually easier for me to deal with, and this is the main task so no real need for pulse checking in the "background".

Cheers. Rob

Hi Dan,

Another trick I found handy when my Manchester decoding was decidedly flaky was to toggle output 13 (+LED) at critical debug points in the program and then look at the output of the Rx (as fed into the Arduino) into, say, LH Channel of Audacity and the Output 13 in the RH Channel of Audacity. Take a screen grab at the right res' and a printout and it doubles as a cheap dual trace storage 'scope. I got the pencil out, ... found my delays were quite accurate and level sensing OK, but discovered after that my Manchester decoding was what was flaky!!!

My son Nick put me on the right algorithmic track about being more careful about keeping track of the state of the signal with wobbly status variables. Tightened that up and now it is rock solid.

Looking forward to being able to compare the two weather stations at the code level.

Cheers, Rob

Hi Folks,

My Arduino replacement for the Bios BW972 Weather Station (or Thermor DG950) base unit has been working very reliably for the last two months or so. I will provide the latest version (22nd) of the software below with Pressure and Humidity sensors fully working. I have also included a graphic of the 7 images of graphs my Python program produces from this data (arriving every minute, though the three types of packets arrive at 40 second intervals so it takes 3x40=120secs for a full update). The website is http://www.laketyersbeach.net.au/weather.html if you are interested in seeing it action.
I have also done a "tear down" on the wind direction and wind speed unit as well and can publish the photos here if you are interested. It is better than the price would indicate.

There are a few extra statements/routines that don't appear to be used, but can un-commented if debugging is required.

The code lends itself to reporting the data as either processed weather readings and out-putting the accumulative real values (eg temperature in degrees Centigrade) every 60 seconds, or if desired the raw numbers in each packet could be output every 40 seconds and broken up and converted by the Python program, The former is convenient, however if there was a need to transmit other data to the receiver the latter maybe more versatile in processing different data sources.

I have also devised a program that broadcasts data that this program can receive and process and will publish it here if people are interested. It provides a very stable 433MHz data link with Manchester encoding.

Cheers, Rob

PS Sorry if you are a C++ Guru and find the comments excessive, but it is the only way I can build a picture in my head.

My Bios station looks pretty much identical, but I'm looking to forgo the wireless like and wire an Arduino straight into the transmitter or the individual sensors. So far all the tutorials I find are going wireless, but I somewhat expect the data stream to be the same pre-transmitter. In my case though, something is wrong with my station as I have never been able to get it to work wirelessly and using the wired connection also just shorts out the power supply. If it's the fault of my sending unit then I'll want to go directly to the sensors. After opening up my anemometer I see that it's some sort of serial connection. Any pointers?

Hi Matt,
A lot of the engineering work is done with the Gray Code wind direction system and the wind speed (magnet and reed relay I reckon, I did not strip it to the last bit) that you could use, though I am not sure how sensible that is. When I pulled my wind speed/direction apart I was pleasantly surprised with the quality of the finish. If they had put the same amount of effort into their USB->PC interface I would not be where I am now with the project. That is another story. I would check the polarity of the of the RJ-4 (?) direct sensors-console cable connections, when held side by side they should look the same, ie it is not a crossover cable, otherwise I think you would definitely short out the power supply with such a cross over cable.

Also just to double check your set up and lack of signals, I was having trouble making connections one day when I was pulling out batteries to reset the transmitter and forgot I had not pulled all one side out, and because the transmitter batteries are 4 cells with two pairs in parallel, the circuit had not been interrupted (why they did not have a simple reset switch for I don't know, pulling batteries when I am up a ladder is a clumsy feature). Also make sure the LCD Base receiver has been reset (it will wait indefinitely), before you do the transmitter, the transmitter only sends about 4 or so "synch" signals so that the base station can latch onto that channel number. So reset console, reset transmitter, wait for console to catch synch. If you think the signal strength is s a problem take the TXer to the RXer. My software below gets around that (though the new station number on Txer Battery replacement start up still needs to be changed in the Python program).

I was getting so frustrated with my old set up (however I had one system broken and yet bought a second one) I was going to go down your track where I had 100% total control. My engineering skills are not that good and the head unit on the system is quite good, and worth working with, rather than junking the electronics in it as well as the LCD Console. The reliability of the whole thing now has far exceeded my expectations. It would be worth building my RXer I have shown below as you will have to make one with your model anyway (I am guessing you will be using some sort of wireless connection?). It will work on a prototyping board quite well so no soldering required to begin with.

Cheers, Rob

PS I have added some strip down photos of the wind sensors for you to look at as I had to wreck mine to get it apart. Not a good point to get to if you intend to reuse it :). I had a cup break off the anemometer, so it was useless to begin with.

I have had this Bios system for a few years and several times I tried to get it running. After I gave up on it, I bought a different unit that I currently operate which connects to my Ubuntu server via usb. The wind and rain sensors have quit on this system and although I have a replacement on hand, I was thinking I'd like to move to something more robust, and that includes no wireless. I usually try to run a wire whenever possible, no battery or interference issues. I have partially opened my wind sensor enough to see what looks like a one-way SPI type digital connection between it and the main transmitter. VSS, VDD, SCLK and DATA are the four labels. It now seems to me that it might be best to still use the main transmitter box but instead of wirelessly receiving the data, I'd like to patch in right before the RF transmitter. Is it reasonable to expect the data format to be the same there as after you receive it? Then I could make use of your existing code.

Hi Matt,
I have got my "stripped" (destructed?) system out again and have included some photos below. Your PCB does not look like mine at all. However I can see your line of argument with the no batteries and not station ID's to worry about. I have only used SPI on a few Arduino products like LCD's and SD cards where all the hard work has been done by someone else, it is now something I am familiar with. Though I can now see where you are coming from. However I am not clear as to whether you are going to tap directly into the wind direction/anemometer unit or the head TXer that houses the batteries etc?

The wind direction/anemometer unit on mine does have an SPI sounding connection down to the head TX unit. ie Yellow=Vcc, Red=SCLK, Green data, Black Vss. So you could possibly tap directly into it.

The TX head unit has a single output that goes to the on-board 433mHz Transmitter and it could be directly decoded from the Arduino. the 433 is sent as bursts of RF, all on or all off so a simple digital signal. Connecting the Arduino with my circuit directly into where the signal for the 433Tx enters, ignoring all my and the Bios RF sections and it should work. However whether the Direct connection provided by the RJ4 jacks on the back is the same or not I don't know. It should not be hard to find out, yours maybe easier to trace.??

Either way the information in the program as to how the data format is byte structured will probably be invaluable in sorting out any data streams you can tap into.

I had tried direct connection as well, but I preferred in the end to have a wireless link to a potential lightning attractor coming directly down into my web server. Having it connected by wire to the modem and 240V supply is bad enough :-(.

I hope this is helping, let me know how you go,

Rob

robwlakes:
However I am not clear as to whether you are going to tap directly into the wind direction/anemometer unit or the head TXer that houses the batteries etc?

Ha ha, I'm not clear yet either which I will try first!

Too bad our TX boards are different, but I think I will start by trying to tap into the TX board. I'm hoping that way your code will work and maybe the sensor data then is all calibrated...unless the RX'ing display does that.