What encoding is used in this signal?

Question

I have a cheap wireless pool thermometer (AcuRite 617 1) and I'd like to intercept the temperature data at the receiver and use it with a computerized data-logging system.

Conveniently, inside the receiver is a small break-out board that is connected to the antenna and has digital "V", "G", "D", and "SH" pins:

Here is a segment of captured data from the "D" pin during a transmission (these happen once per minute). Before this segment, there is what appears to be much-higher-rate data, but I believe that might be noise -- this is the beginning of the 1.36kHz / 680Hz data.

I've googled a bit and can't find an encoding that looks quite like this, but if I were to guess what's going on, here's what I'm thinking:

• the initial 4 cycles of 680 Hz are to synchronize the clocks but contain no data
• the 13 cycles of 1.36 kHz (2x the initial rate) that follow appear to have one of two forms: they either drop low before the midpoint of the cycle or after it -- i'd assume one form is a logical one and the other is a zero.
• after that, there appears to be a weird gap, but if you discount the part of the low that is part of the preceding "1", then the remaining gap is 735 µs, which is a (phase-correct!) continuation of the 680 Hz preamble.

Am I looking at this correctly? Is there a name for this encoding?

Some further notes on the break-out board:

• the board is marked "RF211" and looks remarkably consistent with the MICRF211 "general purpose, 3V QwikRadio Receiver that operates at 433.92MHz"3
• the MICRF211 data sheet has the following figure (with very little explanation), which looks tantalizingly like what i'm seeing except for the double-data-rate square wave as compared to my capture:
  

2016-02-14 Update: I've revisited this project and appear to be getting a clean 64-bit stream between a 4-cycle preamble and a 1-cycle "postamble", after which the display board shuts down the RF module by pulling ^SH low (top line):

According to Micrel's "33/66% PWM" scheme (which appears nowhere else on Google), that's

-_-_-_-_0000011110011000110000000000000000000000100011101000010010101010-_

So now I have to start manipulating the temperature to decode the bits. Here ("x") are the bits that seem to change without any apparent change in the display:

0000011110011000110000000000000000000000100011101000010010101010
------------------------------------------------x----xxxx----xxx

I assume these are either least-significant bits or battery-level (which is only shown as "Low" when it drops significantly).

2016-02-15 Update: I'm taking the show on the road to give the new "Reverse Engineering" stackexchange a crack at determining meaning: https://reverseengineering.stackexchange.com/questions/12048/what-is-contained-in-this-transmission-rf-pool-temperature-sensor-base-unit-re

Answer 1

Micrel refers to it as a 33/66% PWM scheme. It appears to be a fairly simple, but ad-hoc protocol.

PWM stands for pulse-width modulation. There is a Wikipedia page that goes into more detail, but in short, PWM is where you keep a fixed period, so here it is the time from rising edge to the next rising edge, but you vary the percentage of time spent in the high state by changing when the falling edge occurs. For this one, you can see that it is 33% high for a '1' and 66% high for a '0'.

The initial series of pulses are equal high and low times. This is usually done to allow the receiver to sync up before actual data is received.

See http://www.micrel.com/_PDF/App-Notes/an-22.pdf for some more details on what they expect for the module.

A typical way to be able to receive this sort of encoding would be to input this into a timer input capture pin of a microcontroller. Or, you can simply connect to a general input and have it sample at 4-5x the PWM period. The algorithm for decoding is not too hard from there.

Alternatively, as suggested by markt, you can work your way back to the temperature sensor itself. But, if it is an analog output signal, you will have to convert it to digital yourself and may have slightly different numbers in your logging from the original output.

Answer 2

People of my acquaintance usually call that encoding technique "PWM", which I suppose is a reasonable description.

My first thought looking at your data stream, and assuming that you're correctly guessing the polarity of the bits, is that it's a 12-bit ADC reading, LSB first, with a leading '1' as a start bit. I'm going with LSB first because the start of what is presumably the next reading shows a single-bit variation and it's unlikely that an ADC reading of (pool) temperature would vary by a 2nd or 3rd MSB in that short a time frame.

I'd dig a little further into the system, back to whatever is generating the data (as opposed to transmitting it), see if you can identify the temperature sensor, and look for some correlation between the transmitted data and the temperature.

Answer 3

I've started decoding the Acurite 617 and here are my initial observations. I can tell you that the last byte is some sort of "check" byte and the next to the last three bytes contain the temperature. These byte are also sent with using the 7th bit to make even parity and only the lower nibble of each byte is used. I've written an Arduino program to capture the data and have seen the following messages/temperature.

40 ce c0 00 00 0c 03 be
(00 0C 03) => 0C3 => 67F

40 ce c0 00 00 0c 84 39
(00 0C 04) => 0C4 => 67F

40 ce c0 00 00 0c 05 b8
(00 0C 05) => 0C5 => 67F

Other data/temps I have seen are:

E2 => 73F

F5 => 76F

108 => 80F (81 00 88)

109 => 80F

Using this you should be able to do the "straight line" (assumption) conversion.

Since I do not have a good scope (and the fact that the data is sent once a minute) I am not sure about my timing. I see the sync HI and LO as being 720 usec and the data bits being 240 and 480 usec.

Hopefully I will have more info later. I have a bunch of these. As soon as they start to leak I remove them from the pool and dry them out for use around the house. The later 617 modules (with the screw off bottom and O-ring) seem to last longer.

---

I did some more decoding. The last byte (check byte) makes the XOR of all eight bytes equal to 0FFH. For example for "40 CE C0 00 00 8D 0C 30", 40 xor CE xor C0 xor 00 xor 00 xor 8D xor 0C xor 30 is equal to 0FF.

Also, I took the temperature down to 34F and the count was 10 decimal (i,e., 00 00 0A) and at 80F the count was 264 decimal (i.e., 81 00 88 or 108H).

From this I am using Temp(F) = 0.1811 * Count + 32.1889. I might get a bigger span to get some better data if I see any error.

Looking at Rob Starling's string on 2016-02-14:

00000111/10011000/11000000/00000000/00000000/10001110/10000100/10101010 07 98 C0 00 00 8E 84 AA

XOR = FF

Count = 0E4 or 228

Temp = 73.5F

Answer 4

Almost all RF transmission schemes are going to need to have several characteristics in their data encoding protocols. These would include:

1. Consistent format preamble used to lock a receiver on frequency
2. A sync pulse indicator to mark start if frame indication
3. A method to encode data 1's and 0's with some sort of encoded clocking for data recovery.

The odd ball pulse that you noted is most surely the sync pulse indicator.

The data encoding appears to follow what I have seen referred to as pulse width encoding. This is a fairly common technique where the one transition direction follows a constant frequency leading to constant width bit cell times. During the bit cell the active pulse is presented as 25% of the bit cell time or 75% of the bit cell time. This scheme is not a pulse to pulse DC balanced encoding scheme like Manchester encoding offers. It is a common technique with pulse width encoding to provide DC balance within the message protocol by sending extra bits to create an overall balance in the whole message. In its simplest form the data is sent twice with the second copy logically inverted.

In your example it is odd to see pulse width modulated data occurring before the sync pulse. However it is still a feasible scheme if the data decoding algorithm is designed the accept the received data with the sync in this position. It is possible that the unit is sending one type of data before the sync and one after. The split could be between sensor address / temp data OR true data / inverted data.

Edit:

It is interesting to note that it almost looks like the transmitter unit is using a different software algorithm for formulating the positive pulse widths for data cells before the sync pattern than for the pulse width at and after the sync pattern. This implies that there may be a separate hunk of software generating the earlier pattern than that for the subsequent part of the pattern. This difference of pattern could imply that the data source in each case required different handling in terms of how it was accessed bit by bit. The difference seen in the timing diagram could simply be an instruction timing or two difference in the pattern generation loops.

Answer 5

What is it called?

This kind of encoding pops up all over the place. A lot of people run into it dealing with "single wire" addressable pixels (WS281x/Neopixels). It's also used in the DShot protocol which is popular for controlling Brushless ESCs in "drones"/rotor craft. Somehow the industry has not decided on a standard name.

One could argue it's a NRZ(L) signal as there is is no default "level" that is different from the two possible levels. However, the absence of a pulse could be considered a 3rd state (and is often used to synchronize/delineate packets). Therefore, I think using NRZ to describe these signals is unhelpful at best and misleading at worst.

The pulse widths are being modulated, so "PWM" isn't entirely out of place, but PWM usually means using the analog width of the pulse in proportion to some analog value.

To "encode" means to convert one format of data into another. All of these protocols are a stream of binary bits with a bit clock (and using a pause to indicate which is the "first").

PWEB (Pulse Width Encoded Bits/Binary) captures the core details about this coding scheme, independent of digital encoding/verification or expected pulse lengths.