[FSK] Separate preamble length from preamble detector length

[moshe-braner]

In RadioLib there is one function call, setPreambleLength(), and it affects both the transmitted preamble length and the receiver preamble detector length. But one may want a longer preamble transmitted (to maximize the chance that other receivers, some of different designs, will receive what is sent), and a shorter preamble detector length (to maximize the chance that this receiver will receive what is sent by others).

For the sx1262 the RadioLib code is:

SX126x::setPreambleLength(size_t preambleLength) {
...
this->preambleLengthFSK = preambleLength;
// maximum preamble detector length is limited by sync word length
// for details, see the note in SX1261 datasheet, Rev 2.1, section 6.2.2.1, page 45
uint8_t maxDetLen = RADIOLIB_MIN(this->syncWordLength, this->preambleLengthFSK);
this->preambleDetLength = ... (a code for one of the values 0, 8, 16, 24, 32)
return(setPacketParamsFSK(this->preambleLengthFSK, this->preambleDetLength, ...

Thus RadioLib forces the preamble detector length to be the same as the preambleLength (as long as that is no longer than the sync word). The RadioLib user cannot choose a smaller detector length, which defeats the purpose of having that as a separate parameters in the chip config?

This deficiency propagates to the LR1110 (same code). And to the LR2021, where RadioLib uses this code:

LR2021::setPreambleLength(size_t preambleLength) {
...
this->preambleLengthGFSK = preambleLength;
this->preambleDetLength = (preambleLength / 8) << 3;
return(setGfskPacketParams(this->preambleLengthGFSK, this->preambleDetLength, ...

There the preambleDetLength is set to the largest multiple of 8 within the preambleLength, i.e., same as the preambleLength if the preambleLength is already a multiple of 8. One can force some difference between the two by passing, e.g., 7, or 15, then the detector length would be 0, or 8.

Lacking the ability to separate these things pushes me to re-set the preambleLength for each tx and then again when going back to rx.

[jgromes]

This has been added by @StevenCellist in 24f2385

[StevenCellist]

Something was nagging me with the missing default values and the fix yesterday for the C1101's PQT, and it now strikes me that the change that I introduced means that by default, the detLength that is written for the LoRa radios is actually 0 instead of the next lowest multiple of 8. Whether this is something we want, I'm not sure. It means looser reception which can be good or bad depending on your preferences.
@jgromes should I add a double function without detLength argument that brings back the previous behaviour and remove the 0-default of the two-argument function? Or do you think that a default detLength of 0 is OK instead?

[moshe-braner]

I see the default detection length (if not explicitly passed) is "0" but then it is set to same as the preamble length? Shouldn't a zero detection length be allowed? At least for FSK. From the LR2021 datasheet section 11.3.2:
"0x00: Preamble detection is off. Packet detection is based solely on the Syncword."

The value passed to signal "the user did not specify a detection length" could be something like 0xFFFFFFFF instead.

[jgromes]

I think we need to have a reasonable default - in no small part because ConfigFSK_t struct does not have a preamble detector length field, and I'd rather avoid adding one.

To me, "reasonable behavior" is that some detector length is configured, but not so strict that it prevents reception under less-than-excellent conditions. But I also agree with @moshe-braner that "packet detector off" is a possible configuration at least somewhere.

So using a documented magic value 0xFFFFFFFF as alias for "preamble detector length = preamble length - 8 bits/symbols" would be the preferred default.