One. Ok, next post :)
I was curious about the difference between Power-down and Standby in the ATmega328p. Power-down turns off the main clock (a 16 MHz resonator in the case of JeeNodes), whereas standy keeps it on. And quite surprised by the outcome… read on.
There’s an easy way to measure this, as far as software goes, because the rf12_sendWait() function has an argument to choose between the two (careful: 2 = Standby, 3 = Power-down – unrelated to the values in the SMCR register!).
I tweaked radioBlip.ino a bit, and came up with this simple test sketch:
With this code, it’s just a matter of hooking up the oscilloscope again in current measurement mode (a 10 Ω resistor in the power line), and comparing the two.
Here’s the standby version (arg 2):
… and here’s the power-down version (arg 3), keeping the display the same:
I’ve zoomed in on the second byte transmission, and have dropped the baseline by 21 mA to properly zoom in, so what you’re seeing is the ATmega waking up to grab store a single byte out of into the RFM12B’s reception FIFO, and then going back to sleep again.
The thing to watch is the baseline level of these two scope captures. In the first case, it’s at about 0.5 mA above the first division, and the processor quickly wakes up, does it’s thing, and goes into power-save again.
In the second case, there’s a 40 to 50 µs delay and “stutter” as the system starts its clock (the 16 MHz resonator), does its thing, and then goes back to that ultra-low power level.
There are bytes coming in going out once every 200 µs, so fast wakeup is essential. The difference is keeping the processor drawing 0.5 mA more, versus a more sophisticated clock startup and then dropping back to total shutdown.
What can also be gleaned from these pictures, is that the RF12 transmit interrupt code takes under 40 µs @ 16 MHz. This explains why the RF12 driver can work with a clock frequency down to 4 MHz.
The thing about power-down mode (arg 3), is that it requires a fuse setting different from what the standard Arduino uses. We have to select fast low-power crystal startup, in 258 cycles, otherwise the ATmega will require too much time to start up. This is about 16 µs, and looks very much like that second little hump in the last screen shot.
Does all this matter, in terms of power savings? Keep in mind that this is running while the RFM12B transmitter is on, drawing 21 mA. This case was about the ATmega powering down between each byte transmission. Using my scope’s math integral function, I measured 52.8 µC for standby vs 60.0 µC for power-down – so we’re talking about a 12 % increase in power consumption during transmit!
The explanation for this seemingly contradictory result is that the power-down version adds a delay before it actually sends out the first byte to transmit. In itself that wouldn’t really make a difference, but because of the delay, the transmitter stays on noticeably longer – wiping out the gains of shutting down the main clock. Check this out:
Standby is the saved white reference trace, power-down is yellow.
See? Ya’ can’t always predict this stuff – better measure before jumping to conclusions!
PS. While I’m at it – enabling the RF12’s “OPTIMIZE_SPI” mode lowers charge usage only a little: from 52.8 to 51.6 µC, i.e. using fast SPI @ 8 MHz i.s.o. 2 MHz for sending to the RFM12B. Hardly worth the trouble.
Hmmm, interesting results!
But I don’t get it completely at the moment. I understand that, as the processor gets an interrupt, this interrupt is handled a bit later in power-down than in standby, as the oscillator first has to start up. The time between interrupts stays the same, as the transceiver will request a new byte every ~200us (we are looking at transmitting in the pictures above, aren’t we?).
Why is the first ‘sending’ delayed by ~500us in power-down? This is ~8000 cycles.
I don’t know, puzzling indeed. It’s repeatable, and all I change is arg 2 to arg 3.
It does look like the ATmega already has the clock running, even before the transmitter is turned on (white trace is 0.5 mA higher at the left of the screen).
Yep, sorry for the confusion. I’ve adjusted the text.
Would be interesting to see the signal at the resonator. Does a startup delay of 258ck cycles take ‘longer’ on the first startup after a longer power-down than on subsequent startups? It can be seen that the power drawn goes up after the first interrupt and stays at this level for much longer (~300us) before the processor becomes active than on the next interrupts where we see the abovementioned 40us.
And, yes, it is strange that the ‘white’ clock is already running at the left edge of the scope screen (can we have a look at what happened before, please :-) ?
I can’t retro-actively produce that previous screen shot, but perhaps this one helps?
Are you sure about the delay before the first byte? For me it looks like the RFM12 starts sending the moment you enable the transmitter. As soon as the preamble is sent is requests the first data byte. According to my measurements there are two bytes sent before the RFM12 requests a first byte from the ATmega.
But there is one more difference. After the last byte is sent the power-down version needs longer to switch off the transmitter. Isn’t it possible that the energy is lost there?
Thomas,
I think it is pretty obvious, where the ‘energy’ is lost. It is roughly visible as the ‘area’ under the two curves between the ‘sending’ of the first ‘white’ byte and the first ‘yellow’ byte. The area below the two curves is rougly 2500us x 20mA ‘white’ to 2900us x 20mA ‘yellow’, so the yellow code needs ~16% more ‘juice’.
And I think you are right, that the first two (preamble) bytes are sent as soon as the transmitter is enabled. There is still the question, why the first ‘yellow’ data byte is so much delayed!?!