Somehow the OpenTherm Monitor I built a week ago has some problems to correctly decode the signal to Manchester code and produce the correct 32 bits. And the strange thing is, that my logic analyzer which I attached to the input pin on he JeeNode, doesn’t seem to have these problems (click):
Time to figure out how ‘good’ the signal really is, and whether it’s worth the time to try to improve the OT Monitor – I don’t just want to give up!
The first thing I did, was having a look at the distribution of the periods between all the transitions (high <–> low). For that I wrote a sketch that used TIMER2 to check the value of the input pin every 80 µs. The time between each transition was measured and stored into an array during sampling. And after a certain number of transitions, it would write the array to the Serial port.
The Serial Output looked something like this:
2 0 3 1 4 1 5 217 6 2795 7 1246 8 23 9 0 10 0 11 16 12 325 13 281 14 17 15 0 16 1 17 0
Copy & paste to Excel and creating a chart revealed the following:
Here you see the distribution of all the measured periods between a transition (for both high to low and vice versa) .The numbers on the X-Axis should be multiplied with 80 µs to get the real duration of all the periods. Well, it’s clear that there’s a peak at ≈500 µs and a second one at ≈1000 µs (1 ms); that’s good and what can be expected for a signal with 1 ms bit rate and where the difference in duration between the short and long periods is a factor of 2. So far so good.
Another test I did was to see how the ‘low’ periods and ‘high’ periods related to each other; did they both perform equally well?
Don’t mind the X-axis numbers, I’m not that good with Excel 😉 – it’s the red (high periods) and blue (low periods) lines that count. Again, the time of the second peak (63) is twice as larga as the first (31..32). That’s good.
But the chart is not that ‘clean’ anymore… some yet unexplainable things popped up. For example, the leftmost peak of the high periods (e.g. the short high periods) shows a strange curve to the right. In words, this means that there are quite a lot of short high periods that take longer than you’d want – cause the ideal situation would be a chart with only 2 narrow, high peaks for both the highs and lows, right? Could this mess up things? It could very well be that 1 single transition messes up the timing and hence the decoding of a complete OT frame…
I don’t know if that last thought (1 single period messing up things) is right – I have to dig some more, understand the OT Monitor sketch, try to find out where in the frame the timing goes wrong and see if I can find a pattern somewhere. If there’s a pattern, maybe I can create a work-around for it to improve the decoding..
Ow, and why’s there a huge dip in the blue (low) chart?
To be continued…