Oops and yeah!

I don’t know what happened, but yesterday’s post is completely wrong. Maybe it was too late in the evening, maybe because I was trying to do 2 things simultaneously,  I don’t know – but the fact is, that yesterday’s post is totally messed up – it doesn’t reflect what I had in my mind at all… so that post was a major f***-up, if I may say so. Well, I’ll fix that some day. Soon, I hope. Maybe I can explain things better, once my thoughts are documented in code 😉

Fortunately, I didn’t use my own post for what I did today. It’s all in my head, right?  The status so far is that the JeeNode is correctly detecting the short and long periods and it’s reporting those on the Serial port (during the time where there’s no OT communication going on), in a format like this:

FT 1
0S
1S
0S
1L
0S
1S
0L
1L

The FT stands for ‘First Transition’, which tells me that a new transition from 0 to 1 has been spotted.  After that (line 2), the JeeNode input went LOW (0) for a short period (S), HIGH (1) for a short period, LOW for a short period and HIGH for a Long (L) period, …

With this information  I can ‘rebuild’ the signal and the bit stream. For now, I’ve  done this in my favorite programming language Delphi, just to speed things up a bit. The sketch has been running for just half an hour or so and the fact that the reconstructed bit streams have had a length of 68 bits all the time, is encouraging. Cause 68 bits lead to 34 Manchester-decoded bits, which is exactly the size of an OpenTherm frame of 32 bits +1 start- and stop bit. Yeah!!

When I’m 100% sure of how everything should work, I’ll embed all the bit calculations & manipulations  into the sketch, so that all I’ll only receive the resulting 4 bytes per OpenTherm frame from the JeeNode.

But there’s still a lot of work to do before I get there!

Tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *