The maximum LoRaWAN packet time-on-air duration is 3 seconds. After the packet is transmitted by the end-device (uplink message), the timer event "OnRxWindow1TimerEvent( )" occurs precisely after 1 second (± 20 µs), corresponding to the RECEIVE_DELAY1. Then the radio goes into Rx mode on the same RF channel as the transmitted packet, with a data rate which is function of the uplink data rate (refer to LoRaWAN specification Section 7). In case a downlink message has not been received, the timer event "OnRxWindow2TimerEvent( )" occurs 2 seconds (± 20 µs) after the uplink message (RECEIVE_DELAY2) and leads to the configuration of the radio for a second receive window in the function "RxWindowSetup()". The RF channel and the data rate used for the second receive window are defined in the LoRaWAN specification, Section 7.

However, before changing the radio, the code checks the radio status with the call GetStatus(). At this stage, either the radio is in "RF_IDLE" state and the code configures the radio to go into Rx mode, or the radio is in another state (meaning the radio is already busy) and the code will simply drop the command until the next IRQ from the radio.

The minimum receive window duration must be at least the time required by the end-device‘s radio to effectively detect a downlink preamble.

In the LoRaWAN specification, the packet time depends on the Regional Parameters, and will never exceed 3 seconds.

On the node side, this is ensured by the function "ValidatePayloadLength (...)" of the LoRaWANstack which checks the amount of data to be transmitted compared to the data rate.

If the frame is longer than the predefined length, the status LORAMAC_STATUS_LENGTH_ERROR will be returned. On the gateway side, the same kind of mechanism is used so that the time-on-air of any given packet over the network will never reach 3 seconds.

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.

The LoRaWAN stack available on Github supports Adaptive Data Rate. The algorithm is actually controlled by the network server and the network server will send a MAC command to increase or decrease the data rate depending on the received signal level. When using confirmed messages on the node side, if the node does not receive the acknowledge, it will automatically decrease the packet data rate.

The LoRaWAN protocol is not meant for node to node communication. All nodes communicate to one or more gateways that forward all packets to the network server. The network server takes care of de-duplication and forwards the packets from the end-devices to the appropriate application server.

Each SX1257 chip can digitize almost 1 MHz of spectrum, therefore two are required typically to achieve 8 channels with a channel separation of 200 kHz or so.

The limitation of using one SX1257 chip and one SX1301 chip is that you can only digitize 1 MHz of spectrum (and not 2 MHz) and can only build a 4 channel modem since the channels are spaced 200 kHz apart.

Adaptive Data Rate (ADR) can be enabled or disabled on every node depending on the use case. Usually, this has to be discussed with the network provider. As a rule of thumb, static nodes usually have ADR on and the moving nodes usually have the ADR off.

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.

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.

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.

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.

SX1257 can not demodulate LoRa or FSK modulations. It just downconverts a 2 MHz spectrum in the 800 MHz frequency band in raw I and Q signals.

The 4 channels of 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.

Any device able to perform frequency hopping in Tx is also able to do it in Rx. We have an example code on MBED where we show how it works. This may be found here.

One should distringuish LoRa® (PHY) and LoRaWAN®, a protocol working on top of LoRa. LoRaWAN needs a gateway, but doesn't support intra-packet hopping.

LoRaWAN mandates inter-packet hopping, where every next packet is sent on a new frequency, pseudo-randomly chosen. Other customers have successfully implemented LoRa in synchronous systems with FHSS, mostly relevant in point-to-point communication scenarios.

The gateway power consumption is mostly independent of incoming traffic. Therefore, the transmit current posted on the specifications is valid.

We're speaking about a couple of watts (below 10 watts for sure), 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.