robwlakes:
Advice is probably the last thing you feel like at this stage (after all your efforts), I hate being lectured so please forgive me if this offends you in anyway.
Not only it's not an offense, I'm grateful for your advice! It's the only way to learn
robwlakes:
When you are processing the preamble after looping for a rising edge, you appear to set a minimum of 10 for the preamble bits, but process them in a set "for" loop, and if successful completed, then keep looking for the synch waveform (I presume here this part of the search just crunches and ignores any remaining preamble?).
As you say later, detecting the preamble is really not necessary. However, I did it this way because I wasn't sure that my cheap receiver could receive the whole preamble (12 ones) before it had adjusted the gain. So I put just a few as a first check and then wait for the sync (ignoring the rest of the preamble).
robwlakes:
So in your case, I would begin detecting the preamble waveform, checking each 'bit', counting them and noting when more than MAXPREAMBLE is exceeded. When the synch sequence begins then it will appear as a possible "preamble error" or the "synch" waveform, and needs to be further examined to see if the waveform actually complies with the synch period. Personally I would immediately do a long delay that should land me about 1/4 the way into the next hi (0.050s), sample it again twice (eg 0.051 and 0.052s) and if both high, assume it was the synch bit (if not, flag error and exit). Then loop for the falling edge at about 0.054s. Then sample again at 0.56 and 0.58s, if both lo then continue (if not, flag error and exit) and loop for the rising edge of the first "0" waveform, and resynch it all in to the following data bit waveforms.
That would be the best way, and extremely reliable. However, one of the things I like more about this Manchester encoding (which I didn't even know before this small project) is that, even if I make a false positive detecting a sync part, the message part will throw an error and safely discard the transmission. So I can make a simpler detection of the sync, because later the code will auto-detect if we have a valid message.
robwlakes:
Do you know the numbers for the rolling code, ie are the rolling codes always even for example ie A0=0?
At first, I tried to detect the third part of the sync (the low value), and then wait for a rising edge. I thought the a0 was always zero (at least I've always received a zero in my tests with my sensor). However the protocol says that that bit "is not always marked by an RF transition and must be measured from the end of the long sync pulse". So now my first positioning is at the falling edge between the second and third parts of the sync (and then wait a fixed duration that should be the length of that third part).
robwlakes:
Either way at least aligning the program's timing on the falling edge in the synch waveform (0.054s) would be better than the first detected rising edge of the preamble (0.010s).
That's what I did I aligned twice, one on the preamble part, and another when we leave the high pulse of the sync. Aligning on the preamble was redundant.
robwlakes:
Why you might say do the "loop and wait for an edge" all the time? Well mainly because it continually resynchs the detector with the Tx, and this does allow for oscillator variations caused temp or humidity etc, but more importantly it allows for the differences in time to do the processing of the bits that come in. For example processing time for a Zero will be slightly different to a One etc. The delay(duration) commands can give the overall bigger delays required for waveform checking, but small errors can become significant if everything was taken from one part of the early waveform as the only synching point.
You are right! I've found a potential problem in my code. I had my sketch aligned to the edge of the sync, but, after the sync part, through the message, it always moves in steps of one quarter of wave. That means that if the delays I'm using are not accurate enough (and they probably aren't), I could be out of sync after a few cycles. As the message is quite short (32 bits), the code worked and I got away with it, but if the conditions change then it could break.
I've changed my code to solve this. First, I don't look for the preamble at all, I just go for the sync. In fact, the code works if you only look for the second part (the high zone) of the sync, but I detect too the first low part because there were too many fake positives (although the message for them is invalid). Then align to the falling edge of the second zone, wait for what I think is the delay of the third pulse (5100 microseconds) and start a loop to read bits: wait one quarter, read possible value, wait for edge (this realigns the timings), wait one quarter, confirm the value has changed and then wait for another quarter to be at the beginning of the next bit. This should be much more robust than before.
Receive_Oregon_v1.ino (8.48 KB)