So far I thought that public LoRaWAN networks (maybe including commercial shared networks such as TTI) need to use sync word 0x34 (or 0x3444 for SX126x 16 bits). And private LoRaWAN networks require 0x12 (or 0x1424 16 bits). Even @htdvisser mentioned that, though long ago:
Also, I see configurations in some LoRaWAN libraries, to change it.
However, maybe my understanding was just wrong, as in another topic @LoRaTracker mentioned a distinction between LoRaWAN and non-LoRaWAN:
The following synchronization words should be used:
Same for other versions, same for all other regions, and no mention about public/private (there) at all.
If LoRaWAN is indeed always 0x34 (or 0x3444 16 bits), then off-the-shelf sensors that are shipped with just an OTAA DevEUI, AppEUI and AppKey will work on both public and private LoRaWAN networks. Nice.
So: should private LoRaWAN networks use a different sync word?
There’s no offically published document saying this (SX127x datasheets don’t count, they actually say/know nothing about LoRaWAN). And, as you already said, Reg. Params. doc clearly states that 0x34 should be used for LoRaWAN.
Another confusing thing: if 0x12 (or 0x1424 16 bits) would be non-LoRaWAN, then there would be basically only two sync words in LoRa: LoRaWAN and non-LoRaWAN? That’s probably not the case, so why (or by whom) was this 0x12 defined…
I don’t know if 0x12 and 0x34 are the only allowed values, but you surely cannot use whatever value you want to use for sync word. Someone from Semtech was trying to explain these matters at their Salesforce community site some years ago, but that site was redesigned since that (and a lot of valuable info was lost), not sure if it still possible to finf that discussion.
Funny you asked; I started to look for the official documentation as I wanted to make clear that non-programmable off-the-shelf devices are not usable on private networks, as they have the sync word fixed to the public 0x34.
I note the comment in that about setting up a private network, but presumably thats to do with setting up a private backend.
If a user sets up a Gateway and nodes with a different syncword, and uses the (free) TTN backend, are they OK with that ?
One issue with different syncwords is that you may not even know the nodes\gateways are there, so its possible a ‘rogue’ network local to you could be consuming\blocking channels and you wont see them …
In the 3 years since I wrote that message I haven’t heard of any network actually using a different sync word.
@LoRaTracker’s explanation seems reasonable, but the fact that the sync words are specified separately for each band in the LoRaWAN Regional Parameters specification suggests that there could be future bands that use different sync words.
Let’s keep an eye on that thread then.
I would say no. All LoRaWAN networks need to be compliant with the LoRaWAN Regional Parameters specification, and use the sync word defined for the band.
The SyncWord is always configurable. It is here to separate networks and avoid spending time demodulating frame which belongs to another network, so if you are on a completely different band you can re-use a syncword without worry.
As soon as you are on a private network you can use whatever valid SyncWord you want as long as it is different from the public one. I think the value 0x12 for private network was just defined to give people one valid value which was tested and characterized. But if you set up multiple private network in the same geographic area you will need to use different sync word and if you respect some rules it will work properly.
As for the rules:
Each nibble of the SX127x SyncWord must be strictly below 8 to be compatible with SX126x
Each nibble of the SX127x SynchWord must be different from each other and from 0 or you might experience a slight loss of sensitivity
Translation from SX127x to SX126x : 0xYZ -> 0xY4Z4 : if you do not set the two 4 you might lose sensitivity
There is more to it, but this should be enough to setup your networks and hopefully the official response will be more complete.
When it comes to the access point side (gateways), the use of the “private” sync word versus “public” sync word is useful to ensure that the gateways don’t report a vast majority of the incoming traffic using a different setting.
So again, this doesn’t sound like a mandatory thing.
The reason is that sync word detection is “leaky” - try configuring the wrong one, and you’ll see that sometimes packets get through anyway.
If a packet is picked up by a gateway configured with the wrong sync word, and reported in as stronger than any copy of that packet received by one with the right sync word, then the “accidental” availability of that gateway could walk an ADR algorithm into assuming that gateway is a regulator contributor to the network, or get it elected to send a reply.
But since wrong syncword packets only get through a fraction of the time, this would be highly misleading, either causing missed downlinks or causing ADR to adjust for a nearby gateway that picks up the node’s signal loudly when it detects it at all, but usually misses it.
If you’re going to connect a gateway to TTN, definitely use the proper sync word.
Messing that up is far more severe than the “extraneous” (and decoder-rejected) traffic that would occur from sharing a synchword between a private and a public network.
It’s effectively the difference between a “spoofing” denial of service and a (very gentle) “flooding” one.
To the question “do the first and third nibble of the SX1262 sync word really need to be 4” : it actually can be C as-well if I remember correctly but this would set peak position incompatible with SX127x.
Also you did not specify which spreading factor you used for your test:the syncword SX1276 0xF1 can work with the SX1262 for SF7 (the proper one being 0xF414, really not sure why 0x7414 could work tbh) but there should not be any reliable configuration for SF8 to 12 with this sync word.
Edit: thinking about why “wrong” syncword still works, I think it is simply due to the the fact that at high SNR if only half the syncword is correct it can be enough to synchronized, if you were to do the same experiment with some attenuator to be closer to sensitivity level you would observe a lot more issue when setting incorrect syncword.