Close

The Software

A project log for DWM1000 Cat Tracker

Using the DWM1000s amazing ability to pinpoint tags to within 10cm we will track the cats positions in the house with amazing precision.

dryerziniaDrYerzinia 06/28/2016 at 03:331 Comment

So this was only the second time I've used the Atmel SAM devices and I have to say they are starting to grown on me. I have to say the ASF is a pain in the ass, its hard as hell to find the details of the modules for the version of the ASF your using cause its changed so much and there are so many document versions and I had to go digging through source code to figure out how to work some of the modules. Microchip is a lot better in the way the integrate there peripherals code into there datasheets.

On the other hand the ARM architecture has some nice benefits the best of which seems to be MHz per uA and the ability to run on a nice low 1.8 volts, there are only a few PICs that can do that and they are not very powerful.

All the programming was done with the ATMEL ICE and OpenOCD as the debugger running under Arch LInux.

I worked my way up slowly. I verified the output of the SPI bus and all the voltages on the DWM1000 pads before it was soldered. Don't want to damage a 25 dollar module. Once that was all in order I installed the DWM1000 and tried reading the DEVID. It came back 0xDECA0130, nice no problems. From there I went to simple send and receive communications and then to ranging. The DECA API examples where quite well commented and easy to follow. I was up and ranging with only minor tweaks.

The main software issue I had to work through was the SPI timing. Too slow and the readings aren't as accurate as they should be. The interface in the example was speced to run at 20MHz in operation but the waveform I measured coming out of the chip when using the DFLL to boost the core clock to 48MHz to get the SPI up to 20MHz looked like absolute garbage. Ultimately I settled at running it at 8MHz, had to add a bit more delay to the send and receive to get it to work. Initially there was a ridiculous delay between bytes showing up on the oscilloscope. This was due to some serious overcoding of the SPI module in the ASF. The check everything you can check to be wrong and like Santa Clause they check it twice! I had to dig into it and figure out the bare necessities and use that instead. After all that work I had everything running at a decent speed.

Just getting the DFLL running was its own bag of tricks. Took a lot of googling figuring out how to set up the clock configuration. The need to set flash wait states to 2. However after a lot of long term testing running the DFL at full 48 MHz proved to be unstable on some chips. 3 of the 5 devices where quiting on me after a few hours to a few days consistently. I looked at every possible cause, brown outs, trying to capture it on the debugger but I couldn't get any definitive answers. So I reprogrammed it to just run off the internal 8MHz oscillator and the problems disappeared. This required a bit more delay in the ranging but not enough to affect performance significantly.

Up next I'll be positing some measurments of the accuracy.

In the future when I have some time I'll write up some detailed instructions on setting up the build environment and using the ATMEL ICE and adding a link to it here.

Discussions

Sara wrote 04/17/2017 at 05:58 point

Hello,

I'm working on DW1000 too, but the chip what I used is Nordic nRF52 with DW1000. The problem what I met is the same as you, the SPI timing.
In nRF52, the maximum SPI data rate is 8M bps, is slower than the original one (20 M). I know the problem is due to the slow SPI, but I don't know how to really solve this problem.
If it's possible, could you share your experiences or give me some hints about this problem?




Thanks.

Sara

  Are you sure? yes | no