Hi,
I would like to use MDEK1001 (RTLS TWR) to provide location for the drone under a bridge. I can get the precise location of each anchor by GPS RTK. After reading MDEK1001 quick start guide, the user can manually input XYZ location for the anchors. Can the user input XYZ location of ECEF coordinate? For example, (-3014593.6232, 4937707.7517, 2676818.3383). If yes, does the tag (mobile) output its location in ECEF coordinate?
It may work but I wouldn’t recommend it simply because it’s not how it was intended to operate and you don’t know what assumptions are baked into the system.
There may be some assumptions that the Z axis is the local vertical (although I’m not sure how that would impact it.) More importantly the system could well be using floats rather than doubles for calculations, doubles are slower and use up more memory, for an embedded system they are generally avoided unless required. For local XYZ position floats are fine but once you get into global coordinates a float will only give you around 25 cm accuracy (very approximately). In other words if you use ECEF locations you could get all sorts of rounding issues in the internal calculations.
What I normally do when I need a global coordinate output is set the UWB system up to a local grid that is aligned to north and east and note the global coordinates of the origin point. At that point the UWB calculation can run using floats and as long as you are within a few km of that origin the final output can easily be converted to ECEF with minimal effort or loss of accuracy.
Hi AndyA,
Thank you for the reply. Could I change the firmware of the tag to use doubles instead of floats?
Another question is what is the effective range of MDEK1001 RTLS TWR? What is the appropriate distance between each anchors for my drone application (RTLS TWR)?
Changing the system is not easy.
The full positioning system libraries (known as PANS) that are supplied for free are closed source. They may well be using doubles internally, I don’t know. I just wouldn’t trust them to be.
There is an API that is supplied that allows you to write your own firmware (or you can ignore the API, read the user manual for the radio chip very carefully and write it all yourself). At that point you can have as much resolution as you like but you have to do the whole system setup and position calculation yourself, not a quick and easy task.
On the other hand converting local East/North/Up to ECEF using a known origin only takes half a dozen lines of code and since only the final output stages uses doubles is a lot faster to run.
Generally you’ll be looking at 10 - 20 meter spacings between anchors but it does depend a lot on the physical environment and how well you can position the antennas away from obstructions and jamming sources.
Wow!! Thank you AndyA for your input.
Hi AndyA,
Thanks for the reply. After checking the source code, in the file “dwh.h”, it uses INT32 as the variables to calculate the position. You are right that converting local East/North/Up to ECEF at the final output stage is faster and an easy way.