Gps, GPRS, sleep mode, and battery life

Projects General Guidance
1

Very, very early stages of a project right now.
Specs/contstraints include the following —
• GPS "tracker"
• Small size (may be a bit thicker than an iPhone, but not as long).
• Reports position over GSM/GPRS at minimum once per day.
• Battery life of (at minimum) 30 days.

Examples of similar existing technologies —
http://staging.freightsecurity.net/products/sendumpt200 Good, but too large/long w/ battery
http://www.whelectronics.com/Data/AirLoom%20Specifications.pdf Not enough battery life. Not sure why specs require 12V either?

My approach would be to either hack/mod one of above devices to meet my needs ("shrink" the Sendum, increase battery life on Air-Loom) or design my own.

I would kind of like to attempt my own design...just to say I did, and have more overall control.

For my own design, so far I have been playing with the following for prototyping purposes—
• Arduino UNO
• Adafruit Ultimate GPS logger shield Adafruit Ultimate GPS Logger Shield - Includes GPS Module : ID 1272 : $29.95 : Adafruit Industries, Unique & fun DIY electronics and kits
• Adafruit accelerometer breakout (for possible motion activated GPS logging feature)
Triple-axis Accelerometer+Magnetometer (Compass) Board - LSM303 : ID 1120 : $14.95 : Adafruit Industries, Unique & fun DIY electronics and kits

My "plan" thus far is once I have all these things working together, I will (attempt to) design & build a single PCB to contain everything.

I do realize this is no trivial task.

The GPS shield has an SD card for data logging. Though the GPS device itself can hold substantial/sufficient amount of logged position data internally. So, that may simplify things....a little. Also, the GPS can "remember" single ephemeral data for three days to help acquire position more efficiently after being woken up. Nice.

Ideally, the device will be asleep most of the time to conserve battery. It would wake up once per day, and/or after some movement (triggered by accelerometer...suggesting it may soon be outside, thus having a better chance if getting location fix, and possibly wireless signal to send position back to server.

I have the GPS spitting out parsed NMEA sentences already. And I'm figuring out how to get it to do what else I need.

For any specific questions I have...
• Best way to have Arduino sleep & wake when I need it to? How much power could I reasonably save doing this & maintaining the functionality I require?
• Suggestions/advice on calculating my battery requirements? Ways to keep that at a minimum?
• Suggestions on "best" GSM/GPRS device to use? - Efficient, low power, reliable...r just easiest to obtain & find support for it?
• Advice on where else to hunt for god information? — I could, and have been, Googling the heck out of all these things. But, I'm hoping to leverage some of your experience to help me narrow down the results to reliable & helpful resources.
• Anything I didn't mention, but need to consider at this time.

I know this is all still very vague, but I hope to get into more specifics soon.

And, since we always ask the OPs....this is part personal curiosity - to see if I can do it - and part potentially real-world use for un-named third party. They have specified a need/desire for this, and I'd like to try and help make it happen.

Any advice, suggestions, tips, warnings, personal experience, or otherwise useful input or questions are welcome & appreciated!

Thanks!

-Dave

2

For the reduced power/sleep options, I suggest you start with Nicks page at

Any extra components can be powered on and off from the Atmega328P (assuming small load).

Nick shows how you can run for months with very small batteries.

3

Dave,

I am actually doing a very similar project apart from I am using a vibration sensor instead of an accelerometer. Reason behind the vibration sensor is that the accelerometer will only ever work if you are accelerating, if I wanted to track a moving object such as a car there is a risk that at a constant speed I would not feel an acceleration and therefore not log the movement.

At the moment I have the same gps as yourself and I will be looking in to a GPRS solution soon. I use the vibration sensor to wake the arduino from deep sleep. This will then in turn kick off the gps to start logging a location. I need to workout the algorithm for how often it should log and whether it should cold load or stay hot with a second battery on the gps.

I too am also using the UNO but as has been posted on Nicks page the only way to get true energy savings will be to build a barebones arduino yourself, even if it is on a breadboard. There are far too many extra modules, LEDs, pins etc on the uno to sustain this type of project for any length of time. Keep the uno for prototyping and you will soon find out what the bare minimum requirements are ready for when you build the barebones version later.

My project will be aiming at logging my cars movements, kind of the same as the trackers you can buy however I did not see the point in paying huge subscription fee's each year for a service that I can build myself. As you have found the battery life on the standalone units are terrible considering their price. Some last as little as a few days and others only a couple of weeks. I really did not want to link any charging in to my cars current wiring as it is quite old and battery drain on the car is far more annoying than the tracker running out of juice.

As yet another thought, have you looked at creating a charging circuit which links to a solar panel? Even on the adafruit website they have some complete kits for charging your battery with solar and even if you only catch a few rays it may be enough to keep the tracker running once you get it out of the uno prototype shell. You would need to calculate the draw on the battery to size your panel, which may require something quite large and for me that would be the issue in the car however this is just an idea for now.

Finally as this has been quite a scattered ramble there is a board developed from a kickstarter project that has everything you talked about rolled up in to one. The battery life once again is not great AS IS but you can set it up to detect motion and go in to deep sleep, this can bring the range up to 30 days (so it says) and can be completely controlled via an sms to the device from your phone. It even sends you a sms back with a google maps link!

http://www.kickstarter.com/projects/dsscircuits/open-source-tracking-device

4

@Munkee -

Wow. Thanks for your post...and that link!
That's practically the device I had planned on building.

I am actually doing a very similar project apart from I am using a vibration sensor instead of an accelerometer. Reason behind the vibration sensor is that the accelerometer will only ever work if you are accelerating, if I wanted to track a moving object such as a car there is a risk that at a constant speed I would not feel an acceleration and therefore not log the movement

I get what you're saying. I guess it depends on your application & code, but... once moving (assuming you have GPS fix) the GPS unit can keep track of speed & heading (whether accelerating or at constant velocity).
(Pseudo-)Code might look something like -

Arduino, GPS sleeping

Interrupt from accelerometer/vibration sensor triggers ISR

ISR
 {
Wake up Arduino, start searching for GPS fix
}

While (GPS Fix)
{
Track location, heading, and velocity
If (velocity = 0)
{
Wait a few minutes to ensure "permanent" stop
If (velocity STILL = 0) && (No motion activity)
{
Record/report last GPS info
Shut down GPS 
Activate motion interrupt
Enter sleep mode
}
}
}

Accelerometer is really just like a really well tuned vibration/movement sensor anyway.
I just like the accelerometer idea because it can do same thing as vibration sensor, and also has possibilities for future implementation. I could be possible (with enough data reported back) to determine if the tracked "object" has fallen or shifted position/orientation — which, I imagine, may prove useful & important in certain shipping operations involving sensitive or fragile materials; it might even help settle insurance claims for any damages...??

Anyway, thanks again! Good luck with yours! And, I may have to try out that GeogramONE.
XD

5

No problem! I have actually been taking a look at potential battery life and overall power consumption. I think for my project I may even ditch my external interrupt completely and sleep the arduino in power down mode. Every 30 minutes I will use the watchdog timer to fully wake and try to get a reading. I can then on every hour send the data if I want. I guess it really depends on the required level of logging you need and I think there is the potential with a "always on whilst moving" kind of stream to become quite a battery killer on long journeys, I expect this is why the kickstarter project does the "motion arming" option to only do this level of logging if it isn't you in the car etc.

I like the psuedo code and it has given me a couple of ideas. I had actually not even thought about using the gps speed reading! I was going to keep checking the interrupt sensor (silly me...)

Anyway regardless good luck and I have actually just purchased an accelerometer for testing myself. If you have any interrupt code kicking around already I would be very interested to take a look.

6

I believe the longest sleep interval possible is 8 seconds

// watchdog intervals
// sleep bit patterns for WDTCSR
enum 
{
  WDT_16_MS  =  0b000000,
  WDT_32_MS  =  0b000001,
  WDT_64_MS  =  0b000010,
  WDT_128_MS =  0b000011,
  WDT_256_MS =  0b000100,
  WDT_512_MS =  0b000101,
  WDT_1_SEC  =  0b000110,
  WDT_2_SEC  =  0b000111,
  WDT_4_SEC  =  0b100000,
  WDT_8_SEC  =  0b100001,
 };  // end of WDT intervals enum

From: http://www.gammon.com.au/forum/?id=11497

One workaround is to just wake long enough to increment a volatile byte counter variable and go right back to sleep if the counter hasn't reached 225 (225 8-second intervals = 30 minutes). This should only take a few microseconds, so it will contribute a very small (but still measurable) battery load. See this thread's discussion of the SUT (Start Up Timer): 1.8V Arduino w/ internal resonator? - Project Guidance - Arduino Forum as SUT settings may impact the battery life of an Arduino frequently coming out of sleep like this.

Another possible workaround: some RTCs will let you set an "alarm" time and raise a pin high when that time arrives. You can use an interrupt to wake the Arduino on the RISING pin event.

7

I believe the longest sleep interval possible is 8 seconds

That's partly why my plan involves the GPS to wake the Arduino. I've only tested it up to 15 seconds so far, but works pretty well.
It may, of course, depends on capabilities of specific GPS module. And, it may work with some RTCs as well.
I can send a "PMTK" string to my GPS to tell it to go to sleep, wake up every "x" and get reading. Then, use either "GPS Fix" pin or "PPS" pin as the interrupt to wake Arduino.
GPS Fix generates a fixed length high pulse every 5 seconds when it has a GPS lock.
PPS sends a pulse-per-second when getting accurate time readings from satellites.

8

Dave,

Can you elaborate more on:

I can send a "PMTK" string to my GPS to tell it to go to sleep, wake up every "x" and get reading.

Is this held within a datasheet somewhere? I couldn't see it when I was doing a quick skim of the adafruit examples. It looks like another item worth testing against my battery consumption readings instead of using the watchdog timer and going about it the other way around.

9

munkee:
Dave,

Can you elaborate more on:

I can send a "PMTK" string to my GPS to tell it to go to sleep, wake up every "x" and get reading.

Is this held within a datasheet somewhere? I couldn't see it when I was doing a quick skim of the adafruit examples. It looks like another item worth testing against my battery consumption readings instead of using the watchdog timer and going about it the other way around.

Ah...it's in the "confidential" document from G-Top. <Attached!>
You'll need to generate proper checksum values to include at end of commands. That can be done here -
http://www.hhhh.org/wiml/proj/nmeaxor.html

I'm still experimenting to decide which way is really better & most efficient -- MicroController waking the GPS, or GPS waking the MicroController. The *3339 GPS chipset (at least some of them, Adafruit version included) also have built-in data logging called "LOCUS", which can store up to 16 hours (based on one log every 15 seconds) of location data. Ideally, I would have GPS wake up every minute, (hour, whatever...) or so & save the location data. Then, wake up the micro controller once per day (or when has best chance of getting cellular connection), download data from GPS, and send it 'home' via GPRS.

PMTK_A08.pdf (405 KB)

10

Sounding quite similar to myself again, I will be recording twice an hour. Once after 30 minutes and once after 60. On the 60 I will upload the data at the same time. Just had a read of the document and it has some interesting functions! It seems I had briefly seen something along those lines before talking about standby mode here: http://www.gtop-tech.com/en/product/MT3339/Software_Services_21.html

At the moment I have the GPS trying to get a signal for 2 minutes if nothing after 2 minutes I just sleep anyway as I dont want to be stuck in a loop in an area with bad signal. I am currently using the Enable pin to control that so the GPS is completely shut off by the microcontroller just before going in to system power down sleep. I am unsure however whether I will be able to get quicker fixes by adding in the flat battery to the GPS as mentioned on adafruit website. Normally I would expect so but it depends on whether the enable pin is killing everything or still allowing the battery to keep the clock in check.

Also just ordered all the bits needed to get a barebones arduino set up so I can work on the power issues with my uno. However with that being said these GSM parts seem to require a huge amount of spiked power which could become an issue but this is where I think linking in a solar charging loop will save the day if you can get the system to function for at least a week on its own without charging. The solar charge will keep everything topped up .. I hope. There is a mention of some GSM power saving techniques here just for your reference: http://comoyo.github.io/blog/2013/08/09/How_to_efficiently_operate_the_Arduino_GSM_shield_with_a_battery_pack/ however no hard figures on consumption improvements other than a couple of percentages given near the end.

11

Yeah, I've been all over that GTop website. The 3339 is a pretty impressive chip. I wonder how difficult it would be to have them implement some of the "custom firmware" options...?

Hey, mind if I ask....what are you planning on using this for? That is, if you have a planned purpose. Just curious.

I've been reading a lot on Nick Gammon's site lately. I think if I (we?) could get the timing of everything down pretty well....might be able to 'sleep' the Arduino between instructions, NMEA sentences, etc... (like milliseconds at a time) to really try to save every drop of juice possible in that battery. But, that's gonna take a little better understanding of the various timers & interrupts inside the ATMega.

12

I'll be using mine for car tracking. I wasn't happy with the prices and battery life of the commercial available trackers that can be fitted to a car. Also I did not want to use the cars battery at all to charge the tracker when it needed it as this is never infinite and I do not want the problem of going away for a week or two and then coming back to a battery that doesn't have enough charge to start the car.

At first I wanted to monitor the car every time it moved in real time, however after looking a bit deeper in to the use case I do not really gain much benefit from doing it that way. It is much easier to just take a reading 2 or 3 times an hour to give me a rough idea if something is moving.

Nick's site is VERY useful. I'll be following his barebones arduino tutorial and power consumption posts over the next week to get sleep mode running as low as it can. I think you are right the sleeping at every possible moment seems to be the best way to go. Im pretty sure the biggest loss for me is the time taken to get a valid GPS fix as it can take anywhere from 10 - 20 seconds on a good run up to 2 or more minutes depending on the time of day (im in quite a built up area though which doesnt help). I have been looking at the external antennas but the recommended one by adafruit which is an active antenna takes 20mA which means the GPS overall consumption would be doubled between 40mA - 45mA. Couple that up with a GSM running between 70 - 1000mA (Some even 2000mA) for a few seconds it makes your average look pretty messy :confused:

I have no doubt in power down/sleep you can get the current draws in line with what Nick Gammon proposed to sub 1mA but its a case of ensuring the brief powerups are kept to a minimum which is where I think the real work is.

This site is pretty decent for some ball park figures of battery life: Oregon Embedded - Battery Life Calculator

With the following in the calc:
Battery capacity: 3000mAh
Current consumption during sleep: 1mA (GPS off, GSM off, Arduino barebones in sleep_mode_pwr_down)
Current consumption during wake: 70mA (This is the figure that needs to be tweaked more, but on average I expect it will be around this)
Number of wakes per hour: 2
Duration of wake time: 120000

Battery life expectancy: 19 days

13

munkee:
if I wanted to track a moving object such as a car there is a risk that at a constant speed I would not feel an acceleration and therefore not log the movement.

Absolutely no chance of that.

14

@1ChicagoDave

Just wondered how this was going for you now? I am hitting issues with powering both the GPS and the arduino GSM Shield from the same bare-bone 328P. I'm starting to really reach the memory limits at the moment and the big current draw from the GSM seem to make the whole setup very unstable. However I have had success in it running for a few cycles.

I'm now thinking whether to switch out the 328P for the 1284P or run two 328's in parallel one for the GPS and one for the GSM. I'm thinking the latter at the moment as it would help separate concerns and really drop the power of the chips to run only when needed. Also I guess debugging code will be much simpler.

15

I've been getting a little sidetracked by other projects and, well, just life in general. :~

But yeah....that GSM module can suck a lot of juice! How have you been powering it?

One thing I have noticed, is how inconvenient it is to have to parse the NMEA sentences. It really makes the whole system "stutter" sometimes. It has me thinking about how to really get everything timed well....disable interrupts during certain operations....only 'accept' new data during certain parts of the cycle...etc.
Have you tried adjusting baud rate and/or update rate of the GPS module?
Since it suits my needs just fine, I've turned back the GPS update rate to once every 2-5 seconds, and try to get baud rate as fast as reasonably possible.

I've also noticed that the performance of SoftwareSerial is often less than desirable (and memory hungry). Which, in turn, has me thinking that an Arduino with more than one hardware serial port would be ideal.

Although I don't think it absolutely necessary, I do kind of like the idea of maybe having a separate processor for either the GPS or the GSM. Worried about extra power consumption though.
• If for GPS, just have that processor dedicated to checking for GPS fix/accuracy, parsing incoming NMEA strings, and then storing/sending them on to the "main" processor when it's ready for them (requests the parsed info) instead of the only processor being forced to deal with new GPS data as it comes in. I've been inspired by the LCD backpacks that Adafruit sells. I just got this one as a display on one of my GPS projects. (USB + Serial Backpack Kit with 16x2 RGB backlight negative LCD [RGB on Black] : ID 784 : $24.95 : Adafruit Industries, Unique & fun DIY electronics and kits)
It uses a low power Atmel AT90USB162 to listen for TTL commands from my UNO, and use them to run the LCD. I'm wondering how difficult it might be to use something like that to parse the NMEA strings.
And, if I don't need new GPS data at the time, use the main processor to completely cut the power to GPS module AND it's dedicated processor to save power...?

Also, I recently picked up an Arduino Micro (ATMEGA32U4 based, like the Leonardo). It has a little extra SRAM, more digital & analog pins, and built in USB support on separate serial port. So, I can still debug over USB without messing up hardware serial comms to other sensors (GPS).

16

1ChicagoDave:
One thing I have noticed, is how inconvenient it is to have to parse the NMEA sentences. It really makes the whole system "stutter" sometimes.

NMEA should be a walk in the park to decode, even with software serial. What code are you using -- TinyGPS or a Finite State Machine or what?

17

tylernt:

1ChicagoDave:
One thing I have noticed, is how inconvenient it is to have to parse the NMEA sentences. It really makes the whole system "stutter" sometimes.

NMEA should be a walk in the park to decode, even with software serial. What code are you using -- TinyGPS or a Finite State Machine or what?

Can't post my code right now. (I'm on iPad)
But, I'm using the Adafruit_GPS library to parse.
To be fair, the particular GPS project I noticed that with is using a serial LCD to display the parsed data. It sorta 'hiccups' every time a new sentence comes in.

18

1ChicagoDave:
using a serial LCD to display the parsed data. It sorta 'hiccups' every time a new sentence comes in.

I looked over AdaFruit's code and didn't see any obvious delays... a little floating point, not much. Were you using hardware serial for the LCD and software serial for the GPS, or were they both software?

Hard to say without seeing the code but it sounds like updating the display is not an atomic operation -- the display starts to update, then the GPS code runs, then the display finishes updating. What you may want to do is trigger the LCD update immediately after a sentence is received, so that your display update routine has enough time to complete before a new sentence arrives.

19

1ChicagoDave:
I've been getting a little sidetracked by other projects and, well, just life in general. :~

But yeah....that GSM module can suck a lot of juice! How have you been powering it?

It definitely does suck some out but I think this is one of the reasons why I am looking in to using two breadboarded arduinos instead of one. I can up the power on the slave which will be running the GSm shield against the low powered GPS breadboard. It means you can also control the sleep cycle of both very easily. I know I can get my GPS breadboard down to 0.7mA with ease and it runs at around 22mA when awake and searching. This provides great battery life really running at 3.3v.

1ChicagoDave:
One thing I have noticed, is how inconvenient it is to have to parse the NMEA sentences. It really makes the whole system "stutter" sometimes. It has me thinking about how to really get everything timed well....disable interrupts during certain operations....only 'accept' new data during certain parts of the cycle...etc.
Have you tried adjusting baud rate and/or update rate of the GPS module?
Since it suits my needs just fine, I've turned back the GPS update rate to once every 2-5 seconds, and try to get baud rate as fast as reasonably possible.

I haven't had too many issues with this as of yet. Maybe it is an SRAM thing going on for you? It might be worth checking what your ram availability is as you go loop to see if it is dropping low at some points. I am waiting for a valid sentence, parsing and then turning off the gps module with the enable pin as soon as possible if the fix is of good quality. This means im not receiving extra lines and interrupts whilst doing some heavy lifting in the next parts of my code.

1ChicagoDave:
I've also noticed that the performance of SoftwareSerial is often less than desirable (and memory hungry). Which, in turn, has me thinking that an Arduino with more than one hardware serial port would be ideal.

I had major issues with softwareserial/GSM/Adafruit_GPS libraries being put together. There are some good posts over on the adafruit forum regarding AltSoftSerial which removes the requirements to run SoftwareSerial. It may be worth taking a look into.

1ChicagoDave:
Although I don't think it absolutely necessary, I do kind of like the idea of maybe having a separate processor for either the GPS or the GSM. Worried about extra power consumption though.
• If for GPS, just have that processor dedicated to checking for GPS fix/accuracy, parsing incoming NMEA strings, and then storing/sending them on to the "main" processor when it's ready for them (requests the parsed info) instead of the only processor being forced to deal with new GPS data as it comes in.

Power consumption is probably much better off as you gain the benefit of being able to turn each of them off independently. I will only wake the "Slave" via interrupt when I know my gps string is valid, otherwise it sleeps. I then know as soon as I pass on the information to the "Slave" then the "Master" can powedown and sleep whilst the "Slave" goes off and does some more work with the code such as uploading to a database/website (Xivley).

I have pushed my project on to github, the sketch for the master arduino is nearly complete I just need to add in the interrupt function to wake the slave but it might give you some idea of the direction im going at the moment. Once that is done I need to go through my slave code and really get to grips with sending the data up to the server (It is all a dumping ground of code there at the moment).