Why is so slow between messages

[xforus]

Hello, I'm trying to do as much ranges as I can between Tag and Anchor. But I see that time elapsed between: Transmitting Poll and receiving ACK from Anchor is 24ms Transmitting Range and receiving Range Report is 30ms

These times are configuring devices at 110kb/s. When configuring at 6800kb/s times are 8ms and 15ms.

I think that should be smaller in UWB. I need maximung Range, so I have to configure at 100kb/s, but with this, only could make about 10 ranges in one second... Are these times normal??
Maybe there is a restriction in code but I can't see it? I'm using Arduino 1.8.2

Capture of 3 consecutives polls: 1524 ms transmitPoll 1548 ms receivedPollAck 1548 ms transmiRange 1578 ms receivedRangeReport from: 100 Range: 0.59 m RX power: -68.65 dBm

1626 ms transmitPoll 1650 ms receivedPollAck 1650 ms transmiRange 1680 ms receivedRangeReport from: 100 Range: 0.65 m RX power: -67.77 dBm

1728 ms transmitPoll 1752 ms receivedPollAck 1752 ms transmiRange 1782 ms receivedRangeReport from: 100 Range: 0.58 m RX power: -68.36 dBm

Thank you.

[mikucukyilmaz]

Hi , In my opinion there is 2 reasons for slow communications ; 1- Processing speed of Arduino which we can't change , 2- Delayed transmissions Delayed transmissions is set to 3000 us for symmetric ranging also You can look for "DEFAULT_REPLY_DELAY_TIME & replyDelayTimeUS" variables. But it might be optimized for stable working. In fact with better MCU & if you care regulations ( 1 frame per microsecond ) you can finish your ranging <5ms with 6.8kb/s .

[xforus]

Hi @mikucukyilmaz , thanks for your coments.

But I'm using Teensy 3.2. Processing speed should not be a problem. But maybe I have to change some registers to speed up Teensy with this libraries based on Arduino??

Then, I know about delayed transmisions. I using delayed transmisions between 5000-4000us. But I think that this is a small time compared with 24-30ms used in send 1 Poll and receive Poll ACK.

[mikucukyilmaz]

I just using delayed transmissions for Final message because tag doesn't know about Final_tx timestamp before sending it. In 6.8Mbps 1 Tag 1 Anchor whole communication takes 6 ms. In my previous codes with decawave examples 110K whole communication takes 110ms. But now I'm using stm32 and ported version of this library. As I check all libraries are the same.Printf like functions take so much time you can try after closing in communication debug messages.Stm32 has Single-cycle multiplication and hardware division features. Also floating point math can slow down your mcu if doesnt have features like this. Freescale offers K20's with a floating point unit but it is optional.The Teensy 3.x use the non-floating point version of the chip. You can try to speed up SPI communication.Also why you need that much delayed transmissions ?

[xforus]

Hi @mikucukyilmaz , When you say 1 Tag and 1 Anchor take 6ms in a whole comunication, you mean since send a Poll --> until receive range report?

I need this delayed time because I'm using this scheme:

Anchors need to respond in diferent timeslots in order to not speak at the same time. So I'm using 5000us -> 5ms. If I try to reduce this time, it doesn't work. I don't know why.

But this 5ms used in delay, is very small compared to 30 ms that spend in send 1 poll and receive pollack.

I will try to speed up SPI comunications as you say.

[StevenH2812]

Part of the reason is that for every transmitted frame the Decawave sends a preamble. If you operate the Decawave in a mode that transmits a long preamble, that is going to go at the cost of message transmission speed. If your objective is fast message sending then you should operate the Decawave in a mode with a short (e.g. 128 bit) preamble lengths. The message timestamps in the Decawave are the timestamps of when the actual payload starts to transmit, so before that time the preamble has already been transmitted.