Class C: Sending ConfirmedDataDown does not result in ACK
Closed this issue · 1 comments
My device is joined in Class C, from the Chirpstack server I queue a ConfirmedDataDown
message to the device. I see the device sends a response but in Chirpstack ack: false
for that uplink message.
I've tested the same thing in Class A, there ack: true
as expected.
Here you can see ack = false instead of true.
Log output:
14:26:23:675 -> [4439772] OnRxData
14:26:23:676 -> [4439773] printf: ###### ========== MCPS-Indication ========== ######
14:26:23:683 -> [4439780] printf: STATUS : OK
14:26:23:686 -> [4439783] printf: ###### ===== DOWNLINK FRAME 3 ===== ######
14:26:23:692 -> [4439790] printf: RX WINDOW : C
14:26:23:695 -> [4439793] printf: RX PORT : 1
14:26:23:698 -> [4439796] printf: RX DATA :
14:26:23:702 -> [4439799] printf: 66 66 66
14:26:23:704 -> [4439802] printf: DATA RATE : DR_0
14:26:23:708 -> [4439806] printf: RX RSSI : -80
14:26:23:711 -> [4439809] printf: RX SNR : 10
14:26:23:715 -> [4439813] Got LORA event. param=0x3
14:26:23:718 -> [4439816] LORA Receive Pending!
14:26:23:721 -> [4439819] Received:
14:26:23:723 -> [4439821] printf: 66 66 66 | fff
14:26:49:722 -> [4466447] OnRadioRxDone
14:26:49:724 -> [4466447] OnMacProcessNotify
14:26:49:727 -> [4466447] lora_task_notify: 0x02
14:26:49:730 -> [4466447] OnRadioRxDone
14:26:49:732 -> [4466447] OnMacProcessNotify
14:26:49:735 -> [4466447] lora_task_notify: 0x02
14:26:49:738 -> [4466448] OnRxData
14:26:49:740 -> [4466466] printf: ###### ========== MCPS-Indication ========== ######
14:26:49:747 -> [4466473] printf: STATUS : OK
14:26:49:750 -> [4466476] printf: ###### ===== DOWNLINK FRAME 4 ===== ######
14:26:49:756 -> [4466483] printf: RX WINDOW : C
14:26:49:759 -> [4466486] printf: RX PORT : 1
14:26:49:762 -> [4466489] printf: RX DATA :
14:26:49:766 -> [4466492] printf: 66 66 67
14:26:49:768 -> [4466495] printf: DATA RATE : DR_0
14:26:49:772 -> [4466498] printf: RX RSSI : -83
14:26:49:775 -> [4466502] printf: RX SNR : 9
14:26:49:780 -> [4466507] OnMacMcpsRequest
14:26:49:783 -> [4466510] printf: ###### =========== MCPS-Request ============ ######
14:26:49:789 -> [4466516] printf: ###### MCPS_UNCONFIRMED ######
14:26:49:795 -> [4466523] printf: ###### ===================================== ######
14:26:49:802 -> [4466529] printf: STATUS : OK
14:26:49:805 -> [4466532] Got LORA event. param=0x3
14:26:49:808 -> [4466536] LORA Receive Pending!
14:26:49:811 -> [4466539] Received:
14:26:49:813 -> [4466541] printf: 66 66 67 | ffg
14:26:49:832 -> [4466560] OnRadioTxDone
14:26:49:834 -> [4466560] OnMacProcessNotify
14:26:49:837 -> [4466560] lora_task_notify: 0x02
14:26:50:885 -> [4467637] OnRadioRxDone
14:26:50:886 -> [4467637] OnMacProcessNotify
14:26:50:889 -> [4467637] lora_task_notify: 0x02
14:26:50:892 -> [4467646] OnTxData
14:26:50:894 -> [4467648] printf: ###### =========== MCPS-Confirm ============ ######
14:26:50:900 -> [4467654] printf: STATUS : OK
14:26:50:904 -> [4467658] printf: ###### ===== UPLINK FRAME 3 ===== ######
14:26:50:910 -> [4467664] printf: CLASS : C
14:26:50:913 -> [4467667] printf: TX PORT : 0
14:26:50:916 -> [4467671] printf: DATA RATE : DR_5
14:26:50:920 -> [4467674] printf: U/L FREQ : 867500000
14:26:50:924 -> [4467678] printf: TX POWER : 2
14:26:50:927 -> [4467681] printf: CHANNEL MASK: 00FF
Some more information is required in order to answer.
- What version/commit of this project is being used?
- What is the Chirpstack network server version?
- What are the required steps to reproduce the observed issue?
- Network server uplinks/downlinks logs
- End-device previous uplinks/downlinks logs
You say that your end-device is setup for Class C operation however looking at your screenshot the uplink 03071100
on FPort 0 contains answers for two MAC commands.
The first 0307
answers a LinkAdrReq
indicating that the parameters were accepted.
The second 1100
answers PingSlotChannelReq
indicating that it does not accept it.
Having the network server sending a Class B MAC command to an end-device setup as a Class C device looks strange.
From the provided information we cannot know what the network server did prior or after to receive the shown uplink.
What I can say is that the latest version of this project successfully passes the LoRaWAN Class C certification which tests this behavior (Sending a confirmed downlink on a Class C window and having the end-device acknowledging it).
In conclusion not having the required information it will be hard to understand what is going on.
In the future it would be nice if you could post this kind of questions on the project Discussions tab. It is a better place to engage discussions and then we can agree if it is an issue or not.
If you don't mind I move this issue to the Discussions tab.