DWM1000 not sending data to raspberry pi 4

Hi, I’ve been using a few DWM1000s for a university project. The goal has been to set up some basic UWB ranging. We have been testing with two and using two raspberry pis (a 4 and a 5) as microcontrollers. We have been using a standard git library for python testing. However, we have not been able to get anything back from the DWMs beyond “FFFFFFFFFF” in various forms. Our most recent testing with an oscilloscope revealed that the MISO pin is never being pulled down. What the reason for this is, we are lost on. All the connections we have made are good, the wiring pretty straightforward (I’ll describe it below), and the code doesn’t seem to be explicitly wrong. We are lost on what we could be doing wrong. Some things to note are that the CS line seems to be getting 3.3 volts from the chip, which we can’t explain. It seems to still function correctly when we test it under the oscilloscope. We also have no resistors or capacitors between any of our pins. Finally, we have individually tested 3 chips, all with slightly different setups, and we have gotten the same problem with each. Thanks in advance!

RPi: GPIO5 → DWM1000: CS
3.3V → VaddON and V3.3
GND → VSS/GND
MISO → MISO
MOSI → MOSI
SCLK → Clk
GPIO12 → IRQ
GPIO 21 → RST
GPIO 20 → WAKEUP
GPIO 16 → EXTON

Did you read the bit of the data sheet telling you that the reset pin shouldn’t be driven high, it should only ever be connected to an open drain driver?

Remove all the connections other than the SPI bus, power and ground. The rest aren’t needed for basic comms.
Set the SPI bus speed to 100kHz.
Drive chip select low, send 5 bytes of 0x00 on the SPI bus and see what you get back.

If all you see is 0xFF (which should be the default idle state of the bus) then you have a fundamental issue with the part, either it’s not connected correctly or it’s not getting power.
You checked the MISO line and it’s always idle. Did you check the other SPI lines? Are the clock and MOSI lines acting as expected? Is their timing correct relative to each other and the falling / rising edges of the CS lines?

As a side not generally a Pi running python is not a good choice of host. You can certainly go that route if you want, for a university project it’s good enough. But you’re not going to get the best in terms of accuracy or update rate, it’ll be too slow and variable in timing for that. UWB ranging doesn’t need much processing power but the faster you can respond to things the better, neither linux or python make for fast responses.
But it does give you something to put in possible future improvements part of the write up :slight_smile: