Pages: [1] 2   Go Down
Author Topic: Help me decode this 434mhz signal...?  (Read 5376 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 23
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Grabbed this with an Arduino and sound card from my weather station, an old Acu Rite 00605 (http://www.acurite.com/weather/weather-forecast-stations/00605-wireless-weather-station-companion.html)

It does not seem to be manchester encoded, from my limited understanding.  The first capture on the screenshot was taken when the device read 46.2F (7.9C) and 46% humidity.  The second capture was 21.0F (-6.1C) and 17% humidity.

The first part of the sequence seems to be the same in all the captures I've taken, which I'm assuming is a unique device code...

Any help would be appreciated.  I'm still a bit confused on how to read these things. smiley



* capture3.tiff (50.62 KB, 1131x332 - viewed 352 times.)
Logged

Dallas, TX USA
Offline Offline
Edison Member
*
Karma: 47
Posts: 2328
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

maybe this german thread will help:
http://translate.google.com/translate?hl=en&sl=de&tl=en&u=http%3A%2F%2Farduino.cc%2Fforum%2Findex.php%2Ftopic%2C67545.0.html

or perhaps this project:
https://bitbucket.org/fuzzillogic/433mhzforarduino/overview

--- bill
« Last Edit: June 19, 2012, 12:40:34 am by bperrybap » Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 23
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thanks Bill!

I guess I'm just confused on how to read the graphic above... It may be inverted, but I'm not sure.  I found this page that was helpful: http://alyer.frihost.net/thn128decoding.htm

But I'm not sure if I'm even interpreting my 1's and 0's correctly...

If I take the short segments as a 1 and the long segments as a 0, I get:

Code:
46.2 (7.9C) 46%:  1011011011010110110111011101111101011
21.0 (-6.1C) 17%: 1011011011010110110111101011010110101011

Am I even on the right track?  is that even a valid way to decode it?  Forgive my newbie ignorance smiley
Logged

0
Offline Offline
Shannon Member
****
Karma: 160
Posts: 10418
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Since there are never two long gaps in a row, its probably not a bit in itself - the code is probably a short pulse for one symbol and a short pulse followed by a gap for the other bit.  If we call these 0 and 1 that gives:

10101011010100100100001101
10101011010100011011011101

Which makes the messages the same length, which is encouraging.

The 101010110101 sequence at the start is probably packet-synchronization preamble.

More data points needed to progress further perhaps?
Logged

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

Offline Offline
Newbie
*
Karma: 0
Posts: 23
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Since there are never two long gaps in a row, its probably not a bit in itself - the code is probably a short pulse for one symbol and a short pulse followed by a gap for the other bit.  If we call these 0 and 1 that gives:

10101011010100100100001101
10101011010100011011011101

Which makes the messages the same length, which is encouraging.

The 101010110101 sequence at the start is probably packet-synchronization preamble.

More data points needed to progress further perhaps?

Whoa, thanks Mark... that makes a ton of sense.  I've taken several other samples and they all begin with the same sequence, so I'd agree with you that the 101010110101 sequence seems to be a preamble or perhaps some sort of device ID.  

The unit transmits several bursts of the same bit sequence, perhaps 12 or 13 times per sample I've taken - it leaves a longer gap in between each repetition.  Because there's so few bits in the sequence maybe that's its means of a CRC check... just say it until it gets right smiley  

I've attached a couple more samples where the display read 86.0F and 16% (top in attachment) and 85.1F and 16% (bottom in attachment). All the samples I've taken begin with 101010110101.  With the long gap at the end, do you think the last bit would be a 1?

If I understand them correctly, they come out to be:

10101011010100000001000001
10101011010100110001101101

It's puzzling to me that there is not more bits in the stream...  I found this (http://lucsmall.com/2012/04/27/weather-station-hacking-part-1/), specifically the diagram near the bottom of the post, which may or may not prove to be helpful.  

Any ideas, anyone?

EDIT: I should mention I did invert the waveform in this attachment vs the one in my original post...


* capture4.tiff (57.9 KB, 1162x334 - viewed 286 times.)
« Last Edit: June 19, 2012, 11:04:46 am by joshhawk » Logged

0
Offline Offline
Shannon Member
****
Karma: 160
Posts: 10418
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Typically radio packet preambles are alternating 1's and 0's to enable accurate clock-recovery and decrease the risk of confusing noise for a packet.

The actual values in the packet may be raw ADC outputs from the sensors, which might be odd units - hence the need for loads of examples to tease-out the meaning.

Repeating the packet with different spacing is to enable it to get past various forms of repetitive or bursty interference with high likelyhood (I presume the system does not use a packet-acknowledgement protocol as transceivers at each end add to cost).

The actual values might even be encoded of course...  Perhaps 1 should be 0 and 0 should be 1?  bit order could be LSB first or MSB first - have fun code-breaking!
Logged

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

Offline Offline
Newbie
*
Karma: 0
Posts: 23
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yeah, have considered LSB first, perhaps they are raw ADC outputs...  The bit stream just does not seem to be long enough to contain both humidity and temperature in a BCD mode.  How would I go about decoding raw ADC outputs?

I've taken about 10 samples so far of various temps and humidities and they all begin with the same bit sequence 101010110101. 

Another interesting thing the manual said is that the base station can use up to 3 separate sensors, and to wait at least an hour between adding new sensors to the system on initial setup.  Makes me wonder about device codes in the bit stream.

I wonder if it would be helpful to take the transmitter apart and see what's going on inside.

Anyone have any ideas?
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 23
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Alright, I'm officially stumped.  Everything I've found on google related to other weather station protocols have many more bits than the signal that my thermo/hygro sensor gives me.  

At the beginning of every message, no matter what the temperature or the humidity reads, I have the common bits 101010110101, which as I mentioned earlier I'm guessing is probably some sort of device ID.  But that only leaves 13 or 14 bits left in the stream to store a sign bit, temperature (with 1 decimal point), and humidity value.  

For instance, the value I just captured, 71.2F and 39% humidity was: 101010110101 00101100111001

Here are a couple more, closer together:

70.2F 41%
10101011010100000010100101

70.0F 41%
10101011010100101100011101

That seems to rule out BCD mode, which would require at least 4 bits per digit, if there were 4 temperature digits and 2 humidity digits. 

Are there any other types of common encoding systems that I should look into?  Maybe this bitstream is somehow compressed, but I really have no idea how that would work.  Any sort of pointers in the right direction, even if they are just a hunch, would be helpful!
« Last Edit: June 22, 2012, 12:01:13 am by joshhawk » Logged

Norfolk UK
Offline Offline
Edison Member
*
Karma: 52
Posts: 2206
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi joshhawk,

I think we really need several more examples of the transmitter output to have any chance of decoding the signal.
I know you say the transmitter repeats the data several times but how often does the transmitter send new data?
Would it be possible to attach examples of the entire multi-burst sequence as raw WAV or upload to file sharing site that we may download them.
Logged

Handle every stressful situation like a dog. If you can't eat it or hump it. Piss on it and walk away.

Offline Offline
Newbie
*
Karma: 0
Posts: 23
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Riva,

Sure, I can give as many examples as you'd like.

I've attached several raw wav files of a bit stream with values fairly close together to be able to hopefully find the difference between them.  I can give more broad ranged values too if you'd like.

Sample B:  transmitter read 71.2F and 39% humidity
Sample C:  transmitter read 70.3F/21.3C and 40% humidity
Sample E:  transmitter read 70.0F/21.1C and 41% humidity
Sample F:  transmitter read 70.2F/21.2C and 41% humidity

The transmitter sends the burst of new data approximately every 75 seconds.

Thanks for any insights whatsoever, no matter how small!

* sampleC.wav (88.21 KB - downloaded 17 times.)
* sampleE.wav (87.12 KB - downloaded 10 times.)
* sampleF.wav (80.59 KB - downloaded 11 times.)
* sampleB.wav (96.91 KB - downloaded 13 times.)
« Last Edit: June 22, 2012, 09:14:19 am by joshhawk » Logged

Norfolk UK
Offline Offline
Edison Member
*
Karma: 52
Posts: 2206
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi joshhawk,

Thanks for the samples. They are quite low level but with a bit of amplification I get the idea. Looking at them stacked on top of each other (see picture) and I wonder if it is maybe not Manchester encoded. It looks more like a MFM encode but that's normally used for magnetic media use.
Can you open the transmitter case without damage and maybe see what components are inside?

Edit:
Forgot to ask if you could supply more samples over larger ranges please.


* Waveforms.jpg (60.95 KB, 1133x191 - viewed 55 times.)
« Last Edit: June 23, 2012, 02:25:02 am by Riva » Logged

Handle every stressful situation like a dog. If you can't eat it or hump it. Piss on it and walk away.

Offline Offline
Newbie
*
Karma: 0
Posts: 23
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Riva,

Yes, I agree, it does not seem to be manchester encoded...  I did not consider MFM encoding, but that may be a possibility.

Here are a few more samples, plus some photos of the inside boards.

Sample J: transmitter read 80.6F/27.0C and 26% humidity
Sample K: transmitter read 43.0F/6.1C and 19% humidity

I can get more samples and more pictures if you'd like.  Thanks so much for your help!

* sampleJ.wav (90.38 KB - downloaded 11 times.)
* sampleK.wav (99.09 KB - downloaded 12 times.)

* acurite-1.jpg (48.74 KB, 480x640 - viewed 36 times.)

* acurite-2.jpg (67.89 KB, 480x640 - viewed 36 times.)
« Last Edit: June 23, 2012, 06:25:51 pm by joshhawk » Logged

Norfolk UK
Offline Offline
Edison Member
*
Karma: 52
Posts: 2206
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi joshhawk,

Just to let you know what my thinkings are sofar. As transmission length varies depending on content and no long highs I feel sure it's not Manchester encoding. I wonder if it's far simpler than that in that a 1 is a single peak and a 0 is a peak followed by a trough (see image for better idea). The bit values could be reversed (peak for 0 & peak/trough for 1).
I had a quick look at the online manual and it says humidity ranges from 20% to 99% in 1% increments (though one of the samples you sent said 19% humidity?) so the range is 79 (99-20) that can fit in 7 bits. Temperature range is stated as -20 to +70 in 0.1 increments that fit's in 10 bits if you multiply by 10 to remove decimal point.
I also wonder if the last 2 bits are stop bits

A couple of samples of minus C temperatures would be helpful please.


* Waveforms.jpg (104.82 KB, 1231x512 - viewed 38 times.)
Logged

Handle every stressful situation like a dog. If you can't eat it or hump it. Piss on it and walk away.

Offline Offline
Newbie
*
Karma: 0
Posts: 23
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Riva,

Yes, we were talking about the possibility of that encoding scheme in a few of the earlier posts on this thread.  It's still interesting to me though because with that scheme, all of the samples I have taken begin with the same bit sequence 101010110101.  Perhaps a preamble/device id/"channel number" of some sort...

But that does not leave many bits left to represent temperature and humidity.  Despite the manual, I have seen humidities much less than 20% before, reported on the interior and exterior display.  I've attached a quick photo as proof (showing a 16% value).

I've got the transmitter in the freezer now so I will be able to give you some very cold samples very shortly.

Thank you for your help!!!


* acurite-3.jpg (8.58 KB, 240x320 - viewed 14 times.)
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 23
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi Riva, here are several more samples. 

Sample L: transmitter read 21.9F/-5.6C and 16% humidity
Sample M: transmitter read 16.3F/-8.7C and 16% humidity
Sample N: transmitter read 28.4F/-2.0C and 16% humidity
Sample O: transmitter read 28.4F/-2.0C and 43% humidity


* sampleL.wav (98 KB - downloaded 15 times.)
* sampleM.wav (70.79 KB - downloaded 10 times.)
* sampleN.wav (78.41 KB - downloaded 10 times.)
* sampleO.wav (51.2 KB - downloaded 10 times.)
Logged

Pages: [1] 2   Go Up
Jump to: