Support Home Portal Log in
Open navigation

Eagle and Falcon - Estimating Battery Life

All about battery life!

For a full discussion on battery life estimates, and monitoring your device battery levels to ensure timely replacement, see this article: Battery Life, Battery Capacity Estimate & Low Battery Flag

The Eagle and Falcon are both highly flexible devices, with a variety of inputs. Just some of the applications/functions which these devices provide are:

  • Battery powered trip tracking (like an Oyster2, Yabby, or Remora2)
  • Sensor monitoring and data logging
  • BLE Gateway (Eagle)

Often all of these functions can be set to run concurrently, and the wide variety of sensors that can be connected to these devices (see Supported Sensors and Inputs) means that each application is very different, and accurately estimating battery life can be difficult, purely because it's hard to account for all the possible configurations and power drains. 

Additionally for these devices, the impact of sensors cannot be understated. When connecting any generic sensor, there are a few key unknowns such as:

  • How much current the sensor draws to operate
  • How long the sensor must be powered for to return a reading (e.g. what Warm Up Delay we set)

If we're sampling say every 15 minutes, a small change here has a dramatic impact on battery life. 

Additionally, device behaviour isn't as well defined. For example, for a Yabby GPS, on updating periodically 2 x per day, we know that this consists of a Fix and Upload each time (which we know around about the power consumption). If it was making trips, logging a fix every 15 mins during the trip, and uploading at the start and end, if we know the trip time we know how many fixes and uploads that equates to. 

In comparison the Eagle and Falcon can run tasks to measure sensors and optionally get fixes, not get fixes, upload, etc. This is all designed to be as configurable as possible to fit many use cases - but makes the maths harder as there is more complexity!

Cmon.. I still need something - how can we estimate?

You're in luck! - while it's hard, we can still come up with some ballpark estimates for each device ahead of time, and also with testing, more accurate estimates. 

The easiest and most reliable method is to simply set up the device in our desired configuration, with our chosen sensors, and run it for 1-2 weeks. There are that many variables that this is the easiest and most reliable method. Why chance it with a guess? We take note of the battery drain as given by the battery meter (both the Eagle and Falcon have these fitted) - and we can use that to predict the total life. i.e. 1% used in 1 week means we should get approximately 100 weeks. This is discussed further HERE.

What if I need to get an idea ahead of time?

While we should always test ahead of time, we might want to get some sort of estimate, even rough - just to assess whether an application is even feasible. E.g. a user might only be able to get to the device for a battery change every 6 months, and if their desired reporting rate only gets them an estimated 1 month - we know we should be going back to the drawing board!


When we dreamt up the Falcon - we needed an "Oyster with Inputs". So a lot of the GPS/modem and other circuitry is very similar. So acquiring a fix and completing an upload uses pretty much the same power. So we can start from there (we then just need to account for our sensors). 

So for example:

  • Falcon with no sensors connected, used as a tracking device, 24 updates per day
    • We would just look at the Oyster's predicted battery life from here. So we'd expect 1 year battery life. 
  • Then, if we were reading an I2C sensor (say temp every hour), these are quite low power. But to be safe we could just knock 10% off that year total as an estimate, and later confirm with a test and the battery meter measurement.

If you are using a DM manufactured sensor like one of our Temp Probes - we have measured the energy used to take a sample from these, so you can use the attached calculator. 

If you know that your sensor draw and how long it needs to be powered on for each reading, you can work out the mAh used per reading and do your own calculation. E.g.

  • A sensor draws 20mA and needs to be powered on for 5 sec each measurement
  • This would mean it costs 0.02777mAh per record. 
  • A reading every 15 minutes (96 readings daily) costs 2.6667mAh each day. 
  • That is 973mAh per year. 
  • For Energizer Ultimate Lithiums, which have a total capacity of 3100mAh, this is 31% of the batteries drained each year just due to the sensor measurements. 

Note these numbers are all pulled out of thin air, they just illustrate the calculation. 


All the same applies, but we base the Eagle on the Remora2. 

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.