What is the delay between "packet queued" and TX_START? (in LMIC library)

End Devices (Nodes) LMIC
1

I’m using a RFM95 module with the LMIC library as a node. Sometimes when I send an uplink message, there is quite a long time (> 15 seconds) between giving the command for sending (“packet queued”) and transmission starting (“TX_START”). At other times this amount of time is a lot shorter. I’m wondering why/what that delay is?

I’ve noticed that this happens in particular when using a higher spreading factor, and when sending multiple packets close to each other. Is this because of a duty cycle limitation or something? And if so is this limitation hardcoded in the LMIC library? Or is this to do with interference with a downlink message that I am not able to see?
And is there a way to find out what a good moment is to schedule a message, so that there isn’t this large time delay?

I’ve been trying to find literature about this, the only thing I found is the TTN article about duty cycle, this article about receive windows from semtech, and this forum post about ALOHA delays.

2

Yes. That is duty cycle related. You are not able to send a new message until you have been ‘off line’ for 99 times the amount of time it took to send the previous message. In general LoRaWAN is useful for solutions where you send data once every 10+ minutes and you won’t run into issues with that kind of delay between transmissions.
BTW, every 10 minutes at SF12 will still exceed the TTN fait use policy by a huge margin so keep that one in mind as well (max 30 seconds uplink airtime a day and 10 downlink messages including acknowledgements)

(You could of course check the LMIC source in stead of literature, that’s the advantage of open source software)

1 Like
3

Yes, this is probably of the duty cycle limitation. LMIC tries to adhere to that internally, so it will not actually transmit a package right away if the duty cycle does not allow it.

Note that the fair access policy of TTN is actually a lot stricter than the legal limit. IIRC, the legal limit for EU is 1% per band in the 868 MHz range, where you have two bands, so max 2%. TTN has a policy of 30s/day, or effectively 30/86400 = 0.035%.

I asked a question about upload time accounting on the mcci catena LMIC stack github page about this. My suggestion is to be able to get an estimate of the time spent transmitting in the TX complete callback, so my firmware can hold off the next packet. It is possible in principle, but not implemented in a super user-friendly way yet.

2 Likes
4

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.