Ok I'm having trouble trying figure out how to determine where the transmission starts. Here are a bunch of captured transmissions, using long high = 1 and short high = 0. The blue columns add up to the temperature (x10) and the red columns add up to humidity (so first row, temp = 14.6 degrees, humidity = 51%). I'm sure I've got that right because I've checked with different figures over a day now and it's always correct.

The second block was a) when I brought the transmitter inside and b) when I took the battery out/in to see what would change.

So I can't make out what the first 4 bits are, they change a fair bit especially when the transmitter was outside (maybe took longer for the AGC to do something because of a weaker signal so those get mixed up?). The next 8 seem to be the station id as those are what changed when I took the batteries out. The last 8 bits are probably a checksum? But I'm not too familiar with different checksum techniques, I've tried a couple of things but haven't been able to work that out.

At least I know I'm on the right track because I've got the temp/humidity! But my main problem now is determining where the transmission starts. It doesn't seem to send any sort of start sequence (the preceding 1s are noise/indistinguishable from noise).

There should be a a sign bit for the temperature to indicate whether its above or below 0C.Sometimes also, there is a battery sense bit , to allow the indoor unit to indicate when a sensors battery needs changing.

Sometimes also, there is a battery sense bit , to allow the indoor unit to indicate when a sensors battery needs changing.

I don't think my weather station has this feature - the indoor part doesn't display that anyway.

Finding out how to determine where the start of the transmission is doing my head in at the moment, all other protocols look like they do something like send a few long highs (0s) to start off with but this one doesn't seem to. :~

Does the Wireless Station support more than 1 wireless sensor.Does it support other types of sensors like rain or wind.If so, then there have to be fields in the data transmission to identify sensor ID and sensor type.Usually at the start, there is a long row of 1-0-1-0-1-0 transitions to a/ Give the receivers AGC time to adjust to the incoming RF signal.b/ Provide the receivers data slicer with the halfway point of the 1-0 transitions.

Its normal for the next data field to be static as an indication of the start of the valid data, and its normally a value with an equal number of 1s and 0s .You sometimes cant figure out what everything means , as the manufacturers allow room for expansion and put data fieldsin the transmissions that currently have no use.

Ultimately, you may have to test your decoding skills, by making yourself a small transmitter using the companion 433 Mhz transmitter moduleand hooking it up to a microcontroller programmed to send a data stream , and see if the weather console responds to your transmissions.

No it doesn't support multiple sensors or other types of sensors. It is a very simple/cheap weather station, outdoor part only does temp/humidity. This is why the above transmissions include both the temp and humidity in the one go.

Although it only supports one wireless sensor, I'm fairly certain it's sending a "station id" in the transmission, as the instruction manual states that if the batteries are replaced in the outdoor part, the receiver has to be switched off/on AFTER the outdoor batteries are replaced because it has to "learn" the outdoor sensor signal. So it seems to "remember" the station id (probably just from the first transmission it receives) and from then on only pays attention to transmissions with that station id. If I take the battery out of the transmitter those 8 bits before the temperature (8 bits preceding blue in the above) change - they remain static until I replace the batteries, so I'm fairly sure that' s indicating the "station id".

I have a couple of ideas for looking for the transmission start, will test when I get home.. hope I can find it because after that I'm nearly there. Just need to figure out the last 8 bits which I think must be a checksum, but I have no idea how it's being calculated. So now I have an idea where all the data is in the transmission - just not how to determine where it starts yet!

If it only supports one sensor, then it wont have a sensor ID, but will have a rolling code .This is to prevent someone else who lives nearby and has the same weather station from interfering with your weather station.

When you put the batteries in the sensor , the sensor generates a random number and includes that number in its transmissions.When you tell the weather station to search for a sensor it simply searches for the first transmission it finds, and then remembers the random number,and then only responds to subsequent messages with that random number in them.The logic is that as the sensors transmit infrequently, the odds are that if you put the batteries in the sensor and then ask the indoor unit to search for itit will find yours first rather than another one .The random number changes every time the sensor is powerd up.

After some more testing I'm nearly certain that I just have to look for "0100" as the first 4 bits as an indicator of the start of transmission. When my transmitter is close, that's what I get 99% of the time. I think the problem is my antenna, because when I moved the project around a bit suddenly the first few bits got even more mixed up and when I moved it around again it went back to being 0100. I currently have the project on a breadboard except for the antenna pin which I have off the side of the breadboard with my antenna attached dodgily. It's just a thin 17cm piece of insulated wire that I've wrapped around the antenna pin (dodgy job).

So - what is the best material to use as an antenna and what is the best way to connect it?

The 17 cm wire soldered to the receivers antanna pin is the simplest and most effective.Dont place the transmitter too close to the receiver if you have an antenna connectedas the receivers AGC will overload.

Thanks heaps everyone for your help. Project is pretty much finished now. I have started logging the data and can create nice graphs: http://unit.homelinux.net:8888/~filip/weatherstation/

The checksum ended up being a CRC-8 with a polynom of 0x31.

I identify the transmission by the first 4 bits, 0100. The next 8 bits are the sensor identifier (randomly generated, changes when the batteries are replaced). The next bit is to indicate positive/negative temperature, then the following 11 bits are the temperature x10. Next 8 bits are humidity. Last 8 bits are the CRC. 40 bits in total.

Hi There. I've come late to this conversation. I've been struggling with almost the same weather station (Actually a WS1093, here in the 6th AU state, New Zealand). I also went down the sound card route and every 48 seconds saw the same signal Agrajag has posted. At that point I got completely lost. I'm also a software engineer, so the programming is easy, but the electronics phases me. That said, even the interrupt programming for the Arduino is a bit trickier than I'm used to (yep, programing iPhone apps, web services, I can do that, but I'm having real difficulties with low-level Arduino development). Long story, short. Please could you post the Arduino code you wrote. Thanks for any help. Derek

As your weather station is a WS1093, according to the specs for that station, it supports multiple wireless sensors, Temp/humidity, Rain and wind.Thats a bit differant to the OPs weather station which only supports 1 wireless sensor.Means that the decoding process is a bit more difficult.Most of these simple weather stations that use OOK 432.92 Transmitters use a simple form of Manchester Coding to improve the reliability of the Radio transmissions.They usually start with a sequence of 1-0-1-0-1-0- multiple times to give the receivers AGC time to adjust and to give the receivers data slicer a constant 50% duty cycle transmission so that it can find the 1/2 amplitude point , which it then uses to decide whats a 1 and a 0.After the 1-0-1-0-1-0 sequence , there is usually a fixed code called the sync word which never changes, and thats used to indicate that the next thing being transmitted is the Sensor data.This is where the detective work starts, as you need to capture this data and try to make some sense of it.Which usually means , if its a temp sensor, heating and cooling it , and watching what the data fields do.Since this weather station supports multiple wireless sensors, there will be Sensor ID fields to tell the console what sensor is sending, so it can work out whether its temp, wind or rain.Good luck, the programming of the Arduino is the easy bit.

Thanks for the tips. I've seen posts elsewhere hinting to the data layout and once I get reliable data value I'm confident I'll be able to crack the code. Right now however I'm trying to get a sensible bit stream. I get a steady stream of random 1 and 0 meaning I'm just seeing noise. I think I have to filter this (I didn't have, so don't fit the 1k resistor on the data line, but I'll try that next) then there are 4 further filter settings in the code: min, max, min long and max short, getting the right values for these seems to be the trick. I'm going for trial and error, but that's a lengthy process. But a challenge is good right?

In the absence of any input, the receiver winds its AGC to maximum, and that produces random 1-0-1-0 transitions on its output.You can generally tell its noise , as there will be no fixed time periods between the transitions , whereas with sensor data, the times between transitionswill be more ordered.Also the frequency of 433.92 Mhz is used by lots of differant devices that all will produce data that looks like valid data, so you need some way to know thatwhat you are seeing is your sensors and not someone elses.Not a problem if you have no neighbours.

Hi Derek - my main breakthrough was when I printed out the highs/lows that were bigger than a smallish threshhold (100usec from memory) and the how long they were high/low for. I would print a ^ for high and _ for low (I didn't want to use 1/0 because that was confusing me at first, this wasn't the binary data yet), and then the timing (using the interrupt) next to it. During the transmission period my program was printing something like:

^ : 125_ : 255^ : 375_ : 255^ : 375_ : 255^ : 125

When I saw that the lows were always 255 (or very close) and the highs were always 125 or 375, I knew I had it - just ignore the lows and look at the long/short highs. When it wasn't transmitting I would just get fairly random timings.

I don't currently have access to my computer that I wrote the code on that I know works but I do have a version that I "cleaned up", but I haven't even verified that it compiles yet let alone runs. The structure is pretty much the same as the practical arduino code but might be a bit easier to follow.