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:
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.
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 :-)
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?

There is 125kHz and 250kHz, 500kHz LoRa IQ Waveform library in "Tool and SW" ,but narrower than 62.5kHz is not.
Do you have  LoRa IQ Waveform library of narrower than 62.5kHz?
Best Answer chosen by HARA ARATA
SebastienSebastien (Semtech Corporation) 
Hi Hara,

Lower BW are made by simply playing the waveform files at a lower sampling rate. The OSR is set to 4, so play them at 500 kHz for LoRaBW=125 kHz, 250 kHz for LoRaBW=61.25 kHz, 125 kHz for LoRaBW=30.6 kHz, etc...

Frank SandersFrank Sanders 
i designed point to point communication with Sx1278, in my test i getting 14 km in LOS Communication.
My setting for SX1278 : 
BW= 7.8 K
TXpower = 20 dB
Payload= 2 Byte
Preamble = 8 symbols
receive time= 15 second 
Antenna = tow Ygi (7.5 dBi) made myself
My questions : 
1- If use from CAD mode i can get more distance?
2- What your offer for receive packets? CAD mode or normal receive mode such as RX continuous - RX single ?
3- for get the long distance i designed yagi antenna (Gain = 7.5 dBi) and get 14 km (LOS) but today i see 30 dBi Omani antenna in Alibaba store i can't believe this, 30 dBi is very very high Gain, i share this antenna link here please tell me your idea about this.
4- what is your offer for preamble lengths for get more distance ? 
5- My LoRa module use from 26 MHz TCXO, in the page 81 of sx1278 data sheet say if use from TCXO, bit TcxoInputOn of register RegTcxo should be set to 1. i don't set this bit of register but module worked fine. this is Normal ??! why ?
—- My Ygi Antenna picture (made myself)---
Best Answer chosen by Frank Sanders
SebastienSebastien (Semtech Corporation) 
Hi Frank,

Let's first state the obvious, which is that this type of extreme modulation may give good results in certain propagation conditions, but is also more challenging in terms of reference frequency stability, vibration, channel coherence time vs. symbols time.... in other words unless you have static objects, no vibrations, good TCXOs, I would steer away of the 18 bps mode you are experimenting. Oh, I forgot fast fading issues and moving objects which may create packet loss as your symbol time exceeds 500ms. Now onto your questions:

1. Can is fast to detect LoRa Preamble, but the tradeoff is 3dB in sensitivity. So the answer is no
2. It depends on your power consumption tradeoffs. RxSingle to detect Preamble is good, for an infinite power receiver I'd go for Rx Continuous
3. Yagi is good. 14 km LOS with SF12 and 7.8 k is disappointing. I think you are terrain-limited in your experiment. I recommend a propagation simulation in your location first, we've seen customers reporting 100s of km in these conditions.
4. No impact of preamble length on distance as loong as your preamble gets detected (8 symbols)
5. The TCXO mode will save you power, but the chip will work ireespective of this setting. 26 MHz ????? That is not so good, all LoRa is validated at 32 MHz reference, I strongly recommend sticking to 32 MHz


Nikos KaramolegkosNikos Karamolegkos 

Hello all,

I am new to LoRa and I would like to learn some more information on how the nodes change their channel. As I have understand LoRa GWs listen (at the same time) at least to 8 different channel frequencies (it depends on GW manufacture). My question is when and how the LoRa node changes it's transmitting channel?

Best Answer chosen by Nikos Karamolegkos
OlivierOlivier (Semtech) 
Hello Nikos,

The node can choose its transmission frequency. In case of a LoRaWAN protocol it is a random selection between all available frequencies, see LoRaWAN specification 1.0.2 p6 "The end-device changes channel in a pseudo-random fashion for every transmission. The resulting frequency diversity makes the system more robust to interferences."
Also the aim of having a gateway with 8 channels is to be able to listen to several nodes at the same time.
Nicholas DraussNicholas Drauss 
my company had made 300pcs of lorawan gateways modules recently, 80% of them work just fine. I got calibration warnings from the rest of 20% from time to time. 
Here is the screenshot of the warning I got
caliration warnings

It does not happen every time the calibration is performed. I will get 1- 10 warnings every 10 calibration depends on which hardware is under test.

One thing I found out during the test is that it seems that the warning is frequency depended. For the same piece of hardware, say if I run the calibration 30 times on 866MHz, I got 6 warnings; I may have 0 warnings if I run the calibration 30 times on 1000MHz.

Another thing I found is if I modified the source code of "test_loragw_cal" and set the DAC to 2( it was 3 by default) there will be no calibration errors.

I know that I could work around this by writing some code to poll on the status bit of the calibration bit, and if I get warnings just run the calibration again, but this does not sound like not a real solution to me.

My question is what can I do to eliminate the warnings?
Best Answer chosen by Nicholas Drauss
JeromeJerome (Semtech Corporation) 
Hello Nicholas,

The Tx DC offset rejection pass/fail criteria has been set too high (= 20dB) and is hardcoded inside the SX1301 firmware. 10dB Tx DC offset rejection is enough.

One way to eliminate the warnings is to not take into account the "cal_status" value from SX1301 firmware and to calculate the calibration pass/fail status inside the HAL by reading back to the Tx DC offset rejection values. To do so, you could modify the "loragw_hal.c" file as follow:

// Comment the Tx DC offset "cal_status" checking from SX1301 (line 858)
if (rf_enable[0] && rf_tx_enable[0] && ((cal_status & 0x20) == 0)) {
    DEBUG_MSG("WARNING: problem in calibration of radio A for TX DC offset\n");

// Add the read back of the Tx DC offset rejection values + Perform the Tx DC offset rejection calibration pass/fail checking (from line 858)
static int8_t cal_offset_rej_a[8];
static uint8_t tx_dc_offset_min = 10;
    for(i=0; i<=7; ++i) {
        lgw_reg_w(LGW_DBG_AGC_MCU_RAM_ADDR, 0xC0+i);
        lgw_reg_r(LGW_DBG_AGC_MCU_RAM_DATA, &read_val);
        cal_offset_rej_a[i] = (uint8_t)read_val;
        if (cal_offset_rej_a[i] < tx_dc_offset_min) {
            DEBUG_MSG("WARNING: problem in calibration of radio A for TX DC offset\n");

Best regards,
Umesh PatilUmesh Patil 
Trying to use same stm32l072 as end node and gatewa ...but its not working. what to do??
Best Answer chosen by Umesh Patil
SebastienSebastien (Semtech Corporation) 
Hi Umesh,

I suggest you describe tje debug steps you have been thru already, that will help understand what you are doing

karim El Qounskarim El Qouns 

I want to know what is the estimation of the oscillator's drift (RC64khz of Sx1261) in ppm. I didn't found this information in the datasheet.

Thank you

Best Answer chosen by karim El Qouns
GregoryGregory (Semtech Corporation) 
Hello Karim,

For all questions related to the sx126x, I invite you to post them in the group SX126x Forum in the Collaborate section of the community. 

On the sx126x, the RC64 clock can drift due to temperature change ( maximums are +/-10 % ) and can drift due to change in voltage (maximums at +/-2 %). However, please note that the RC64 clock can be calibrated at any time using the function "Calibrate(...)", then the RC64 should be accurate within 0.7%.