Empty POLL messages after successful UPLINK/DOWNLINK being sent

[dolfandringa]

Describe your question or issue I have a device working with a private Chirpstack and MCCI arduino lmic using OTAA. Everything seems to work except that I see extra empty messages being sent from the device back to chirpstack after it successfully sent an uplink message and received a downlink response. The messages is triggered at the next os_runloop_once after a EV_TXCOMPLETE has been issued. The messages have no payload.

I dug into the LMIC code, and the messages are sent because LMIC.opmode & OP_POLL is true and OP_TXDATA is false (hence an empty message). That state seems to happen because of pending mac data (line 2330 of lmic/lmic.c)?

What is the meaning of that empty message? Is that behaviour required in the LoraWAN standard, and if so, what is the use of it? It often (but not consistently) happens 2 or 3 times in a row. My device runs off batteries and takes sensor readings every minute, and sends them over lorawan every 5 minutes. In the mean time it is in a sleep mode to conserve power. But because the extra messages are sent, it consumes a lot more power. So if I could disable this behaviour, it would be much better.

Environment

• Version of LMIC being used: 3.1.0
• Version of Arduino IDE being used: platformio with stm32duino Arduino Core 1.8.0
• Network provider (The Things Network, Swisscom, ChirpStack, etc.) Private Chirpstack
• Region (EU868, US915, etc.) US915
• Board (MCCI Catena, Adafruit Feather M0, Heltec Wi-Fi LoRa 32 v2, etc.) generic STm32F103C8
• Radio (HopeRF, SX1276, etc.) RFM95W

[altishchenko]

@dolfandringa Hello Dolf, yes this is required. Upon successful uplink the server sends to the node some control information called ADR and device should reply to those MAC commands back to the server. This is a reason of an "empty" frame on port 0 to be sent back after a successful uplink-downlink exchange. It does not happen to often, but it is done periodically. Some networks, like TTN, also setup extra communication channels with these and much more (rate, frequency, power control, etc).

[dolfandringa]

@altishchenko thanks for the quick answer. You say it doesn't happen "too often". But for me it does happen too often. I am trying to keep the lorawan module asleep for 5 minutes, and have the device only take sensor measurements in those intervening 5 minutes (and deepsleep in between sensor measurements). But now often, 2 or 3 of those 5 times that it wakes up, only to take a sensor measurement, it also has to send an empty lorawan message. Effectively, it seems to almost double the number of lorawan messages being sent in my case. Since the lora modules uses over 100mA during sending, while the MCU only uses a few microamps, that makes a huge difference in power consumption. Is that normal? I also see that every uplink message also triggers a downlink message from chirpstack. Should Lorawan really be that chatty? Or is there a configuration issue here that causes too many mac commands to be sent or something?

[altishchenko]

No LoRaWAN is not that chatty, it depends on the network server really. Things to make sure - you disabled LinkCheck in LMIC - this one generates some extra traffic, also look into Chirpstack's configuration - may be device status request is happening too often or it does not succeed in setting up all required channels, rx/tx parameters... there is a lot that can be configured from the server on the device. My server sends device status requests about once an hour, so apart from periodic data rate/tx power change messages I don't see them too often.

[altishchenko]

One more hint, frame logging on the gatewy (or server if it can), can reveal what those messages really contain.

[terrillmoore]

ChirpStack, in my recent testing, at least in the US region, sends a whole number of settings after a join -- including setting the repeat count to 3, initially. The LMIC is compliant, mostly, and so if the network tells us to do something, we do it. The repeat count of 3 means that we try to send uplinks 3 times. ChirpStack is much slower about doing ADR than TTN; in my use cases, TTN is better for this reason. Probably you can tune it in ChirpStack, but I have no idea how that's done. It's not a device/LMIC problem. Obviously, the repeat count keeps the LMIC busy longer after uplinks. It would be possibly more intuitive to have a message queue rather than a built-in buffer. But that's not what we have in this version. (The arduino-lorawan library creates a queue on top of the LMIC primitives, and you can do something similar; but it would be better to have it built in because it would keep more info visible to the LMIC.)

[dolfandringa]

This is awesome help @terrillmoore and @altishchenko. Thanks a lot. I do have live logging on in chirpstack, so I can see the contents of the messages. I know its outside the scope of this question and LMIC in general (it's behaving as it should), but do you have any summary of the message types that could be sent and their meaning?

[altishchenko]

@dolfandringa Dolf, all of these messages are detailed in https://lora-alliance.org/resource-hub/lorawanr-specification-v103 , the current LoRaWAN Core specification 1.0.3

[terrillmoore]

I made up a LoRaWAN-at-a-glance chart... I suspect it may be helpful to others:

https://github.com/mcci-catena/arduino-lmic/blob/master/doc/LoRaWAN-at-a-glance.pdf

--Terry

[altishchenko]

@terrillmoore This is cool! Thank you!

[terrillmoore]

@altishchenko you're welcome. I also posted the vsdx -- helpful if you have a Visio license, pretty much useless otherwise.

[dolfandringa]

@terrillmoore and @altishchenko You are legends. thanks!

[dolfandringa]

@terrillmoore if you want to include it in your schematic, I have copied the MAC message table from the 1.0.3 spec into a google doc: https://docs.google.com/document/d/1btA3z_F2C_5LgyKK0gye5bYqUZbjprH6BhO_ZlqECMU/edit?usp=sharing