What are these port 0 downlink messages?

[pomplesiegel]

I’m sure for the right person this is an incredibly obvious question, but I haven’t been able to easily find an answer (or maybe I don’t know the right keywords).

Question: What are these port 0 downlink messages I am seeing in response to my Feather M0 LORA’s uplink messages?

Is this OK? I’m not attempting to do acks or anything like that, as I would like to reserve bandwidth and battery life + follow best practices for a dense LORAWAN network.

Thoughts?

Thanks so much!

[azazeal]

I believe these are related to the network server sending the end device adaptive rate messages.

[pomplesiegel]

Oh interesting! That would make sense why they only sometimes occur. There is no metadata btw:

[arjanvanb (Arjan)]

If you happen to have access to the gateway’s Traffic page in TTN Console, then you can also see the full LoRaWAN packet. When decoding that you might see some MAC commands in FOpts then, which you could try to decipher, like shown in LMIC Library Always Does Unwanted Downlink - #10 by arjanvanb (AU915-928) and ADR problems - node of the same type have different ADR behaviour - #11 by arjanvanb (EU868).

You might also run into FCtrl being hexadecimal 0xA0, or binary 0b10100000, which along with:

…actually indicates it’s indeed an ACK, but also that there are zero bytes in FOpts. So, that apparently indicates ADR does not require any changes on the device, as FOpts includes no MAC commands whatsoever.

The Trace part in the Traffic might show things like:

networkserver ttn-networkserver-eu set ack reason: adr-ack-req

…indicating the node indeed requested an ADR downlink by setting the ADRACKReq bit in the FCtrl of its last uplink:

(Also, clicking the preceding uplink in the gateway’s Traffic page sometimes shows some details in its Trace part, especially in case of errors.)

[pomplesiegel]

Thank you so much for the thoughtful reply!! I can see a lot of learning in my near future.

Thanks again and take care.

[pomplesiegel]

Hello @arjanvanb, I do have access to the gateway, and indeed I did see what you predicted

Would it be advisable for me to disable the ADRACKReq bit to save bandwidth/power, or would that be a potentially risky move? For my application the gateway and the nodes will remain stationary.

Thank you!

[pomplesiegel]

I already have called LMIC_setLinkCheckMode(false) after a join, and from the code it appears that would accomplish this?

void LMIC_setLinkCheckMode (bit_t enabled) {
    LMIC.adrChanged = 0;
    LMIC.adrAckReq = enabled ? LINK_CHECK_INIT : LINK_CHECK_OFF;
}

Still, the downlink messages persist.

[pomplesiegel]

Interestingly too, with verbose logging, this is what the node reports when receiving that ack downlink. Not sure what the error means:

22618296: RXMODE_SINGLE, freq=926300000, SF=7, BW=500, CR=4/5, IH=0
22619621: process options (olen=0)
22619660: ??ack error ack=1 txCnt=0
22619701: decodeFrame txrxFlags 0x1 --> 21
22619750: Received downlink, window=RX1, port=-1, ack=1, txrxFlags=0x21

When running overnight, 8% of the traffic for a particular node is downlink ADR commands from the gateway, which seems like potentially a bit much, right?

[arjanvanb (Arjan)]

@pomplesiegel

indeed I did see what you predicted

Ah, I think your node is also confirming previous settings, by setting channel-mask-ack, date-rate-ack and power-ack too. Also, it seems to be issuing a LinkADR MAC command at the same time, and requesting ADR through the adr-ack-req.

I’ve not dived into the matter that deep. I see a lot of ADR as well for an LMIC node, but I know it’s using an old version of LMIC (I’m not even sure which library is best nowadays), and simply figured my node was not acknowledging the ADR in its next uplink. But I never investigated…

[pomplesiegel]

@arjanvanb, FYI this behavior seems to be fixed by the latest commits to https://github.com/mcci-catena/arduino-lmic ! The downlink messages are happening far less often now.