Soft chippy, warm chippy, little chunk of RAM. Happy chippy, sleepy chippy, purr purr purr..

Like Sheldon Cooper, also the ChiliCAN needs a good night's sleep. I've been tinkering power optimization features and I must say the results so far are pretty good!

Here's the list of tricks that I've found by reading the datasheets and various articles on the web related to Arduino power saving:

• MCP2551 CAN transceiver can be put to sleep via the Rs-pin. Just control it via one of the Atmega328 output pins via 10k resistor (+5V in sleep mode, 0V awake), and we can save around 4 milliamps.
• Atmega328p has various power saving modes, and I wanted to use the most aggressive one (SLEEP_MODE_PWR_DOWN), which reduces the power consumption to less than few hundred microamps! It can then wake up with an interrupt generated by either the CAN controller or the GSM module.
• MCP2515 CAN controller has a sleep mode as well, enabled with SPI command. Before that we must enable the CANINTE.WAKIE interrupt signaling and connect the interrupt pin to INT0/1 on Atmega328p. Then, when a new CAN frame is received, interrupt is generated and the CPU can also kicked out of his silicon bed. Warning: The first CAN frame is always discarded and does not end up into the receive buffer (I think the sleep mode of both the transceiver and controller cause this). However in my setup it doesn't concern me, since the signal from key fob light button is not in the first CAN frame in the burst of messages sent to the bus when button is pressed and the car wakes up from its slumber. Another pitfall can be found in the wake up routine of MCP2515: If we want to wake up the controller (for example when the interrupt is generated by GSM module and not the controller), then it must be done by generating the CANINTF.WAKIF interrupt by ourself, and NOT the operation mode switch by SPI interface. The latter DOES NOT WORK! This is kind of weird, since the SPI interface is specified to be active even when in sleep mode. Reading its registers seems to work, but chancing the CANCTRL has no effect. Anyway, putting the controller to sleep gives us savings of around 3-4 mA.
• Ditch the AEM and consequentially, be able to get rid of the grounding relay as well. Naturally, this has no effect on sleep mode power savings directly, but since the relay is a power hog (~ 50mA when switched on!), getting rid of it enables us to use smaller and more efficient voltage regulator (those usually have also lower maximum output current). 
• Switch from 7805 to LM2936Z-5. The 7805 has in my tests shown quiescent current (waste current generated by the regulator even without any load) of more than 4 mA, where as the LM2936 is much more efficient, having quiescent current measured only in tens or hundreds of microamps, depending on the load. Unfortunately its maximum output current is 50 mA which is way too low if we want to use the GSM module as well.  

So, putting all the chips to sleep and using other aforementioned power saving tricks, I managed to get the sleep mode consumption down to 400 MICROamps! :) Now I don't have to worry anymore about accidentally emptying the car battery!  

Now, the measurements above are done without the Seeedstudio GSM module, because it is completely another beast: 

• The SIM900 GSM chip itself doesn't consume that much in sleep, its specified to be around  1-1.5 mA, but then again it has a peak current consumption of 2 amps during network registration and other wireless activity, which makes it little bit difficult to find suitable but efficient power supply. 
• The GSM shield has its own power regulator MIC29302BU. It is a low voltage drop regulator that can use Arduinos +5V and will provide 4.1 volts (adjustable) for the rest of the GSM shield to use. It is also able to handle the peak currents required by SIM900. Unfortunately it has a quiescent current of around 8 mA when idle, which is not that good.
• The shield has a "input power on" LED as well as an actual "power on" LED that is lit when SIM900 is turned on. I'm not sure of their forward voltage drop, so it's hard to guess their current consumption. It's maybe around 2.7 mA + 9 mA when fed with input +5V, if assuming voltage drop of 2.3 V (green SMD led). Also there's a orange GSM activity led, but it's on only intermittently (one blink every 2-3 seconds).
• The total consumption of the shield when the SIM900 is not even powered  is 12.6 mA! 
• When powered and in sleep mode, the consumption increases to 23.6 mA, having bursts of 36.2 mA every 3 seconds. 
• The total consumption of the whole device (7805 as the regulator, since LM2936 doesn't output enough juice for the GPS shield) when all the chips are in sleep mode is 27.4 mA (bursts of up to 40 mA every 3 seconds). 

It's quite clear that the SeeedStudio GPRS shield v1.4 is not designed for low power consumption in mind, otherwise it would have included a more efficient power regulator and a way to either disable the LEDs or give a way to control them for example with PWM. Since the MIC29302 is intended for automotive applications and has maximum input voltage of +60V, it should  be safe to power the whole device with this regulator. However while Atmega328p and MCP2515 can operate with 4.1V, the MCP2551 CAN controller needs at least 4.5V, which is then too much for the SIM900. So, another regulator is anyway needed.  

What about LM2936 for the main board and then power the shield with car battery directly? I looked at the LED configuration in the GSM shield schematics and found out that the LEDs are powered straight from the VIN (i.e. before the regulator), and if we give the shield input voltage of +12V without changing also the resistors, LED consumption would rise to tens of milliamps (probably burning them, if not at idle, but at least when the car alternator is running..)  So in this case little bit of resoldering would be needed anyway.