Notes/Issues with HPDWARN and dwt_starttx

I thought I would share some discoveries I’ve made about HPDWARN flag and delayed transmissions in general. Maybe these have been obvious to other people, but they took me a while to track down.

My goal was to minimize the turnaround time between receive and transmit in a ranging node response. If the delay value is too small then the decawave clock will have passed the instructed start time by the time the register is written. What this means in terms of the provided ranging examples is that if the value for POLL_RX_TO_RESP_TX_DLY_UUS is too small, then your code gets stuck in an infinite while loop waiting for the transmission to complete.

At first this didn’t make sense to me because the clock wraps after 16 seconds or so, meaning the transmission should go eventually. It doesn’t. Even if you use interrupts you will wait forever. Furthermore if you poll the SYS_STATUS register for HPDWARN and TXPUTE (the TX_ERR values) you’ll never see them. This is what I found:

dwt_starttx looks for these error flags already. If it sees them it aborts the transmission and returns an error. You can find this in the API documentation, but none of the example code uses it. I think this has been the cause for a lot of confusion when porting these examples to other devices. If you look for this error then your code can handle a delay overshoot, move on, and try again.

My problem now is if I operate with a delay value where ~50% of my transmissions overshoot I see a different strange behavior. A transmission frame begins (TXFRB flag is set), but never is never sent (TXFRS is never set), so my code gets stuck in the infinite while loop anyway. I’ve had to implement a manual timeout to avoid this.

Does anyone know what this behavior means?

Best,
Bryan

Hi Bryan,

I have also been experimenting with delayed transmission and the minimum time needed for successful transmission, here are my observations:

A. when the delay before the frame is due to be sent is long, the following can be seen from the status (0x19) registers:
e.g. long delay

  1. 0x0900020000 TX IDLE
  2. 0x0400020000 TX IDLE
  3. 0x0C00040001 TX preamble
  4. 0x0C00040001 TX preamble
  5. 0x0C00040001 TX preamble
  6. 0x0C00040001 TX preamble
  7. 0x0C00040001 TX preamble
  8. 0x0C00040001 TX preamble
  9. 0x0C00040002 TX SFD
  10. 0x0C00040004 TX SDE
  11. 0x0C00040006 TX RSP_DATA
  12. 0x0C00040006 TX RSP_DATA

B. when the delay is too short or time has already passed, we get HPDWARN. If you don’t use API functions, but just write to register 0xD, the frame will be sent after clock wraps around to the same value again.

C. if the delay is not too short, but the transmitter does not have enough time to power up before the 1st symbol is sent, then you’ll get TXPUTE, but the frame should still be transmitted.

D. there is a time which is slightly longer again, so there are no flags set, but the frame does not get sent. This time is between C. and A.

  1. 0x0C00040000 TX IDLE
  2. 0x0C00040000 TX IDLE
  3. 0x0C00040000 TX IDLE
  4. 0x0C00040000 TX IDLE
  5. 0x0C00040000 TX IDLE …… forever

If the TX clocks are enabled (see register 0x36) then this error does not happen and the frame is sent.

So, in conclusion, you can either add a watch, which you can use to check if the frame is sent in required time, or can enable TX clocks before issuing delayed TX start command. These workarounds are only necessary if your issuing of TX command is very close to the delayed TX time.

Regards,
Zoran

I believe the behavior you describe in D) is what I’m seeing. I’ll try overriding the Tx clock setting.

Thanks for the good info.,
Bryan

Hello Zoran/Bryan,

I was reading your post Notes/Issues with HPDWARN and dwt_starttx.

I have a problem were the [color=#333333]transmission frame begins (TXFRB flag is set), but is never sent (TXFRS is never set). SYS_STATUS register reads 0x800072[/color]

[color=#333333]I was trying to read the SYS_STATE register (0x19) and get a 0x[color=#333333]00060000 value. Any idea why? [/color][/color]

[color=#333333]Your thoughts on this would be appreciated[/color]

Hi,

After weeks of research I finally found this topic which confirmed what I was thinking on my issue. I think this issue should be explicitly reported in decawave documentation. Anyway I tried the solution of enabling Tx clock and it works for me but I wonder what are the effects of this workaround on performance and consumption. I realize this is an old topic but I hope someone will be able to answer me.

Thank You.