Both of these settings provide a trade-off between time-on-air of the signal and the sensitivity or robustness of the link. The most important of these two factors is spreading factor: this offers a clear ~2.5 dB improvement in sensitivity for each increase in SF, but a the cost of doubling the symbol period.

The FEC does not provide any significant increase in sensitivity, but instead offers improved immunity to partial loss of the packet information by increasing the level of redundant information in the packet. for this reason the time-on-air penalty can be high for marginal perceived gains - unless the interference environment your link will be operating in is well understood.

For this reason, your link should be optimized for SF first - i.e. select the link budget required by your application (using the lowest FEC possible). Then, if your link may be subject to interference, consider the application of stronger error correction.

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.

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 CAD interrupt is generatedat at a pre-determined time after CAD has been requested by the host. It can be configured to trigger on preamble (yielding optimal performance) or payload observation.

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.

The latency between the  transmission of a packet by a LoRa capable transceiver and the moment a DIO interrupt is generated by a SX1272 receiver is roughly 3/4 of a symbol and only depends on the chosen Spreading Factor employed by the packet's modulation scheme. This latency is the time needed by the SX1272 transceiver to process the packet and perform the required 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 or SX126x. However, you will not be able to create a LoRaWAN base station with just one SX127x or SX126x. The SX127x and SX126x are single frequency, single data rate chips while a gateway receives several channels and several data rates at the same time.

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.

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.

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.

No radio performance benefit is seen from SF diversity in terms of range or timestamping performance. Instead some benefit can be gained in mobile systems where multiple SFs are employed in a “blind ADR” strategy. In such a scheme, low SF packets are sent more frequently than high SF packets - thus allowing more frequent information transfer when at close range to a gateway, but at a minimised energy cost.

In urban and sub-urban environments, the presence of interferers may cause lower SF, higher data rate, packets to have greater reception success when sent multiple times due to their shorter time on air. E.g. a SF10 packet may have 90% success, while a SF8 packet has 70%, but when the SF8 is sent three (3) times it will have 97% success and cumulatively use less energy. Note: this is only true for noisy RF environments and does not address link budget, just chance of success.

The doppler effect at high speed (from 100 to 300 km/h) can be acccomodated by LoRa technology. At these speeds multiple effects come into play such as frequency offset due to doppler shift and rapid variations in channel characteristics (e.g. RF signal fading) . Mitigatiing these factors often requires "case by case" consideration to acheive optimal results. That being said, we have received customer feedback  detailing successfully employed LoRa solutions operating  in such scenarios where speeds exceed 200 km/h.

The LoRaWAN standard supports acknowledgment, either at the MAC (concept of Confirmed Frames) or the Application level. Although this functionality is offered, it is only recommended to used acknowledgement for mission critical packets, such as alarm conditions.

Uplink capacity being much higher than downlink capacity, to maximimze uplink packet success rate it is generally speaking better to use packet repetition techniques, rather than ACK, to maximize success

The 500 kHz maximum signal bandwidth mentioned in the SX1257/SX1255 datasheet corresponds to a maximum RF double sideband bandwidth of 1 MHz i.e. 500 kHz up and down from its center frequency.

To avoid any loss of useful signal and due to the specific LoRa® spectral shaping, the maximum RF double side band bandwidth for SX1257/SX1255 is defined in the libloragw HAL as follows:  

• 925 kHz for 125 kHz LoRa® channel  
• 1.0 MHz for 250 kHz LoRa® channel  
• 1.1 MHz for 500 kHz LoRa® channel

LoRa packets always use a forward error correction code defined by the coding rate. Therefore, even to transmit a 0-byte payload, LoRa modems will always use some error correction. The user programmable payload ranges from 0 to 255 bytes.

RF wave propagation through water is complicated by the conductivity of the water as a function of salts and contaminents. While in theory LoRa could be used for short distance of 1 to 2 meters in fresh water, we are not aware of anyone practically implementing such a solution.

The SX1257 can not demodulate LoRa or FSK modulations. It is a radio transceiver that downconverts up to a 1 MHz chunk of spectrum in the 800/900 MHz frequency band to baseband I and Q signals.

The SX125x parts, while used in conjunction with an SX130x component can demodulate multiple datarates across multiple channels simultaneous. The SX130x baseband processor utilizes the quantized baseband spectra provided by the SX125x to demodulate the various channels and signals.

The LoRa Alliance website references a number a modules and modems available from the LoRaWAN eco-system, with different characteristics.

Modules have open MCUs where you can implement LoRaWAN and application. Modems on the other side, are typically closed-source module with the stack built-in, and must be driven by an external Host MCU, usually over a serial interface.

More recently, RF-only modules have also appeared. They contain no MCU, but they simplify the RF design and qualification.

No specific study has been run by Semtech on the performance of LoRa in rain. However, there is literature documenting the impact of rain on 1G and 2G cellular systems, which essentially use the same UHF frequencies. Therefore, the impact of rain on the performance of LoRa can be considered low.