Yes, ADR support is mandatory and enforced in the LoRa Alliance certification.

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.

Yes, in principle it is possible to adopt this kind of policy in the network controller. It can even be a policy which is applied specifically by end-device, meaning that a pool of end-devices could be acknowledged on Rx1, and others on Rx2.

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

For noise immunity (digital to RF), it is safer to use a separate 3.3 V power rail between SX1308 baseband chip and SX1257 RF transceivers.

SE2435L RF front-end uses two power rails: 3.3 V (VCC0) and 2.0 V (VCC1 and VCC2). Concerning the 3.3 V (VCC0), it is already shared with the 3.3 V LDO SX1257 radio_A on the reference block diagram and schematic of Picocell Gateway. You can keep it this way.

You can share the same 3.3 V power rail between the two SX1257 radio_A and radio_B RF transceivers.

This 3.3 V power rail can also be used to supply the 32MHz TCXO.

In summary, two separate 3.3V power rails are recommended:

• the first one to supply SX1308 baseband chip
• the second one to supply the two SX1257 radio_A and radio_B RF transceivers, VCC0 of SE2435L RF front-end and 32 MHz TCXO.

For more details, see the Picocell Gateway reference design.

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 LoRaWAN  protocol supports packet repetition to maximize packet success rate in an asynchronous system. The right pointer is the NbTrans parameter in the LoRaWAN specification.

The gateway power consumption is mostly independent of incoming traffic.

We're speaking about a couple of watts (below 10 watts), but for a precise answer please get in touch with your gateway maker. The overall consumption depends on the supply strategy, peripherals, CPU used, and backhaul among others.

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.

The description of the PHY header is best found in the datasheets of the PHY devices, namely SX1272, SX1276, SX1261, SX1262, and LR11xx RFICs from Semtech.

In explicit header mode, the header carries three values:

• the Coding Rate (CR) of the forthcoming payload
• the size of the forthcoming payload
• if the forthcoming payload is appended by a CRC-16 or not

You can find more detailed information on the LoRa header in sections 6.1.3 "LoRa Frame" of the SX1261 and SX1262 datasheets.

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.

The tradeoff is quite complex, but in principle the sensitivity of the PA output is inversely proportional to the load-impedance required to obtain the output power.

• On PA_BOOST, regulated PA, we're getting 17 dBm with only about 1.65 V of DC bias, in order to maintain it from 1.8 to 3.7 V. This calls for a fairly low load impedance (P=V^2/Z).
• On RFO, we are targetting much lower power, 14 dBm, with direct attach to VBAT, nominally 3.3 V. Therefore, the load impedance is much lower.

You can grasp that a mismatch at the antenna will have less impact on RFO than it does on PA_BOOST (less impedance transformation). The OCP block is here to limit the current drain, protecting your power supply or battery in case of severe mismatch conditions.

The RSSI (Receive Signal Strength Indication) value corresponds to the estimation of the received input power signal at the antenna seen by the gateway. There is no block at the antenna to perform this estimation, but a baseband RSSI "sx1301_rssi " is estimated inside the SX1301 chip. Then the RSSI (at the antenna) is calculated by subtracting the gain of the Rx chain "Rx_gain" to the baseband_rssi:

sx1301_rssi = Input_level_antenna (=RSSI) + Rx_gain

This implies that RSSI =   sx1301_rssi €" Rx_Gain.

The RSSI value is read from the SX1301's packet buffer and is then summed with the rssi_offset:RSSI = sx1301_rssi + rssi_offset => so rssi_offset = -Rx_gain

The accuracy of the RSSI value depends of two factors:  

1. The estimation error of the signal envelope power done by the SX1301  
2. The estimation error of the Rx gain

The Rx gain includes analog gain (from antenna to ADC block) as well as digital gain. The analog gain, by nature, can change from one gateway to another one. "rssi_offset" can then be used to calibrate/compensate any Rx gain variation.

The RSSI parameter can be used for following features:  

• Rx AGC (managed by the gateway itself)  
• ADR (Adaptive Data Rate)
• Downlink message (to choose the best path/GW when corresponding uplink message has been received by several gateways)

Path loss in the sub-GHz spectrum is now well studied and documented, thanks to analysis done by the cellular industry over the last few decades.

Both line-of-sight and urban-type models are available, such as the Friis formula for line-of-sight, and COTS-231 for urban environments.

Path loss estimations are compared to the link budget of the LoRa technology, which can be estimated by summing the effective radiated power of the transmitted (typically 14 dBm in Europe and Asia), and the sensitivity of the received (down to -137 dBm).

Depending on the network server used, the antenna gain offset calculation is done in the server or in the gateway. In recent versions of the packet forwarder, there is an entry in the"global_conf.json" file that looks like this:  "antenna_gain": 0, /* antenna gain, in dBi */  

This "antenna_gain" can be used to compensate the gateway Tx Ouput Power "rf_power" by the gateway itself, not by the network server. Indeed, the "rf_power" field for each entry of the Tx LUT, defined in the "global_conf.json" too, corresponds usually to the conducted Tx Output Power, not the radiated one.

For instance, the "rf_power" along with its gain fields ("pa_gain","mix_gain" and"dig_gain") can come from a generic/conducted (i.e. without any antenna) calibration performed at production time. So, afterwards, you can define the "antenna_gain" in the"global_conf.json" configuration file to take into account any gain of the antenna mounted on the gateway in the field.

In the packet_forwarder program of the gateway, the "antenna_gain" field is subtracted from the "rf_power" field for all Tx LUT entries as follow: final_rf_power = rf_power - antenna_gain. "antenna_gain" must be a signed 8-bit integer, from -128 to +127.

The Frame counter shall never reset, as it would indicate a potential security issue to the network server. The Security White Papers published by the LoRa Alliance address this point.