Ready, set, optimize!

Alright, finally I had time to grab my solder iron and punish the naughty GSM shield for being such a greedy pig when it comes to efficiency in power consumption.

When we look more closely at the shield schematic, we can see that NETLIGHT and STATUS pins of SIM900 control the transistors which turn on and off the leds, powered from Arduinos +5V input via 300 ohm resistors R21 and R20. There's also the "shield powered" led that is always on when, as the name implies, the shield receives input power, regardless whether the GSM module is powered or not. Very wasteful when thinking about power efficiency, so I started with that first:

Actually I haven't ever done any operations on such a small SMD components before, so after unsoldering the R1 the end result was quite far from satisfactory: both copped pads under the resistor were ripped off because of too high temperature, excess force and prolonged heat exposure. Oh well, not that I need the "shield powered" LED anyway..

Before removing the R1 the power consumption of the SeeedStudio GSM shield was 12.2 mA (shield powered, but SIM900 not turned on) and 23.4 mA (SIM900 in sleep mode) when powered with external +5V lab supply (HP 6632B). After removal of R1 and thus disabling the LED, power consumption drops to 9.1 mA and 20.3 mA, respectively. This brings savings of 3.1 mA. Nice.

Wiser from this incident, I practiced desoldering a little bit with old PC motherboard and found a suitable removal procedure consisting of adding liquid flux, new solder and then removing everything with a solder wick. Then add little bit more solder to both ends of the resistor, heat one end with solder iron while lifting it with tweezers. Then repeat this with the other end and finally the resistor can be removed.

 I removed the R20 and R21 resistors and soldered a breadboard jump wire to bypass the LEDs. This time no solder pads were harmed and thus the procedure is reversible. The transistors Q3 and Q4 now connect our NETLIGHT and STATUS wires to ground when signaled by SIM900, making it posssible not only to put the GSM power and/or activity leds on the enclosure if needed, but also it's now easy to check the power status of the GSM module. Before this, the only way to see if the module is powered was to send AT commands and wait for the answer. Actually this was one of the things that annoyed me about this shield from the start. Luckily now only one digitalRead is needed.

It could have been possible to remove the transistor and tap into the NETLIGHT and STATUS pins of the SIM900 directly, but leaving them behind transistors is safer since the module uses lower voltage than rest of the device. It could have been possible to destroy the whole chip or at least the output pins with software by simply switching the pin mode on Atmega side to output and signaling +5V. Puff, there goes the magic smoke.

Since there isn't a nice way to attach strain relief to the jumper wires,  I used hot glue (again) to attach the proximal ends to the PCB to make sure all the vibration and shaking in the car doesn't cause the cables to come loose.

Now, after bypassing also the STATUS led and rewiring the NETLIGHT led (blinks once every 2800 ms, so not a concern in this case), I've managed to reduce the sleep mode consumption from 23.4 to 10.2 mA! Those LEDs really are gluttonious beasts! Then I tried inputting +12V onto the shield directly via its "low ground current, low-dropout voltage regulator", the MIC29302. Low ground current my ass. Increasing the voltage from +5V to +12V increases the quiescent current (=ground current) linearly from 10.2 mA back to 21.8 mA! And that is even without powering the GSM module! So, in this case it is better to use the 7805 to drop the voltage from +12V to +5V and distribute that to the GSM shield. If someone knows better alternatives, I'm all ears.

All in all, the ChiliCAN now consumes 14.3 mA when all the chips are sleeping (i.e., when there's no CAN traffic and no calls are being made). That constitutes maybe 90% of the time. When the heater is on (or otherwise CAN bus is active), the consumption wanders between 30 and 55 mA. During phone calls it lies around 100-200 mA having maximum peaks of 1.5 A, but those are quite short bursts, having almost nil effect on battery life. If we assume average consumption of 17.2 mA, it would take almost 4 months for ChiliCAN to deplete my 95 Ah car battery to 50% charge. I could live with those numbers :)