Go Down

Topic: When sleeping helps (Read 11682 times) previous topic - next topic

Coding Badly

Any recommendations for making this less cluttered, feel free to provide.


There are no references to sleepHandler.  You could remove it.

Coding Badly

#16
May 05, 2013, 10:44 am Last Edit: May 05, 2013, 10:49 am by Coding Badly Reason: 1
Code: [Select]
 delay(2000);     // Unsure what this does but it was included in the one-wire tutorial

I believe that's to allow time for the conversion.  I also believe it's only necessary for parasitic power.  How are you powering the 1-Wire device?

In either case, it should be replaced with a blink-without-delay pattern; a while-loop polling for 2 seconds to elapse.  In the while-loop body put the processor to sleep (Idle mode).

afremont

750mS is the recommended minimum conversion time allowance, regardless of power mode.  That's for a 12-bit conversion.  The OP could cut that long delay in half at least.  12 bits is the default for a new part, but I believe it can be overridden by a flashable programming setting. 
Experience, it's what you get when you were expecting something else.

Coding Badly

750mS is the recommended minimum conversion time allowance, regardless of power mode.


I believe, when the device is fully powered, some devices can be polled for completion.  I recall the temperature sensor I was using took considerably less than 750ms.

afremont

#19
May 05, 2013, 11:14 am Last Edit: May 05, 2013, 11:30 am by afremont Reason: 1

750mS is the recommended minimum conversion time allowance, regardless of power mode.


I believe, when the device is fully powered, some devices can be polled for completion.  I recall the temperature sensor I was using took considerably less than 750ms.



That's absolutely correct, but I've never actually timed any to see how long they take.  Do you recall how much less it was?  I'm a big fan of the 1-wire stuff, have been for many years.  I've also found that many times you can get away with doing a conversion using parasite power mode, but not supplying the so-called "strong pullup" on the bus.  Only one device at a time though.  Which reminds me of one other piece of probably useless trivia.  You can do a SKIP ROM and then start a conversion on all the devices on the bus simultaneously.  Conversions using less bits of precision take substantially less time to complete according to the datasheet.

EDIT:  I've had good success using a PIC I/O pin to power the 1-wire bus when awake and then powering it down when sleeping, but I wrote it in assembler so it was relatively easy to insert the control code.  Now that I've thought about it as long as it took me to type this, it probably wouldn't be that hard to wrap the library code with something to accomplish the same thing.  Possibly just powering up after sleep and down just before, but you probably have to wait up to 60uS for the RESET pulse from the temp sensors after releasing the bus from reset mode.  I don't know if you have to hold the bus in reset mode for an extra 480uS before releasing it after applying power.  Experimentation would be in order on that.
Experience, it's what you get when you were expecting something else.

fungus


Do we have data on how much power is consumed by an actual Arduino board in Sleep vs running, for various power sources?
I think I've dismissed this as "it doesn't get low enough for long-lived battery operation", but it occurs to me that that is not at all the same as "not significantly lower."


Most of the power consumption is from the other chips on the board.

I don't think "long-lived battery operation" is realistic with an Uno. If that's what you want you'll have to start with something like this: http://evilmadscience.com/productsmenu/tinykitlist/180


Advanced Arduino

tlharv

My long-term plan isn't to use my Uno for the final application; I'll use it to make the thing work, then build my own barebones or standalone unit with either an ATmega328 or an ATtiny85.  I know I'll have to peruse the ATtiny85 datasheet to get the addresses & settings correct, as they're probably different than the '328P.  But the approach & program structure should be the same.

tlharv

Quote
How are you powering the 1-Wire device?


On my breadboard, I'm powering the 5V rail straight from the Uno 5V pin.  The temp sensor gets its supply voltage from that rail.

afremont


My long-term plan isn't to use my Uno for the final application; I'll use it to make the thing work, then build my own barebones or standalone unit with either an ATmega328 or an ATtiny85.  I know I'll have to peruse the ATtiny85 datasheet to get the addresses & settings correct, as they're probably different than the '328P.  But the approach & program structure should be the same.


Building your circuit out on a new board with an efficient regulator, you'll be able to get average power consumption down to near nothing.  If you really want low power usage, look at running at relatively slow clock speeds such as 32kHz.  The power requirements become surprisingly low at those speeds.  You can be running and only consuming way less than 1mA (more like hight 10s or low 100s of uA) if you use a low voltage too.

Your big power consumer will be keeping the 1-wire bus powered during the lengthy temp conversion. 
Experience, it's what you get when you were expecting something else.

Coding Badly

Do you recall how much less it was?


I don't.  Just enough less to make it worth investigating.

Coding Badly

#25
May 05, 2013, 08:25 pm Last Edit: May 05, 2013, 08:30 pm by Coding Badly Reason: 1

Quote
How are you powering the 1-Wire device?


On my breadboard, I'm powering the 5V rail straight from the Uno 5V pin.  The temp sensor gets its supply voltage from that rail.


Change that to an I/O pin.  You will have to add code to "power up" the sensor after the processor wakes and "power down" the sensor before sleeping.  As @afremont mentioned earlier, you may need a short delay to give the sensor time for a bit of coffee.

Change the code to poll for the conversion to complete rather than waiting a fixed amount of time.

afremont

I'm not trying to start an argument, but I was just thinking that it might be an interesting case study to see where (or if) there is some break even point is on polling vs. just waiting it out with a slowly clocked CPU.  I'm wondering if there might be some point where beating on the bus dissipates more power than just waiting it out.  I really wish I knew now how much time you can shave off that 750mS with polling. 

Argh this is why everything takes me so long, I get obsessed over the most mundane oddities that I uncover in some code until I completely understand what is happening.  I spent a couple of days obsessing over the dropped time from delay() when micros() rolled over.  Found it though.  Now I feel 1-wire timing tests creeping up on me.  ;)
Experience, it's what you get when you were expecting something else.

DamonHD

I have implemented both 'running the CPU clock with maximum prescaling' (which gets me 31.25kHz) and sleeping with watchdog timer.  I use the former for delays too short for the latter.

See the following for some experiments:

https://sourceforge.net/p/opentrv/code-0/HEAD/tree/trunk/Arduino/test/BlinkPower/BlinkPower.ino

Busy waiting with a slow CPU was taking ~3mA, which is a decent saving over running flat out, but sleeping with the watchdog timer takes maybe 1000th of that for me I think. (I confess that I was measuring power-save sleeping against the async timer 2 clock towards the end, rather than the watchdog, but I the datasheet seems to agree with me.)

Sleeping waiting for an interrupt can also be beneficial, eg for the ADC, if it's not too fast that the interrupt latency is a problem.

Rgds

Damon


Coding Badly

#28
May 05, 2013, 09:56 pm Last Edit: May 05, 2013, 09:58 pm by Coding Badly Reason: 1
I was just thinking that it might be an interesting case study to see where (or if) there is some break even point is on polling vs. just waiting it out with a slowly clocked CPU.


You bring up a good point.  Polling may not be the best choice.

Polling vs waiting (sleeping it off) is more of an application question.  How quickly does the device need to get the data and react?  If the wait time is irrelevant then sleeping it off is the best choice.  My suspicion is that @tlharv's application could just sleep for the 750ms.

Polling is easily made efficient by bisection and sleeping (tweaked by the application requirements).  For example...
- Start the conversion
- Sleep for 750 * 1/2 ms
- Poll for completion.  If the conversion completed, mark the high time as 750 * 1/2, the low time as 750 * 0/2, and finish up.
- Sleep for the other half (another 750 * 1/2 ms)
- Conversion has to be completed, mark the high time as 750 * 2/2, the low time as 750 * 1/2, and finish up.

The next time around, we know to either sleep 750 * 1/4 ms or 750 * 3/4 ms to split the range in half.  Each time around, the range narrows and the sleep time becomes more precise.  Quickly we arrive at the perfect sleep time.  The process becomes...
- Start the conversion
- Sleep for the perfect amount of time
- Poll to ensure completion (make any necessary minor adjustments)
- Finish up


Now I feel 1-wire timing tests creeping up on me.  ;)


Resist.  ;)

DamonHD

@CB: conversion time may vary from sample to sample depending on the sensor/ADC/etc...

Rgds

Damon

Go Up