Intercepting 433mHz Signals from Bios CE1177 Weather Station

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.

Hi Matt,
I'd be pretty sure the calibration is done in the TX head unit as they would just throw together base units and head units into boxes willy-nilly and not try to match them so closely. I have actually written an Arduino TX unit that mimics the TX head unit on the Bios WS. My idea was to have a second transmitter for my RX-Apache-Ubuntu system to listen to, and I could include graphs of other sources such as my solar hot water and photo-voltaics or the cat leaving or entering etc. It would simply picked it up as another station with my RXer. To test this out I was trying it, and getting corrupted "test" signals picked by my weather station (not good!!!).

In the end I figured out I could connect one Arduino (Rx) directly to the other Arduino (Tx) and check the Manchester encoding etc without creating any RF interference. (It was neat to have two Arduinos connected to the one Laptop at the same time, with two IDE's running and being able to debug both at the same time. Well work on the TX code, and look at what the RX was receiving on the serial monitor screen :slight_smile: ). To try to cut a long story a bit shorter, if you can find the point the data feeds into the 433mHz TX stage and tap that straight into the Uno (through a 1k resistor if your are not sure exactly what your tapping into :sweat_smile:) it could give results very quickly.

However I would suggest tapping into the official line out of the Tx Head Unit socket would be best as from looking at my board it looks as though it has some sort of line driving buffering (2-3 SMD transistors?) to drive a long line with good data. However building a simple non-inverting transistor line buffer off the 433 point would not be hard either.

My Tx Head Unit also had a couple of healthy sized diodes (like IN4004's) near the sockets which may be used to stop reverse currents into the system. I still think polarity in your direct connect cables may have been a problem.

Anyway, over to you.

Rob

I have tried running your Arduino program (ver 20) as well as another one by Kayne Richens http://kayno.net/2010/01/18/arduino-based-thermorbios-weather-station-receiver-sketch/
I have tapped into a trace on my TX head unit as per the attached photo and the other two pics show some of the data wave form I am seeing. Based on the wave timings I don't think I have the right spot and neither program pick up any useful data yet.

I count what looks like about 96 header pulses and 13 (8 or 9 bit) bytes of data every 1.7 secs.

*edit
I think I have my TX head unit in "SET ID" mode. In "Normal" mode I don't see any pulses.

IMAG001a.BMP (47 KB)

IMAG001b.BMP (47 KB)

Hi Matt,
First of all may I congratulate you on the quality of the 'scope graphics, very nice indeed. :slight_smile: I assume you can see about 80-100 ones (ie short pulses) leading into this data? Is one graphic the start of the header (many short pulses) and the second graphic a sample of the data (ie short and long pulses in either polarity)? That 5ms break though looks a bit strange and a bit worrying??? I have included my primitive Audacity screen capture of my data for you to look at. The top line is the signal, and the line below shows the activity of the CPU. The little "blip" is the CPU time processing the received bit before waiting for the next one.

It looks as though you might be on the right point. Those waveforms look a bit familiar, but I am not entirely convinced. The piezo could be used as a signal probe as you ear will pick the data packets. Though with a 'scope like that my advice may be redundant. You could solder a piezo transducer across that point and you should hear the "pure" tone of the data packets go past. I found hearing the packets was really handy as I knew how long it would take for the next to arrive eg approx 40 secs and I could associate any activity on the screen with data passing. Maybe your data polarity at that point is inverted, but I don't think so. My Arduino->Arduino worked.

My Version 20 may well be looking for my station number of "3" whereas your WS will start up with a random number 0-255 (or thereabouts) each time you power it up. Plus you will have to wait until the 4 or so Synch packets have been sent before the real data arrives.

I have put my very latest Version 22 below as well as a cut down Version of 22 called Debug. It has the Pressure and Humidity bits chopped out, and no filtering of the station number. The Debug version should announce the Synch packets and show the station number. It will also show the binary version of the packets for the first three packets and then show combined processed CSV data in between binary packets after that. Each packet type arrives in rotation 1,2,3 in 40 second separations, so it takes 40*3 seconds before all three packets can be combined into valid CSV style data. This may have been holding you back as you probably did not realise it could take up to 3-5minutes before valid data arrives, especially if the synch period is also included.

The Debug version should respond as soon as a packet arrives and flash Pin13 when ever a data stream passes and a header is detected. It maybe a good idea to power the Head Unit with batteries so a constant station number is produced during this time and synch activity is over and done with.

I hope this helps, you could be very close!!
However on the other hand, chin up!!

Rob
PS you may notice on the Audacity/CRO example below I have got the primary channel looking at the incoming signal from the 4333=MHz Rx and the other stereo channel looking at OutputPin13 ie the onboard LED. This allows me to ste and reset pin13 at critical parts of the waveform and see what the CPU is doing within the Bit timing, The small peak inside the low bit is the time it takes to process the bit and get ready for the next one and [ack the bytes etc. Other people may find this a handy debugging idea for cracking other Serial Protocols. Good luck.

MyOwnEX22.ino (19.4 KB)

DebugVersion.ino (18.7 KB)

Thanks for sharing your code. After analyzing my data and comparing it to your code and the notes in your program, I'm starting to think my data stream is structured slightly different. I see some patterns related to the rain indicator but I could not see any changes in data in respect to temperature or wind. Seeing as I want external humidity, I would have to use my own sensor (probably a DHT22/AM2302) which usually also includes temperature and the rain gauge is just a simple reed switch, I think I will work on interfacing directly to the sensors with an Arduino. For the anemometer, I'm going to try reading the encoder directly, similar to these two blog posts.
http://www.100randomtasks.com/weather-station-remodel
http://www.100randomtasks.com/weather-station-part-ii

Let me know if you are interested in seeing my collected data. Thanks again for your help.

No Probs Matt,
Your investigations have broadened my view on my own hardware as well. The website you referred me to shows internals in his BW951 which are different, though not by much, to mine. I was hoping I still had a choice to either totally swap models and/or brands if (and when) the current WS breaks down OR just buy a swap over replacement for the BW951. Obviously I would be expecting to use my current software, however that may not be the case.
Over the last few months of excellent reliability I have grown to re-like my Bios/Arduino system and would not appreciate having to begin all over again.
I have a DHT22 on my home base to measure humidity, and it does give a temperature reading, but looking through slots in the shell it appears to be a thermistor type sensor. I maybe wrong, but I preferred to use the temperature sensor on the air pressure sensor as it appear to be digital, and hence more accurate and stable.
The internals of the BW951 are quite rugged and the Gray Code encoder is well built.

I wish you every success and thanks for the correspondence, if you start a new Post then I will post a link to it here if you drop me a line or two on your progress.

Rob

The DHT22 is supposed to use a DS18B20 for temperature (according to the pdf from adafruit), although it doesn't look like one.

I successfully have an Arduino decoding the 4 bit grey code encoder and calculating RPM from the wind speed sensor. Somehow I will have to convert RPM to MPH yet. Decoding the grey code turned out well as I got my 4 bits in order the first time, although in reverse order but that I took care of with some LSB<->MSB switching. I also had to add a small ceramic capacitor to the wind speed and rain inputs to debounce the reed switches. The bounce was actually so consistent, most of the time I could just divide by 2 but not quite the proper way to do it. For those two inputs I use the two interrupts and the wind direction is read whenever the Arduino is not busy with something else.

Hi Matt,
You have certainly made good progress. I checked my humidity detector and it appears to have two sensors, one is the rectangular white one (the same as what I removed from the base station in the Bios) with interleaving finger like contacts on it and the other is a two legged black blobby one, that I took to be a thermistor. I have seen where a DS18B20 (usually a three legged device) can be used with only 2 out of the 3 legs connected. Very clever bus design!

You did well with the Gray Code, I had to go back to my oldest files (the Console-USB-Linux code!!! From about 6 years ago) to get a grip on it. Tapping into the right points on those PCB's would be a challenge.

Now, I find what you have done with the rain gauge very interesting. I have been very concerned that my rain gauge is not calibrated right and I have had several different tries at it. Currently I using a small rain gauge out on the fence to gather "standard results" and checking them against the WS. Yesterday, by chance, we had an early morning down pour and I checked the standard gauge and it reported about 10mm. My WS was reporting 4.5mm. A factor of two discrepancy!! I got up on the roof to check there were no blockages and no spiders had taken up residence, took the cover off and rocked the detector a couple of times to see that it was free. When I got back down and checked the Bios->Arduino figures, the rain gauge had jumped about 45 "clicks"., way more than I had triggered. Maybe my Bios gauge is not triggering cleanly and either missing pulses, and/or bouncing as you have said and adding in extra pulses.

Very curious. Do you do a software "debounce" in your interrupt routine or just take it raw?

If you would like to start another thread more closely on your topic, let me know and I will follow it. I don't mind it being here but you might get more people more closely aligned with your approach (which is bearing fruit!!!) with your own topic.

Cheers and congrat's,

Rob

I got Lacrosse/TechnoLine Weather Station WS2355 and also few cheap 433Mhz receivers [1] and antennas for them [2] but I have found out that they have really small range, they work only in same room upto 3m/10ft, anything beyond that they stop receiving data when connected to arduino...

Original WS2355 receiver works through thick indoor walls upto 30m/100ft, which is quite impressive.

This is original receiver in WS2350 weather station, thin wire is antenna:
https://secure.flickr.com/photos/valent_turkovic/13380962533/in/set-72157642850005724

I'm looking for good 433Mhz receivers that I can connect to Arduino and collect data from weather station, but one that has good range, because these ones I got are really bad for anything beyond few meters...

Are there shops that sell finished 433 rx modules, or some ebay shop that sells internationally? Ebay is definitely preferred because of price and also easy worldwide shipping. There are quite few US based shops that have crazy shipping prices, so rest of us outside of US can't use them :frowning:

[1] http://www.ebay.com/itm/121117930415
[2] http://www.ebay.com/itm/371027094605

Hi Valent,

Your boards seem to have some similarity with the Bios/Thermor setup with RJ-connectors to skip the RF connection if required. However that aside, you also have another low frequency antenna there with the ferrite rod. I would guess the base unit can synch with the Radio Time signal?

Low detection rates can be either signal strength/Rx sensitivity or mismatch with the software.

I agree the long red wire curling around the top is most likely the 433MHz antenna. If you measure this it will give you an indication what it is tuned to. From memory, around 170mm is 433MHz. For these purposes it only has to be within ball park range to work well, though you might like to look up the exact length and maybe fine tune yours by changing the length. I would certainly start by attaching a wire the same length as the red wire to your Rx begin with. I am surprised that you are only getting that sort of reception. All of my current Oregon Scientific sensors are within6-7 meters, but do pass through the upstairs floor, and they are on top of a big corrugated steel roof, so a fair bit of shielding around, but they have been very reliable with very little data missed.

I am currently using the classic Rx design unlike the ones pointed to in your reply. I will add my circuit below that I use with them as I have found some of the 8 pin jobs have to be connected correctly, ie there are a number of "earths" to be dealt with. The piezo transducer (not a buzzer!) was added to the digital output during debugging to listen for data packets and I then watched on the IDE screen whether they were detected and decoded successfully or not. This could be worth trying for you as it would allow you hear if the packets were arriving (the white noise changes to a distinct chirp) and if your software may not be trapping them successfully. The OOK system is basically an analogue RF system adapted to send digital information. Unless the Rx amplifier is centered in the sweet spot of the signal, the on/off times can be become quite distorted and much harder to decode reliably. The AGC on the Rx has to be stable (hence the need for header bytes) and a good signal strength to turn AM bursts into a digital stream.

Likewise the software you are using may also need tuning as well for your situation. Especially if your piezo is indicating packet bursts are being missed. Manchester encoding (I presume you are using this sort of signal decoding) is quite tolerant and can be +- 15% out with the timing intervals and still manage to get many of the signals decoded correctly. However it is so much more reliable if it is closely aligned duration of the bit delays coming from your Tx. Some some experimentation there could be good.

Finally 433MHz receivers are fairly prone to RF noise, so I use a long USB cable on my 24/7 web server to get it away from the computer, however I found short ones while debugging on my laptop have been OK. The Rx and Uno set up was identical for both the Bios/Thermor and now the Oregon Scientific, just different software. I am about ready to post the latest OS software as there a quite a few interesting updates.

If you are after a higher quality Rx/Tx system have a look at the Dorji 433MHz line. I have used both at times, but just ended up getting my system to work first with the old classic 8 pinner Rx, and so have stuck with it. The Dorji though is a far superior design and technology. http://www.wiltronics.com.au/catalogue/200791/picaxe-rf-dorji-robots-kits/rf--dorji/dorji-ask-modules/dorji-fsk-rx-modules/dorji-433mhz-107dbm-ask-receiver--dip-package

Cheers, Rob

2014-03-26 10.48.00x600.jpg

2014-03-26 11.15.23x600.jpg

Rob: I cannot find your Arduino code!