Electronic – QI Charging – Differential Manchester encoding

Your representation is correct. Differential Manchester encodes each data bit as follow:

• If it has the same value as the data bit before --> High to Low transition (that would be a '0' in non-differential Manchester)
• If it has a different value than the data bit before --> Low to High Transition (that would be a '1' in non-differential Manchester).

The very first bit of the transmission would not be specified, you may choose to encode it as normal Manchester.

You may also first calculate the "differential data stream" and then perform a normal Manchester encoding of this differential data stream. The differential data stream would be defined as: \${\text{diff}}_i={\text{data}}_i \oplus {\text{data}}_{i-1}\$.

For example if your data is 00110110 you would get X0101101 and then encode it as normal Manchester.

The decoding of the data stream is just the same. You may decode it first as normal Manchester and then apply \${\text{data}}_i={\text{decoded}}_i \oplus {\text{decoded}}_{i-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.