What encoding is used in this signal?
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.
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.
Almost all RF transmission schemes are going to need to have several characteristics in their data encoding protocols. These would include:
- Consistent format preamble used to lock a receiver on frequency
- A sync pulse indicator to mark start if frame indication
- 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.