CLI Firmware: Automatically Restart RESPF After Session Stops?

I have set up a few DWM3001CDK as anchors, using the CLI firmware, and RESPF / SAVE to have the boards automatically start in responder mode. This works great, but the problem is that the tag I’m using (not a DWM3001CDK) stops the session whenever it’s not actively ranging, after which the anchors enter IDLE state, and need to be power cycled to participate in ranging again.

Is there any way to have the boards automatically resume responder mode if the session stops? Of course, I can achieve this with custom firmware, but I was wondering if there’s a way to do it from within the CLI? (If not, suggestions on the easiest way to achieve this with custom firmware would be appreciated! Tweaking the CLI firmware perhaps to repeatedly re-issue RESPF?)

Note that I have very little control over the tag side, so I’m looking for a solution in the DWM3001CDK anchors. The idea is that the anchors will run non-stop in responder mode, always ready to range with the tag on request.

Below is an example of the logs in an anchor, as it starts up, initially timing out since the tag is not yet transmitting, then starts actually ranging, then as soon as the tag stops, the session is stopped in the anchor, and does not restart.

SESSION_STATUS_NTF: {state="INIT", reason="State change with session management commands"}
SESSION_STATUS_NTF: {state="IDLE", reason="State change with session management commands"}
SESSION_STATUS_NTF: {state="ACTIVE", reason="State change with session management commands"}
SESSION_INFO_NTF: {session_handle=1, sequence_number=0, block_index=0, n_measurements=1
 [mac_address=0x1234, status="RX_TIMEOUT"]}
SESSION_INFO_NTF: {session_handle=1, sequence_number=1, block_index=1, n_measurements=1
 [mac_address=0x1234, status="RX_TIMEOUT"]}
SESSION_INFO_NTF: {session_handle=1, sequence_number=2, block_index=2, n_measurements=1
...
[mac_address=0x1234, status="SUCCESS", distance[cm]=29]}
SESSION_INFO_NTF: {session_handle=1, sequence_number=261, block_index=1, n_measurements=1
...
SESSION_STATUS_NTF: {state="IDLE", reason="Session stopped due to inband signal"}

Hi @bennedich , the message “Session stopped due to inband signal” comes when the initiator/controller sends an in-band termination signal in the RCM to the responder/controlee. Therefore, it appears that your tag, which is the initiator, is sending this signal. The anchors are simply adhering to the request and that behavior is part of our MAC so it is not possible to ignore that request without altering the MAC.

The parameter IN_BAND_TERMINATION_ATTEMPT_COUNT needs to be set to 0 to disable the in-band termination attempt on the initiator side.

1 Like

Thanks! I’m unable to modify the tag behavior unfortunately, but I was able to modify the firmware to ignore the request. Seems to work fine now!