Serial.print(F("RegSyncValue1="));
Serial.println(radio.readReg(REG_SYNCVALUE1));
Serial.print(F("RegSyncValue2="));
Serial.println(radio.readReg(REG_SYNCVALUE2));
The problem with short sync ids is that they lead to frequently mistaking noise for actual packets if the rssi threshold is set below the noise floor (which it is in the default rfm69 settings). You don't notice that directly since the library switches the radio to automatically discard packets with invalid crc. What you'll see instead is a short interruption in ability to rx every time a phantom packet hits.
With higher bitrates this is already noticeable with 2 byte sync. With one byte it would happen all the time.
To further elaborate: sync word detection is implemented as a bit shift register. So every bit gives you a new word that could match. With a one byte sync id you should get a phantom packet every 256 bits, or every 32 bytes, or every 5ms at the 55khz default settings on average. At 2 bytes it's about one per second.
This is why I'm using 3 bytes which averages one phantom packet in around 5 minutes at 55khz.
IF a preamble is being used (as it now seems likely), does that cut down at all on the frequency of occurance of the phantom packets? i.e. does the phantom packet have to, in some sense, have to be preceeded by a well formed preamble? i.e. does having a long preamble also act as a filter of sorts, or not?
I'm still not clear on exactly how the sync word detection works. You can have zero bytes of sync word even in packet mode, which would imply some kind of delimiter after the preamble (otherwise how does it byte align, or know where the data actually starts?).
I suspect it does what the EZ-Radio does (see links below), which is to shift the next n bits as determined by the sync word length register, and then compare. If the answer is no match, start to detect a preamble again, and once it thinks it's got that look again for the delimiter and repeat. This would give the impression of continual scanning.
There may be a delimiter, I don't know. It'd be pretty easy to check: set a one byte sync word with the same pattern as the preamble and check if you get ADDRESSMATCH if the other side is merely sending extended preamble.
I suspect it does what the EZ-Radio does (see links below), which is to shift the next n bits as determined by the sync word length register, and then compare. If the answer is no match, start to detect a preamble again, and once it thinks it's got that look again for the delimiter and repeat. This would give the impression of continual scanning.QuoteThat is definitely not what's happening. Once the radio starts looking for the sync word it does so until it finds it or you change mode or issue RXRESTART. The entire approach of running at an RSSI thresh of 255 is predicated on this.
During preamble reception the radio does AGC, AFC etc. I don't think it's reasonable to assume that it can detect whether the signal actually is preamble at the same time.
Also the frequency of phantom packets would be much lower than what I'm seeing if a full preamble had to be seen to restart sync address detection.
waiting for the delimiter at the end of that preamble
Yes, I suspect this is in reality is really just a continually shifting register as you stated but with a short delimiter, possible only one repeated bit, at the end of the preamble. I can't see how using zero sync words could actually work without it. In which case chosing sync words with 'good auto-correlation functions' would reduce the false triggering:
http://community.silabs.com/t5/Proprietary-Knowledge-Base/EZRadioPRO-and-Sync-Word-Selection/ta-p/113455
Mark.
So I think that answers the question about the shifting.
I'm assuming (?) that the data whitening applies to the payload only, and not the sync words.
Is the property of "good auto-correlation" an abstract mathematical property that's hardware independent, or rather does it (I'm guessing) depend on how the underlying hardware works? In which case, how do we choose good sync words for the RFM69 that have good "auto correlation"? I have not even an inkling, other than to apparently avoid repeating bit patterns (as suggested by the Silicon Labs link) that look like a preamble.
Ay yi yi. Sometimes it feels like we practically have to be able to build an RFM69 all the way up from gates and transistors in order just to use one!
but I'm as in the dark as you are as to how to calculate such a thing other than as you say avoiding patterns that look like a preamble.