8 or 16 bit Sync Word for SX1262?

[MrSniffer]

The Semtech SX1262 data sheet shows both a LoRa Sync Word MSB and LoRa Sync Word LSB. But the RadioLib LoRa library begin call has a parameter uint8_t syncWord. Is there some fixed mapping between the one->two byte values? The library call setSyncWord takes two bytes meanwhile, with a comment that the second parameter should be 0x44 "for compatibility". N.B. My usage may be a special case, since I am using only SX1262 to SX1262 communications and no other device types and has no LoRaWAN functionality, working elsewhere in the US 900 Mhz ISM band.

[jgromes]

This is one of, perhaps even THE greatest "gotcha" in SX126x documentation. The LoRa sync word does not have an MSB and LSB. As a matter of fact, the sync word does not translate into any bits, as one would expect e.g. with FSK. LoRa sync word are a few chirps sent after preamble, and the commonly used 0x12 or 0x34 values change that in some as of yet officialy unpublished (to my know knowledge) way. It's not like in FSK where a different sync word, even with a single bit of difference can be used to distinguish different networks. In LoRa, you can still receive packets with different sync words than you are expecting. The two values that give the largest difference in terms of the amount of these false positives are 0x12 and 0x34. Using something else other than those two is not really recommended.

In case of SX126x, the single "byte" of the sync word spread accross two different registers - why was it done in this way, I have no idea. To make matters worse, the extra bits that are not taken up by the sync word, are used for some undocumented purpose, and so setting them to anything other than 0x44 will likely significantly impact the performance, or prevent it from working altogether (speaking from experience here). So I would suggest to stick to the recommended 0x12 value for private networks, as that seems to be what you are doing.

[MrSniffer]

Sigh. You are confirming the impression I have based on a few articles dealing with this subject. My system design is a LoRa mesh network. I don't want to impact LoRaWAN users so (1) I can use frequencies which are mhz away from the LoRaWAN channels (2) I can use 0x12 for my syncByte. However I am attempting to distinguish two modes of transmission in my system. I'm not sure that inter-channel filtering is so great given widely varying signal strengths along differing paths. And given that, filtering packets at the sync level can significantly reduce the burdens of interrupt handling, task switching, etc. purely in software, which is my current technique. So 100% filtering accuracy isn't essential; any amount is desirable IMHO.

Using only 2 code points (0x12, 0x34) of the total 216 or 28 seems so poopy!

And regarding the curent RadioLib implementation: were you saying that for any of the 256 uint8_t settings, the other nibbles are always set to 0x44?

[jgromes]

Using only 2 code points (0x12, 0x34) of the total 216 or 28 seems so poopy!

Agreed, though with testing, you should be able to find custom value that could be used. There's an article here that does something similar, not sure if you've seen it yet.

And regarding the curent RadioLib implementation: were you saying that for any of the 256 uint8_t settings, the other nibbles are always set to 0x44?

By default yes, the second argument in SX126x::setSyncWord allows you to change that.