I’m writing an application that implements distance measurements between two (or more) devices that act as both initiator and responder in TWR.
I’m a little stumped because I have managed to get my application working on the dwm1001C development board; however, when I ported this over to my own hardware Everything seems to work except for UWB transmit and receive (I even get a TXFRS event indicating the frame sent).
I think that the solution lies in programming the OTP memory because the only difference I can see between the two systems are the values stored there. I haven’t been able to find information regarding which addresses to program and how to determine what values to program. I’m fairly sure I have to program 0x19 (CH5 TX Power Level PRF 64), 0x1C (TX/RX Antenna Delay) and possibly also 0x0E.
If anyone can explain how to calculate appropriate values for these or at least nudge me in the right direction (there’s a good chance I’ve missed something right in front of me) I would be very grateful.
The values you put on the OTP only matter if your firmware reads the OTP and uses the values stored there. You can completely ignore it in your code if you want to. Obviously if your code reads values from there to set things like the transmit power then you will need to program it correctly but it may be easier for development to skip the read and hard code the value.
You say you have moved to your own hardware, are you sure your issue isn’t with the hardware? Did you use the DW1000 chip directly or did you use something like the DWM1000 module?
If you used the DW1000 chip then it is incredibly sensitive to board layout, power supply noise, clock sources etc. If you have an issue with the board design then you could easily end up with a system that looks to be working correctly from a firmware perspective but doesn’t function correctly on the RF side.
I see. So instead, to set the transmit power for example, I can simply write directly to register 0x14 and there is no need to touch OTP address 0x019 (unless I explicitly want my firmware to load the values found in OTP memory)?
That’s a very good point, it’s increasingly looking like it is a hardware issue. I think I’ve exhausted my list of firmware debugging options at this stage. I have used the DW1000 chip directly on my hardware, and using the same antenna and nordic chip as found on the module
Thank you again, Andy. That was super helpful - very much appreciated!
One simple test to do is to put the DW1000 into carrier only mode and check the output on a spectrum analyzer. You should get a nice clean narrow spike at your center frequency.
If you are using a crystal and the spike is slightly off the correct frequency then use the crystal trim register to get it as close as you can to correct. You will need to do this for every unit.
If you see lots of harmonics and side spikes on the plot then that is a sign that you have hardware issues.
If your commercial / confidentiality requirements allow you can post the relevant sections of the schematics and board layout here and you’ll probably get lots of feedback on it. Probably best to do it as a new post with more appropriate title.
The main areas to check are the power supplies into the power amp pins (the two next to the RF output) and the clock source (if you aren’t using a crystal then the cleanliness of the clock can be a big issue).
Failing that the design guidelines and application notes are a good starting point. As are the schematics and board layouts of the decawave modules where they are available.
You may notice that none of the schematics exactly match, the design guide and various modules all have minor differences. Any of them will work but the recommendation when this was last raised was to go with the most recent module where possible, the changes were all to give minor incremental improvements.
Many thanks for your help, I do appreciate it. You were right, it turned out to be a hardware issue. After the fix, my device is now able to transmit and receive UWB frames.
Apologies, I just have one more question. I am having issues with getting delayed transmission to work on the responder side. I’ve tried playing around with the delayed send time but with no luck and all of my SPI transactions seem to be working correctly so I don’t think the issue relates to register access.
I’m seeing HPDWARN and TXPUTE events sugesting that there’s a timing issue but at this stage I’m running out of things to try. Is it possible that a hardware issue could also be affecting this? Again, this worked perfectly when I programmed it on the development board but not on my hardware that uses the same Nordic nRF52832 processor.
Personally I’ve not seen any hardware related issues with delayed transmit. The only issues I’ve had with it have been when a poor reception gives me an invalid time stamp and so I schedule the transmit for the wrong time and have to wait 16 seconds for the timer to wrap around.
I caught that issue by comparing the RX timestamp and the raw RX timestamp and rejecting ones with over a certain difference.
I suppose hardware issues could make things like this more common.
Thanks for getting back so soon! That’s interesting, I’m not sure that’s what I’m seeing since all my response frames are simply being dropped before anything can happen, but it definitely sounds like something to be aware of.