twr_nranges_tdma example does not work when changing the preamble or/and data rate

[EpsilonZ]

Board used: DW1001

After working for a while in a real environment, I wanted to higher the preamble and lower the data rate for longer distances and be able to extend the NLOS situation (as stated in the application notes from DecaWave).

After doing so, I found out that when I set the preamble/data rate to a different value results in "Receive Wait Timeout" obtained from the sys_status at the dw1000_mac.c.

I'm changing the datarate and preamble by establishing at the nrng_tag and nrng_master_node as follows:

UWBCFG_DEF_DATARATE: ""850k""
UWBCFG_DEF_TX_PREAM_LEN: ""1024""

I've tried to change TWR_SS_NRNG_RX/TX_TIMEOUT, NRNG_RX/TX_TIMEOUT, TWR_SS_TX/RX_TIMEOUT, TDMA_SANITY_INTERVAL, OS_LATENCY, UWB_CFG_DEF_SFD_TO.

I've also tried changing the PHR to Standard and SFD_TYPE to 0.

It's weird because I'm testing the same parameters in another evaluation board that contains the DW1000 and they communicate. It seems as it was an application level problem resulting in a rx_timeout event that I'm not correctly understanding. Also, I've seen that in certain configurations I see the tag trying to TWR_SS in the Wireshark but the anchor does not respond.

Have you got working the TWR_NRANGES_TDMA example with other data rates / preamble lengths? If so, could you share the syscfg.yml of the nrng_tag and nrng_master_node just in case I'm missing something?

Thanks!

@ncasaril some help into this would be amazing :) sorry for tagging as I know it may be annoying

[ncasaril]

When changing the preamble length and datarate you effectively change the length of the packet.
The nrange example is quite a tuned example and have from memory hard set timeouts and holdoffs. In order
to work with the longer packets you'll have to change at least the following:

• holdoff and timeout for the range type used
• the number of tdma slots in the superframe, this is because the entire range exchange is now longer - a longer tdma slot is needed.
• or, instead of changing the number of tdma slots, increase the length of the superframe, see CCP_PERIOD (from memory)
• Watch out for the sfd timeout, I can't remember if that's set automatically or if you need to up that as you're increasing the preamble length. It needs to be a bit longer than the preamble or you will never receive a frame.

[EpsilonZ]

I've been working with what you mentioned and I can't seem to find a correct combination of parameters. They seem to communicate but when doing rangings, it seems like a missconfiguration is causing issues.

PAN and CCP seem correctly configured but when doing rangings, the TAG device does not print any rangings. When looking at the Wireshark, this is what I'm sniffing:

TAG->0x1916
ANCHOR->1A40

When the TAG sends the broadcast, sometimes the master_node responds correctly (but tag does not print any range) and afterwards, within the CCP_PERIOD, it does not answer anymore.

These are the parameters I'm working with:

    _i found somewhere in the DecaWave forum that this parameter could cause issues but haven't found it useful_
    TDMA_SANITY_INTERVAL: 10
    _i lowered the tdma slots for an increase of time as you said_
    TDMA_NSLOTS: 10 
    _i tested this parameter too as I read somewhere in the DecaWave forum it could cause issues but after some tests I found it wasn't useful_
    OS_LATENCY: 1000
    UWBCFG_DEF_CH: "\"2\""
    UWBCFG_DEF_RX_SFD_TYPE: "\"0\""
    UWBCFG_DEF_DATARATE: "\"850k\""
    UWBCFG_DEF_TX_PREAM_LEN: "\"1024\""
    _this timeout is calculated from (PREAM+1+SFD_LENGTH-PAC_SIZE)_
   _sfd_lengths 6m8->8 850k->16 110k->64_
    UWBCFG_DEF_RX_SFD_TO: "\"977\""
    UWBCFG_DEF_RX_PREAM_CIDX: "\"9\""
    UWBCFG_DEF_TX_PREAM_CIDX: "\"9\""
    UWBCFG_DEF_PRF: "\"64\""
    UWBCFG_DEF_PACLEN: "\"64\""
    UWBCFG_DEF_RX_PHR_MODE: "\"s\""
    _I've modified these parameters in many different ways but I can't find the correct combination. default value on TX is 0x300 and in RX is 0x10_
    TWR_SS_NRNG_TX_HOLDOFF: 0x05000
    TWR_SS_NRNG_RX_TIMEOUT: 65535
    NRNG_TX_HOLDOFF: 0x05000
    NRNG_RX_TIMEOUT: 65535
    _i've tried the solution of increasing the CCP_PERIOD instead of lowering the TDMA_SLOTS and didn't work correctly_
    UWB_CCP_PERIOD: 0x100000
    UWB_CCP_LONG_RX_TO: 65535

When I show the logs from the NODE, i see that all NRNG requests are being received and the first answered (I can see it as I registered a custom callback of the TX_COMPLETE):

{"utime": 195330842,"msg": "UWB_DATA_CODE_SS_TWR_NRNG"} -> here a request is received which has the UWB_DATA_CODE_SS_TWR_NRNG frame code

tx_complete -> here the NODE answers

reception cb -> here are consecutive RX but are discarded as RX_UNSOLICITED. It knows it by checking &nrng->sem==1. it seems like the tx_complete is not releasing the sem in some way...

reception cb

reception cb

reception cb

I registered TX_COMPLETE and TX_ERROR callbacks and I can't register any errors on the TX. I can see the TX_COMPLETE as in Wireshark. I can't seem to understand what's is going on. I also registered a RX_TIMEOUT_CB and it's not triggering within the CCP_PERIOD thus the RX_TIMEOUT value seems correctly configured.

The source of the issue seems the semaphore which is not being released previously for some reason. Thus, when it starts receiving after the first TX within the CCP_PERIOD, all the receptions are discarded.

It is clear that after changing default RX_TIMEOUT and TX_HOLDOFF the master is able to respond once but it's not fully working... I'm surely missing something.

Do you remember if there are any more parameters that could solve this issue? Or is it that I'm missconfiguring the timeouts in someway?

Thank you very much for your time and help.

[ncasaril]

The _HOLDOFF parameter is in us, essentially it should be the length of the packet plus the turnaround time for the board to go from receiving the request to sending the reply. For a 128bit (and us) preamble this is in the order of 600us, so when increasing the preamble length to 1024 you should increase the holdoff to something of the same order, i.e. 2000us is reasonable.

0x5000 is not reasonable as that's 20ms, i.e. you'll struggle to fit more than a single reply into the max possible rx-timeout.

You may need to think about the maths a bit more. With 10 slots you have about 100ms per slot to play with. If the request takes about 1.5ms at 1024bit preamble (roughly) and you have 2ms holdoff... etc.

Your RX_SFD_TO looks wrong to me, it should generally be longer than the preamble as otherwise it will timeout before the entire preamble is finished. Try something like 1032, or 1050.

[EpsilonZ]

I've been testing and playing around with what you mentioned. Below ~2000s as the TX_HOLDOFF the NODE seems that it is not able to respond. Anyway, it seems that this value does not make things work properly. I've been testing around with the RX_TIMEOUT values too but they seem to have no effect on the behaviour.

I've tested these RX_SFD_TO values too but same behaviour occurs.

In case it helps, these are some stats I retrieved from the NODE and the TAG:

TAG

MAC ->

038348 tx_bytes: 7260
038348 rx_bytes: 5069
038348 DFR_cnt: 196  -> data frame ready
038348 RTO_cnt: 3364  -> receive timeout
038348 ROV_err: 0
038348 TFG_cnt: 378 -> transmission
038348 LDE_err: 0
038349 RX_err: 468
038349 TXBUF_err: 0
038349 PLL_LL_err: 0

TWR_SS_NRNG:

041595 rx_error: 89
041595 rx_timeout: 407
041595 rx_complete: 0
041595 rx_unsolicited: 106 -> unsolicited is incremented each time a reception happens and the semaphore is not released
041595 reset: 0

NODE

MAC ->

052417 tx_bytes: 15410
052417 rx_bytes: 8841
052417 DFR_cnt: 465
052417 RTO_cnt: 2876
052417 ROV_err: 0
052417 TFG_cnt: 542
052417 LDE_err: 0
052417 RX_err: 930
052417 TXBUF_err: 0
052417 PLL_LL_err: 0

TWR_SS_NRNG ->

055368 rx_error: 378
055368 rx_timeout: 1516
055368 rx_complete: 110
055368 rx_unsolicited: 378
055368 reset: 0

It seems like the RX_TIMEOUT and RX_UNSOLICITED is occuring but how? The MY_NEWT RX_TIMEOUT variables from what I can see in the code is for TOF allowance thus it shouldn't make sense changing them, right?

Just for curiosity, if I head to the RX_CB at the TWR_SS_NRNG and make the semaphore release if previously it hasn't been released, things seem to work in Wireshark but in the TAG COMPLETE_EV_CB is not triggered thus it does not compute any rangings.

For illustrating this:

And then, If I execute it, I see on Wireshark all working good:

Am I missing any other timeout / holdoff values? I'm currently working with this parameters:

    TDMA_NSLOTS: 10
    UWBCFG_DEF_CH: "\"2\""
    UWBCFG_DEF_DATARATE: "\"850k\""
    UWBCFG_DEF_TX_PREAM_LEN: "\"1024\""
    UWBCFG_DEF_RX_SFD_TO: "\"1050\""
    UWBCFG_DEF_PACLEN: "\"64\""
    TWR_SS_NRNG_TX_HOLDOFF: 2000
    NRNG_TX_HOLDOFF: 2000

NOTE:

The calculation of the SFD timeout I initially did it was taken from the source code of the dw1000_hal.c :

Anyway, I tested your values and what the dw1000_hal.c says and they do not work :(

[EpsilonZ]

@ncasaril any hint? I'm kind of stuck on this. Thank you :)

[ncasaril]

The best hint I have is to start from the working example and change one parameter at a time until it breaks. For instance, go back to the default set and only try preamble length 256. If that works, then up it to 512 etc.