Post your questions to the LoRa community of users or showcase your knowledge and expertise by answering other’s questions. Before posting a question, make sure the information is not available elsewhere by using the search function. When your question is answered, make sure to select the best answer to make it easier for others to find, and give credit to the person who helped you!

Ask Search:
jet sujet su 
     Why SX1278 switch from SLEEP mode to STANDBY mode need to be configured STANDBY  twice to succeed. 
         SX1278LoRaSetOpMode( RFLR_OPMODE_SLEEP );
         SX1278LoRaSetOpMode( RFLR_OPMODE_STANDBY );
         SX1278LoRaSetOpMode( RFLR_OPMODE_STANDBY );

If configured STANDBY Mode only once, and then read back the RegOpMode register value, still the SLEEP mode.

Is there a limit to the use of the RegOpMode register?

Best Answer chosen by jet su
GregoryGregory (Semtech Corporation) 
You don't need to configure Standby twice. The command is not immediate and the radio needs a few us to go from Sleep to Standby (please, refer to the datasheet for exact timing). If you add a small delay between the time you set the radio in Standby and the time you read the register, you will see the radio behave as expected.
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?

Vincent van BeverenVincent van Beveren 
We did extensive measurements with a number of motes at different locations and two gateways. 20k packets have been transmitted. We wish to make an estimate of the 'real' received signal strength as the reported RSSI has a lower limit at about -123dBm (reported by our Kerlink Wirnet gateways). Around this point the SNR can drop below 0dB. So, the actual signal would be below the -123dBm.

What would a realistic figure be for received signal strength? I would expect:

 RSS = RSSI if SNR > 0, otherwise it is RSSI + SNR

Is this correct?

For signals with an RSSI > 100dBm, the SNR seems to top in the range of 7-14dB.
What limits the SNR to this range, as I would expect to continue to increase with RSSI?
Best Answer chosen by Vincent van Beveren
SebastienSebastien (Semtech Corporation) 
Hi Vincent,

The calculation you are proposing is mostly right, and is the simplification we actually propose in our drivers and documentation. It may be made better when SNR is close to 0 (energies sum up), but this approxximation is good enough.

Concerning the SNR, by implementation choice is tails off when it becomes quite positive. You just have to consider that SNR is "suffucient" when over 5dB, and then just rely on RSSI.

Actually, in your calculation, a better description would be "packet power" instead of RSSI, which is effectively what you are trying to quantify.

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.
Andre SchwarzmeierAndre Schwarzmeier 


I would like to know, if here is any integrity check for downlink messages foreseen in the LoRaWAN?
Refering to the LoRaWAN Specification 1.0.2. in section 4 decribes, that the CRC for integrity check is only available for uplink messages. This would mean, that a corrupted payload, e.g., caused by collisions or other effectes of the channel, might never be detected if there is no further integrety check on application level, right?Hello!

I would like to know, if here is any integrity check for downlink messages foreseen in the LoRaWAN?

Referring to the LoRaWAN Specification 1.0.2 in section 4 describes, that the CRC for integrity check is only available for uplink messages. This would mean, that a corrupted payload, e.g., caused by collisions or other effects of the channel, might never be detected if there is no further integrity check on application level, right?
I hope, I did not misinterpret the standard and someone can help me to shed a lot of light on :-)


Best Answer chosen by Andre Schwarzmeier
GregoryGregory (Semtech Corporation) 
Hello Andre,
You are correct, in the specifications, the CRC is only applied to the uplink messages. This was made so that the GW can discard packets straight away and not forward "known bad packet" to the server. This way, we are sure that the GW only forward valid packets to the server, the server will then check the MIC to validate the content of the payload.
On the node side, the integrity of the messge is only checked with the MIC but this is sufficient to discard errors on downlink messages and adding the CRC would be redundant.

Xuan Dung LEXuan Dung LE 
Hello everyone,
I read the LoRaWAN specification version 1.0.2 that can be found in LoRa Alliance website.
I found out that the application payload for uplink message can reach up to 242 bytes
Unfortunately, I could not find out the maximum size of application payload for downlink message.

I saw that the reciever window size is smaller than the transmitted package. So does this means that the downlink payload size is smaller than uplink one? 
Could you give me more information about the size of downlink application message, please.?
Another question: I found out that it can be possible to communicate between sx127x. Could anyone tell me how many end-devices with sx127x chipsets can communicate together? that means, if I create a base station by sx127x, how many end-devices can communicate with the base station?
Thank you
Best Answer chosen by Xuan Dung LE
GregoryGregory (Semtech Corporation) 
One by one:
>>I could not find out the maximum size of application payload for downlink message...So does this means that the downlink payload size is smaller than uplink one?
Maximum payload size is depending of the datarate and the size limitations are identical on the Tx and Rx side. The receive windows are actually only used to detect the preamble and one a LoRa preamble is detected, the window will remain open until the reception is fully done.
>>Could anyone tell me how many end-devices with sx127x chipsets can communicate together?
Two devices can communicate in a point to point way or you can create a small GW with one sx127x but you will not be able to create a LoRaWAN base station with the sx127x. The sx127x is a one frequency, one datarate device while the GW is able to cope with several channels and all datarate at the same time.
Vyacheslav KhudyakovVyacheslav Khudyakov 
Hello, I have a question about using real-time data transmission in LoRaWAN. LORIOT company have shown data feed visualization in real-time (in their Youtube channel). Many experts prove that for LoRaWAN it is impossible. If it is possible, what is the maximum number of nodes can work in real-time per 1 gateway. I hope to get the answer. 
Best Answer chosen by Vyacheslav Khudyakov
GregoryGregory (Semtech Corporation) 
Hello Vyacheslav,
I would be glad to know who are these experts who "proved" LoRaWAN is impossible :-) There is no magic at play here, only technology and maths!

Lets go back to basics:
Each GW has at least one sx1301, the sx1301 is a huge digital baseband chip which emulates 49 LoRa demodulator and 1 FSK demodulator, all running in parallel.
The sx1301 has 8 channels and it is continuously scanning for the presence of preambles of any datarate on any of these 8 channels. Due to the orthogonalities of LoRa signals between them, the sx1301 can demodulate 8 LoRa packets at different datarate (DR0, DR1, ...DR7), at the same time, and on the same channel (providing you have a sufficient link margin between each packet). If you multiplex these parameters over time and the 8 channels, the number of nodes per GW can become staggering, even more as the network densify and the time on air of each packet decrease (due to ADR).

Everybody wants a definite answer as to how many nodes a GW can support but the answer is 4 dimensional:
- rssi/SNR of the received packets (simultaneous reception on the same channel)
- time on air of the packets (equivalent to datarate, the longer the packet, the longer one demodulator of the GW is used)
- frequency of the packets (two packets with the same datarate and the same RSSI/SNR will collide unless they are on 2 different frequencies).
- number of times per day a node will send a packet (taking resources another node could take)

The answer is thus incredibly complex to calculate because these 4 parameters all have an impact one on another. If you add the legislations which are different for each region (Duty Cycle, LBT,... ), the calcul becomes even more difficult to compute. So in the end you will be disappointed, there is no definite answer and even simulations can go from figures to figures depending on the input parameters. You can of course set your input parameters for your specific case and you will have a certain number but this number won't necessarily be representative of a real life deployment.

PS: to add some fun into the equation, LoRaWAN is all about country wide network deployment. At this level, the geographical distribution of the GWs over the territories also have an impact on the number of nodes the network can support :-)
Michele FerrariMichele Ferrari 
Dear all,
is there a documentation of JSON available values for global_conf.json and local_conf.json Semtech packet forwarder?
In particular, for "gateway_conf" object I would like to know if there's the possibility to specify more than one server.

Thanks for cooperation
Best Answer chosen by Michele Ferrari
Nestor AyusoNestor Ayuso
There is not such document, you can just review the source code.

Packet forwarder does not support more than one server. You can develop a small server for duplicating UDP frames. Or you can use TTN Poly-packet forwarder implementation doing exactly that.
Shashank KapoorShashank Kapoor 
Hello everybody, 
I am new to this topic so need help. I am trying to build my end node using STM32L151CBU6 and SX1272. When i disconnect the resistor which supplies power to sx1272 i am able to get 1.8uA of current consumption by putting the STM IC in standby mode. But if the resistor is connected i am unable to get the current consumption below 70uA. I even tried to write the RegOpMode register with 0x00 but still not able to get less current.
On the sx1272 side I did the following things
Disabled the RC oscillator
De-Initialized the IO's
Put sx1272 in sleep mode by writing the RegOpMode register as 0x00
Disabled SPI
on the stm side i did the following things
De-Initialized the UART
De-Initialized the ADC
De-Initialized the GPIO (Made all the GPIO as input and PULL-UP)
De-Initialized the HSE
De-Initialized the LSE
Put the STM32 in standby mode
I am trying to make the current consumption below 8uA.
Any help would be greatly appreciated
Best Answer chosen by Shashank Kapoor
GregoryGregory (Semtech Corporation) 
Hello Shashank,
The main issue with the Standby mode is that you do not keep the configuration of the MCU GPIO. This means that, unless connected to a known level through pull-ups or downs, you will have leakage pretty much everywhere. To fix this, we usually recommend the STOP mode where the GPIO configuration is kept. This way, you will not suffer from the leakage and you should get to a current consumption MCU+Radio down to 2 or 3uA