the DWM3001_cdk is an nRF based host for a smaller board based on the nRF52833, not yet available but in sampling mode already.
Ideally, if the same code can run on all platform, it would help increase the shared code.
@exus-mu , if you have any preference or specific requirements, you can comment here and I would provide hints on how to share the dev effort if possible on different platforms. For example, is the size of the used dev kit important, do you need battery operation, would you prefer to use the Arduino IDE SW as a start or are you open the SES (Segger Embedded Studio) or Zephyr.
I took a chance and purchased: STM32F413ZH
I see I could have gotten a smaller form factor and would have been ok. I only ordered one so far. I’ll test with the first one and get the basics down before I order more.
@exus-mu I added a new section on the website to describe the DWM3000 evb
I just realized that In the Decawave product documentation there is a software with a quick start guide mentioning support of hw platforms nRF52840-DK which link I posted above and nucleo-F429ZI from the nucleo family I mentioned.
In the doc there is even a guide for building the API examples.
STM32 vs nRF
For info, I ordered a DWM1004C that is DW1000 with STM32 but I do not have a port of my meshposition to STM32 target yet. I might develop a simple app instead of porting the whole generic request based framework, or if I get STM32 running on Zephyr, I could then port the whole framework.
DWM1000 vs DWM3000
I’ve seen from Decawave so far only examples targeting the old nRF SDK from Nordic. The new Nordic framework nRF connect is using Zephyr, which is to me a huge win of integration time, I did work with the old SDK makefiles and config and won’t manage to afford that wasted time again. Someone ported the DWM1000 on Zephyr, that’s what I based my work upon. Now the DWM3000 decadriver needs the same porting work, but given the existing DWM1000 example, it should not be hard.
@exus-mu as you noticed Decawave suggested the DWM1001-DEV, for the reason that it’s more beginner friendly, which is true, but also because they provide the PANS lib with it which is a binary closed source solution to use out of the box without any line of code. For info that’s exactly the kit I have, I got 12 modules, and I tested their PANS solution which does really work out of the box, they even offer a raspberry pi gateway where you can solder a pi header and you get a node that transfers positions to an MQTT broker. But right away I realized that the closed source is very limiting and very simple things like taking range from 5 anchors becomes quickly impossible, that’s why I started developing my own. Developing your own is easy for learning but using it in a commercial scope or selling is out of scope.
I did not want to recommend the gen 1 DWM1001 as I assumed your decision to use the gen 2 DWM3000 family was made, but in case you’re interested in gen1 and have questions let me know, and if you have questions about the Decawave closed source PANS solution then you can ask on the forum, they give good support for it.
You can see at the bottom I even prepared 3d printed cases for a bigger battery format
I initially tried to go with DWM1001-DEV but the kits are hard to find. I was able to purchase 3 used but they are back order for several months. The more I dig and read, I’m starting to realize while the DWM1001-DEV will be easier to perform basic tests with, it will not allow me the flexibility I’ll eventually need. So, while it’s going to be a more difficult road for me, I think working through the code will be more beneficial.
I thought I saw somewhere initially where the code for DWM1001-DEV was open sourced by the manufacturer, but it sounds like that’s not correct.
Forgive my ignorance, but please clarify if these are incorrect:
-DWM1000 is flashed with a factory firmware that is not modifiable
-PANS is the library, code, that lives on the microcontroller to interface with the DWM1000 chip
-The micro controller can then communicate with an additional device to send the data received by the DWM1000, i.e. computer thorough USB port or across the network if the MCU has wifi or ethernet.
Pity you could not get enough of them. I understand the confusion, I’ll try to sort it out answering your questions. On the page I linked above I started gradually from the
Q : DWM1000 is flashed with a factory firmware that is not modifiable
A : Formulation is ambiguous. You cannot modify the PANS but you can of course flash your own firmware and flash the PANS back. First there is no DWM1000, subtle difference DWM1001C is the name of the module with Host + Transceiver. Host = nRF52832, Transceiver = DW1000. The Host nRF uC is fully accessible for flashing and reflashing. Decawave provides an example binary so called PANS in two forms, ready binary hex with all functions and a stripped down lib that you could include on top of a custom source code that you compile, but in that case you still won’t manage to change the content of the lib that talks to the transceiver. So you can very well alternate between your custom code and set back the Decawave PANS .hex when needed.
Q : PANS is the library, code, that lives on the microcontroller to interface with the DWM1000 chip
A : as above PANS in two forms full .hex and bin library. Yes lives on uC, interfaces the DW1000 not DWM1000, the “M” stands for module uC + transceiver.
Q : The micro controller can then communicate with an additional device to send the data received by the DWM1000, i.e. computer thorough USB port or across the network if the MCU has wifi or ethernet.
A : yes, the nRF52832 can do bluetooth and custom RF, no wifi. I’m using custom RF for a real time constrained protocol that I can combine with the ranging functions that are hard real time and need to be on a bare metal loop, so I had a trick to let them run on an os with the highest prio task.
So to summarize, the DWM3000 evb is equivalent to the transceiver part only. The DWM3000 evb + nucleo STM32 would be the equivalent of the DWM1001C except with nRF52 uC not STM32.
In the link above, I created a diagram that shows the inside of the DWM1001. PANS lib was built on top of ecos OS and the nRF has two SPI one to talk to the transceiver and one to act as a slave for an external Host like the rasp.
Makes perfect sense now. Does decawave provide partners the PANS lib source? I’m wondering their motivation for keeping it closed. I’m guessing they license it to partners to help their partners gain business in application development, thus they wouldn’t want to provide it freely.
We can speculate about it, I don’t think Decawave do not want to open it, I think they might be bound with licenses from third parties that provided it to them in the first place. Decawave have been taking many initiatives to provide open source examples, they provide ranging examples, which is the basis for positioning but do not have the advanced compensations for precise positioning and also does not include a TDMA protocol.
Also if I would be a partner, I would not need their source code as all the concept is so clearly explained in the documentation that implementing one with your own code basis might get you faster there with less dependencies and with your own integration and coding rules decisions.
After all, we can split the PANS in x3 main stages :
ranging, source code samples available
TDMA protocol, on how to split the time to know who’s ranging whom and when. I already developed a dynamic one even that can be set based on the request flexible even with an unlimited number of responders
Multilateraion, or how to turn many distances of a tag from a known position anchors into the tag position, lots of open source code exist for it, so only a matter of integration if you need to compromise performance over quality, but as I ported the ranging to python, lots of libs exist for that, and even if I need a high refresh rate, I think I can create a c++ app on the rasp that would be way faster than any uC implementation. Running Multilateration on the uC is really a special use case.