Consider the following scenario: the payload data packets are running at 9600 bit/s, with a 250 kHz bandwidth. In these conditions the LoRa Calculator Tool offers two possibilities that are compatible with the 9600 kbit/s speed:
a) SF7 and coding rate 4/5, giving a maximum payload rate of 10937 bit/s.
b) SF6 and coding rate 4/8 (a much better FEC), giving a maximum payload rate of 11718 bit/s.
The second option is certainly better, if the link margin is sufficient. For the same time-on-air, you have more redundancy, which will give you a better chance to recover the packet in case of a nasty, high-power, in-band interference. At the cost of a small sensitivity hit, of about 2.5dB.
Lower BW are made by simply playing the waveform files at a lower sampling rate. The OSR is set to 4, so play them at 500 kHz for LoRaBW = 125 kHz, 250 kHz for LoRaBW = 61.25 kHz, 125 kHz for LoRaBW = 30.6 kHz, and so on.
This method is extremely widespread in the industry, for instance in drive-by smart-metering scenario where an interrogator is present and sends a long preamble to wake-up a device for seldom interrogation. It is all a trade-off between Rx duty-cycle (energy efficiency on the Rx), length of the interrogating preamble, and over-hearing.
The source has to be clever enough to detect false interrogations and adapt itself to fake interrogations, for example due to a raise in the noise floor in the channel. Typically, wake-up on RSSI is used and self-adapting RSSI threshold helps mitigate over-hearing, which is harmful for the battery lifetime.
Most commercial gateways have either a built-in GPS or have an input to use an external one. The GPS is mandatory for Class B so that the beacons are all synchronized.
Typical Noise Floor is usually close to -120 dBm, this will be your average lower bound for RSSI. When the signal is saturated, -40 to -30 dBm sounds about right.
The LoRa receiver is able to demodulate RF packets with a SNR as low as -20 dB in SF12. Anything higher than +5 dB is meaningless, and should be considered as there being "plenty of signal".
The typical channel spacing for LoRa and LoRaWAN is 200 kHz, which is the separation between two channels (if you have one device running at 912.2 MHz, the next one would be at 912 or 912.4 MHz). In principle, LoRa gives proper separation (selectivity) with more than 1.5*LoRaBW as far as channel separation goes. This would be at the minimum 178.5 kHz. Any lower separation would yield lower isolation and therefore more collision chances, the larger the better.
The CAD interrupt happens at a determined time after the CAD has been requested by the host. It can be on preamble (best performance), but could also fire up on payload if it is launched then, although with potentially degraded performance.
It is not possible to use one of the DIOs of SX1280 to start a transmission sequence.To fine control the instant of a Tx start after a Rx event, it is recommended to use the command "SetAutoTx"
The payload size limitations are identical in uplink and downlink. The limitation itself depends on the data rate and the local regulations. Depending on the regulation, the time-on-air may have some limitations which are then enforced in the LoRaWAN Specifications. For more information, check the LoRaWAN Specifications and the LoRaWAN Regional Parameters.
Between the moment a packet is sent by a sensor, and the moment a DIO interrupt is started by a SX1272, there is a certain latency time.The value of this latency is roughly 3/4 of a symbol and only depends on the chosen Spreading Factor.This latency is actually the time needed by the SX1272 to process demodulation.
Two devices containing an SX127x chip can communicate in a point-to-point mode. Alternatively, you can create a small gateway with one SX127x. However, you will not be able to create a LoRaWAN base station with just one SX127x. The SX127x is a one frequency, one data rate chip while a gateway is able to cope with several channels and several data rates at the same time.
Transceivers used in LoRa®-connected end-devices are frequency-agile, i.e. they have a fast switching PLL onboard. During the uplink, they use a first channel (say 902 MHz), and it is very easy and fast to change the frequency to, for instance, 920 MHz, before the transceiver is turned to reception mode. This takes typically 100 microseconds to do.
Both the uplink and downlink messages are transmitted on determined channels. For example, on class A devices the uplink channels are controlled by the channel mask (ChMask) , whereas the downlink channels are either a function of the uplink channel or configurable through MAC commands.
LoRa is a spread-spectrum modulation and offers throughputs from 300 bit/s to 11 kbit/s in the EU LoRaWAN implementation. The next proposed setting is FSK 50 kbit/s, which LoRa doesn't currently achieve. The intent in this definition is to offer a way to "throttle", that means to increase the bit rate when the device is close to the gateway. This has multiple benefits, such as reducing the transmission time and saving the battery, reducing the chances of collision and therefore packet loss, and increasing the capacity of the networks.
The LoRa Alliance has developed a comprehensive certification program.
It offers the possibility for the Members to receive one LoRaWAN Certification Test Tool (LCTT) license annually. The LCTT lets you troubleshoot and solve development issues before sending it off for certification testing at an Authorized Test House.
More information on the LoRa Alliance website: https://lora-alliance.org/lorawan-certification/
Only public LoRa network operators or private network operators who use roaming need to get a NetID from the LoRa Alliance™. Private network operators that don't use roaming don't need a NetID. NetID 0 or 1 can be used freely in any network. It is not LoRaWAN compliant to use a NetID which is not allocated.
You can perform firmware upgrade from the server, the time needed for the upgrade depends on the size of the firmware to be updated. The LoRa Alliance has standardized a way to group devices together in a Multicast group for concurrent update, and an efficient Transport layer with built-in redundancy for optimized file delivery. The idea is to switch the node in class B or in class C and to send data from the server. There are examples of FUOTA (firmware upgrade over the air) available from several partners of the LoRa Alliance.
Let's take an example to best illustrate a choice between equivalent modulation parameters.
In the first case we have Bandwidth (BW) 125 kHz and Spreading Factor at SF12. This results in a data rate at 30 symbols/sec and Rx sensitivity at -137 dBm.
Let's compare this with BW 10.4 kHz and SF8, which results in very similar result: data rate at 40 symbols/sec and Rx sensitivity of -138 dBm.
The trade-off here is that with BW 10.4 kHz, you will have to use a TCXO which adds cost to your system. Contrarily, at BW 125 kHz, you do not need a TCXO anymore.
At the end of the day, it is simply a matter of cost versus performance.
Whether private or public, overlapping networks in a specific geographical area will share the medium, and therefore the collision rate will increase.
The common techniques which can be used to alleviate this situation is the use of Clear Channel Assessment, which evaluates the "cleanness" of a channel by using spectral scanning techniques (and therefore adapt the channel plan), and implements retries in packet transmission to maximize success rate.
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.
The LoRaWAN stack available on Github supports Adaptive Data Rate. The algorithm is actually controlled by the network server and the network server will send a MAC command to increase or decrease the data rate depending on the received signal level. When using confirmed messages on the node side, if the node does not receive the acknowledge, it will automatically decrease the packet data rate.
Each SX1257/50/55 chip can digitize almost 1 MHz of spectrum, therefore two are required typically to achieve 8 channels with a channel separation of 200 kHz or so.
The limitation of using a single SX1257/50/55 chip and one SX1301/08/02 chip is that you can only digitize 1 MHz of spectrum (and not 2 MHz) and can only build a 4 channel modem since the channels are spaced 200 kHz apart.