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.
That's a worthwhile experiment to do. I'll see if I can knock up a test.
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.
That 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.
I'm not suggesting the user restarts the preamble detection, I'm saying the radio itself might automatically. So the receive process might be:
1) go into RX mode
2) radio hunts for the preamble, once detected then goto 3
3) radio waits for the delimiter (bit repeat?), once detected then goto 4
4) radio bit shifts the next n bits and only at the end compares. If match goto 5, else go back to 2.
5) receive packet.
So that would scan indefinitely. And if the preamble is longer than the sync word you won't lose any packets with RSSI threshold set at 255, but if the sync word is longer than the preamble you might.
That's the way the EZRadioPRO appears to do it, and it therefore would allow arbitrary sync word patterns, although I note it recommends sync words with 'good auto-correlation functions' and has a warning about 0xAA or 0x55 patterns but that might be for the non-PRO versions.
So are we
really sure this isn't what is happening? It may well just do a simple scan as per the non-PRO EZRadios, but I can see the above potentially giving the same test results if the number of preamble bytes is more than the sync word.
Mark.