Help with 433mhz receiver

ah-ha! After reading that oregonscientific pdf I realised I wasn't quite going far enough and that I needed to look at the timing of the highs/lows in the transmission period. I now know that the highs in the high/low period are either very close to 372msec or 130msec (all low periods are about 255msec). So, on to the next step of decoding the long/short highs.

Figured it out :smiley: After the above post I just captured a bunch of transmissions and recorded the long/short highs. Guessed that a long high = 1 and short high = 0. Found that there are 12 bits that equal the temperature and 8 bits that equal the humidity, bingo! Just need to figure out what the other bits are now, I'm guessing perhaps a station id (I think this changes when I replace the batteries in the transmitter) and a checksum. Will write up the protocol when I've got it all sorted.

If your weather station caters for more than one temperature sensor, there will be some kind of sensor ID code to differentiate between them.
Its also fairly common for there to be some kind of logic to differentiate between sets of sensors, to prevent the problem of you having a weather station and a nearby neighbour also having one and the sensors interfering with each other.
Reverse engineering wireless weather stations sounds simple, but its quite often fairly complicated.
Im currently trying to do the reverse of what you are doing, making my own sensors for an existing weather station.

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.

111111111111 1100 1110 0101 [color=blue]0000 1001 0010[/color] [color=red]0011 0011[/color] 1010 0001-
        1111 1000 1110 0101 [color=blue]0000 1001 0010[/color] [color=red]0011 0011[/color] 1010 0001---
  1111111111 0100 1110 0101 [color=blue]0000 1001 0010[/color] [color=red]0011 0011[/color] 1010 0001----
 11111111111 1100 1110 0101 [color=blue]0000 1001 0010[/color] [color=red]0011 0011[/color] 1010 0001------
        1111 1010 1110 0101 [color=blue]0000 1001 0010[/color] [color=red]0011 0011[/color] 1010 0001---
     1111111 0100 1110 0101 [color=blue]0000 1001 0010[/color] [color=red]0011 0011[/color] 1010 0001---
          11 1000 1110 0101 [color=blue]0000 1001 0010[/color] [color=red]0011 0100[/color] 0011 0110-----
         111 0100 1110 0101 [color=blue]0000 1001 0010[/color] [color=red]0011 0100[/color] 0011 0110----
      111111 0100 1110 0101 [color=blue]0000 1001 0001[/color] [color=red]0011 0100[/color] 0001 1011---
         111 1100 1110 0101 [color=blue]0000 1001 0001[/color] [color=red]0011 0100[/color] 0001 1011------
       11111 1010 1110 0101 [color=blue]0000 1001 0001[/color] [color=red]0011 0100[/color] 0001 1011--
  1111111111 0100 1110 0101 [color=blue]0000 1001 0001[/color] [color=red]0011 0100[/color] 0001 1011--
        1111 1100 1110 0101 [color=blue]0000 1001 0001[/color] [color=red]0011 0100[/color] 0001 1011--
          11 0100 1110 0101 [color=blue]0000 1001 0001[/color] [color=red]0011 0100[/color] 0001 1011------
         111 1010 1110 0101 [color=blue]0000 1001 0001[/color] [color=red]0011 0100[/color] 0001 1011----

111111111111 0100 0111 0110 [color=blue]0000 1001 0010[/color] [color=red]0011 0100[/color] 0110 1100----
     1111111 0100 0111 0110 [color=blue]0000 1001 0010[/color] [color=red]0011 0100[/color] 0110 1100----
       11111 0100 0111 0110 [color=blue]0000 1001 0010[/color] [color=red]0011 0100[/color] 0110 1100---
    11111111 0100 0111 0110 [color=blue]0000 1001 0010[/color] [color=red]0011 0100[/color] 0110 1100-
      111111 0100 0111 0110 [color=blue]0000 1001 0010[/color] [color=red]0011 0101[/color] 0101 1101---------
     1111111 0100 0111 0110 [color=blue]0000 1001 0010[/color] [color=red]0011 0101[/color] 0101 1101----
      111111 0100 0111 0110 [color=blue]0000 1001 0010[/color] [color=red]0011 0101[/color] 0101 1101-
     1111111 0100 0111 0110 [color=blue]0000 1001 0010[/color] [color=red]0011 0101[/color] 0101 1101----
    11111111 0100 0111 0110 [color=blue]0000 1001 0100[/color] [color=red]0011 0101[/color] 0000 0111-----
      111111 0100 0111 0110 [color=blue]0000 1001 0100[/color] [color=red]0011 0101[/color] 0000 0111------
  1111111111 0100 0111 0110 [color=blue]0000 1001 0100[/color] [color=red]0011 0101[/color] 0000 0111-----
     1111111 0100 0111 0110 [color=blue]0000 1001 0100[/color] [color=red]0011 0101[/color] 0000 0111-----
        1111 0100 0111 0110 [color=blue]0000 1001 0101[/color] [color=red]0011 0110[/color] 1010 0000-------
     1111111 0100 0111 0110 [color=blue]0000 1001 0101[/color] [color=red]0011 0110[/color] 1010 0000-----
  1111111111 0100 0111 0110 [color=blue]0000 1001 1000[/color] [color=red]0011 0111[/color] 1101 0001------
        1111 0100 0111 0110 [color=blue]0000 1010 1000[/color] [color=red]0011 0111[/color] 0110 0011------
         111 0100 0111 0110 [color=blue]0000 1010 1001[/color] [color=red]0011 0111[/color] 1001 0111----
         111 1100 0111 0110 [color=blue]0000 1010 1010[/color] [color=red]0011 0111[/color] 1011 1010-
          11 0100 0111 0110 [color=blue]0000 1010 1010[/color] [color=red]0011 0111[/color] 1011 1010--
1111111 1111 0100 0111 0110 [color=blue]0000 1010 1010[/color] [color=red]0011 0111[/color] 1011 1010---

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).

Agrajag:
using long high = 1 and short high = 0

Oops sorry other way around, long high = 0, short high = 1.

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.

mauried:
There should be a a sign bit for the temperature to indicate whether its above or below 0C.

Heh this might be a bit hard for me to find, it very rarely gets to below 0 where I am. I suppose I could put it in my freezer for a short time.. not sure if it would be happy with that though

mauried:
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 fields
in 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 module
and 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 it
it 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 connected
as 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 transitions
will 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 that
what 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.

See here: http://whatsbeef.net/philip/weatherstation/src/

If I have time tonight I'll verify that it compiles/runs.

Thanks guys, lots of leads for me to follow up tonight. I was getting bogged down with the RF processing, but you've both given me heaps of useful help. mauried, unfortunately here in AKL, NZ neighbours are thick on the ground. However there are no other weather stations in the vicinity, plenty of other chaff though I'm sure. Agrajag, the code will help a lot and even if it doesn't compile I'm sure I'll be able to work it out. Thanks again guys, I owe you a virtual bottle of VB...