matthijskooijman / arduino-lmic

:warning: This library is deprecated, see the README for alternatives.
705 stars 651 forks source link

EV_TXCOMPLETE taking too long to occur with SF9...SF12 #251

Open henriquetoledos opened 4 years ago

henriquetoledos commented 4 years ago

Hello! I'm using a Heltec WiFi LoRa 32 (V2) as a LoRaWAN Node at TTN, but I'm facing an issue. I'm using ttn-abp.ino example as a base for my code.

If SF is set to 7 or 8, the EV_TXCOMPLETE event occurs correctly (I think) after more or less 2s of RX timeout. This lead me to assume that the DIO pin mapping I've set (26, 35,34) is correct. If SF is set higher, the EV_TXCOMPLETE starts to take longer than expected.. at SF12, it may take almost 2 minutes to happen. And the packet only arrives to the gateway after EV_TXCOMPLETE happens. Does anyone knows what may be causing this? I've read all related issues on but didn't find anyone with the same issue. This will be a problem as I'm trying to implement a low power mode on this node. Thanks!

MikhailYuzhakov commented 4 years ago

Same problem!

MikhailYuzhakov commented 4 years ago

First delay between packed queued and EV_TXCOMPLETE (3s) image Second delay (2m 18s) image Third delay (2m 18s) image

fguiet commented 4 years ago

Hi,

I have the same problem. Delay between Packet queued and EV_TXCOMPLETE is very long with starting from SF11 to SF12

Any idea?

Fred

trlafleur commented 4 years ago

RFM95 use a standard xtal, at these SF, frequency accuracy is very important, if the xtal has drifted due to age or temperature, the radio often finds it hard to communicate.... you can get RFM95 with a TCXO xtal that helps the problem.... but they consume a bit more power....

~~ /) ~~~~ /) ~~ _/) ~~ _/) ~~

Tom Lafleur

On Jun 6, 2020, at 1:26 PM, Frederic Guiet notifications@github.com wrote:

 Hi,

I have the same problem. Delay between Packet queued and EV_TXCOMPLETE is very long with starting from SF11 to SF12

Any idea?

Fred

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

PepperBurst commented 3 years ago

That also happens to my setup, I think it has something to do with the duty cycle. There was a snippet that involved the LMIC.bands[BAND_MILLI].avail = os_getTime(); that worked for me to basically remove those 2 minutes of wait time.