for a hobby project I stumbled upon UWB and to get started I bought two development kits from M5Stack. A StickCPlus and a Core2. They are both ESP32 based kits. M5Stack offers an UWB module (Ultra-Wideband (UWB) Unit Indoor Positioning module (DW1000) | m5stack-store) that is based on the DW1000 and seems to be a custom DWM1000 for easy connection the M5Stack development kits.
So far so good, I got a basic example to run but now I have the problem that I only get new ranging values every 1.3 seconds. I can read values between these 1.3 seconds but the value doesn’t change. So let’s say I move the tag about 10cm/10ms, then I basically get the first value at 0m range and then a lot of 0m range values and then after 1.3 seconds I get a ±13m range value after 1.3 seconds and then again a lot of 13m range values until after another 1.3 seconds and so on. Is this a M5Stack firmware problem? They seem to be using some sort of lite driver version where you set some configuration towards the UWB module via AT-commands (m5-docs). Or is this a ESP32 problem? I read somewhere that the UWB modules are optimized for nordic semiconductor MCUs or something.
For my project I need basically:
sensor refresh rate of <=10ms
distance accuracy of 10cm
range of 50-100m (or I use multiple anchors so this is no hard requirement)
Is this achievable with DW1000 or DW3000? Can I somehow set the sensor refresh rate with the decawave firmware?
I should add I am farely new to embedded stuff but I read a lot and played around with arduino a lot. If anything is unclear I will try to be more specific. I hope this forum is the right place for these kind of questions.
Yes this is a firmware issue. Exactly where is hard to say since I have no familiarity with the stack you are using.
To be honest unless you are using the decawave / qorvo supplied drivers then this probably isn’t the best place for firmware support. Most people here either use the off the shelf positioning system, the official drivers or a few of us were crazy enough to write our own drivers. There are very few people here using 3rd party drivers. If you can find a forum more specific to the drivers you’re using you may have more luck.
The physical chip is purely an SPI device and as such not optimised for any specific hardware. The official drivers are optimised for nordic and STM parts.
Nothing I’ve ever seen before has used AT commands for it, that is a peculiarity of your drivers.
There are some generic Arduino DW1000 drivers around, you may have more luck with those.
As for your capability questions:
Yes range measurement at 100 Hz (10ms) is possible. If you really push it you can get over 1kHz point to point range updates but that is very dependent on the drivers being written for speed.
Yes range accuracy of 10 cm is possible. Out of the box with no special tricks you may see slightly larger errors than that but that is the correct ball park. With calibration we can get range to be +/- 2 cm most of the time. However this does require calibration, control of antenna orientation, compensation for power and temperature etc…
Yes range of 50-100m is possible. If you need to stick within the FCC power limits then 100m while getting a high update rate may be tricky, all the things to improve range slow things down. So high speed and long range at the same time while keeping the power within the regulations is hard. If you crank the power up then you can’t sell it and have to shut down if there is any sign of causing interference but you can get the range and speed.
I am currently reading through the DW1000 user manual and the DW1000 software API guide to understand where to start.
Some more questions if you are happy to answer:
Are the drivers installed on the DW1000 itself and would I have to do something special to use the decawave/qorvo drivers on my hardware`, like installing it on the DW1000 somehow? Or is it just a different library I would use in my code to access the official API?
What kind of problems can I expect to run into if i don’t use hardware that the drivers are optimised for? In the user manual it says “The DW1000 driver source code is targeted for the ARM cortex M3 but is readily portable to other microprocessor systems.”. If i use an ESP32 based microprocessor, will it just not compile or upload to the microprocessor or will there be tricky bugs?
Also any advice on how to start? There seem to be examples within the DW1000 software package which I’ll give a try, but any other resources apart from the user manual and the software examples I should have a look into?
Thanks again for taking your time to answering my initial questions!
There are no drivers on the device itself, it’s an SPI slave device. The interface to the device is purely reads and writes to internal registers, there is nothing that in the device that will check that the values you’re writing are valid or that the addresses you’re reading make sense.
In other words it’s all down to the firmware on your processor.
Most of their drivers are generic C, as such as long as you modify the functions used to access the hardware (mainly the SPI read/write functions in the platform directory) it should build for just about any platform. They are mainly putting that language in as a warning that they haven’t tested other processors and compilers and so some oddities may exist.
The examples are a good starting point. However they are also fairly simplified with little or no support for anything beyond a polling based point to point link. They are good as examples and to show how to do certain operations. But expanding them into a full positioning system requires enough changes that once you understand how the examples are working it may be easier and will certainly result in cleaner code to start from scratch.
The descriptions of things like PANS and other positioning systems can also be handy for giving you insight in to how other people have structured their final system. The drivers and examples are very low level, pass a couple of packets, calculate a distance. Going from that to a network of devices and reliable multi-tag operation requires a certain level of system design that isn’t in the documentation.