Reducing propeller power consumption

heliboy

I have a battery powered application, but I am concerned about the high power consumption of the propeller. In my previous experience with PICBasic it is possible to reduce power in idle conditions by commands such as SLEEP. I have found no such command for the propeller. I need the 80mHz speed because of high baud rates but I only need to operate for 5·seconds every 30 minutes. Based on the circuit I have on the professional dev board I measure 83 mA in idle (on main 12V supply), 135 mA when all the 5V circuits are switched on (5 seconds) and then to 150 mA when transmitting on the RF (1-2 seconds). If I measure the power on the 3.3V rail I use on 0.33mA and this is essentially constant. The 5V rail is 0 mA at idle and 15mA when transmitting (the prop controls a relay that switches the 5V rail on and off). I was able to reduce the idle power (12V input)·to 70mA by·stopping the external cog runing MCP during the idle time. The RF Transceiver code (thanks to Beau) and some one-wire routines run in Cog0, but Cog is paused (power consumption ?) using the WaitSyncmSecs routine in the clock object obtained from the prop exchange.

I would very much appreciate any ideas for reducing power consumption. Even a 70mA draw for 30 minutes adds up to a big battery and it is particularily·inefficient since I only need it to operate for 5 secs. I could put an external PIC to turn power on and off to the prop every 30 minutes but this seems a bit stupid that the prop would need a power nanny !

- Heliboy

Beau Schwabe

heliboy,

What is the Propeller doing during the 30 min 'rest' periods? ...and do the wakeup periods need to be at exact intervals, or can they be approximate time periods. What if any external events would there be to act as a trigger to wake the Propeller up?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

heliboy

Hi Beau:

Nothing really. Just waiting for the next time to transmit. Now the idle time is adjustable from 10secs to 60 minutes (via pot).

General scheme :

repeat

... clock.MarkSync

....MCP.start, turn 5V power on etc

... perform calculations

... transmit RF

... clock.WaitSyncSec(5)· ' must complete within 5 secs

... clock.PauseSec(Datasecs) ' IDLE time - wait for Datasecs·( for 30 minutes = 1800-5 seconds )

... back to repeat



Thanks,

Duane Degn

heliboy,

what about something like this.

PUB SendData
  
  
  
    
        
  repeat
    repeat 35  ' or however many times make the delay you want, could be a variable controlled by pot.
      waitcnt(1 + cnt)  'This will wait for counter to roll over
    {Turn stuff on, send data, turn stuff off.}

My power supply shows about 40ma.· I have measured it accurately.· And, as I think what Beau getting at, this isn't very precise.· If you don't need the precision, I think it uses less power than the clock object.

Duane

pjv

Heliboy;

You can get power consumption down to as low as a few micro amps if you turn off all the Cogs except for one and have that do the delay timing for you. That low current requires the clock to run at 20KHz (Internal RCSLOW) while the unit is "sleeping". Then, on time-out, simply crank the clock back up to 80 MHz, and get your work done. Then slow the clock down and go back to the long sleep.

Unfortunately the 20 KHz internal oscillator is not very precise nor stable with temperature. It is easy to get a 10% variation, and if that is not suitable, then some method of introducing more precision is required. This is a bit of a hassle, but should be able to be accomplished by waking up much more frequently, and calibrating the 20 KHz to the 80 Mhz (5 Mhz crystal) you have on board by timing the charge rate of an RC circuit at both clock rates.

I am currently exploring this and expect to get to a few tenths of a percent by calibrating once per second, yet not increasing the average current due to the extra calibration procedure too high..... values to be determined.
My target is 3 years of operation on 3 "D" cells with the processor being awake at 80 MHz·for 2 to 5 mSec every minute, and making a cell phone call-out (2 Amp peaks) once per day.

Hope that helps.

Cheers,

Peter (pjv)

Post Edited (pjv) : 3/22/2010 4:38:16 PM GMT

heliboy

Duane:

I tried your suggestion but it did not make any significant difference - maybe 0.5mA. Yes, I do not need great precision, but I do not have any external triggering event except timing.

Heliboy

heliboy

Peter(pjv):

If I understand you right - I need to move my code to say cog1. Leave only the timing routines in cog0 which I believe cannot be stopped. Run cog0 at 20kHz and then execute the main code at 80Mhz in cog1, shut down cog1, crank down to 20kHz and then wait for the next timing event. Correct ?

- Heliboy

pjv

Hi Heliboy;

As usual, I'm thinking only in terms of assembler, but presumably you are running SPIN, evenso what you describe should be correct. I have not much experience at SPIN, but I assume that a WAITCNT consumes the same power in SPIN as in PASM.

The calibration routine might need to be written in assembler unless you can create that with your required precision/repeatability in SPIN. Perhaps the cog's built in counter modules operating in logic mode can help here.


Post edit;

OOPS, forgot to mention to be very sure you observe the timing requirements in switching from internal RC clocks to crystal clocks. If you use the crystal before it has stabilized, the PLL will not lock on properly, and you'll have trouble. The specs ask for 10 mSec, but I have found that the time required is a function of how long the oscillator has been out of the crystal mode. By waking up often enough (don't recall the numbers just now) I was able to get it to come up without any delays...... so please experiment to find your sweet spot.... 10 mSec is a long time if you need absolute minimum current.

Another answer is of course to add an RTC at 32 KHz to wake the unit up.... but that's more parts.


Cheers,

Peter (pjv)

Post Edited (pjv) : 3/22/2010 5:23:15 PM GMT

Tracy Allen

Heliboy, there is no need to run in a separate COG. All COGs always run at the same speed, whether that be at 20kHz for low power, or 80MHz for time-critical tasks. Here is SPIN to switch from 20 kHz (nominal) to 80mHz (xtal with PLL). Note that this runs at12MHz (RCfast, nominal) for about 10 ms to allow the xtal and PLL to ramp up. The transition from 20kHz to 12 MHz is practically instantaneous, so that can be used for fast response if necessary.

clkset($01, 20_000)    ' using RCslow
  ' ... some time at low speed, microamps.
clkset($68,  12_000_000)  ' oscillator & pll warmup,  using RCfast in the interim
' response critical task goes here
waitcnt(cnt+120_000)  ' approx 10ms at 12mhz 
clkset($6F,80_000_000) ' switch to pll16x, 80mhz
' now can go to frequency critical and other tasks

If you have real time clock, it can supply a periodic 1 second heartbeat or an alarm that can be sensed by the RCslow via a waitpin, to get accurate timing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

heliboy

Thanks for all the responses. Using either the waitcnt or the clock routines reduce the power consumption almost to that of stopped cog. Setting the clk speed as suggested by Tracy and Peter also work to reduce the idel power further. The thing that is making power measurement somewhat difficult is that the Parallax professional development board has a power draw of around 43.3 mA measured at the 12 volt input terminals. I am using a 9V battery so no error from an AC adaptor. I get a power draw of 42.3mA even if I take out the prop chip completely ! Does anyone know what causing this power draw ? I have no connection to the 3.3 or 5 V busses.

-Heliboy

Mike Green

There's both a 5V and a 3.3V regulator and both have some idle current. I believe there's an LED "pilot light" on the 5V supply and there are some other ICs (headphone amp, stepper driver, RS232 level converter, etc.) that are powered from the 5V or 3.3V supply all the time. All these small current draws could easily add up to 40mA or so. The PDB was not designed for very low power operation.

Tracy Allen

Here is a comment early on from Chip Gracey about the design of the Propeller as it relates to low current drain.

By the way, the Demo Board has a plug-in jumper between the power supply and the Prop power pin, so you can measure its current directly, independent of the regulators and the peripherals.

Following up on what Mike said, in order to realize the lowest possible current you will have to move your project onto a board that has only the needed peripherals, with good power management, and if the regulators will have to be high efficiency types with micro-Amp level quiescent currents.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

heliboy

All:

I have got the base load (no prop) down to 3.89 mA. This is basically the 5V and 3.3V regs. With the prop, using the tricks to choke it down to 20kHz the draw is about 23 mA. This seems to be about the best possible. When the prop is speeded to 80MHz the current is about 70mA When all the peripherals are active the draw goes upto 130mA and when actually transmitting it peaks at 150mA. Much improvement in the idle state, but not microamps ! I could replace the voltage regs with better efficiency devices but the prop is still the major load even when idle.

Thanks to all. - heliboy.

Leon

If you want low power forget the Propeller and use something like an MSP430 or an XLP PIC. The PICs typically take 20 nA in deep sleep mode, and as little as 500 nA with the RTC running.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

Post Edited (Leon) : 3/23/2010 7:39:37 AM GMT

Phil Pilgrim (PhiPi)

heliboy,

Make sure you don't have any floating inputs, as they can make the Prop draw excessive power. Either use pull-ups/pull-downs or set unused pins to outputs to reduce power consumption.

-Phil

Humanoido

Phil said...
Make sure you don't have any floating inputs, as they can make the Prop draw excessive power. Either use pull-ups/pull-downs or set unused pins to outputs to reduce power consumption.

Phil: that's a very good idea. What is approximate excessive power draw when the pin input floats? Thanks.

humanoido

Leon

It's about the same as the length of a piece of string.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

Phil Pilgrim (PhiPi)

humanoido said...
What is approximate excessive power draw when the pin input floats?

Not sure what the #@*% Leon's on with. The answer depends on where an input is floating. The problem occurs when its level is near the input logic threshold, which can cause the internal circuitry either to oscillate or to operate in its linear region, both of which can draw excessive current.

-Phil

Leon

I meant that it's impossible to give even an approximate figure - how long is a piece of string?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

Post Edited (Leon) : 3/23/2010 6:14:45 PM GMT

Phil Pilgrim (PhiPi)

Ah, got it.

-Phil

Tracy Allen

Excess current for a single input pin peaks at about 1.2 mA. I measured (a couple of years ago) by scanning a triangle ramp up and down through the threshold and monitoring the power supply current. Subtract the baseline current from the peak current. The baseline current is with the pin at 0 or 3.3 volts I posted a graph somewhere, but can't find it now.

The peak is very narrow, and is due to the fact that both p and n channel transistors are conducting at the crossover point of the totem pole input structure in order to speed up the transition. I expect there would be variation from this length of string to that, but the string does have a characteristic curve. A floating pin subject to AC pickup and noise may draw an excess of only 50 or 100 µA, because it does not stay right at the threshold. This current and its fluctuation is especially important in limiting the performance of things like RCTIME and sigma-delta conversion, because they purposely hover the input at the transition point.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Post Edited (Tracy Allen) : 3/23/2010 6:47:34 PM GMT