Put simply, I’m designing a system to measure the distances between one anchor and three different tags to determine which tag is closest. I’ve not found any information on the matter, but am I required to have a separate microcontroller board for each DWM3000, that is, have something like the ESP32 UWB DW3000 combined module for the anchor and each tag? If only one universal microcontroller is required, what is the typical set up for the remaining DWM3000s and how are they to connect to the microcontroller without physical access? Please do ask for additional clarification if I haven’t been too clear, cheers.
The DWM3000 doesn’t have any form of processor, it needs to be connected via SPI to a processor of some sort.
While you could in theory connect multiple DWM3000s to a processor each DWM3000 is normally in a different location which generally means one processor per DWM3000 device. Running SPI at the required speeds over any significant distance gets tricky, even if it was physically possible to share a processor it probably wouldn’t be worth the hassle. Plus some drivers probably make the assumption that there is only one device connected and use global / static variables that would cause issues with multiple instances.
An ESP32 is complete overkill in terms of processing power and memory but they are cheap so no real reason not to use one for each node.
I’m trying to use these UWBs for very short range measurements, as in typically less than a metre. Would it be true that a microcontroller with a higher clock speed could allow for more accurate measurements? Say, an ESP32 operating at 160MHz would give more accurate measurements than an ATmega328 at 8MHz? If possible, I’d be hoping to achieve +/- 1cm or less, for example.
Short answer: No.
At 1 meter, assuming you could run a wire between the two points, running them both from the same processor would become possible. But personally I would still go with one processor per device for simplicity.
The issue with slower 8 bit processors (other than the lack of memory some have) is that the time taken to read, process and then queue up a reply to a UWB message is significantly longer. This stretches out the time taken per measurement which 1) drops your measurement update rate and 2) increases the effects of clock differences and drift. Neither of these directly impact accuracy but clock errors will cause range errors if you don’t correctly compensate for them and no compensation is ever going to be perfect. Averaging is a good way to reduce noise and error, a lower update rate doesn’t help this.
There are two sorts of measurement error - random noise and bias. From our testing the random noise for two way range has a standard deviation of around 3cm. For good signal strengths single sided and double sided TWR systems have very similar noise levels. Averaging will remove this random error.
The bias you can’t remove with averaging, some of this will be signal level related, some temperature related and some antenna delay related. You need to measure, calibrate and compensate for these effects. There is also a certain amount of environmental effects that you just have to live with. In our testing the range output tended to almost be quantised, if you moved at a very slow constant speed and applied sufficient averaging the resulting range Vs time chart was steppy.
At short distances you also have to worry more about signal strength effects, signal strength drops with the inverse square of range so at shorter ranges you get a bigger effect for the same amount of distance moved than you would at a longer range.
We ended up getting a system that was +/- 2cm over ranges of 1 m to 60 m. But that took a lot of effort and unit specific calibration. We may be able to get a little better over a narrower range of distances but I don’t think under 1cm is realistic without getting into something horribly complicated involving multiple units in a fixed geometry on each side of the distance being measured.