Ask Search:
DollarDollar (Semtech)  
From the definition of source code, the MAX_RX_WINDOW is 3000ms, it means that if detected a preamble during Rx1 window or Rx2 window, the max receiving duration is 3000ms? If the data packet exceed 3000ms, then the data can't be received? That's right? 
But, after tx completed, we set the Rx1 windower timer and Rx2 window timer simultaneously. So, if end-device detected the preamble during the Rx1 window and start to receive data, but the data packet duration over 1s. Then, after 1s from the beginning of RECEIVE_DELAY1, the receiving status will be abort and enter the Rx2 window timer event. So, even if end-device has been detected the preamble during Rx1 window, but as the data packet duration over 1s, and the RECEIVE_DELAY2 is 1s later after RECEIVE_DELAY1. Thus, end-device can't receive data packet correctly during the first receive window. 
So, if the end-device wants to receive data completely during Rx1 window, the time on air should not be exceed 1s? That's right?
But if time on air not exceed 3s, it's will be ok in the Rx2 window, that's right?
Best Answer chosen by Dollar (Semtech) 
GregoryGregory (Semtech Corporation) 
Your question is in two parts:

"it means that if detected a preamble during Rx1 window or Rx2 window, the max receiving duration is 3000ms"

Yes, this is correct. In the LoRaWAN stack, the packet time will never exceed 3 seconds in TX or Rx. 
On the node side, this is ensured by the function "ValidatePayloadLength (...)" which verify the amount of data to be transmitted compared to the data rate. 
If the frame is longer than the predefined length, the LORAMAC_STATUS_LENGTH_ERROR status will be returned.
On the GW side, the same kind of mechanism is used so that the time on air of any given packet over the network will never attain the 3 seconds.

"So, if the end-device wants to receive data completely during Rx1 window, the time on air should not be exceed 1s"

No, the limitation is at 3 seconds. 
After a Tx, the timer event "OnRxWindow1TimerEvent( )" will occur precisely after 1 second and the radio will go into Rx mode.
After 2 seconds, the timer event "OnRxWindow2TimerEvent( )" will occur and will lead to the configuration of the radio for the second reception window in the function "RxWindowSetup()".
However, before changing the radio, the code checks the radio status with the call to Radio.GetStatus( ) 
At this stage, or the radio is in "RF_IDLE" state and the code will configure the radio and 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.
DollarDollar (Semtech)  
For Class C device, we set RxWindowTimer1 of RxWindow1Delay after Tx done. If RxWindow1Delay was expired, then jump to OnRxWindow1TimerEvent() to set Class C device as
singl receive mode for time of symbTimeout to detect preamble in Rx1 window. We assume that the Class C detected the preamble in Rx1 window, but the data packet time
on air over 3s. After 3s, then jump to the SX1276OnTimeoutIrq() in SX1276.c, and call RadioEvents->TxTimeout( ), as it's the function of OnRadioRxTimeout() in
LoRaMac.c. Our original idea is that to call OnRxWindow2TimerEvent() to set Class C device as Rx2 status for continuous receive mode. But, in OnRadioRxTimeout(), we
didn't set the SX127x RF status as RF_IDLE when receive timeout. So, when we call OnRxWindow2TimerEvent(), we can't set the SX127x as continuous receive mode. Thus, we
should watiting for receiveing complete no matter how long the data packet duration is. Then go into SX1276OnDio0Irq() in SX1276.c to set the SX127x RF status as
RF_IDLE, and reset the Class C device as Rx2 continuous receive mode by calling RadioEvents->RxError() or RadioEvents->RxDone(). 
Best Answer chosen by Dollar (Semtech) 
GregoryGregory (Semtech Corporation) 
In the LoRaWAN stack, the packet time will never exceed 3 seconds in TX or Rx. 
On the node side, this is ensured by the function "ValidatePayloadLength (...)" which verify the amount of data to be transmitted compared to the data rate. 
If the frame is longer than the predefined length, the LORAMAC_STATUS_LENGTH_ERROR status will be returned.
On the GW side, the same kind of mechanism is used so that the time on air of any given packet over the network will never attain the 3 seconds.
DollarDollar (Semtech)  
For Join the network according to OTAA process, if the end-device send the Join_Request but tx timeout. Then will call OnMacStateCheckTimerEvent() to set the DeviceState as DEVICE_STATE_SLEEP to stop transmit cycle due to tx timeout. Then the end-device will go to DEVICE_STATE_SLEEP in main function. 
My question is: How to start to the second attempt to join the network when above scenario occurred?
Best Answer chosen by Dollar (Semtech) 
GregoryGregory (Semtech Corporation) 
The Tx Timeout is really a legacy verification from the early days of the LoRaWAN stack.
Actually, you should never have this irq unless you have a strong HW issue. The status of the radio is continuously monitored so that this event cannot happen.
Krzysztof ChojnowskiKrzysztof Chojnowski 
According to the datasheet the PpmOffset is calculated as PpmOffset = 0.95 * measured Offset [PPM]. Which frequency should be taken into account to get the measured Offset [PPM]: the carrier, the bandwidth or the external crystal?
Best Answer chosen by Krzysztof Chojnowski
SebastienSebastien (Semtech Corporation) 
Dear Kryzsztof,

The offset in ppm can be computed from either the carrier frequency, or the reference (XTAL oscillator) frequency. This would give you the same results.

Best,
Krzysztof ChojnowskiKrzysztof Chojnowski 
I observed that payload CRC error occures quite often when the two modems are very close to each other, especially with SF = 2048. What can be the reason of this behaviour? Please advise where to start debugging of this issue.
Best Answer chosen by Krzysztof Chojnowski
SebastienSebastien (Semtech Corporation) 
Dear Krzysztof,

Could you confirm that the CRC errors disappear when the modems are separated by a longer distance? This could be related to saturation of the receiver, although we have an internal AGC which takes care of saturation. It may fail for extremely large coupled powers, exceeding the max ratings of the chip. Also, do you see a difference when the "LowDataRateOptimize" is set?

Best,