Hello,
I gathered some facts from datasheets and source about this topic and hope to supply a bit more clarification of what is done with the sync word behind the scenes without adding confusion.
sync word / synch word are the same. It is just not used consistently.
LoRaWAN Specification:
According to the lorawan regional parameters the synch word (not sync word. it’s synch word) states use of LoRa modulation. No mentioning of 0x12. It is always 0x43 for LoRa but they mention it SHOULD be used, so not essentially required. Also I could not find any explanations there.
See lorawan_regional_parameters_v1.1rB-final.pdf, page 15 section 2.2.1 EU863-870 Preamble Format.
Also I noticed the synch word is not defined for all countries, e.g. Australia.
Semtech Packet Forwarder Source:
There is no mentioning of a “sync_word” key/value (also no synch_word) in the semtech packet forwarder configuration but there is a sync_word variable which is only used for GFSK modulation.
But there is a lorawan_public key/value and it has the following comment:
“Enable ONLY for public networks using the LoRa MAC protocol”
And in the code it does write the numbers of 0x34 (if lorawan_public == true ) or 0x12 (false) into the registers using SPI.
Note the SX1301 (concentrator chip on gateways) registers are not explained in the data sheet. You are referred to the github repository instead.
SX1272 / SX1276:
https://www.semtech.com/uploads/documents/sx1272.pdf
and
https://www.semtech.com/uploads/documents/DS_SX1276-7-8-9_W_APP_V5.pdf
The data sheets say this about sync:
4.2.11.1. Sync Word Recognition
Sync word recognition (also called Pattern recognition) is activated by setting SyncOn in RegSyncConfig. The bit synchronizer must also be activated in Continuous mode (automatically done in Packet mode).
The block behaves like a shift register as it continuously compares the incoming data with its internally programmed Sync word and sets SyncAddressMatch when a match is detected. This is illustrated in Figure 29 below
During the comparison of the demodulated data, the first bit received is compared with bit 7 (MSB) of
RegSyncValue1 and the last bit received is compared with bit 0 (LSB) of the last byte whose address is determined by the length of the Sync word. When the programmed Sync word is detected the user can assume that this incoming packet is for the node and can be processed accordingly.
4.2.14.2
Variable Length Packet Format
Variable length packet format is selected when bit PacketFormat is set to 1.
This mode is useful in applications where the length of the packet is not known in advance and can vary over time. It is then necessary for the transmitter to send the length information together with each packet in order or the receiver to operate properly.
In this mode the length of the payload, indicated by the length byte, is given by the first byte of the FIFO and is limited to 255 bytes. Note that the length byte itself is not included in its calculation. In this mode the payload must contain at least 2 bytes i.e. length + address or message byte.
An illustration of a variable length packet is shown below. It contains the following fields:
- Preamble (1010…)
- Sync word (Network ID)
- Length byte
- Optional Address byte (Node ID)
- Message data
- Optional 2-bytes CRC checksum
4.2.14.3. Tx Processing
In Tx mode the packet handler dynamically builds the packet by performing the following operations on the payload available in the FIFO:
- Add a programmable number of preamble bytes.
- Add a programmable Sync word.
- Optionally calculating CRC over complete payload field (optional length byte + optional address byte + message) and appending the 2 bytes checksum.
- Optional DC-free encoding of the data (Manchester or whitening).
4.2.14.4. Rx Processing
In Rx mode the packet handler extracts the user payload to the FIFO by performing the following operations:
- Receiving the preamble and stripping it off.
- Detecting the Sync word and stripping it off.
- Optional DC-free decoding of data.
- Optionally checking the address byte.
- Optionally checking CRC and reflecting the result on CrcOk.
In variable length mode the first byte received after the sync word is interpreted as the length of the received packet.
4.2.14.6. Packet Filtering
The SX1272/73 packet handler offers several mechanisms for packet filtering, ensuring that only useful packets are made available to the uC, significantly reducing system power consumption and software complexity.
Sync Word Based
Sync word filtering/recognition is used for identifying the start of the payload and also for network identification. As previously described, the Sync word recognition block is configured (size, value) in RegSyncConfig and RegSyncValue(i) registers. This information is used both for appending Sync word in Tx and filtering packets in Rx.Every received packet which does not start with this locally configured Sync word is automatically discarded and no interrupt is generated. When the Sync word is detected payload reception automatically starts and SyncAddressMatch is asserted.
Note
Sync Word values containing 0x00 are forbidden.
Address Based
Address filtering can be enabled via the AddressFiltering bits. It adds another level of filtering above Sync word (i.e. Sync must match first) and is typically useful in a multi-node networks where a network ID is shared between all nodes (Sync word) and each node has its own ID (address).
Register description mentions this:
Timing diagrams show some important info about the sync word:
Next: Recommended SX1272 Settings for EU868 LoRaWAN Network Operation
https://www.semtech.com/uploads/documents/an1200.23.pdf
Semtech Forum
Comment by Semtech employee:
http://semtech.force.com/lora/LC_Answers_Questions?id=90644000000PlqNAAS
Gregory (Semtech Corporation)
Hi All,
We have used the term sync word as we could not[SIC] find a better name but it is not a sync word as such. This register is just a way to differentiate two LoRa signals which do not interfere with one another. Here, not all values are permitted if you want to be able to differentiate signals with different “sync word”.
How sync word change looks on the scope:
https://revspace.nl/DecodingLora
Personal Conclusion
For me it boils down to a bad choice of variable name ‘lorawan_public’ and ambiguous interpretations by different people even within Semtech Corporation.
The default value mentioned everywhere depends on the level of abstraction, e.g. Semtech chip has Default 0x12 but end device radio modules will most likely set to 0x34 as ‘their default’.
If you want to use your end device with different gateways (and subsequently networks) all participants, end device and each gateway operator will need to stick to the mentioned 0x34 or devices wont be able to communicate due to sync word mismatch. So my advice is to stick with this value if you want to compatibility.
Also from the docs above:
The SX1272/73 packet handler offers several mechanisms for packet filtering, ensuring that only useful packets are made available to the uC, significantly reducing system power consumption and software complexity. Sync word filtering/recognition is used for identifying the start of the payload and also for network identification.
This is a mentioned in the data sheet and not the lorawan specification but still the mentioning of ‘network’ even if only understood in a broader sense does relate a bit to the lorawan network term. But setting the sync word other that 0x34 will shut off access to lorawan networks while only allowing matching sync word networks.
So if you choose a sync word different you lose compatibility of end devices to other networks but if thats what you want, this should be done in order to achieve less iC activity or better battery runtime depending on configuration.
What else happens inside undocumented firmware as side effects of setting the sync word I don’t know.
I also read that using a different sync word other than 0x34 means not being 100.0000% compliant to the lorawan spec even if all participants would be compliant in all other aspects of the specification.
I am not a lawyer but maybe someone could find out if it is legit to run a public lorawan network without using 0x34 even if that would not make a lot of sense to do so.
