Completed first integral power test of the Cricket Asset Tracker using a fully-charged 150 mAH 1S LiPo battery, gathering BME280 and BMA280 sensor data and logging same to SPI flash once per minute using the RTC alarm as a timing interrupt, sending same data plus longitude and latitude to a LoRaWAN network (the Things Network) via TTN gateway every ten minutes, and acquiring a new fix from hot start every ten minutes. I know from testing the LoRaSensorTile under more or less the same conditions that the average power usage of everything except GNSS is about 50 uA, so the 150 mAH LiPo would last 125 days except for acquiring GNSS fixes.

The GNSS engine (CAM M8Q) was set up to wakeup every ten minutes using a millisecond timer, acquire a 3D fix, then go to sleep again until the next wakeup. So in addition to the average current usage a key performance parameter is the average time to hot fix (TTHF). This will depend on a lot of factors. In this test, I am using the external (active) antenna with an 18 mm patch antenna I bought on Aliexpress instead of the internal chip antenna embedded in the CAM M8Q. The active antenna requires ~10 mA more power in use but also lowers the TTHF, so for GNSS-signal challenged environments like indoors on my work desk as in this test, it might be a good tradeoff.

In the end, the test ran successfully for just over three days, or 72.5 hours. I received the first LoRaWAN data packet on TTN at 10:46 AM 2/6/18 and the last at 11:10 AM 2/9/18. This means the average current draw was ~2.1 mA and the inferred average time to hot fix was just under 38 seconds.

I got the full data log on the 8 MByte SPI flash, here is an example of temperature and humidity over the three days:

I made some mistakes on the first run. I logged GNSS time instead of RTC time so even though the pressure and humidity, etc data changes the times are the same for each ten minute interval instead of incrementing properly when using RTC time. That is why the data look "spiky".  I also forgot to  read the GNSS altitude variable so these were logged as all zeroes, not very useful.

But the first test of the Cricket Asset Tracker is a success, everything worked and the power figure is very good. 2.1 mA at 10 minute intervals in a challenging (indoor) environment is a pretty good place to be. This means under these same conditions I could expect to get ~1100mAH/2.1 mA ~22 days on a single AAA battery at this duty cycle. Every ten minutes is too fast for slow moving objects like a bull dozer on a construction site and too slow for rapidly moving ones ike bicycles and cars.

The ephemeris data downloaded from acquired satellites is accurate for about four hours and has to be re-read after this time so a practical upper limit to the acquisition duty cycle is four hours. A practical lower limit is once per minute if in challenging conditions it takes a good fraction of a minute to get a hot fix. In practical asset tracking,  the duty cycle would have to be balanced between the competing goals of power usage minimization and tracking accuracy.

The art , then, of a practical asset tracker is to adjust the duty cycle of the GNSS fix acquisition to the tracking problem at hand by acquiring a fix infrequently when the device is more or less stationary and more frequently when the device is in motion. That is the reason why there is an accelerometer on board Cricket and making the GNSS engine motion aware is the next task.