Hello, I am a student working on my diploma project. I am using the DWM3001CDK to implement 2D positioning for vehicles (Vehicles as controllers/tags and controlees / anchors). My aim is, to get the 2D position of the vehicles.
The vehicles use a ESP32 for control. To get the readings from the controllers (DWM tags), I have connected the DWM via the Raspi header pins to ESP GPIOs. I want to send UART UCI frames to control the conntroller (init seassion, get readings for ranging, …).
I have spent around 40h looking through all of the relevant docs, example codes (python scripts) and have concluded, that I have to change the firmware, to enable the UART GPIO interface. After changing the config file and bulding it, it still does not work. Interestingly enough, the UCI frames, that I send from the ESP, can be read at the J-Link port, when connecting to it with a serial monitor. Is it possible, that only the J-Link is listening to those ports?
What do I have to change in the firmware, to enable the GPIO UART ports / redirect from the J-Link? If more informations about my case are needed, I will gladly provide them. Thank you in advance.
Hi Christoph, I remember doing my diploma project and how frustrating these sorts of issues can be. I’ll try to help as best I can.
The DWM3001CDK is configured by default to use USB CDC (USB Virtual COM port) for communication and the UART over GPIO pins is disabled by default. You’re correct that you need to modify the firmware to enable the GPIO UART interface.
Confirming Your Suspicion
Yes, you’re absolutely right - only the J-Link is listening to those ports. This is exactly what’s happening because the firmware is routing all UCI communication through USB CDC by default, even when you send UART frames to the GPIO pins.
The USB_ENABLE Flag Relationship
From Section 5.5.2 of the manual, there’s this important note:
“The ‘UART’ command is not available when the compile flag ‘USB_ENABLE’ was removed from the project.”
This suggests the relationship between USB and UART might be more complex than just enabling/disabling them. When you modified the config file, did you completely remove the USB_ENABLE flag, or did you try to keep it while also enabling UART?
What the Manual Confirms About Your Problem
From Section 3.1.1, the manual confirms exactly what you’re experiencing:
“UART over USB (USB CDC ACM) allows for the communication with the MCU over USB connection, enabled by default” “UART allows for the communication with the MCU through the UART pins, disabled by default”
This explains why your UCI frames show up at the J-Link port - the firmware is routing everything through USB CDC by default instead of the GPIO UART pins your ESP32 is connected to.
Missing Information
The manual identifies your problem but doesn’t actually document the exact firmware changes needed to switch from USB CDC to GPIO UART as the primary communication interface for UCI.
Could you share:
Which specific config file you modified?
What exact changes you made?
This would help identify what additional firmware changes might be needed to get your ESP32 communicating properly with the DWM3001CDK via GPIO UART for your vehicle positioning system.
Thank you very much for your reply. I now have decided to work with the CLI interface, as recommended by my teacher. As you probably know, it is way simpler and allows a simple redirect to UART via command. If I have enough time left, I will maybe come back to this problem. A small question remains: If I want to get 2D positions from my tag (initf …), do I have to manually define the anchors mac’s and positions in the initf command, or is there some sort of automation available, to perform such actions?
Regarding your questions to the firmware I modified:
The answer is yes, you do have to provide the MACs, unless you plan on modifying the stock firmware. The initiator needs to know which boards it’s talking to. In the stock firmware, the default MAC for initf is 0000, and then default or respf is 0001. This means that if you’re trying to put 4 in the corners of a room (for example), the stock initf and respf commands won’t work and you’ll need the -multi, -addr and -paddr flags etc. Luckily the manual actually provides good information on this, e.g. Listing 5.3: Example of INITF command with multiple Responders INITF -MULTI -ADDR=0 -PADDR=[1, 2, 3]
I’m likely going to have to modify the firmware to dynamically allocate MACs myself, but it’s a bit of a complicated problem. The issue is that two boards with the same MAC will cause data collisions, so providing them all from the initiator means that you don’t get that. If you set the MACs on the responder boards with no knowledge of each other, you could get the same MAC on two boards (unless you knowingly hard-coded the board’s MAC).
I have already worked out something similar in the meantime. I now have a system capable of performing One-To-Many ranging sessions. Due to my system having 8 tags and not 1, I decided to use a slot-based approach.
So one tag starts a session with INITF -MULTI -ADDR=0 -PADDR=[1,2,3] -BLOCK=100, takes one ranging result and closes the session. Then the next tag does the same thing. I measured, that it takes around 190ms to perform one such cycle. This would total up to a cycle time of around 1,5s. I concluded, that it is not optimal but enough for my system, that every vehicle gets a position update all 1,5s.
The vehicles have multiple sensors with which I can calculate, where the vehicle should be. If the one performed measurement is not successful, such a method could be used to fill the gap.
Is there a better / more efficient approach, where I can get more readings? I already tried to reduce the BLOCK duration bellow 100ms, but that already is the lowest allowed value in the CLI interface.