02/18/2018

I am in the middle of my second Cricket Asset Tracker power test but I already have some interesting results.

Firstly, I used the fact that the BMA280 accelerometer has two interrupts and a quite sophisticated interrupt engine to set up "wake on any motion" on one interrupt and "sleep on lack of motion" on the other. The BMA280 remains in low power mode 1 (drawing ~6 uA on average) and in this mode wakes up every second to sample the accelerometer. If it detects a change in acceleration greater than a defined slope threshold it wakes up. If it is already awake and detects less than this threshold it goes back to sleep, activating the appropriate interrupt to let the host know which state it is in. The interrupt handlers simply set a flag and wake up the host like so:

void myinthandler1()
{
  BMA280_wake_flag = true; 
  STM32L0.wakeup();
  Serial.println("BMA280 is awake!");
}

void myinthandler2()
{
  BMA280_sleep_flag = true;
  STM32L0.wakeup();
  Serial.println("BMA280 is asleep!");
}

 Then in the main loop I manage the BMA280 interrupts like so:

    // use BMA280 wake and sleep motion detection to detect motion state
    if(BMA280_wake_flag == true) 
    {
      BMA280_wake_flag = false;      // clear the flag
      InMotion = true;               // set motion state latch
      BMA280.activateNoMotionInterrupt();                                                                // Re-enable BMA280 no motion interrupt
      attachInterrupt(BMA280_intPin2, myinthandler2, RISING);   
    }

    if(BMA280_sleep_flag == true)
    {
      BMA280_sleep_flag = false;    // clear the flag
      detachInterrupt(BMA280_intPin2);                                                                  // Detach the BMA280 "Go to sleep" interrupt so it doesn't spuriously wake the STM32L4
      BMA280.deactivateNoMotionInterrupt();   
    } /* end of sleep/wake detect */

This detaches the noMotion interrupt when the BMA280 is sleeping and re-attaches it when the BMA280 wakes to save a bit of power and avoid false positives. It also sets an InMotion flag for use by the rest of the main loop program. This is a little clunky and I can probably make this more efficient. I did it this way simply to make clear the logic for myself and get the Cricket to behave the way I wanted.

The next bit of magic is the two TimerMillis callbacks:

void callbackNoMotionActivity(void)
{
  GNSS.wakeup();
}


void callbackInMotionActivity(void)
{
  if(InMotion)
  {
   InMotion = false;
   GNSS.wakeup();
  }
}

The first simply wakes up the CAM M8Q at a low frequency, in this test set to once an hour. The second is called every minute but only wakes the CAM M8Q if motion has been previously detected. In other words, I want the CAM M8Q, which is the big power hog on the board, to get a fix infrequently when the asset being tracked is stationary and to update the asset position more frequently when it is in motion. Since it takes a good fraction of a minute to get a hot fix in challenging conditions, a minute for the high frequency period seems reasonable. And since the ephemeris downloaded from satellite is good for four hours, three or four hours seems a reasonable period for the low frequency update. here I chose one hour just to make sure I would get a lot (relatively speaking) of data.

The last bit to making this scheme work is the CAM M8Q sleep criterion:

         if(EPE < 100.0f) {
            Serial.println("***GNSS go to sleep!***");
            GNSS.sleep(); // once we have a good location fix put CAM M8Q to sleep
            callbackLoRaTx();  // update dashboard/backend via LoRaWAN
         }

I am using the quality measure EPE (estimated position error) as a sleep criterion such that once a fix is obtained with an EPE less than 100 the CAM M8Q goes to sleep, to wake up either an hour later or whenever motion is detected. The value of EPE is arbitrary but there is a tradeoff. If I use a small EPE threshold, it will take longer to achieve a fix and I will use more power. And conversely, if I make the EPE too large I will get fixes that wander all over the place. The value of 100 gives this kind of result (I am using the CayenneLPP dashboard to capture and display the data):

You can see my house in this Google maps view and the cloud of GNSS fixes over a 12 hour period (once per hour) with the actual location of the Cricket Asset Tracker marked in black. Cayenne supports three-byte GNSS data meaning the LSByte is cutoff and the effect is to remove the fine position variations  below about 20 feet. The row of four dots including the black-marked one represents four different fixes where the longitude is the same but the latitude varies by one bit out of 18. In fact, all but two of the points vary by just one bit. Not sure what happened to the other two, unless the DoD is still playing with GPS in the Western US.

So this is acceptable performance for the purposes of this test but I might want to tighten up the sleep criterion to get more accuracy at the cost of more power usage. We'll see...

In the mean time, I am at day four of the test using a 105 mAH LiPo battery and I expect the test to continue for at least another week. I take the Cricket for a 20 minute walk once a day just to exercise the fast frequency capability and get a more realistic power curve. Everything is being recorded on Cayenne LPP and the on-board SPI flash memory. I project the test will consume an average of ~400 uA, or ~10 mA per day. This might drop to ~3 mA per day with a low frequency period of three or four hours. One year on a AAA battery is the goal.

For many of the applications I have in mind, the asset will be stationary most of the time if not all of the time and the key to success will be detecting and alerting to motion in a timely manner.

Update 2/28/18

The second Cricket power test completed today. The asset tracker was configured to read BME280 and VEML6040 sensor data and battery level every minute, log to the SPI flash every minute, send the latest data via LoRaWAN every ten minutes, and obtain a GNSS fix every hour unless the BMA280 detected motion, then the GNSS fix rate was once per minute (described in detail above). The GNSS fix was determined to be obtained once the EPE (estimated position error) fell below 100, then the CAM M8Q would go back to sleep until the next wake period.

EPE of 100 is rather low resolution for GNSS and the results were usually a cloud of points on the CayenneLPP map mostly covering my house with an occasional outlier or two, so not bad. But this needs to be tightened up for actual asset tracking.

The asset tracker spent most of the time sitting outside on my back deck table or inside on a window sill if it was raining (enclosure is not waterproof). Once a day on average I took the asset tracker for a walk to get the mail or down the block to make sure about once a day the “in-motion” threshold was triggered and extra GNSS fixes were required. This is to mimic the actual use case of tracking items that are expected to be stationary most of the time and where it is important to know when they are being moved as well as generally where they are.

Anyway, the test lasted 14 days 6 hours on a fully-charged 105 mAH 1S LiPo battery so average current of ~307 uA. This exceeds expectations since this means at this configuration and use rate the asset tracker would last about one year on a single 3.6 V, 2.6 AH Lithium Thionyl Chloride (AA-sized) battery.

Next test (just started) is to double the long-frequency duty cycle to two hours (ephemeris data grows stale after four hours) and halve the accuracy criterion to EPE = 50.

I will report on the results of this test in about two weeks.