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

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.

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

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

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

The description of the PHY header is best found in the datasheets of the PHY devices, namely SX1276 and SX1272 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 4.1.1.6 "LoRa Packet Structure" of theSX1272 and SX1276 datasheets. The datasheet and User Manual of SX1261/61 and LR11xx devices contains similar information"

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.