Go Down

Topic: Help with 433mhz receiver (Read 9889 times) previous topic - next topic

Agrajag

Hi, for my first arduino project I am trying to do something like http://www.practicalarduino.com/projects/weather-station-receiver but with a different weather station I have. At the moment I am just trying to get the 433mhz receiver to work.

I have used the code from that page and bought a 433mhz receiver and connected it up in the same way as the schematic in the above link:



I have commented out all the code in the ISR(TIMER1_CAPT_vect) function and just made the LED on pin 13 blink (I put pinMode(13, OUTPUT) in Init_Ports()) when that interrupt happens. I just want to see when I receive some data and not do any decoding yet. My problem is that the LED is blinking constantly (it looks dim) so it looks like I'm receiving 010101010... constantly. I have tested the exact same code with a button connected to input 8 instead of the 433mhz receiver and the LED flashes properly when the button is pressed/released - so it seems the code/interrupt is working properly.

I then had a good look at the receiver and found it has RXN3-b printed on it, so I think it's this http://www.spiriton.com.tw/download/RXN3-b-s.pdf rather than the rxb1 (data sheet) which I thought I had bought. Comparing those two datasheets it looks like there might be a difference in the output current (but this is the first time I'm looking at datasheets so am not too sure). Does this make a difference for the schematic? If not, where else might I have gone wrong?

(yes I have turned off the weather station transmitter just to make sure it's not sending 010101010... when idle :))

mauried

These types of receivers are extremely simple amplitude modulated types which produce "data" all the time
on their output data port,even with no signal being received.
The "data" is simply the digital component of the noise input when there is no Rf signal present.
You have to use them with some kind of data decoding logic to separate the real data from the noise.
Most weather station sensors send a long sequence of alternating bits at the start of the transmission
to allow the receivers AGC (auto gain control) , to adjust , and they also usually use some kind of Manchester coding
to ensure a 50% logic level.


MarkT

This behaviour is common to most RF (and IR) links - in the absence of a transmission the receiver increases its sensitivity until the noise floor is detected.  This is why there are preambles and CRCs on radio packets, so that the receiver can filter out the noise efficiently.  Preambles are usually a burst of 010101010101 at a known rate - the longer the preamble the more reliable the recognition of packet v. non-packet.

One common technique used in receivers is a clock-detection circuit, using the transitions to try and recover the transmission bit clock - such a circuit (or software) can also discriminate between signal and noise.  Using manchester encoding and variants allow particularly simple clock recovery as a valid transmission has transitions at every clock (as well as some in-between clocks).

[ I won't respond to messages, use the forum please ]

Agrajag

Thanks guys that's been very helpful. I've figured out when the transmitter is sending packets of data now, every 8 seconds 7 times when the transmitter is first powered up then every 48 seconds after that. Now I just have to fiddle with filtering out what is real data and what isn't. I am receiving a bunch of 10101010 at the beginning of the burst of data but what I get after that doesn't seem to make any sense yet, I think I have to play with the "period width filter" until I get what looks like sensible data - and then figure out what it means. Cheers.

mauried

What sort of weather station sensor are you using.
The trick with these things is figuring out where the data starts and what it means.
They generally also send some kind of sync bytes and some kind of CRC.
The sync bytes come straight after the flag sequence, and then usually the data, followed by the CRC.
An easy way to look at the data is to download a PC oscilloscope program which allows you to see
whats coming out of the receivers data port using your PC sound card as an input.


Agrajag

Model is "WS1150" - a very cheap one I bought off ebay a year or two ago. The outdoor/transmitter part is only humidity/temp so it's not sending heaps of data like some more expensive ones with more sensors.

That trick with the sound card sounds handy, I'll look up how to hook that up. I've been trying different things for a couple of hours now but haven't really gotten anywhere besides figuring out when data is transmitted.

Cheers.

Agrajag

Ok so here are two captures just using sound recording software (audacity), I couldn't figure out how to make xoscope do what I want, not sure that it even does what I want. As you can see, the first one happened at around 1:00, the next at 1:48, so 48 second intervals as I mentioned previously.

First:


Second, 48 seconds later, annotated with what I think it's doing...


So it sort of looks like it is doing a bunch of 010101, then a bunch of 0s, then.... maybe some data?

MarkT

sound card not up to this task I think!  Your analysis seems sound though (no pun intended) - the sound card is heavily low-pass filtering the signal though, hence the big dip - that's obscuring things.
[ I won't respond to messages, use the forum please ]

Riva

Can you save just the section you show and attach it to a post. The big dip could be when the transmission has finished and the AGC is ramping up.

MarkT

The big dip is because the signal is low-pass filtered - this is the receiver output logic level being sampled, remember - it should be a rectangular waveform without the distortion.
[ I won't respond to messages, use the forum please ]

mauried

When using the oscilloscope idea to capture the data you need to know exactly when the sensor is transmitting
as the transmissions are very short, usually 100 milliseconds or less.
This means that you will need some kind of way of determining electrically when the sensor is sending
and then gating the data from the receiver to the oscilloscope.
Also, the data pin on the receiver is designed for driving a high impedance load so it needs to be connected
to something that wont load it , like a hi impedance cro probe.
You should be seeing on the oscilloscope a rectangular waveform toggling between 0V and Vcc, which will be there all the time.
Have a read of this
http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf
Whilst its not for your sensor, it will give you some understand of how these sensors work and how they transmit and what you should be looking for.

Agrajag

Thanks guys that's helpful again (though much of what you're saying is going over my head, I'm beginning to think this might be a bit of an ambitious first project, I'm a software engineer, never done this sort of thing before)

Anyway, I decided to make it print out data to serial and monitored what was coming in, using 300uS as a minimum period filter for the time that the ISR(TIMER1_CAPT_vect) interrupt was fired, so printed out 0 if it was low for 300uS or more and 1 if it was high for 300uS or more.

Each line here is a capture with the same data (55% humidity, 13.9 degrees C) sent by the transmitter (with a bit of noise on either end, just happened to be what I copied/pasted):
Code: [Select]

11111111111111111111111111111111111111111111111111111111111111111111111111111111111011011010101010010101001010101010101010101010101010101010101010101010101010101010101010000000000000000000000000000000000000000000000000000000000000000110101111011101111111101111101111001100110111011111111111111111011111111111011111011111111111111111111111101111101111111111111111111011111111111110111110111111111111111101
1111111111111111111111111111110111111111111111111111111111011111111111111111011111111101101101001001001010101010101010101010101010101010101010101010101010101010101010101010100000000000000000000000000000000000000000000000100000000000000001100001111111111011111111111111110011111111111111111111111111111111111111111111111111111110111111111111111111111111111111111111111111110111
111111110101010101010101010101010101010101010101010101010101010101010101010101010101010101010100000000000000000000000000000000000000000000000000000000000000110101010011111111111111111111111111111111111111111111111111111011111011111111101111111111111101011111111111111111111110
1111111111111111110101011100111111111111010101101011011010101010101010101010101010101010101010101010101010101010101010101010100000000000000000000000000000000000000000000000000100010101100110111111011111110111110111111111111111111011111111111111111111111111111111110111111111111011111111110110111111111111111111111111111111111111111111111111111111001111111111111101111111


So each one has the 10101010.. then a bunch of 0s then.. something I can't make much of. The noise is mostly 1s but the section after the 0s has a few 0s, I'm not sure if that's noise or data, maybe because of the AGC I'm getting more 0s there than in the normal noise while it's adjusting - but if so, where's the data part! Is it possible that 300uS is too long and I should be filtering from a lower value?

Agrajag

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.

Agrajag

#13
Aug 14, 2012, 12:40 am Last Edit: Aug 14, 2012, 01:35 am by Agrajag Reason: 1
Figured it out :D 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.

mauried

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.

Go Up