Acknowledge to confirmed downlink was received (gateway traffic) but not shown in console

Hello there!

I was testing confirmed downlink messages over the TTN console. I configured my node (using RN2483) to reply automatically to those messages with an acknowledge message without payload.

I can see in the gateway traffic that such an acknowledge message is received, however, the console is not showing it. What’s more disturbing is that the confirmed downlink is therefore send again and again and again.

Has anyone experienced something like this before?

This is the console view:
Bildschirmfoto 2020-02-05 um 18.43.00

And this is the gateway traffic view (Counter No 1629 being an empty uplink message with ack flag set to true, as the packet decoder says)
Bildschirmfoto 2020-02-05 um 18.43.56

While I guess TTN should support that, maybe the empty message is the culprit? Also, a node is not required to send an acknowledgement right away; it’s perfectly fine to wait for the next uplink to set the ACK bit, even if that’s days or months later. So: what if you test without that special configuration?

Aside: why did you configure it like that? It just eats airtime, I’d say.

Thank you for the hint with the later uplink + acknowledge.

I found out that the acknowledge flag is only send in the next message if I send a second message without setting the module to sleep, which I do for longer intervals and re-init at boot-up. But if it sends the next message with the acknowledge flag, the console interprets that correctly, shows the acknowledge (see screenshot) and stops the confirmed download.

Bildschirmfoto 2020-02-06 um 15.13.32

Message 3715 triggers the downlink but until 3716 the module goes to sleep and is re-booted, so 3716 doesn’t bring an acknowledge with it and the download is triggered again. There is no re-boot between 3716 and 3717, and the message 3717 contains the acknowledge flag.

But as you said, the empty message for pure acknowledging could be the problem. Maybe that is fixed in V3 stack? If anyone know, please share that information.

As I said, and it showed valuable, that I wanted to test this process.
In the product I need this only on very few occasions, where I download a configuration to the node and I want to make sure that the configuration that I set e.g. in a mobile app is really received by the node. The configuration can later be viewed in the mobile app and needs to be trusted.

Sounds like the state of the LoRaWAN stack is not saved or at least not all required state.
What hardware are you using?

1 Like

Hi Jac!

Yes, seems like that. I do use the save command of the Microchip RN2483, otherwise I would even lose the Frame Counter. Seems like the confirmation request is not part of the saved parameters. Maybe someone from Microchip is carefully reading this forum. :wink: Should be a question of the module’s firmware and possible to solve.

1 Like

Indeed, the September 2018 documentation for the RN2483’s latest firmware (1.0.5) seems not to list it:

2.4.4 mac save

Response: ok

The mac save command must be issued after configuration parameters have been appropriately entered from the mac set <cmd> commands. This command will save LoRaWAN Class A protocol configuration parameters to the user EEPROM. When the next sys reset command is issued, the LoRaWAN Class A protocol configuration will be initialized with the last saved parameters.

The LoRaWAN protocol configuration savable parameters are:

  • adr: ADR state
  • appeui: Application Identifier
  • appkey: Application Key
  • appskey: Application Session key
  • ch: All Channel Parameters
    • drrange: Data Rate Range
    • status: Status
  • class: LoRaWAN operating Class
  • devaddr: End-Device Address
  • deveui: End-Device Identifier
  • dnctr: Downlink Frame Counter
  • dr: Data Rate
  • join flags: Join parameter flags
    • appeui: Application Identifier set
    • appmultiskey: Application Multicast Session Key set
    • appskey: Application Key set
    • devaddr: End-Device Address set
    • deveui: End-Device Identifer set
    • devmultiskey: End-Device Multicast Session Key set
    • nwkmultiskey: Network Multicast Session Key set
    • nwkskey: Network Session Key set
  • mcast: Multicast State
  • mcastappskey: Multicast Application Session Key
  • mcastdevaddr: Multicast End Device Address
  • mcastnwkskey: Multicast Network Session Key
  • nwkskey: Network Session Key
  • rx2 parameters: RX Window 2 parameters
    • freq: Frequency
    • status: Status
  • upctr: Uplink Frame Counter
1 Like

Wondering: so you’re making the RN2483 sleep, but keep it powered on? What does the sleep and re-init code look like?

I thought that sleeping did not need any re-init after waking up. (Hence, I thought that one would not even need mac save.) But the 1.0.5 documentation does not make this explicit:

2.3.1 sys sleep <length>

This command puts the system to sleep for the specified number of milliseconds. The module can be forced to exit from sleep by sending the UART a Break condition followed by a 0x55 character. Forcing the module from sleep in the manner also triggers the UART auto baud detection. The module will adjust the UART baud rate to match the baud rate at which the 0x55 character was sent. Refer to the note box in 1.4 “UART Interface”.

I know (because I used it) sleeping keeps everything current and does not require re-init. After Microchip fixed the sleep power consumption that has become the go to solution for me.

1 Like

Hi Arjan!

I set it to sleep for a very long time and wake it up by hardware (reset pin). Because I have an external controller taking care of the timing. That’s why it won’t keep the non-persistent parameters.