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.

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

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

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.

Geo-location-ready gateways are specific, and implement 2 times 8 channels and full diversity, meaning that they have two RF ports connecting to 2 distinct antennas.

Per the test results that we have gathered and shared, there is no benefit in using spreading factor diversity. Whilst SF12 offers the best link budget, in many situations of mobile devices it is certainly better to use a “blind ADR” type of strategy, which provides better energy efficiency and good macro- 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.

It's actually in the LoRa® standard, section 4.3.1.2:

"The server aims to respond in one of the immediately following receive windows, either with a frame it was going to send anyway or a fresh frame generated for the purpose. The acknowledge bit is raised in this frame."

If it is not received the frame should be re-transmitted.

If all of the devices require an acknowledgement then the downlink is likely to struggle. However, in general, and depending on the regional regulations the downlink is selected to be in a specific channel that might allow a higher power or duty cycle. In the European region we typically use a higher data rate for the downlink than the uplink. This means that the time-on-air in the downlink is less from the gateway end than the uplink of each sensor but, of course, gateway duty cycle can start to become an issue if a large number of sensors request acknowledgements.

The message length has no influence on the accuracy of the timestamping, as the timestamp is taken during the preamble phase of the LoRa® packet.

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.