-
|
My device is joined in Class C, from the Chirpstack server I queue a I've tested the same thing in Class A, there Here you can see ack = false instead of true. Log output: |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
Some more information is required in order to answer.
You say that your end-device is setup for Class C operation however looking at your screenshot the uplink Having the network server sending a Class B MAC command to an end-device setup as a Class C device looks strange. 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. |
Beta Was this translation helpful? Give feedback.
-
|
Something that you could try is to display on the end-device log the value of As a general note: A LoRaWAN stack is very time critical therefore one must take a lot of care when adding |
Beta Was this translation helpful? Give feedback.
-
|
I did what you suggested, search for I'm running LoRaMac-node 4.7.0 on FreeRTOS. |
Beta Was this translation helpful? Give feedback.
-
|
According to the LoRaWAN 1.0.4 specification the time range to answer to a confirmed downlink is of 8 seconds. From your log the variable is set to false after executing According to the log the variable is set to false before the 8 seconds elapsed. The following condition is This means that the issue is maybe related on how the You could add some debug information to see what are the values of the Something like: static bool LoRaMacHandleResponseTimeout( TimerTime_t timeoutInMs, TimerTime_t startTimeInMs )
{
if( startTimeInMs != 0 )
{
TimerTime_t now = TimerGetCurrentTime( );
TimerTime_t elapsedTime = TimerGetElapsedTime( startTimeInMs );
printf("startTimeInMs: %ld, now: %ld, elapsedTime: %ld\n", startTimeInMs, now, elapsedTime );
if( elapsedTime > timeoutInMs )
{
Nvm.MacGroup1.SrvAckRequested = false;
return true;
}
}
return false;
} |
Beta Was this translation helpful? Give feedback.
-
|
You were right, there was a bug in |
Beta Was this translation helpful? Give feedback.
According to the LoRaWAN 1.0.4 specification the time range to answer to a confirmed downlink is of 8 seconds.
Please read chapter "15 Continuously Listening End-Device (Class C)" of the specification.
From your log the variable is set to false after executing
LoRaMacHandleResponseTimeoutfunction.https://github.com/Lora-net/LoRaMac-node/blob/2bf36bde72f68257eb96b5c00900619546bedca8/src/mac/LoRaMac.c#L1843C1-L1855
According to the log the variable is set to false before the 8 seconds elapsed.
The following condition is
truehttps://github.com/Lora-net/LoRaMac-node/blob/2bf36bde72f68257eb96b5c00900619546bedca8/src/mac/LoRaMac.c#LL1848C14-L1848C14
This means that the issue is maybe related…