Hi there,
I work with the Leapslabs UDK1 demo kit (QM33120 + Nordic nRF52840) and their SDK.
I started with ex_05a and ex_05b examples (simple TWR ranging between initiator and responder).
I changed the initiator code to start the TWR in a fixed frame period of exactly one second.
I changed the responder code to send two (dummy) poll messages after the final frame (I need that for my application).
I schedule the first dummy poll to be sent 32ms after the TWR-Poll-rx-timestamp.
I schedule the second dummy poll to be sent 998ms after the TWR-Poll-rx-timestamp.
So plenty of time for scheduling and starting of the two additional dummy Poll messages.
And it actually works most of the time but after between approx. 5-10 minutes of working perfectly, I get a FFFFFFFF return value form the dwt_starttx(DWT_START_TX_DELAYED) function.
Also the print logs that I have, indicate that I am far from scheduling being too close to the function call. All looks good. So I’m stuck and running out of ideas what I can try.
There is this note in the responder source code:
When running this example on the DWK3000 platform with the POLL_RX_TO_RESP_TX_DLY response delay provided, the dwt_starttx() is always successful. However, in cases where the delay is too short (or something else interrupts the code flow), then the dwt_starttx() might be issued too late for the configured start time. The code below provides an example of how to handle this condition: In this case it abandons the ranging exchange and simply goes back to awaiting another poll message. If this error handling code was not here, a late dwt_starttx() would result in the code flow getting stuck waiting subsequent RX event that will never come. The companion “initiator” example (ex_05a) should timeout from awaiting the “response” and proceed to send another poll in due course to initiate another ranging exchange.
What does the “(or something else interrupts the code flow)” phrase mean ?
In the example code the “error handling” is to abort and “continue” to the next ranging cycle but that I cannot do. I have to bring these dummy poll msgs out resp. activate the EXTPA GPIO at exactly the scheduled times.
So please help me with addressing this problem. It is a core functionality of my application and I may not have any dwt_starttx errors.
Anybody has an idea what is going wrong here or ideas how to debug this ?
Are there other possible reasons for the dwt_starttx function to fail than beeing too close to the function call with scheduling ?
Here is the responder log that I mentioned:
+++Ranging Cycle Success DIST: 0.13 m
sys_time_0 46487ef4 status_0 01800077
sys_time_1 464f6c36 status_1 01806f77
Poll RX-Timestamp 464f21be Poll 1: 46c901be Poll 2: 5528189e
+++Ranging Cycle Success DIST: 0.16 m
sys_time_0 5529233c status_0 01800077
sys_time_1 5530114c status_1 01806f77
Poll RX-Timestamp 552fc124 Poll 1: 55a9a124 Poll 2: 6408b804
+++Ranging Cycle Success DIST: 0.14 m
sys_time_0 6409d0de status_0 01800077
sys_time_1 6410be32 status_1 01806f77
Poll RX-Timestamp 6410608a Poll 1: 648a408a Poll 2: 72e9576a
Dummy Frame 1 TX Error: ffffffff
///Ranging Cycle Fail
sys_time_0 72ea576c status_0 01800077
sys_time_1 72f12542 status_1 01801377
Poll RX-Timestamp 6410608a Poll 1: 736ad88a Poll 2: 81c9ef6a
sys_time_0 is the systime before the wait statement for the TWR-Poll msg coming in
sys_time_1 is the systime after the wait statement for the TWR-Poll msg coming in
Poll1 and Poll2 are the schedule-times for the dummy poll messages
Printouts are done between Poll1 and Poll2 message where I have more than 900ms room.
Any comments, ideas, suggestions are highly appreciated.
Thanks
Pirmin