trying to receive RF signals sent bij an outdoor weather station sensor

Hi All,

I'm trying to receive RF signals sent bij an outdoor weather station sensor.

I have used the following tutorial:

http://www.espruino.com/Remote+Control+S­ockets

First I tested with my remote control:

http://www.klikaanklikuit.nl/shop/nl/afs­tandsbediening-ayct-102/

Different type than used in the tutorial I guess (it's Dutch). The outcome is also different:

On!
1:
0b101010100000000000101010
2:
0b101010101000000000101010
3:
0b101010100010000000101010
4:
0b101010101010000000101010

Off!
1:
0b101010100000000000101000
2:
0b101010101000000000101000
3:
0b101010100010000000101000
4:
0b101010101010000000101000

Also a lot of garbage between these lines...

But I wasn't able to receive a signal from the weather station sensor. Has anybody tried that before?

The one I use is an Oregon Scientific THR188.

I did find some protocols, but I'm not really understanding it. Unfortunately nothing is decoded with the code provided from the tutorial.

Kind regards,

Reinoud de Lange

1 Attachment

• OregonScientific-RF-Protocols.pdf

Hi,

It's really good news that the other remote control works... The 433Mhz frequency is a bit of a free-for-all. Anyone can transmit whatever they want to, so there's no guarantee that the existing code will work with another model of mains socket.

By the way, I updated the tutorial with a bit more info about how the receiver works.

For your weather station, it looks like there are at least 3 different versions of the protocol, from 1.0 to 3.0 - and it would be much easier if we knew which one the station uses. There's a table in the PDF you gave but it doesn't list the THR188. Does the receiver or transmitter have a different model number that might be in the table, or does it say in the manual?

The main difference between the remote controls on the website and your weather station is that your weather station uses Manchester Coding whereas the remote controls use a binary pulse width modulation (I'm not sure what the correct name is).

Basically you can't easily just send the raw data wirelessly, because if you sent a lot of '0's, there would be a big gap with no radio signal and interference might get picked up. So you need a way to make sure that there is always going to be a pulse every so often - which leaves you two main ways to encode data:

• Manchester coding : A 0 is represented by a transition from 0 to 1, and a 1 is represented by a transition from 1 to 0
  
• Pulse width modulation: A 0 is represented by a short pulse, and a 1 is represented by a long pulse.
  
  

I don't believe Pulse width modulation is as efficient, but (at least for me!) it seems easier to decode.

The other difference is inn the speed of transmission, which might be the reason you're not getting any data at all (even garbage). You could try the following decoder functions instead which has different numbers, and could see which works:

// Protocol 1.0
function sigOff(e) {
  var d = e.time-t;
  t = e.time;
  if (d>0.001 && d<0.004)
    n = (n<<1) | ((d>=0.0025)?1:0);
  else
    n=0;
}

// Protocol 2.1 and 3.0 
function sigOff(e) {
  var d = e.time-t;
  t = e.time;
  if (d>0.0002 && d<0.0011)
    n = (n<<1) | ((d>=0.00085)?1:0);
  else
    n=0;
}

But it's not guaranteed...

It'd help if you could force the weather station to transmit. Is there a button, or does taking out the battery and putting it back in force it?

So I think the next step is to find out what protocol version you have... If you can't google it or find it in the manual, do you have a digital storage oscilloscope?

If not, we can get Espruino to measure the pulse lengths, but it's tricky as there will almost certainly be loads of interference that will get in the way.

I've been taking a look at reading data from an electricity monitor I have (An 'Owl' one) and that uses Manchester coding too.

I'm not sure this is 100% correct, but here's my simple decoder which at least gives me something:

var data = "";
var last = 0;

function onEdge(e) {  
  var d = 0|((e.time-e.lastTime)*1000);
  if (d==0) {
    if (e.state) data+=last;
  } else if (d==1) {
    data+=last^=1;
  } else {
    console.log(data);
    data = "";
    last = 1;
  }  
}
setWatch(onEdge, B15, { edge:"both", repeat:true });

It's designed to execute relatively quickly, so again it's not very easy to read. Basically:

• This one expects the data length to vary between 0.66ms and 1.3ms, so it checks whether they are greater or less than 1ms long. It does this by multiplying by 1000, and then converting the number to an integer (using 0| - a JavaScript trick). You might have to change the multiplier in your case (depending on the protocol).
  
• Then, d==0 for a small pulse, and d==1 for a long pulse
  
• In manchester coding, because of the way the bits are output, you get two small pulses if the bit stays the same and one large pulse if it changes. So if the pulse is small, we ignore one of them (by checking e.state)
  
• Then we just add the digit we think we got to the 'data' string, and when we get something we're not expecting we output what we had and then zero it.
  
  

I soldered right onto the insides of my electricity monitor so I'm not getting any noisy signals. You'll probably have to do some extra checks before outputting the data, so the noise doesn't cause lots of stuff to be output. Even a simple if (data.length>16) ... might be enough

WOW! That's impressive! I do have a DSO Nano (DSO201), but I have to figure out how to record the signal... I will try to capture it and post it here!

Hi Reinoud, even the first few bits of signal might be enough - at least you could figure out what the bit rate is, and from that get some idea of the protocol.

Personally, I'd crack open the transmitter and look inside. There's often a transmitter module with a clearly marked 'data' pin, and if you hook onto that then you can get a nice clear signal to analyse (if you go from the radio receiver, you'll probably get all kinds of stuff and it won't be obvious which one is from the weather station).

I tried to figure out how to use my DSO Nano... (don't understand much)
I got a picture of the signal, don't know if it is helpful.. !

Edit: I cannot upload files, a server error is returned...

Sorry - I'll check with the people who make the forum... I can't upload either.

Hi Reinoud - I think this is fixed now. Please can you try posting up again?

well... here it is:

1 Attachment

• IMG_022.BMP

I tried to capture a signal using Single waveform, but I'm unable to do so... (anyone with a DSO 201 and knows how to do it please let me know...)

I can stop the waveform / signal when I transmit a signal from my remote control for the remote socket. It is clear that it uses the binary pulse width modulation:

1 Attachment

• IMG_060.BMP

I tried to capture the signal again. I also have a csv file (not sure how to interpret it yet):

2 Attachments

• IMG_061.BMP
• DATA007.CSV

Hi, That's pretty handy anyway... Do you think you could sample at a higher rate (1ms like you did for the remote control?) We don't need all of the signal - just a few bits from somewhere in it (so we can work out how long each bit is)

Just to add, it looks from the screenshots (down the bottom of them) like the DSO has a buffer that's about 3x the size of what you can see - so (even though we don't need the whole signal) it looks like you may stand a chance of getting it in.

you're right... I'm getting a bit familiar with it! :-) never really used it that much! So I have a few screenshots:

4 Attachments

• DATA011.CSV
• IMG_062.BMP
• IMG_063.BMP
• IMG_064.BMP

Ok, this is great!

So looking at it, the small pulses are roughly 1.5ms. Looking at the document you posted up earlier, the actual 'clock rate' they're talking about is half that... so 1000ms/3ms = 333Hz - which looks extremely similar to the 342Hz clock rate they give for Version 1.0 devices!

So now we know the clock rate, we can just modify the timing in the code I gave before. With it there's a description of how the *1000 was worked out...

Basically now we're expecting pulses between 1.5ms and 3ms (ish), so the midpoint is 2.25ms. So that means we just multiply by 1000/2.25 = 444

var data = "";
var last = 0;
function onEdge(e) {  
  var d = 0|((e.time-e.lastTime)*444);
  if (d==0) {
    if (e.state) data+=last;
  } else if (d==1) {
    data+=last^=1;
  } else {
    console.log(data);
    data = "";
    last = 1;
  }  
}
setWatch(onEdge, B15, { edge:"both", repeat:true });

Hopefully if you use that code, you should get something back. If you're really lucky it'll start with twelve 1 bits... Although it looks from the docs you gave like the format is actually:

• 12 1 bits
  
• a 4.2ms gap with nothing in
  
• a 5.7ms pulse of radio waves
  
• a 5ms gap with nothing in
  
• The actual data
  
  

So I think the current code may give you 12 1s, then on a new line it'll give you the data.

When I look at page 8 and 9 (and understand well) the message should look like the following:

1 Attachment

So I don't know what this rolling code should look like... the channel is set to 1, so nibble 1 should be 0. Nibble 5 could be 0 or 3 because I notice a battery low indicator on my weather station.

Why do you think I will get 12 1's? Can't we divide the datastream in nibbles as shown in my diagram?

I tried to construct the binary code from the two examples in the documentation (page 9):
“8487101C” should be: 1000 0100 1000 0111 0001 0000 0001 1100

“88190AAB” should be: 1000 1000 0001 1001 0000 1010 1010 1011

Do you agree?

I posted a question on which protocol is used on a weatherstation forum, this is a reply I got:

After some searching, I have determined that the Protocol may be 1.0
or 2.1 protocol. It depends on what series you have. The later
manufactured THR 188, has a 2.1 protocol. It is in any case certainly
not 2.2 or 3.0 protocol.

Looking at the bit rate of 342 Hz it is most likely I have a protocol 1 sensor. I also read in the documentation that the manchester coding is used.

Yes - it's protocol 1, 342Hz, manchester coding - which I'd hope the code above will decode. Did you get a chance to try it?

The reason I think you'll get the 1s first is that there is a 'preamble' and sync pulse that is sent before* the payload (see the picture).

For the 'rolling code', the document says 'Value changes randomly every
time the sensor is reset'. I don't know if this means that the code increments by one after each transmission or not? Personally I'd just ignore it for now unless you find you're receiving data from someone else's weather station as well!

Personally I'd just try and get some data read in and then work backwards from there. Once you have the bits in the data variable, you can extract them with: parseInt(data.substr(nibble*4,4),2)

1 Attachment

“8487101C” should be: 1000 0100 1000 0111 0001 0000 0001 1100

“88190AAB” should be: 1000 1000 0001 1001 0000 1010 1010 1011

Looks right to me!

And:

var data = "10001000000110010000101010101011";
for (var nibble=0;nibble<8;nibble++) {
  console.log(parseInt(data.substr(nibble*­4,4),2).toString(16));
}
// prints...
8
8
1
9
0
a
a
b

Hi Gordon,

I tried to capture it with the code you proposed. I get a constat flow of data, probably stuff from other devices. We tried to solve it by letting my son scream "yes!" when the sensor transmits something (we see a red led flash...) and I disconnect the espruino (don't know how to pause terminal output). What I get is this:

0111111
0000
1111111111111111111111110001111111111111­1111111111111111111111111111111111111111­1111111111111111111111111111111111111111­1111111110000000000000000000011111011111­1111000000000000000110000000000000001111­1111100001110000000000000000000001100111­1111111000111111111011000000000111100111­1111
010
111111111
00000111
1111110

Made a second attempt:

According to my son it was 14,3 degrees. If I understand well it is sent backwards:

0011 0100 0001

But I don't see the string "001101000001" in the following capture:

01001001100001010000001110010111

0
00000
1111111111111111111110

0100100110000101000000110010111
1

11
1
0000011111110011111111111111111111111111­111111111111111111111111111111111111111>­1111111111111111111111111111111111111111­1111111111111111111111111111111111111111­11>1111111111111000000000000000000000000­0000000000011111111111111111111>11100000­0011000000000001111111110000000111111110­1111110000000000
1110000000000000000000000001
11111111111
11111111
0000011110000001111111101111011110001100­00000011111111
1100
1111110001111111111111000000000000011
10001
001111
10000001000001110
111
1111111111
110000
1100000000111
1111111111110001111111110000000011100000­000000000
11
111110111111111
00001111111110001000000
Disconnected

Hmm, it's very tricky to extract what is from the sensor when there is all the noise :(

Looking at the protocol description there seem to be at least 12 '1' pulses beforehand, so I guess it's worth looking for the data right after those.

I guess ideally you'd actually open up the transmitter and connect a wire to it, then you could check everything was working without the noise, and could then work on cutting out the noise once you knew it actually worked.

If you don't want to do that, one other thing is to make the receiver code much more strict about the length of signals it accepts (it should be 1/342 = 2.92ms and 0.5/342 = 1.46ms)

var data = "";
var last = 0;
function onEdge(e) {  
  var d = 1000*(e.time-e.lastTime);
  if (d>1.3 && d<1.6) {
    if (e.state) data+=last;
  } else if (d>2.7 && d<3.1) {
    data+=last^=1;
  } else {
    if (data.length>8) console.log(data);
    data = "";
    last = 1;
  }  
}
setWatch(onEdge, B15, { edge:"both", repeat:true });

Hopefully that'll output much less information...

I don't want to open up the transmitter because it is an outdoor sensor... I don't want to break it...

I will try the code, I hope it will work.