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 Asset Tracker was placed just under the emergency brake over the drive train and on most cars this space gets pretty hot, especially on a hot July day in Livermore. So it is not surprising the temperature rose to 150 F. Yet, the Asset Tracker had no trouble working and recording data, etc. at that temperature. This is a gratifying testament to the robustness of the design and the hand-assembly of the components on the pcb

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

The elevation at ~300 feet is where the car passes Pleasanton at the 580/680 junction, and then at ~500 feet is parked at Livermore. This is the same time that the temperature soars above 100 F so it is not surprising that the elevation estimate creeps up a bit as the temperature rises. The subsequent changes in elevation mark the return through Pleasanton (at ~22:00:00) and entry into the Danville area (elevation ~400 feet). Finally at the end of the trip, the climb up the hill to our house at 1050 feet elevation. Of course, elevation estimated from pressure can easily be off by 100 feet. Altitude provided by GPS can be more accurate but I find too many gaps in the GPS altitude and too much variation to be useful, at least in this driving application.

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.