DWM1000 Cat Tracker

So I decided to try and graph the power consumption of my tags when ranging by hooking them up to a huge capacitor and sampling the voltage with an Arduino.

Pretty simple setup and it resulted in a very interesting graph of the voltage

This shows that the bottle neck is clearly the transmit, the 30 seconds between ranging's counts for essentially none of the battery usage. This means to increase my battery life, or shrink the battery size I'm using I will either have to push those further apart, which I am working on using a motion sensor to detect when to update the location because why update if the cat has not moved.

The other is to optimize power usage in the beacon cycle. My first though was to combine the 3 rangings into a single shot, though that could cut it in half, but when I zoomed in something else stuck out at me.

Two different slopes, it didn't make sense the entire ranging was taking ~600ms to do. So what was going on? Turns out my code is bad.

		if(mode == MODE_TAG){

			check_sleep = true;

			delay_ms(500);

			reenable_dwt();

			// TODO retry up to 3 times if ranging fails
			ds_twr_init(ancor1_addr);
			delay_ms(10);
			ds_twr_init(ancor2_addr);
			delay_ms(10);
			ds_twr_init(ancor3_addr);
			goto_sleep = true;
			sleeping = true;

		}

I am delaying for 500ms after it comes out of SLEEP! And whats worse is there is no apparent reason why I should do such a thing, it hasn't even started bringing back up the DWM1000! 58% of my power usage is just the chip sitting there doing nothing!!! FAIL!

Remove that 1 line of code should double my battery life. So how does it look after the code change is made?

A 55% change in voltage drop and instead of 600ms it only takes 80ms. Now instead of 44 days I should get 90 days out of the battery. Hopefully this plus motion sensing and combing the 3 ranging into a single shot will let me shrink the battery and also give it a year long run time.

This version of the project is coming to a close, after doing some power optimization and final stability testing I will be moving on to trying to use the AT86RF233 to do the ranging. Its cheaper, lower frequency, and has considerably lower RX current consumption. In a separate project I will be seeing how that works out, if its performance isn't as good as I like I may come back to the DW1000 chips.

I have a design right now that I'm hoping will last more than a year on at 10mm lithium coincell. It primarily saves power by using a vibration sensor so it only updates the cats position every 30 minuets or when they are moving. I'm also considering sending an "I'M HERE!" TX burst every 2 minutes for fast out of range alerts. Its smaller than the buckle on my cats collars. I'm calling it the YoctoTrack. Hopefully will have a project page up for it soon. The blue ring in the layout is 10mm in diameter. The whole board is smaller than a dime.

I have linked a repository with all the code and schematics if anyone wants to replicate my design or needs a reference to work off. There will be further posts detailing how to build/program/setup the server for this project. But the rest is really just a clean up and instructions, no new designs.

I have successfully tested the Micro version of the tracker. None of the WLCSP pins have shorted and they are all connected. I can attach the programmer and load a build on the chip. This chip has a smaller program memory of only 16kB so I had to make some significant changed to the code. Basically I ripped out everything but basic tag functionality, No UART, no re-writable settings.

You can see how nicely the balls came out. I used tacky flux and a small hot air tool to get it to settle into place after putting it down with tweezers. If you look closely at the above image you will see a 0201 LED with concealed pads on the bottom I also managed to get down with hot air. This minimalist design left me with lots of space on the bottom and I managed to shove my logo in there.

This design end up with a board no bigger than the DWM1000 Module that sits on it. The only annoying thing was I used a footprint for a LDO that has a quiesent current of 25uA where I meant to use one with sub 1uA. I will have to search Digikey for one with the same layout because I don't want to get more boards made and I want to minimize sleep current, and that's taking up a big chunk.

You may be wondering how I used a 0.4mm pitch WLCSP with OSH Park design rules. The answer is I cheated! I lose out on some GPIO but by just shorting them to the inner pins I had to route out the design still worked out.

I actually found the WLCSP easier to solder than a QFN, probably because I never use solder stencils but I did manage to make a board of the same size with the QFN version of the chip as well as some extra goodies:

After setting everything up and getting the tags on the cats I periodically went and found them to make sure the system was working. By watching them move around on the screen I found out some interesting new places they like to hang out. For example I found out Fiona started sleeping in my parents bathroom closet while my sister was in China.

What a silly kitten.

And I also found Jasper hiding under the bed. I would have never found him if he wasn't wearing the tracker. Even knowing exactly where he was because of all the crap under the bed I had a hell of a time spotting him.

I even set up a Raspberry PI to display where the cats where in the house in the living room so anyone in the house could have a quick look and see where they where.

I thought this would be a good place to mention why I put all this effort into tracking the cats. With my grandma in town for a few months and her prepensity for leaving the doors open as well as the many Coyotes roaming the open space around the house its necessary to know where the cats are to keep them safe.

The battery life is quite excellent with the 400mAh I am using. You can see the tag in the background here. The battery is about the same size. A bit big for the cats but based on measurements of the voltage over the time the cats have been wearing them it will last 106 days. Charging batters once every 3 months is a pretty good timescale I think.

The standby power was measured at 70uA. I am considering using a external timer to trigger the beaconing instead of the internal RTC and I could maybe get that down to sub 1 uA. Based on the battery voltage drop the overall current consumption is 330uA. So the device averages out to 260uA of operating current with its 30 seconds ranging cycle. Using an external crystal for system stability and increasing the SPI clock speed up to 16+ MHz should let me do the ranging in about half the time hopefully dropping the average beacon current consumption to 130uA. This would either result in a much longer battery life, or i could make the beacons come closer together, use a smaller battery or a combination of all 3.

As I mentioned before the current size is quite huge because the home made single sided PCB, but I have plans for a much much smaller board.

You can see I went a bit crazy and used a chip scale package for the processor. Its basically at the size of the DWM1000 module now. Tune into the next project log to see how the super minature tag works out.

After a lot of testing I've found it to be exceptionally accurate in free space but there are issues when signals have to travel through walls. With the anchors upstairs and the power maxed out I can just barley get full coverage of the house. (3 stories about 40ftx40fx)

The very first measurements I did showed a standard deviation of exactly 10cm. Right on the spec, however the absolute measurements where a bit off and I need to calibrate it on all the devices still.

So the results don;t really fit a bell curve but the standard deviation was 10cm and the worst overall difference was about 38cm. This is with the transmitter and receiver both just sitting in the same spots for about 30 samples. It was also a short range test in the basement. To really get a good idea of how well these work we will have to look at tests with all 3 anchors in place upstairs and the tag in various places.

In this image you can see the received points in various places in the house and the associated standard deviations. The lone red dots show the anchor positions. Some of the results are excellent. And some are oddly erratic. The best I can guess the erratic once must be because of duct work or other metallics in the way of the signal. There was never a sever deviation on all 3 nodes.

The Guest Bedroom Window in particular had quite the variation in its measurements to the BA5E node which is the furthest left anchor. The other 2 anchors had standard deviations less than 2 cm supposed to its 21 cm error. This results in a large amount of uncertainty along a line in 3D space.

The Livingroom Corner result was another oddity. Perhaps some one moved into the RF field skewing the results for a while. There appeared to be 2 relatively well matched groupings spaced slightly appart. I suppose it could also be a result of a sudden shift in the crystal frequency of the tag or the ancors, but that seems unlikely cause it affected 2 of the anchors rather than all of them or just one.

Overall the position reported was pretty much always within 30cm when it was working well, but when there were what I assume where multipath issues it significantly increased to up to 2 meters of error. It will be enough to know the cats are safe in the house and to figure out where they are pretty quickly.

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.

So after changing to the new microcontroller most things where the same. Same power supply, same RF module but as can be expected I made more mistakes.

Its a nice and clean single sided layout with only 3 jumpers.

First off, like an idiot I assumed remappable pins meant any pints for any function on any module like it is in most pic controllers with remappable pins. But if I had read the pin IO descriptions I would have seen that the SERCOM on these chips have spesific sets of pins they can be on with specific function muxes. Fortunately I was only off by 1. Cutting and flipping 2 traces on the SPI bus and I was golden. I got lucky that the UART was ok.

The second issue was with the charge circuit. I noticed it drawing more current than expected to charge the battery so I took a look at the schematic and the FET/Diode I was using to switch to external power. When I had drawn the symbol for that part I had neglected to draw the body diode of the FET. I had the battery on the wrong side and it was letting current from the 5V USB rail flow strait into the battery. Well that was just great no battery for this board.

Finally I was experiencing periodic issues communicating with the DWM1000 over the SPI bus. It wasn't responding properly to commands. My best guess was some kind of reset issue. You can see the bodged in an NPN transistor for the reset line of the DWM1000. I tried to just assert the IO pin low but in sleep mode it caused issues so the NPN.

I also printed a nice case for it that slides together. Sadly the API command to enable the DWM1000 LEDs didn't seem to work. No blinks.

Overall it came out quite nice. I did have some strange issues with the soldering on the QFN. I've never really had issues soldering QFN's but this time around I did have some strange bugs. I recently switched from using leadless to leaded solder after reading a nice long NASA paper on the subject and it was quite finicky. Normally I tin the pins and then drop it in place with the hot air but it didn't seat quite right. That might have just be the lack of solder mask. But then I went back and bumped each of the edges with some leaded solder and flux and got most of the connections looking solid. Inspite of this there where still some issues with contact and I found I got the UART working again after I pressed down on the solder fillet on the edge of the chip with one of my multimeter probes. All worked out in the end.

So its always nice to start off a project with a nice fat failure. It would have only taken 10 minutes to compile the DWM1000 library for the pic I chose to see if it would fit in its program memory and of course I waited until after I made the board to see if the code would fit.

Fortunately didn't populate the expensive hard to desolderer radio module yet but I had to look in my micro-controller drawer to see what else I had.

I was a in a bit of a hurry for this design because my sister was going to China for 2 weeks and I was trying to get the trackers made in just a couple of days so she could see where in the house the cats where on her phone.

Anyway after looking through what I had on hand a ATSAMD20 seemed appropriate for the next attempt.