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. 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.

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 ModemStatus signal will indicate when the modem has found preamble it judges good, but it doesn't mean that the preamble is over.  A better indicator, although later down the line, would be the Header interrupt, which occurs when the header is found. This makes sure the preamble is over

The estimated accuracy of these is ± 2/LoRaBW, or 16 µs in a 125 kHz setting.

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.

Documentation, schematic and tools are available on the SX1308 product page, under the tab “Datasheets and Resources".

Control from a Windows 7/10 machine host through a GUI

- PicoUI Demo App tool

- PicoCell Gateway GUI User Guide

Control from a Linux host (e.g. Raspberry)

- picoGW_mcu***, picoGW_hal and picoGW_packet_forwarder source code

- User Guide to the LoRa PicoCell Gateway

Note: All libraries are provided as Reference Design, please refer to the built-in license agreement.

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.

There are several options. You may connect to the provider of "hosted servers" and verify functionality. This would be a first approach to see if you are compliant. Also, the approved certification houses of the LoRa Alliance™ are currently building pre-certification offers, you may want to reach out to them and request it. Check the LoRa Alliance™ certification overview page.

Only public LoRa network operators need to get a NetID from the LoRa Alliance™. Private network operators don't need a NetID. NetID 0 or 1 can be used freely in public networks. In private networks any NetID can be used.

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 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.