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 ). 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 ) 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.
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.
Hi Matt,
First of all may I congratulate you on the quality of the 'scope graphics, very nice indeed. 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.
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.
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.
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.
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
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.
). 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 
) it could give results very quickly.
