I am using the ready library for Arduino (https://github.com/thotro/arduino-dw1000). For now, I can communicate between anchor and tag using the basic DW1000Ranging class. But I have some problems. I would like to ask these questions:
This class of this library is still full of deficiencies. These shortcomings seem to continue in the future. Also, the size of this library is extremely large and I think it contains many unnecessary variables. For this reason, I want to write this library myself based on the DWM1000 class. Because we want to create a corporate product. Do you think it would be a problem if I proceed in this way? Or should I trash this library entirely? How accurate would it be for me to use an ATMEL processor? Will this do me any harm? Should I use STM32? The project will be used to track miners underground.
Can you share the documentation for the DECAWAVE DWM1000 required for me to write this library? I will use C++ for ATMEL.
What exactly are Device ID, Unique ID, Network ID and Short Address used for? What do they mean? Why do we need to define a Unique ID for the device? Is the MAC function only used for CRC? Is CRC required?
When we define a DWM1000 module as anchor, can it also send data to tags?
For real environment tests I will use MODE_LONGDATA_RANGE_LOWPOWER or MODE_LONGDATA_RANGE_ACCURACY. I learned the differences between them. But which one should be used in real environment. As I said, my goal is to get location information once in 5 seconds from tags.
Data comes in non-stop with Thotro’s standard library. As such, it will cause a battery drain. How should the timer be positioned (for every 5 seconds)?
Is it possible to get Unique ID data from hardware without defining it myself?
I want to integrate other data besides location information. I will send other sensor data as well. What are the limitations here? Thanks for your patience…
The answer to all of these questions is ultimately how much work do you want to do?
Personally I wouldn’t touch any Arduino library for commercial products, the few times I’ve dug into some of it I’ve not been impressed. But I know others feel differently.
There is a c API library available from decawave/qurvo that provides an interface to the chip allowing you to configure it and then send and receive packets. This is targeted to STM hardware but all of the hardware specific code is contained in a couple of files in the platform directory. If you modify these for your hardware (mostly the SPI calls) then the rest of the code should be portable. I’ve done this to retarget the drivers to NXP LPC parts.
Or you can ignore that completely and create a pure c++ driver from scratch. Everything needed to do this is provided in the DW1000 user manual. The DWM1000 is a DW1000 with antenna and required support hardware added, from a firmware perspective the two are identical. This is far more work, especially coping with all the possible error cases, but will give you a smaller, cleaner driver that is more targeted to your specific application.
See above, you want the DW1000 user manual, it’s on their site in the documentation section. If creating your own range calculation system I would also highly recommend the application notes. Getting an approximate range is simple, getting an accurate range is hard. The application notes give a lot of detail on what you need to do to get the best possible performance.
3-8) All of these are purely a feature of firmware and the range measurement protocol used. If you are creating your on ranging code then every part of this is entirely up to you. The DW1000 provides a configurable means of sending and receiving time stamped packets. How you configure that radio, how you identify the sender and intended recipient of a packet, how you maintain your network structure, and what data you send is entirely up to you.
You can take the existing code and make the minimal changes required or you can throw it all away and start from scratch. As with the underlying driver this is a trade off between work required and how ideal the implementation is for your use case.
There is optional on chip packet filtering, this will require the radio packets you send to conform to an IEEE standard which includes certain restrictions on packet formats and headers such as unique ID, network ID etc… However there is no requirement that you must conform to this standard or use the hardware packet filtering. If you aren’t following that standard then the IDs required for it become redundant and you can use your own method of identifying things if you desire.
The chip does contain a factory set chip_ID and lot_ID. I don’t know off hand how unique these are, whether chip ID is unique within each lot or whether its more a device type ID.
On item 8 - while you can send additional data, I’ve implemented a serial link over them in the past, these radios aren’t optimised for bulk data transfer. Small amounts of data are fine but if you need to send lots then there is probably a better alternative.
