27 |
31 | Decoding Oregon 28 | Scientific Weatherstation Messages using Gnuradio
29 |by B.Kerler DO2BJK (c) Jan 2015
30 |-
32 |
33 |
- Configuration 34 |
- How I figured out how it works 35 |
- How the gnuradio processor works 36 |
- Encoder versions supported 37 |
- How-To-Use 38 |
- Example Messages 39 |
41 |
43 |
47 |
48 |
52 |
53 |
55 |
56 |
57 |
58 | Now I had to look closer at the signal. I recorded the signal to a wav 59 | file with 48Khz.
60 | This way I could clearly see that the signal is being sent twice and 61 | that the structure was as I expected :
62 |
63 |
64 |
65 | The next step was to see how the bytes were encoded :
66 |
67 |
68 |
69 | The signal starts with a "01" sequence where 0 is the value for low and 70 | 1 is the value for high, which is being repeated 16 times for Version 2 71 | and 12 times for Version 1 of the
72 | Oregon Scientific Encoder, encoded as Manchester. Thus in order to see 73 | the right bytes you need to leave apart every second byte. After that, a 74 | sync message is being sent,
75 | which is "0101" for version 2 and "01100" for version 1.
76 |
77 | The main problem however started when I had to decide whether to decode 78 | the signal using c++, python or using gnuradio itself. It turned out 79 | that indeed the Binary Slicer
80 | can be used to output a bitstream which then can be easily being used 81 | for further processing. However in terms of speed, I think it would be 82 | better to use a own slicer
83 | and clock recovery in c++ instead. The slicer is more or less a function 84 | to measure if a high or low signal actually occurs. You can just use 85 | this pseudo-code as well instead :
86 |
87 | unsigned char midlevel=0x80;
88 | string bitstream="";
89 | unsigned char bit=0;
90 | while (bit=fifo->read(1)) //read one byte from stream or wav file 91 | (same as one bit as one byte is one symbol)
92 | {
93 | if (counter==datarate)
94 | {
95 | if (bit>midlevel) bitstream+=1; //high detected
96 | else if (bit<=midlevel) bitstream+=0; //low 97 | detected
98 | counter=0; // Start counting from 0 again
99 | // Here you would create thread to handle the 100 | bitstream or anything else
101 | }
102 | counter++; // Increase counter while looping
103 | }
104 |
105 | Here is how my gnuradio pre_processor for ask looks like :
106 |
107 |
108 |
136 | Opening up the output file by 137 | Hex-Editor, you should see something similar like this :
138 |
139 |
140 |
141 | I wrote a small script named "oregonscientific_test.1sc" for the 142 | 010Editor, just position the cursor at the "00" before the "01" byte to 143 | get a decoding by pressing F7-Function key.
144 | You can find both Wav- and Outputs for both Oregon-Scientific Versions 1 145 | and 2, which I've recorded by using my own temperature sensors.
146 |
147 | 148 |
152 | THR128H
153 |
154 | Version 2:
155 | THN132N, THR238NF
156 |
157 | 158 |
162 | 2. "gnuradio-companion rx_ask.grc" and run grc
163 | 3. "mkfifo /tmp/fifo" if fifo doesn't yet exist
164 | 4. "python OregonDecoder.py"
165 | 5. Select appropriate decoder Version from Tab or use any datarate for 166 | custom ASK-Decoders
167 |
168 | 169 |
172 | FFFF A EC40 1 5F 0 730 0 D3 : FFFF=Preable, A=Sync, Flags: 1, Rolling 173 | Code: 5F, Temperature: 3,7°C, Checksum: 3D ok
174 | FFFF A EC40 1 5F 0 830 0 E3 : FFFF=Preable, A=Sync, Flags: 1, Rolling 175 | Code: 5F, Temperature: 3,8°C, Checksum: 3E ok
176 |
42 |
43 | Configuration
44 | Tested using Ettus Research B210 using 433 Mhz Discone Antenna. Due to 45 | usage of Osmocom Source, Rtl and Hackrf Dongles should work fine as 46 | well.47 |
48 |
How 49 | I figured out how it works
50 | First I took an example recording to see how the actual signal looks 51 | like using gnuradio :52 |
53 |
55 |
56 |
57 |
58 | Now I had to look closer at the signal. I recorded the signal to a wav 59 | file with 48Khz.
60 | This way I could clearly see that the signal is being sent twice and 61 | that the structure was as I expected :
62 |
63 |
64 |
65 | The next step was to see how the bytes were encoded :
66 |
67 |
68 |
69 | The signal starts with a "01" sequence where 0 is the value for low and 70 | 1 is the value for high, which is being repeated 16 times for Version 2 71 | and 12 times for Version 1 of the
72 | Oregon Scientific Encoder, encoded as Manchester. Thus in order to see 73 | the right bytes you need to leave apart every second byte. After that, a 74 | sync message is being sent,
75 | which is "0101" for version 2 and "01100" for version 1.
76 |
77 | The main problem however started when I had to decide whether to decode 78 | the signal using c++, python or using gnuradio itself. It turned out 79 | that indeed the Binary Slicer
80 | can be used to output a bitstream which then can be easily being used 81 | for further processing. However in terms of speed, I think it would be 82 | better to use a own slicer
83 | and clock recovery in c++ instead. The slicer is more or less a function 84 | to measure if a high or low signal actually occurs. You can just use 85 | this pseudo-code as well instead :
86 |
87 | unsigned char midlevel=0x80;
88 | string bitstream="";
89 | unsigned char bit=0;
90 | while (bit=fifo->read(1)) //read one byte from stream or wav file 91 | (same as one bit as one byte is one symbol)
92 | {
93 | if (counter==datarate)
94 | {
95 | if (bit>midlevel) bitstream+=1; //high detected
96 | else if (bit<=midlevel) bitstream+=0; //low 97 | detected
98 | counter=0; // Start counting from 0 again
99 | // Here you would create thread to handle the 100 | bitstream or anything else
101 | }
102 | counter++; // Increase counter while looping
103 | }
104 |
105 | Here is how my gnuradio pre_processor for ask looks like :
106 |
107 |
108 |
How the gnuradio processor works
110 |First, the gain of the signal is being
111 | increased using AGC2 before the FIR Filter and Band Pass Filter.
112 | Amplitude Shift Keying turns out to be quite bad when it comes to use
113 | AGC2 between the FIR
114 | and Band Pass Filters, if there are better options, please tell me :)
115 |
116 | After the signal has been filtered, it is being demodulated by 117 | AMplitude ... it doesn't matter if you use the Complex-To-Magnitude 118 | block instead, it works fine as well. After the signal has been 119 | demodulated,
120 | you can now see the low and high signals occurring. However, as the 121 | signal sometimes is too weak to process by the Binary Slicer, you have 122 | to use a "add const" block to level the signal up. For the B210,
123 | 390m is just fine, other recievers might have to in- or decrease the 124 | value to get proper decoding. The Clock Recovery MM Block just 125 | recovers the stream according to our datarate, or in other words : it 126 |
127 | picks up one sample every 47 samples, which is 128 | (audio_rate/data_rate)=(48000/1020)=47 samples per second, and writes 129 | it to a new output stream, which is thenbeing sliced (high to 1 and 130 | low to 0) as a
131 | bit stream to a file.
132 |
133 | As the sample_rate of 2.4M is way to high to process for slow PCs, the 134 | Xlating FIR Filter decimates the samples by 50, which is 2.4M/50=48K.
135 | 114 | and Band Pass Filters, if there are better options, please tell me :)
115 |
116 | After the signal has been filtered, it is being demodulated by 117 | AMplitude ... it doesn't matter if you use the Complex-To-Magnitude 118 | block instead, it works fine as well. After the signal has been 119 | demodulated,
120 | you can now see the low and high signals occurring. However, as the 121 | signal sometimes is too weak to process by the Binary Slicer, you have 122 | to use a "add const" block to level the signal up. For the B210,
123 | 390m is just fine, other recievers might have to in- or decrease the 124 | value to get proper decoding. The Clock Recovery MM Block just 125 | recovers the stream according to our datarate, or in other words : it 126 |
127 | picks up one sample every 47 samples, which is 128 | (audio_rate/data_rate)=(48000/1020)=47 samples per second, and writes 129 | it to a new output stream, which is thenbeing sliced (high to 1 and 130 | low to 0) as a
131 | bit stream to a file.
132 |
133 | As the sample_rate of 2.4M is way to high to process for slow PCs, the 134 | Xlating FIR Filter decimates the samples by 50, which is 2.4M/50=48K.
136 | Opening up the output file by 137 | Hex-Editor, you should see something similar like this :
138 |
139 |
140 |
141 | I wrote a small script named "oregonscientific_test.1sc" for the 142 | 010Editor, just position the cursor at the "00" before the "01" byte to 143 | get a decoding by pressing F7-Function key.
144 | You can find both Wav- and Outputs for both Oregon-Scientific Versions 1 145 | and 2, which I've recorded by using my own temperature sensors.
146 |
147 | 148 |
Encoder 149 | versions supported
150 |151 | Version 1:
152 | THR128H
153 |
154 | Version 2:
155 | THN132N, THR238NF
156 |
157 | 158 |
How-To-Use
159 |160 | 1. Install Gnuradio-Companion 161 | 3.7 or higher
162 | 2. "gnuradio-companion rx_ask.grc" and run grc
163 | 3. "mkfifo /tmp/fifo" if fifo doesn't yet exist
164 | 4. "python OregonDecoder.py"
165 | 5. Select appropriate decoder Version from Tab or use any datarate for 166 | custom ASK-Decoders
167 |
168 | 169 |
Example 170 | Messages
171 | THR132N V2:172 | FFFF A EC40 1 5F 0 730 0 D3 : FFFF=Preable, A=Sync, Flags: 1, Rolling 173 | Code: 5F, Temperature: 3,7°C, Checksum: 3D ok
174 | FFFF A EC40 1 5F 0 830 0 E3 : FFFF=Preable, A=Sync, Flags: 1, Rolling 175 | Code: 5F, Temperature: 3,8°C, Checksum: 3E ok