Asset Tracker

The CAM M8Q is the heart of the Asset Tracker and what a great GNSS engine it is. Even though I am using the minimum recommended pcb board dimensions the chip antenna on the CAM M8Q is really superb. I have been able to track cars around town with little trouble and even get 3D/DGNSS fixes at my workstation indoors, albeit after a ~20 minute wait.

Still, there are many applications where good enough really isn't, like keeping track of vehicles in a crowded construction site, or when the Asset Tracker is inside of a container, etc. Even in my tests so far, having to wait twenty minutes for a fix is a real power waster. It is best to be able to keep the CAM M8Q on for as short a time as possible to get a fix, and to ask for a fix a very few tmes a day to have any hope of keeping the Asset Tracker going for a year or more on a LiPo battery, which is the project goal.

For these more practical cases, I need to have a means to increase the sensitivity and what better way than an active antenna. The active antennas themselves are cheap and easy to use, the hard part for this project was figuring out how to allow either use of the chip antenna or an active antenna without having to solder 0 Ohm jumpers or otherwise fuss with the board. With the help of the u-blox forum I found an elegant and effective solution, which I will now describe.

The solution requires use of an RF switch which also has an embedded LNA (low-noise amplifier) that allows automatic detection and RF path switching when an active antenna is attached but otherwise routes the chip antenna output to the CAM M8Q RF input. There are a few of these switches around, some embedded in SMA connectors; I chose the MAX2674 (actually recommended by u-blox) because it is small, cheap, and easy to use. It is a 2 x 3 WLCSP (SMD wafer-level chipscale package) so some surface mounting experience is required to make use of it. Here is the schematic for the MAX2674 that I used (basically a copy of the reference design, of course):

There are 100 pF DC blocking capacitors at the CAM M8Q ANT and RFIN pins; in addition, there is a matching 88 nH inductor in series with the DC blocking capacitor for the CAM M8Q chip antenna. I could only find 91 nH inductors but these work just as well. I am not sure how sensitive this choice is but it is a little concerning Maxim chose to specify 88 and not 80 - 100 nH, for example. I will try to find an 88 nH inductor. I have noticed it is often the case that passives are specified in reference designs that can't be found by mere mortals!

The MAX2674 power pin is bypassed by a 10 pF capacitor. The RF switch and LNA require power, but the MAX2674 also powers the active antenna which can draw quite a few mA, so this adds to the average power usage and somewhat offsets the shorter time to acquire a fix. Lastly, there is a shut down function that can cut power to the MAX2674 to 10 uA. In this design, I have connected the shutdown pin (via a 25 K resistor and 39 pF DC blocking capacitor) to the CAM M8Q LNA_EN pin. The LNA_EN pin is set to HIGH (3V3) when the CAM M8Q is in active mode and is set to LOW (0 V, I added a 100 K pulldown on LNA_EN to be sure) when the CAM M8Q is in power down mode. This ensures the MAX2674 will be powered off (and use 10 uA) even when an active antenna is attached as long as the CAM M8Q itself is sleeping.

On the Asset Tracker, board space is tight, but this solution requires a very small footprint:

It's not great to have 90-degree turns in an RF feed but this is the only reasonable way I could find to make this solution work. At the bottom of the image is the CAM M8Q. Left edge in the middle is the shut down passives and LNA_EN connection. The MAX2674 power pin bypass capacitor is between the CAM M8Q ANT and RFIN traces. The active antenna connects to the uFL connector using an uFl-to-SMA cable adapter that can be mounted on the side of the container for the Asset Tracker, providing a clean and compact solution.

How does it work?

Well, with just the chip antenna, it takes ~20 minutes from cold start to get a 3D fix when the Asset Tracker is connected to my laptop with a USB cable and an FTDI connector and sitting between the laptop and the window next to my workstation (indoors, of course!). This is great performance for a 20 x 45 mm pcb.

With the active antenna connected, it takes ~2 minutes from cold start to get a 3D fix and <4 minutes to get a 3D/DGNSS fix with HDOP < 1 meter.  Both solutions see about the same number of satellites, it's just that the signal strength without the active antenna is about 10 dB lower overall.

So adding an active antenna makes a very significant improvement for just a few dollars extra BOM cost. It is really great to have the option now depending on the use case, but I can see I will get spoiled pretty quickly with this kind of performance!

07/08/2017

Test 3 of the Asset Tracker went pretty much the same as Test 2 except I got almost twelve hours of continuous logging but otherwise I see the same kinds of corroborating data along with absolute position from GPS. The one big difference was power consumption. First of all twelve hours is the longest I have gotten the Asset Tracker to run on any LiPo battery, in this case an 850 mAH capacity battery fully charged. But according to the battery voltage data:

the battery was only down to 4.00 V after the 12 hour run. If I assume a linear drop off to 3.7 V this would mean about 36 hours of run time at an average current of 24 mA. Still much larger (by about 2x) than I expect but much better than the ~50 mA I was measuring when I had neglected to disable the ESP8285.

I ran another power test with a fully-charged 350 mAH LiPo battery and the Asset Tracker lasted for exactly 20 hours for an average power usage of 17.5 mA; now that is more like it!

In addition to disabling the ESP8285 I enabled stillness mode on the EM7180, which allows the EM7180 to put its sensors to sleep when it detects no motion. I verified that this works by noting on the TFT display during the test that if I picked up the Asset Tracker or nudged it a bit, the yaw, pitch and roll would respond and keep changing slightly after the nudging stopped, but after a few seconds would freeze to fixed values.

So for the car logging application I am nearly done. At 17.5 mA average power I can get 48 hours of more or less continuous logging of vehicle (or animal) motion in a small, wearable package. Car tracker, cow tracker, cat tracker...

And the CAM M8Q is doing what I asked it to do:

It is taking 5 - 10 seconds of GPS data (I am showing pressure and altitude here but my STM32L432 program only records data if there is a GPS pps pulse--a valid fix--as another low power strategy) every minute like clockwork (twenty minute scale above) with ~1 minute of satellite acquisition and ephemeris update every ten minutes.

The Asset Tracker + size-matched 850 LiPo battery is about the perfect balance of location/time resolution for fast moving objects (5 - 10 seconds per minute) and power usage (48 hours). But not logging capacity, since 48 hours is only ~3600 out of 65536 pages. Maybe I just need a 1 MByte SPI flash...

The next class of application is the Sentinel or Security Guard, if you will. In this case, the Asset Tracker needs to acquire a fix once an hour or once every eight hours and report via wifi to a server that all is well. Also, if the Asset Tracker detects that the object is moving it should alert by sending a wifi alarm. In this application 48 hours is not going to do it. If the Asset Tracker can last 48 hours with an 850 mAH LiPo battery updating its location every minute I would hope that it could last, say, 120 days reporting its position every hour and 1440 days every twelve hours, etc.

In some applications like this, say, monitoring cargo containers at sea, the device reports its location once per day and is expected to remain active for years. Here is an example of 18 months of twice-per-day tracking using an 8800 mAH battery. This is less than the longevity I am projecting with the Asset Tracker. Of course, I haven't factored in the power required by the ESP8285 to send state information/data via wifi, nor have I actually demonstrated this mode of operation, etc. Lot's to do...

I usually set up a web server to report data via wifi from a remote sensor with an embedded ESP8285 but the web service times out after 30 seconds or so of non-activity and this is not a good match to this kind of infrequent reporting anyway. Better would be an ESP8285 dongle attached to a laptop that can receive UDP messages and store them on its internal 1 MByte flash memory and/or send them on to the serial monitor for continuous observations, like might be done in a plant security control room.

07/07/17

I am continuing to learn how to get the most out of the Asset Tracker, and I will report on the successful second test below.

First I want to report that I found out why the average power was measured to be ~50 mA in the initial testing. I forgot that I have pulled up the ESP8285 enable pin with a 12K resistor such that the STM32L432 connected to the ESP8285 enable pin has to set this pin LOW to disable it. So for all of these tests (including the one described here) the ESP8285 was enabled in whatever default mode it comes in as an IC from the factory; I haven't programmed it yet. So I will repeat the average power test with the ESP8285 disabled using the unfairly-maligned 350 mAH LiPo battery and I should expect to get average power usage more like ~10 mA or less.

For the second test I again took advantage of the test daughter's errands and packaged the Asset Tracker with an 850 mAH LiPo battery partially charged to 4.02 V in a small plastic box like so:

I was in a rush so the device wasn't "warmed up", meaning it took some time for the CAM M8Q to acquire its first fix, which didn't occur for ~twenty minutes or so after the car left our house. I know this because the first recorded data are at an elevation of 244 feet, which puts the location somewhere in Pleasanton, about 15 miles away from our house.

This time I obtained a little more than six hours of uninterrupted data, and I recorded absolute orientation data (heading, pitch, and roll) as well as pressure, temperature, time and data, battery voltage as well as latitude and longitude.

First the GPS position tracking data:

At this scale it looks impressive but there are several places where the trajectory is clearly not on a road or where there are gaps like here:

This is mostly due to the 5/60 duty cycle of the GPS periodic mode I chose, and this is a reasonable balance between following the location and conserving power. I can see that the car turned right from Concannon Blvd onto Holmes Street, etc even though some details of the trajectory are missing.

The goal of the Asset Tracker is to allow tracking over long periods of time. If I can get the average power down to ~1 mA then with the size-matched 850 mAH LiPo battery I could track an object continuously in the above manner for a month.

The temperature data show the Asset Tracker has no trouble functioning at elevated temperatures:

The pressure and pressure-derived altitude show the same elevation changes noted last time that make a nice complement to GPS position data:

The absolute orientation data is interesting as well:

Since I know that driving times are relatively short in this six-hour record compared to parking times (a fact I could also ascertain by correlating GPS position and heading changes) the more or less constant heading portions of the data are when the car was parked. Pitch and roll are uninteresting until the end, when on return to the house the car has to climb a steep, winding hill and then turn down a steep driveway.

The original idea of including an absolute orientation sensor on the Asset Tracker was to allow dead reckoning for those times when a GPS fix could not be acquired. This occurs in urban canyons and when driving through tunnels, etc. Dead reckoning with inertial data alone is pretty hard to do accurately for any length of time just because the error from the double integration of the linear acceleration to get relative distance grows quadratically with time.

Even though I am using the car as a test vehicle here the end application is for high-value, stationary capital equipment where the goal is to detect when an item that should stay put has moved. This could be a vehicle on a construction site, high-value tools in a tool box, or some other object subject to theft or other misplacement. It could also be tracking high-value items through the production process at different locations in a plant. In all of these cases, dead reckoning is less of interest but the absolute orientation of the object might be more interesting, and detecting if the object had been tipped over, or dropped on the floor (via the acclerometer), encountered large magnetic fields, or elevated temperatures, etc. could be useful.

Bottom line, the Asset Tracker represents capability that has to be configured and managed (i.e., firmware has to be written) to meet the needs of disparate applications. The tests here are simply to understand what kind of data is available and the best way to approach some of the potential use cases.

July 5, 2017

Here I describe the first practical test of the Asset Tracker after simply verifying that all of the components (except the ESP8285) work as expected and that pressure, temperature, altitude, latitude, longitude, and yaw, pitch and roll data are properly available to the host and can be written to the 16 MByte SPI NOR flash.

The flash has 65,536 pages that hold 256 bytes each. I constructed a data packet of 32 bytes such that I can write 8 segments of 32-byte data per page. The 32-bytes is enough for most (but not all) of the interesting information. In this first test, I sacrificed pitch and roll to stay within the 32-byte segment limit. I also chose to write data to the flash every ten seconds. At this rate, the flash can store 90 days worth of data!

In this first test, the questions I want to answer are simply 1) can I get data logged to the flash and 2) can I meaningfully interpret the data?

I had previously tested the battery life using a 350 mAH 1S LiPo battery and found even with the ESP8285 disabled (there is an STM32L433 GPIO connected to the ESP8285 enable pin so it should be completely disabled unless I specifically enable it in the code, which I did not so far), the CAM M8Q in periodic mode with a 5/60 duty cycle (seeking a fix for 5 seconds every 60 seconds, in sleep mode otherwise), and the STM32L433 in STOP mode unless servicing quaternion updates from the EM7180 at 10 Hz I could only get about seven hours of life, or an average current usage of ~50 mA.

The CAM M8Q uses ~25 mA when active so should use ~3 - 4 mA on average in periodic mode. The STM32L433 uses << 20 uA in STOP mode and I chose to set the CPU clock to 4 MHz which similarly saves on power even when the STM32L433 is woken by interrupts and placed back into run mode. The ESP8285 should draw very little power, but I need to verify this. The EM7180 + MPU9250 + MS5637 should require ~10 mA according to separate tests so I am somewhat at a loss to understand how the average power could be anywhere close to 50 mA. This seems much too high to me and I suspect there is something wrong with the battery, like it is only taking a partial charge due to age. Still, six or seven hours is long enough for the first test and I took advantage of the fact that my daughter was heading out the door to go watch fireworks to ask her to drop the asset tracker, placed in a plastic bag inside a mailing envelope with a partial battery charge on her dashboard for the evening...

The following day I retreived it from her and was pleasantly surprised to find lots of data on the flash. Here is some of what I found:

There is just over six hours of data but there is a curious two-hour gap, so really only four hours of data. It looks like the data stopped as the temperature rose above 100 F. The daughter reports she had to park the car away from its usual spot and that it was exposed to the setting sun so this could be a case of overheating, although all of the electronics are rated to at least 85 C (max temp shown is ~40 C) so this explanation seems suspect. In any case, the device recovered as the temperature dropped. Perhaps the GPS signal simply skipped two hours, I don't know what to make of this gap. Turns out the Air Force is monkeying with GPS the entire month of July and the gap could be a result.

Looking at the pressure:

it is clear that the pressure at first increases as the car descends from the 1050 foot elevation of our house to the relatively lower levels (~300 feet) of the 680 freeway, then spikes as the car crosses the Benicia bridge both at the 02:00:00 and 06:30:00 marks. The bridge is just ~100 feet above sea level. All during the experiment the pressure is slowly but steadily rising. Upon return home, the pressure is higher by a few mbar.

Perhaps surprising compared to the absolute positioning afforded by GPS and absolute orientation afforded by the EM7180 (which data I have not yet analyzed for this experiment), lowly pressure data holds a lot of information about the Asset Tracker's movement.

Of course, this pressure data would be much more difficult to understand without the GPS position data:

This map was fantastically easy to generate by simply cutting and pasting the latitude and longitude data from the spreadsheet, itself taken from cutting and pasting from the Arduino IDE serial monitor and clicking "map" on the www.GPSvisualizer.com site.

Except for the odd cross-country excursion to Oakland (which is an artifact, of what I don't know but I assure you our car cannot fly!) the position trajectory is just what I expect moving from our house just right of the "l" in "Las Trampas Regional" across the bridge to Benecia and back.

So I would call this a mild success, data collected, some meaningful interpretation possible, and the promise of a practical asset tracker looks bright. There is still plenty to do.

The six hours of the battery lifetime is way out of balance wrt the 90 day SPI flash capacity, and I haven't even started to make use of the wifi yet. Job #1 is to try to get the average power usage down. Still, even six hours (or twelve hours if I were to use a common 750 mAH battery of which I have plenty) is long enough to get some useful trajectory information.

Then there are the interesting applications, like tracking your cat. Where does your cat go at night? Now you can find out...