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:
Modulation
Sync word
Preamble length
LORA
0x34
8 symbols
GFSK
0xC194C1
5 bytes
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?
This, obviously, isnât correct. A officially assigned NetID isnât required for a private network. But 0 and 1, typycally used for private networks, surely are NetIDs too.
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.
Semtech have never, as far as I am aware released full information of how syncwords work or which ones are compatible between SX127X systems (16 bit sync words) and SX126X systems (32 bit syncwords).
I have also not seen an reasonable explanation as to why some constructs of syncwords loose you sensitivity on the receive side.
However following an issue raised on the Semtech Knowledge base;
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.
To be clear, I very much endorse an open, shared, public network: Why do you need TTN?
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.
Since the datasheet does not mention a syncword for LoRa, then even if you assume there is a secret one there and it is hardcoded, its possible value is of no real relavence.
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.
We actually were talking about LoRaWAN and hypothetical changes to Regional Settings doc, not about P2P and the only currently available end node chipâs datasheet.
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.
We recently had the situation where we needed to participate in a private network with a SX1262 using a special, predetermined sync word (0xF1 on SX1276) and did a few experiments to find out which sync words work between the SX1262 and the SX1276. Iâm putting the link here, may be this will help somebody in the future: https://blog.classycode.com/lora-sync-word-compatibility-between-sx127x-and-sx126x-460324d1787a
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.
