Hello. can someone share the source code for the TDA system? Interested in a method of calculating coordinates, wired or wireless synchronization. The distance between the anchors is 5 meters. I guarantee gratitude.
Hello Arthur,
Decawave has a solution for TDoA with DW1000 – It is the TTK1000 kit. The software source code is not opened, the customer must get a license to access it.
Please see TTK1000 - DW1000 based TDoA Toolkit for further information.
Hope it helps,
Thnaks
Yves
If you want full source code for a simple distance measurement, take a look at
1 Like
So does no open-sourced code exist for basic TDoA elements? Only TWR?
No one on the Internet has open sourced the code of tdoa.
But I wrote several articles introducing how to implement your own tdoa uwb location system. I introduced how to solve some difficulties in tdoa technology. If you are willing to spend time, you can implement your own location system based on tdoa.
Hello. Is it available now? I seriously searched online and still couldn’t find it. I wonder if anyone has found it?
The answer is still no, you need to make your own.
TDoA requires very tightly synchronised timing on the beacons. This normally involved special hardware with dedicated time sync signals being passed to all beacons. If you need custom hardware then an open source solution isn’t much help unless they also open source the hardware designs. But even then manufacturing a board with the DW1000 IC rather than a module (as required for hardware time sync) is not trivial.
It is possible to do this without special hardware but the firmware to obtain the required time synchronisation is not trivial. For TWR you can skip all the little details that give better results and still get a fairly good solution making it simple to get a system that’s good enough a lot of the time. With TDoA if you don’t get the details correct and all the different compensation factors included you get junk. Generally anyone who is going to take the time to do that well is going to be doing it as a commercial project and so won’t be open sourcing it.
Thank you for your reply. What library did you use for TWR? When I looked at the libraries on GitHub, the system does not work for multiple tags and starts to choke.
I didn’t use any library, I created my own.
Just about all the examples on the net seem to be based on some old decawave example code. This was apparently written by someone who had never heard of a packed struct and so used a byte array for putting the message together.
I suspect it was originally intended purely as a proof of concept and means of testing the hardware rather than as a real world system implementation. Unfortunately most of the open source code out there seem to have taken this proof of concept code and make the minimal (if any) changes needed to make things work for their hardware.
The changes for multiple tags/anchors aren’t too complex:
Give each unit a unique ID number.
Change the message structure to include To and From ID fields (technically only one is needed but both gives more flexibility).
On message reception if the To field doesn’t match your ID then ignore it. Either go to idle or back to receive mode depending on how your system works.
There have been systems built this way, sending a clock signal via wires to anchors. The problems with this approach are many. For example, the wire delay changes with temperature. For another, a pure MHz clock on the wire creates an EMC issue. For all those reasons and more, building an anchor array with a wired distributed clock is basically unworkable.
This is correct.
There is a relatively simple way to do this and that is to designate an anchor as a time master. This anchor periodically transmits a time code to all the other anchors, basically what it’s DX_TIME was at moment of transmission. Any tag being received between time packets can now be interpolated to the master anchor’s time. You do need to correct for the time of flight from master to each anchor, but this is known from the anchor survey. This system is relatively robust and simple and we used it many years ago in our early systems.
It does have several faults. One, the master anchor cannot participate in the location since it cannot receive its own transmission, so you need an extra anchor just to be the master. Two, if the master anchor fails, the system is down. Three, all other anchors have to be in UWB range of the master anchor which limits both the size and possible layout of the system.
For the above reasons and others, we developed a distributed clock modeling algorithm which escapes the master anchor limitations. In this system, some number of anchors are time “seeders” and they transmit time packets to other anchors forming a mesh. All this data is sent from the anchors to the central processor and a very precise model of each anchor’s time is made relative to a global virtual time. Anchors that are not seeders get modeled also based on the packets they hear from the seeders. With that, any local time at any anchor can be converted to the global time and thus directly compared. This process requires constant updates and processing as the anchor local clocks drift with temperature, age, etc. But the system can now scale to large size and can survive the loss of a number of seeding anchors.
Our largest system to date is 650 anchors installed in a 130,000 m^2 fulfillment warehouse. All 650 anchors maintain time modeling to around 50 picoseconds (about 1.5 cm). The entire warehouse is one time “zone”, a uniform global time across the entire area. This works even though anchors at one end of the building cannot receive anything from anchors at the other end. The system makes a “mesh” of about 150 seeders to keep all anchors modeled so an event at one end can be compared in time to an event at the other end. This is the largest unitary UWB system in the world that I know of.
Needless to say, the development effort was non trivial and it won’t be freely given away.
This is true and avoids the clock modeling or sync issues since TWR is based entirely on relative times at each node. Compared to TDOA, multiple TWR does reduce the number of anchors you need for any given system precision.
TWR does suffer from limitations. It uses more energy due to more packets being sent and received for every locate operation. It uses more air time thus limiting capacity. If the anchors are not synchronized, then establishing a precise slot based scheduling system for the network is not possible, so the system usually uses an Aloha style access method, which reduces capacity and causes packet collisions. If those issues are tolerable, then multiple TWR is a lot easier to create than a TDOA system.
Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408