Making TREK faster

Hi all,

I received help here before about making a TREK system faster and have developed that some. I now have some questions about timings discussed in source code guide and APS016.

In my system I use 4 anchors and 6.81Mbps mode with preamble length = 128 like default TREK mode when switch 2 is on. I do not use anchor to anchor and I only have 4 tags so I have made 4 slots. Now I reduce slot time to 4ms.

In APS016 says:

The TREK10000 allows 100 µs between messages, to account for delays in the microprocessor in
processing and responding to the message, and it further divides time into slots which include 3 ms
to 6 ms of guard time between tag transmissions, (where the 1 ms microprocessor tick timer is used
to control transmission).

APS016 says we can reduce to 80 µs. Where is the 100 µs in source code?

In source code guide:

This means that the total time of ranging exchange takes about 26 ms in 110 kbps mode and 2.25 ms in 6.81 Mbps mode.

APS016 says we can reduce guard time to 250 µs with different timer. Guard time is already counted in slot time if I understand. So can I make 3ms slot time and have 750 µs guard time and keep 1ms tick timer?

How do I need change replyDly in sfConfig for this? I can’t understand that value.

Please pardon my English! My coworker isn’t here to correct for me.

Thanks,
Sam

I forgot to say that DEEP_SLEEP is disabled.

Thanks,
Sam

80us vs 100us “processing time”, this is the time that the micro needs to process the received message, and prepare response message. It depends on the micro processing power, SPI rate, etc. The TREK code uses RX_RESPONSE_TURNAROUND to specify this time.

Note the App 016 does say it can be reduced, however this may not be as straightforward as just changing the RX_RESPONSE_TURNAROUND, you will probably have to optimise the TREK code as well.

Similarly TREK / ARM uses a 1ms tick time, this means that you need a >3ms guard time to make sure the ranging slots do not overlap. If you want to reduce this guard time, you will have to change the timer to < 1ms, e.g. 100 us.

All of these optimisations/improvements are left to the user to experiment with/develop. These are just suggestions. TREK code is only a simple demo or TWR RTLS.

This makes much clearer sense for me now. I understand TREK code is demo but I am learning both TWR and ARM to push it faster. I am not confident to refactor large parts of the code yet. But maybe I am given no choice now.