Ranging with multiple anchors

[gilbertgit]

Does the lib allow for ranging with multiple anchors? (aka, 1 tag to 3 anchors...?) I just get RX timeouts as soon as I add another anchor to range to. How would you implement this?
Thanks again for your help.

[br101]

the library doesn't support ranging with multiple ancors at once. i haven't figured out a good way to do that.

i range with each of them sequentially. something like:

uint16_t anc[] = { 0x0001, 0x0002, 0x0003 };

for (int i = 0; i < 3; i++) {
    twr_start(anc[i]);
    // wait for TWR to be finished, i usually use a semaphore which i give in the twr callback
}

[gilbertgit]

So this is what I have been trying but not having any luck. I'll try to explain what I'm seeing. If I range between 1 anchor and 1 tag, everything is working great. As soon as I try to range to another anchor, the first anchor will receive the first message and the second anchor does not. THEN neither of the anchors will not receive any other messages after that. If I restart the first anchor, it will receive one time again.
It's really odd that just by trying to send to the second anchor, the first one freezes up. Have you seen anything like this?

[br101]

Hi, yes I have seen this, but only when CONFIG_DECA_XTAL_TRIM was enabled (it causes the clock drift to be adapted to the last sender).

First, I assume you are using latest versions of decalib and decadriver...

To debug this, maybe activate IRQ debugging (CONFIG_DECA_DEBUG_OUTPUT_IRQ) and see if you get any kind of interrupts.

Another thing I'd recommend is activating the frame filter (dwmac_set_frame_filter()) on all sides.

Last but not least, too much of a temperature change can cause the clocks to drift too much. so you should run dwhw_calib_if_temp_change() every once in a while...

Hope that helps...

[andrik78]

@gilbertgit did you solve your problem? I am experiencing the exact same behavior.
Do you have any additional advice to those already indicated by @br101 ?
Many thanks

[br101]

As I mentioned before, I do TWR to different ancors all the time. I suggest to turn on IRQ debugging on the ancors to see if any packets arrive... also it's important to wait for the TWR to finish before you start the next one.

[andrik78]

Hi,
Thank you very much for your response.
I managed to get a system with N-tags versus M-anchors running, but it still requires significant optimization. Below, I’ve outlined a few additional questions:

1. Regarding the IRQs: During the initialization phase, I needed to enable them by calling (on the ESP target) two additional functions compared to your reference example:

dw3000_hw_init_interrupt();
dw3000_hw_interrupt_enable();

From my understanding, these functions are not called anywhere else. Is that correct?

2. Where can I catch an event for TWR completion on the tag side when no REPO packet is used?
   Reviewing the code, it seems that when no REPO is expected, the twr_handle_result function is invoked with dist == TWR_OK_VALUE. In this condition, no twr_callback is triggered.
   Would it be acceptable to simply add the twr_callback as follows to invoke the observer callback, or is there a better approach?

} else if (dist == TWR_OK_VALUE) {
    // This is on the initiator side when no reports are expected; the distance is unknown
    LOG_INF("#%d " LADDR_FMT " -> " LADDR_FMT ": OK", cnum, LADDR_PAR(src),
            LADDR_PAR(dst));
    // >>>
    twr_callback(src, dst, dist, cnum);
    // <<<

3. I’m still encountering issues with MAC filtering.
   After calling dwmac_set_frame_filter(), I stop receiving any packets. Do you have any advice on resolving this?

Thank you!