Go Down

Topic: Decoding RF 433.92MHz data? I?m in over my head (Read 4901 times) previous topic - next topic

TheLost

For the past few months I've been playing around trying to capture packets sent from Oregon Scientific v3 weather sensors.   I've modified the code from http://www.practicalarduino.com/projects/weather-station-receiver to capture a buffer of data.  Once the buffer is full I dump it to the serial port.  I look through the output to find a range that looks like possible data. Then I modify the code to only capture data in that range.  

Here is a sample of what I think is the data sent from the sensor..  It's a constant size and is sent approximately every 60 seconds. (data is the pulse lenght).

Code: [Select]

134
131
130
127
129
124
127
123
125
125
123
121
121
123
121
121
119
121
251
252
125
123
124
123
130
131
249
249
129
130
129
250
246
126
127
247
126
127
247
125
247
127
124
127
246
120
121
126
125
125
128
126
244
126
127
127
125
126
126
245
127
244
116
124
126
127
127
244
243
115
119
117
119
127
124
245
127
243
119
117
118


The problem is? now I'm stumped.   Converting the data to binary (100 - 190 = 0, 200 - 300 = 1 or reversed) doesn't give me anything useful.  It doesn't look Manchester encoded and  I can't see anything that looks like good data.

Help!  Do you think my logic is wrong on how I capture the data? What's the best way to decode the packets?

Udo Klein

The first step is to correlate captured data with sensor readings. This is much simpler than just looking at the captured data.

Code: [Select]

http://en.wikipedia.org/wiki/Known-plaintext_attack


Then you should try to locate parts of the code sequence that stay equal. I would guess that the stream is not encrypted. So this should not be that hard.

If  there seems to be no correlation whatsoever the question would be if you actually did receive anthing or just picked up random giberish.

Next thing that I would do, I would just guess that the pulse lengths correlate with 0s and 1s. That is ~127 --> 0, ~255 -> 1. But I might be wrong of course.

Cheers, Udo
Check out my experiments http://blog.blinkenlight.net

EriSan500

Is this of any help:

http://alyer.frihost.net/thn128decoding.htm

Could you post some code, so other people can have a look and jump in if possible?

Greetings,
EriSan500

TheLost

Im tyring to decode the OS V3 protocol...   The thn128 uses V1 (or V2).  I've gone over that post quite often  :D

I'll post the code im using to capture the data tonight when i get home.

If somebody can help me decode the data i'll give them a free THGN801 temp/humid sensor 8-)

TheLost

Here is an overdue progress update:

I hooked the RX up to my computer (http://davehouston.net/learn.htm) and got a clean 'image' of what I needed to decode (here is the signal from the THGN 801 temp/humidity sensor http://www.lostbyte.net/thgn801.png).  It was all downhill from there.    I've successfully decoded all 4 of the V3.0 Oregon Scientific weather sensors I own.

THGN 801 - Temperature / Humidity
PCR800 - Rain Gauge
WGR800 - Wind Sensor (speed / direction)
UVN800 - Ultra-violet Index Sensor

But... I can't figure out the checksum  :-[

Here is the binary data from a temperature sensor (note: data bytes need to be reversed):
Code: [Select]

10111110001010000101000100101010000101010100000000011101010000011100010110000100
-------------------------------[T4][T3][T2][T1][TS][H3][H2][H1]-----------------

TS = 0000 = 0 (0 = +, 1 = -)
T1 = 0000 = 0
T2 = 0101 = 5
T3 = 0101 = 5
T4 = 0000 = 0
H1 = 0000 = 0 (This might actually not be part of the Humidity.. just a guess)
H2 = 0101 = 5
H3 = 0111 = 7

Temperature is: +05.50c (41.0f)
Humidity is: 057%


Can anybody figure out the checksum? I assume it's the last 2 bytes but I can't seem to crack it.  It would be nice if I could validate the packages since the wind sensor sends a signal every ~15 seconds there are a few 'collisions'.

Udo Klein

Well, it would be extraordinary helpful to have some reasonable number of sample data, not just one sample. Since you seem to get a sample each 15 seconds, would you provide some 100 - 1000 samples (or more) incl. he suspected checksum? Preferably in a csv format?

Even if you suspect a crc16 or something similar this can not be infered from just one or two samples.

Udo
Check out my experiments http://blog.blinkenlight.net

XOR



XOR

thanks, but I would like to know how to compute the protocol checksum Oregon 3.0
what algorithm is used in checksum THGN801

Grumpy_Mike

Quote
thanks, but I would like to know how to compute the protocol checksum Oregon 3.0
what algorithm is used in checksum THGN801


so how was anyone supposed to know that when all you said is:-
Quote
hello, got to find an algorithm CRC?


so have you googled:-  checksum THGN801

XOR

16.1° 44%
0xFA, 0x28, 0x24, 0x96, 0x10, 0x16, 0x40, 0x04, 0x3E, 0x0A

0xFA
0x28
2 Channel # 1 (1 = 0, 2 = 1 ...)
4 ???
0x96 address changes randomly after reset
1 A 10th degree
0 b3 = reset/norm, b2 = lowbat, b1? b0?
1 unit degrees
6 tens of degrees
4 units of moisture
0 b3 = 1 negative temperature b2? b1? b0?
0 ???
4 tens humidity
0x3E checksum, the sum Niblo -10
0x0A ??? CRC?

I am having trouble with some 433.92 RF decoding too, if anyone can help over at http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1279418455 it would be greatly appreciated.

Cheers,
Dean

Go Up