WP34s Power Proc-Speed Performance

[MarkHaysHarris777]

Greetings, I suspected that my batt might be low on this used 20b, for several reasons not limited to some flaky behavior, so I decided to take the batt reading under processor load (stress), even though the batt reading at rest was 2.8-2.9/ the code follows, then comment:

Code:


LBL  'A01'
TICKS
LBL  33
DSE  00
GTO  33
TICKS
BATT
END
-

Comment: Prior to running this silly counted loop, make sure to load register '00' with some large value... I chose 20,000. The battery annunciator came on almost immediately, the unit shifted into proc 'slow' mode and the program completed in about 150 ticks (fifteen seconds); the posted batt reading was 2.5 at the end of the run.

I decided to run this same program on my other units (currently playing with three of them) the 30b(s) indicate 3.0v at rest; the one gave a stressed batt reading of 2.7 (unit B) (with annunciator flicker) and the other gave a stressed batt reading of 2.6 (A) without annunciator. The units did appear to run at different speeds; however, they were not consistent. Unit A came in at 8.7 seconds, while unit B came in at 14.3 seconds. The second time I ran unit A, it came in at 11.4 seconds.

It would be interesting to know how speed stepping works here. Is there more than one step? Under load does the processor speed toggle depending, or once it steps down does it remain there?

... will be interesting to watch the mA reading (if the silly thing ever gets here).

marcus

[MarkHaysHarris777]

PS ... sometimes the 20b actually shuts-down during the run/ that's it, replace batts.

PSS ... probably should mention that to get the seconds with this program after the run, roll the stack down then swap x<>y and finish with (-) which gives the total number 1/10 seconds (ticks). You could divide this by 36.0e3 and run the value through (fgold) H.MS to get minutes seconds



(questions remain though)

[Marcus von Cube]

(02-13-2015 10:01 AM)MarkHaysHarris777 Wrote:  It would be interesting to know how speed stepping works here. Is there more than one step? Under load does the processor speed toggle depending, or once it steps down does it remain there?

While running a program the speed is set to the available maximum. This maximum is automatically reduced to SLOW mode (about half the maximum frequency) when the voltage reading is below a certain value. The reading may go up again when the speed is reduced, causing a switch to full speed, causing the voltage to drop, and so forth...

[MarkHaysHarris777]

(02-13-2015 06:46 PM)Marcus von Cube Wrote:  

(02-13-2015 10:01 AM)MarkHaysHarris777 Wrote:  It would be interesting to know how speed stepping works here. Is there more than one step? Under load does the processor speed toggle depending, or once it steps down does it remain there?

While running a program the speed is set to the available maximum. This maximum is automatically reduced to SLOW mode (about half the maximum frequency) when the voltage reading is below a certain value. The reading may go up again when the speed is reduced, causing a switch to full speed, causing the voltage to drop, and so forth...

Thanks, Marcus; that's what it looked like to me, but its good to hear it straight from the tech guy for the innards of this instrument. Thanks, again.

PS Well, I have an update... having replaced the coin cells in all three units--- all units have become stable and consistent (big surprise).

The batt value at rest is 3.2v, the batt value under load is 2.9 or 3.0, and all three units run in 'fast' mode at or under 9.0 seconds using the tight loop above with an initial counter of 20,000 (my 30b [A] unit came in at 8.7 seconds).

I'm in the process of making a 3.0v battery supply (C cells) that can be easily attached via coin-plugs and cable (pics coming later) for long looping, and for update or program transfers.

Cheers,
marcus

[MarkHaysHarris777]

Greetings, having completed my first pass at making a power-plug for a stand-alone battery pack (for updating, long loops, &c) decided to post a pic with my update on the power requirements of my 20b wp34s in a tight loop:



The program is the same as above; however, I had to set the counter much higher to gain some time for manipulating the camera. The battery pack is attached through a bass wood plug with appropriate brass fittings (glued in place with wood modeling cement). I intercepted the current flow at the battery terminal for connection to the Triplett VOM, and took this pic while running the counted NOP loop. The run exited in 9.0 seconds flat with a load voltage drop of 3.0v and a steady current of 19mA ( I have the meter set on the 60 mA scale, look at the inside track ). So we're looking at 57 mW for this test.

Obviously 20 mA is too much drain to be expected from coin cells (even two of them) for very long. I need to make my battery pack a little more permanent so that I can reliably use it for extended runs, for updating, and for program and data tranfers peer to peer. I'm actually thinking of a battery docking station (yes, in a cigar box) with battery pack, mA meter, cabling and IR transmitter (need to give that some more thought).

Cheers,
marcus

[MarkHaysHarris777]

hola! ... I'm back with an update from the lab with additional information regarding the 20b WP34s power consumption in 'slow' m-o-d-e / So, for this test everything is setup just as before; the difference being that I ran the 'SLOW' function to drop the processor frequency (according to Marcus, to about half of what 'fast' was...). Again, for the pic I increased the counted loop to gain some camera time...




It took almost twice as long to complete the 20,000 run; this time the voltage drop under load was 3.1v, with a steady current of 8.5 mA ( or power dissipation of about 26.4 mW , ~the power dissipation listed in the 20b specs! )

So, the lesson here is that you will literally cut your power consumption in half ( delta of -53.8 % <decrease> 26 mW-minute vs 57 mW-minute) by setting your proc frequency to 'SLOW' prior to long loops, data transfers, or updates.

Cheers,
marcus

[matthiaspaul]

(02-13-2015 10:54 PM)MarkHaysHarris777 Wrote:  So, the lesson here is that you will literally cut your power consumption in half ( delta of -53.8 % <decrease> ) by setting your proc frequency to 'SLOW' prior to long loops, data transfers, or updates.

But you basically won't gain anything in regard to the needed energy, since you need twice the time (ignoring some chemical processes inside the battery, which differ depending on the load)... ;-)

FWIW the observed trade-off of speed versus current is what can be expected from a processor manufactured in CMOS (complementary metal-oxide semiconductor) technology. One characteristic of this technology is that a cell consisting of two complementary MOSFETs draws measureable power only in state transitions, whereas in the static phases between these transitions, either one or the other transistor is always off (and the complementary one always on, respectively), so that no current can flow from supply to ground except for in those moments of state transition. So, the power consumption is a linear function of clock frequency - down to virtually zero when the clock is off.

Greetings,

Matthias

EDIT: For easier reference more threads on similar topics:

http://www.hpmuseum.org/forum/thread-3453.html
http://www.hpmuseum.org/forum/thread-3336.html
http://www.hpmuseum.org/forum/thread-3077.html

[MarkHaysHarris777]

(02-13-2015 11:35 PM)matthiaspaul Wrote:  

(02-13-2015 10:54 PM)MarkHaysHarris777 Wrote:  So, the lesson here is that you will literally cut your power consumption in half ( delta of -53.8 % <decrease> ) by setting your proc frequency to 'SLOW' prior to long loops, data transfers, or updates.

But you basically won't gain anything in regard to the needed energy, since you need twice the time (ignoring some chemical processes inside the battery, which differ depending on the load)... ;-)

FWIW the observed trade-off of speed versus current is what can be expected from a processor manufactured in CMOS (complementary metal-oxide semiconductor) technology. One characteristic of this technology is that a cell consisting of two complementary MOSFETs draws measureable power only in state transitions, whereas in the static phases between these transitions, either one or the other transistor is always off (and the complementary one always on, respectively), so that no current can flow from supply to ground except for in those moments of state transition. So, the power consumption is a linear function of clock frequency - down to virtually zero when the clock is off.

Greetings,

Matthias

What was it that the 'BORG' said to Data, "... you think so three dimensionally!".

The gain is not in energy over time (which can neither be created nor destroyed, only transferred); rather, the gain is in performance and critical load balancing. Its better to have a long loop running x2 with a lower voltage drop because it is more likely that the voltage drop will remain above critical threshold and the damn thing won't shut down mid process! By the way, if that happens, it is possible to lose everything in the system! If we keep the current low, the voltage hi, and the process stretched out over some time we get better performance and avoid the power-off-in-the-middle-glitch.

Also, coin cells will recover better from lower current over time, than huge current draws over short time. The power consumption over time will be the same regardless, but the overall performance of the system will be better at slower proc frequency.

Cheers,
marcus

[MarkHaysHarris777]

(02-13-2015 11:35 PM)matthiaspaul Wrote:  One characteristic of this technology is that a cell consisting of two complementary MOSFETs draws measureable power only in state transitions, whereas in the static phases between these transitions, either one or the other transistor is always off (and the complementary one always on, respectively), so that no current can flow from supply to ground except for in those moments of state transition. So, the power consumption is a linear function of clock frequency - down to virtually zero when the clock is off.

Yes. This is measurable as well, with the setup above. At rest the current drain is virtually zero; I think I measured (not sure how accurately) something just less than 200 microAmps... 0.2 mA. During a square-root the current spiked quickly to 5 mA and quickly dropped back to zero. The CMOS gates are voltage logic... the high is tapped directly to Vcc, and the low is tapped directly to Grnd; no current flows except very briefly at transition; which is nice, because it allows us to power these hand-held super calculators with coin cells! The problem is that when the coin cells begin to die they still have a 'surface' voltage that reads near 3.0v, but which cannot sustain a 57 mW-minute. Marcus confirmed that the speed-stepping will try to auto-adjust up if it can; I think it should be designed so that if a shift down is necessary, it stays down! Consequently, I think its better to use the 'SLOW' function to set the frequency low from the get-go when we know that high current draw is going to be a problem.

PS Since I installed fresh cells the 2 second power-on delay has been corrected. I had a situation where the BATT reading was 2.9 (should have been high enough) but the system was losing power, forcing the power-on to reinitiate crystal calibration (Marcus knows the details).


Cheers,
marcus