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.

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

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.

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.

Per the test results that we have gathered and shared, there is no benefit in using spreading factor diversity. Diversity should however be part of the ADR strategy: frequency and time diversity are highly beneficial. SF12 makes sense for static end-devices which are at the limit of coverage, typically with a repetition order of 4 (NbTrans=4). In many situations of mobile devices it is certainly better to use a low spreading factor (e.g., SF7) and a high repetition rate, up to 15 times, which maximizes time and frequency diversity.

The doppler effect at high speeds (from 100 to 300 km/h) can be handled by the technology. However, at these speeds other effects come into play, such as the change of doppler shift with time and important variations in the channel characteristics during packet reception. This being said, we have feedback from users being able to receive at more than 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

The 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 and thus the minimum payload size is 0 and the maximum payload size is 255 bytes

RF wave propagation doesn't really work through water as the attenuation at high frequencies is far too high. In theory if the frequency was low enough (down in the Hz and not MHz ) it could work but this is not within the scope of the system specification and so the simple answer is no.

The SX1257 can not demodulate LoRa or FSK modulations. It just downconverts a 1 MHz chunk spectrum in the 800/900 MHz frequency band in raw I and Q signals at baseband.

The 4 channels of a SX1257 can be freely configured to the same, overlapping or adjacent frequencies.

Using two SX1257 at the same frequency will not improve the reception sensitivity or capacity if both SX1257 share the same antenna. You can use two 180-degree directional antennas oriented one to the north and the other to the south improving sensitivity, or better two omnidirectional antennas separated 1 meter with each other for diversity, mitigating the multipath.

Two signals on the same frequency and the same SF will interfere with each other. If one signal is, for example, 30 dB higher than the other, you will receive only the strongest one.

Two signals on the same frequency and different SF will interfere with each other, but as SF are orthogonal to each other. If one signal is, for example, 12 dB higher than the other, you will receive both signals. If not, you will receive only the strongest one.

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