beegee-tokyo / SX126x-Arduino

Arduino library to use Semtech SX126x LoRa chips and modules to communicate
MIT License
231 stars 64 forks source link

why Lorawan Trans Receive take time of 7-9 second to complete #57

Closed mightChamp closed 2 years ago

mightChamp commented 2 years ago

Hello, As per Lorawan It transmit and then wait for RX1 Window(1 second) and RX2 window(2 second) So total counts to 3 second after payload transmission. So, why this library consume 7-9 second for Next Packet Transmission. If Send before this 7-9 second wait, it will give error of lmh_busy.

So, how can I reduce this time to 3-4 second, I need to send 4 frame consecutively in minimum time of operation.

Thank You

beegee-tokyo commented 2 years ago

The RX1 and RX2 delays are setup by the LORAWAN server, not by the device. You can check on your LORAWAN server if you can change the delays there.

TTN changed the RX delays to (I think, not sure) 5 and 6 seconds.

beegee-tokyo commented 2 years ago

@mightChamp https://www.thethingsindustries.com/docs/getting-started/migrating/major-changes/#rx1-delay

mightChamp commented 2 years ago

In IN865 Region Header file RX1 and RX2 delay is 1 second and 2 second respectively, 5 and 6 second wait for OTAA join delay 1 and join delay2. and I am using chirpstack server, and I am also getting downlink with this configuration. But I didn't understand that It should complete task within 4 second, instead it take 8-9 second to complete.

Below is library Log with time: [10:33:24.174] OnRadioTxDone [10:33:24.174] OnRadioTxDone => RX Windows #1 995 #2 2002 [10:33:25.169] RX window timeout = 3000 [10:33:29.171] RadioIrqProcess => IRQ_RX_TX_TIMEOUT [10:33:29.171] OnRadioRxTimeout [10:33:29.231] LoRaMacState = idle

Please suggest me a solution in which I can reduce this time to 4 second. Thank You

beegee-tokyo commented 2 years ago

Don't trust Serial output timings. Sometimes they are cashed before sent.

Use a GPIO (or one of the LED's), set it to high when you start TX and set it to low when the TX_FINISHED callback is called. Use this to measure the time.

mightChamp commented 2 years ago

Sorry but this timing is on SerialPort Utility software, and I use this mostly for serial output and its timing is accurate. but, I doesn't rise issue on behalf of this Serial timing data. On consecutive send if I set next packet transmission time below 9 second then I always get LMH_BUSY error, on next transmission, So have to keep 20 second between current and next lorawan transmission.

beegee-tokyo commented 2 years ago

I guess you don't want to believe me, anyway here is some REAL measurement.

Setting IO1 to high when I enqueue the packet, setting IO1 to low when TX finished callback is called. Using AS923-3, RAK7258 gateway and Chirpstack running on local RPi3.

On Serial log it says 29 seconds: image

Measured with oscilloscope the pin IO1 says 6 seconds image

About your BUSY error, Do you have confirmed message enabled? If yes, if the packet is not acknowledged from the LNS, it will resend the packet until it gets an ACK. During this time the LoRaWAN stack reports BUSY. Other possibility is that Dutycycle is enabled, in this case, the number of packets you can send in a certain time is limited by the LoRaMAC stack and it will return a BUSY error as well.