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:
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)
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.
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.
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. Should be a question of the module’s firmware and possible to solve.
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
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.
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.
Should be a question of the module’s firmware and possible to solve.