I’m working for an artist on an interactive installation for kids, where they move around a garden and trigger sounds based on their proximity to certain objects. The kids wear backpacks with electronics and speakers inside, and the sounds in the piece are all created by kids. It’s fun! In the past we used a BLE beacon hidden inside each object and an android application that read RSSI, but this setup was not accurate enough.
I’m evaluating the DWM1001 system and thought I would ask for a bit of clarification while the Mouser order is in transit. I’ll be interfacing the tags with a Teensy 4.1, and was hoping to use the PANS firmware rather than rolling my own NRF52 recipes.
To simplify the installation of the piece it would be ideal if we could place a DWM1001 anchor in each object (14 in total) and read the distance data from the three to four closest tags. Specifying the xyz location of each anchor could prove tedious (the creative process being what it is). Can PANS be used this way? Will I get back meaningful distances from calls to “dwm_loc_get” if all of the anchors are set at 0,0,0?
Or am I better off just creating an inexact grid of anchors and using PANS as intended? Any help you all can provide is much appreciated.
I’m hardly an PANS expert but I don’t think that will work. It only measures 3-4 ranges for a position calculation. If all the anchors claim to be in the same location then you have no way to make it use the closest.
I believe however that it does report the anchors used and their measured ranges in addition to the calculated location.
In this situation if you can put in approximate locations for the anchors it should work well enough. The anchor locations don’t need to be correct, they just need to be close enough to ensure the correct ones are used. You can then read the measured ranges directly and use those in your application.
So hardly perfect, large changes in anchor locations would require an update, but small changes would be ok.
Hi @soundman
no it would not work. If the TN cannot calculate its position (and with poorly positioned anchor it will be not possible) it will pick some random anchors to do ranging and try estimate the position.
The only one workaround for this is to have max 4 anchors or you can have more anchors but there must be bigger separation between them so TN can always hear only 4 of them.
But anyway I dont think PANS is a good SW for this use case.
If it doesn’t work (and leapslabs know PANS a lot better than I do, wrote it) then it is always possible to fall back to custom firmware but that is a lot more work.
On the plus side you don’t need to know the position, you have a known and fairly small set of anchors and you’re tracking something slow moving so update rate isn’t critical.
You can make each backpack range to all the anchors, 14 anchors shouldn’t take more than 50 ms to measure (if things are optimised enough you can do it in well under 20ms). If you make it so each backpack attempts to update every second with a random length backoff if it detects another one active when it wants to start. That would easily allow 10 packs at 1Hz update.
That represents about 50% active time, you don’t want to go much higher without some sort of time sync and proper coordination between backpacks. And adding that time sync makes life a lot more complicated.
The final update rate would depends on the number of backpacks you expect to be in use at the same time. It it’s 20 then 2 seconds between updates, 100 then 10 seconds.
If that works out as giving you too slow an update for what you want then you could start to get sneaky and change the rate dynamically based on the distances. If you are far closer to one anchor than any other then you can drop the update rate, the closest isn’t going to change soon. If you are close to a switching point then increase the update rate to detect the transition point better.
I’ve got a tag ranging with two anchors now. MDEK on the way.
I’m wondering if the following installation setup routine would allow me to still use PANS:
Anchors are placed in a grid measured on the site
Tags are brought to the locations that will trigger sounds. Their position is read by the host controller (teensy) which then re-configures them as anchors using this stored position.
Repeat step 2, for all locations that trigger sound, maintaining enough anchors to cover the entire site.
Ride off into the sunset without writing custom DWM firmware?
I spent a few months working with the NRF52 last year and will get my hands dirty if I have to but this project is for a friend and relatively (cough very) low budget so I would like to avoid it if possible.
So you are using a small number of fixed anchors to survey the locations of “moveable” anchors by running the movable anchors as tags. Sounds feasible. It shouldn’t be too hard for your host micro to automate this, when set into survey mode it switched to tag mode using the known good anchors, measures the location and then switches to anchor mode using that location. You can average the measured location and verify that it’s stable and sufficiently low noise in order to improve the quality.
If this is very cost sensitive then once the location of the moveable parts are nailed down your anchors used for the survey could potentially be re-purposed into tags for the backpacks.
The positions you get out from tags using the “mobile” anchors isn’t going to be great, you’re going to be propagating a lot of errors. But it will give you an approximate survey that is far far better than you could make by guessing.
You may want to manually set the heights for the anchors, that isn’t going to change when they get moved and the height accuracy of the system is no where near as good as the horizontal accuracy. This is a fundamental limitation of the geometry, you can easily get 10 meters of anchor variation on the x axis, it’s a lot harder to get that much variation vertically.
Just wanted to update for anyone who is thinking about using the DWM1001 for a similar application:
I ended up using PANS2.0 out of the box and it worked very well. I created a “master controller” with a teensy 4.1, tft, and DWM1001 tag. After creating the network of anchors, the positions of the various sounds could be set by reading the position from the tag on the master controller. The radius at which the sound should be activated could also be set, in addition to fades, db levels, etc. These settings could be transferred to the playback units (stashed in custom backpacks with headphones, also Teensy based). Despite many restrictions placed on us by the site where we were presenting (for example, all anchors needed to be mounted less than 1m off the ground), we were still able to get great position data over the course of the exhibition.