Get started with the DWM3001CDK UWB module

[Geogouz]

I ended up having many DWM3001CDK UWB modules mounted on RPi's Zero 2 on hand, and I would like to get started with programming them. Since there is no PANS available for them and since, eitherway, I want to do actually mesh ranging, I would like to ask for any guidance for doing that. I have no clue where to start from.

[wassfila]

Hi @Geogouz ,
You probably landed up here out of the page
https://www.homesmartmesh.com/docs/microcontrollers/nrf52/dwm3001_cdk/

As I suggest in the FAQ section there, it is always good to refer to the official forum, where you can get answers from the company employees and sometimes their partners.
https://decaforum.decawave.com/

But that really depend on your background. If you're working on a big company, startup or developing a commercial product under budget pressure, the official forum is the right place. You might even seek support from one of the partner companies. Now of course that implies huge budget, but even that is nothing compared to the budget needed to develop your own core uwb algo, you might need a big Dev Team for that.
UWB is a young industry that is not much into open source software like Linux, npm, pip,... So if you're an academic researcher under budget constraints or a hobbyist that wants to develop an own DIY devices, you might get stuck same as I was, that's why I started the website and tried to connect people who want the same thing, which is open source ranging algos. Keep in mind that UWB is also subject to certifications which also excludes any DIY from being a viable commercial product.

That being said, my approach was to split UWB into a stack of two layers, the uC layer here specific to nRF52 with code in this repo
https://github.com/nRFMesh/sdk-uwb-zephyr
I also have a discussion section for support specific to nRF52
https://github.com/nRFMesh/sdk-uwb-zephyr/discussions
And the app layer that is uC independent and is wrapped with Python, with the originality that the ranging sequence is not hardcoded in the uC layer but transferred as a request from the app layer, which result in incredible flexibility (but also a certification nightmare in case you need to) ideal for research and concepts
This is the related repo
https://github.com/HomeSmartMesh/mesh_position
And discussions about it can stay in the 'Ultra Wide Band Category' of this Discussions

I wanted so much to have the DWM3001C, but it was not available at the time I started by UWM investigation, so I had to fall back on the DWM1001C. Because of that I had to develop my own Simple Mesh algo.
The concept of my network does not rely on Bluetooth like the demo Decawave project for backend device to device communication but uses the simple Mesh which is a custom DIY mesh protocol. With the DWM3001C, it would be possible to get rid of it and use 'Thread' 802.15.4 instead.
For other projects like the Thread Sensor Tag, I developed Thread based applications, samples are here
https://github.com/HomeSmartMesh/sdk-hsm-sensortag/tree/main/samples
There is also located the simplemesh_dwm1001
But the main firmware that runs on the UWB modules is the generic node combining both simple mesh and uwb
https://github.com/nRFMesh/sdk-uwb-zephyr/blob/main/samples/06_uwb_node_sm/src/main.cpp

It's been almost a year since I did not check updates on the survey of available UWB software especially for the new DWM3001C, if you find more references, let me know and I'll add them here
https://www.homesmartmesh.com/docs/networks/ultrawideband/#software-survey

Depending on your background, you can tell me more about your scope and see if we can collaborate and also keep my contribution potential clear not to give you false hopes.

[Geogouz]

Hi Wassim, as you correctly guessed, I landed here from your website homesmartmesh.com . Also, I am currently indeed pursuing a PhD with my background being in Geomatics engineering and thus, unfortunatelly far from embedded systems at all. Yet, I am lucky enough to currently have access to a quite big swarm of DWM3001CDK's attached to an RPi Zero 2 (namely 40 pieces). Therefore, I have a nice opportunity to make use of them for my work. My main interest/work lies mainly on the theoretical/localization-model side and not the practical one (and thats why I assume I have ended up being even more stuck as you had been due to the lack of background knoweledge there). I am specifically working on the development of a cooperative localization methodology based on a probabilistic ranging model of the underlying technology used. This is actually technology agnostic (as long as one can model the ranging likelihood). Based on already conducted experiments using BLE signals, I have seen accuracy improvement with the increase of the nodes and thus, the more nodes I use for the cooperative localization, the better actually. Knowing just the basics about UWB, I am really interested to try to apply my method there and see how the number of nodes can affect the overall accuracy. However, I am stuck on the fact that I should most probably have to develop the firmware myself to do that. From what I had noticed, PANS only allows you to perform ranging with a specific maximum amount of nodes, however, I would be interested to even have a system of 40 UWB nodes doing range with all other 39 nodes (i.e. a fully connected system). To keep things simpler, I would be interested into basically the least sophisticated random access protocol that can support 40 UWB nodes communicating with all others.

[wassfila]

Hi @Geogouz ,
Now I understand, your situation is one that could make sense of a collaboration. I also had discussions with a Master student some time ago to whom I provided support related to my UWB code.
A bit about myself, I had a Phd in a Robotics Lab in the Past now working in industry, in my free time I like to contribute to open source and I have projects centered about home automation but range from sensors and microcontrollers till web app development, graphs and data management.
I went through multiple ways how projects can be communicated to the public to enable social interactions, I was not always successful with it. Started with Hackaday, then hugo static websites. Discussions went from Discord that is a closed platform to discourse that I'm discontinuing now because it needs yet another account, I'm settling now on github with its wiki and Discussions.

The limitations of the PANS is the exact reasons why multiple researchers abandon it very early in their investigations (you can many posts about that in their Forum). The scaling to a random ranging sequence participants list was built in the core concept of meshposition. Now we also have to be cautious, even if it's working and tested, it's only a Proof of Concept and have limitations, the custom RF is not mesh yet but start as functionality porting from previous gen is missing, other people tried BT, but BT one to one is also not interesting, BT Mesh is possible but technically challenging to integrate. So even if you do not end up using the meshposition framework I developed, you can take it as a reference to explain to others how an open API UWB framework should be.
I migrated one post from the previous forum to github wiki
https://github.com/HomeSmartMesh/mesh_position/wiki/Python-UWB-REST-API

It's a bit redundant to the website page
https://www.homesmartmesh.com/docs/networks/ultrawideband/
But I think the github wiki is faster to update and does not need as much cleaning and organization, so I'm also kind of less maintaining the website and focusing on bringing data around each github repository with its tickets, discussions, wiki

So have a look at it and try to understand every line of python code, to be aware of the potential, the embedded firmware would come at a second stage. You have to clearly communicate to your advisors that an UWB firmware is not just a piece of code, some people buy it with tens of thousands of dollars/euros. If it is accepted to be used in draft condition, it still hardly the job of the same person that also takes care of the high level algo. Yet, if you have no alternative that to develop firmware yourself, I can give you hints how to get proper initiation, that will cost you training time in the beginning but that time will be paid back as you'd be autonomous in the test/debug/fixed phases.

The firmware I developed is one node to do everything (initiator / responder) and it is based on Zephyr. To put it shortly, Zephyr is developped by the Linux Foundation and is the new Linux Like for microcontrollers. Using the nRF-SDK few years ago took me ages (Months) to get one sample up and running, while Zephyr has achieved a correct abstraction between drivers and platforms and allow to put a project together in an afternoon, given that all drivers and hardware are supported in Zephyr.
https://github.com/nRFMesh/sdk-uwb-zephyr/tree/main/samples/06_uwb_node_sm

Also keep in mind to have a clear strategy on what you openly communicate and what not, I think that open source UWB firmware brings nothing to research but the algo logic does. We still can discuss in a closed repo about some topics, but the one related to firmware I think can stay open as they might benefit to lots of people in your situation.

40 DWM3001CDK's is excellent. The RPi Zero is not powerful enough I think, and even if other frameworks rely on the Raspi being real time, e.g. the PANS demo only works on Raspi 3 version with 100MBit not the 1GBit due to latency issues, the simplemesh does not even need any middle system like Raspi, as the main PC can have a node that directly communicate with the network. So you would only need a Raspi if you have to leave your system running permanently and want to reduce power consumption

[Geogouz]

I would indeed prefer to avoid reinventing the wheel. Therefore, making use of your prior work based on Zephyr sounds very tempting and the way to go for me. However, I still foresee a big learning curve because I am not only new to Zephyr, but even new to any RTOS. Plus, meshposition is designed for another set of hardware and thus, I don't even know what kind of changes should I expect to be required for the project to enable support for my current hardware.

Moreover, the reason why I still need the small individual RPi nodes is that the localization algorithm that I want to experimentally implement is completely decentralized. Simply said, within this fully-distributed cooperative localization, every node is locally calculating its position based on the ranging measurements from the other nodes.

[wassfila]

Yeah, makes sense, anything you feel comfortable with can be a good start. Afterall, the meshposition has two parts, a pure Python PC part and a uC or uwb node part. Even if the uwb node is totally different, the pc python part could inspire you how to automate ranging tests. I have to admit the uwb is a bit tricky, and even if Zephyr does the hw abstraction for you, it is not a beginner environment. So, if the ranging time does not matter to you, as you do not target a commercially usable grade product, you can use the simplest 2 nodes only ranging program then keep repeating across different nodes. With Rpi, you have wifi so no mesh back channel problems.