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.
https://lora-alliance.org/sites/default/files/2018-11/20181114_NetID_FAQ.pdf
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.
1 Like
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.
1 Like
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;
https://lora-developers.semtech.com/knowledge-base/forum/viewthread/173/#453
It seems that Semtech might be about to reveal what is known about syncwords.
1 Like
Should TTN be encouraging the setup of Private networks in the first place ?
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.
1 Like
2.4 GHz, for instance. And it seems that there will be additional different PHY level(s) for 868/915 MHz.
2.4Ghz LoRa does not have a configuarable syncword, according to the datasheet.
SyncWords for GFSK and FLRC modes are supported.
Yeah, but what is the hardcoded value of sync word? 0x12? 0x34? 
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.
I just ran into a LoRa (not LoRaWAN) FAQ-item from Semtech, emphasis mine:
How does LoRa behave when there is coexistence of private and public networks at given location?
…
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.
That would be extremely bad.
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.
1 Like
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
2 Likes
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.
1 Like
It needs to be remembered that this discussion of sync words is not related to TTN.
For TTN leave the sysncwords at the standard values.