Location update delay when Tag is set to 60 sec update frequency

Wireless Connectivity Ultra-Wideband
, ,
1

We have configured the Gateway and every thing works as expected.

When we set the Tag update interval to 100 ms / 0.5 sec / 1 sec i am ok with the response data received in MQTT from the gateway.

But when I set the Tag to 60 Sec update freq (0.016 Hz) i get the latest location details in a huge delay.

scenario is when my Tag is in (x,y) = (10,10) at 11:00 AM
and i move to (20,20) (x,y) in 11:01AM

Expected: (MQTT)

11:00 AM = (10,10)
11:01 AM = (20,20) (or atleast at 11:02 AM)

Actual result:

|11:01|(10,10)|
|11:02|(11,11)|
|11:03|(12,12)|
|11:04|(13,13)|
|11:05|(14,14)|
|11:06|(15,15)|
|11:07|(16,16)|
|11:08|(17,17)|
|11:09|(18,18)|
|11:10|(19,19)|
|11:11|(20,20)|

looks like the Tag stores mostly all the location even happened and updates it in 60 sec interval. because of this behaviour we can’t use this solution in production env :frowning:

2

Hello, this behavior is due to the fact that the included location algorithm has a small window to reduce the oscillations, in general it calculates the delta of the previous position and the acutal position and predicts the next position. For small frequencies this behavior is inperceptible, for longer times it is not a desired behavior.

I have managed to eliminate this behavior by overwriting the location engine with one of my authorship.
to cancel the internal filter the variable must be decalrated

extern char pos_est_first

and always write it at 0x01 every time the distance is calculated.

I share my development of the trilateration algorithm, I would have to add extern char pos_est_first in dwm.h and pos_est_first = 0x01; in dwm-simple.c in trilat_solve

regards

3

Thanks for the update. now i understand the issue.
i hope decawave will have some kind of configuration to resolve this issue in future.

i will have a look at your algorithm and try to compile and flash it when i get time.