Does anyone know if the battery life of the new HP 15c LE is comparable to the battery life of the HP 12c+? I think they use basically the same package, just a slightly different exterior ? If so what has been the battery life of the HP 12c+? (Beside what is advertised in the manuals)

Reason being is that my 3 year old HP 35s is, for the 1st time giving me a low battery warning. I'd like to think that I have used the HP 35s quite heavily. And if the HP 15c LE (or HP 12c+ if they are the same internally) can give me around 3 years of use on one set of batteries, I personally would think that is a pretty darn good in this day and age.

Katie Wasserman and others have documented very high power consumption in the 15C LE, so it's very doubtful that you'll get near the battery life of a 35s. I've been using a 15c LE regularly for 4 months, and the batteries are not yet spent, but I don't run a lot of time consuming programs. One thing you don't want to do is hold buttons down for extended periods.

Edited: 1 Jan 2012, 10:51 p.m.

You're out of luck. The power consumption is way too high on the 15C LE with the current fir mare and the low battery warning doesn't work.

Here's a summary of the known problems. You'll find more details, if you want them, by searching this forum.

You beat me to the pumch by 1 minute!

This may be old news, and it does not directly address Poindexter's question, but it's an interesting data point. The Introduction to the original 15C Owner's Handbook has four bulleted items touting the calculator's features:

*******

* 448 bytes of program memory (one or two bytes per instruction) and sophisticated programming capability, including conditional and unconditional branching, subroutines, flags, and editing.

* Four advanced mathematics capabilities: complex number calculations, matrix calculations, solving for roots, and numerical integration.

* Direct and indirect storage in up to 67 registers.

* Long-life batteries.

*******

The Introduction to the 15C LE Owner's Handbook repeats the first three items word for word (the new Handbook was intended to duplicate the original exactly, as far as I know), but it omits the last item. A reasonable conclusion is obvious.

Hmmm, is there any reason why the HP 15c LE does this but not the HP 12c+?

Also i tried installing the old batteries from the HP 35s into my HP 15c LE. I got a "Pr error". Which is fine considering how low it might be (i didn't have any Programs on the 15c LE). But is the original HP 15c (or LE) designed with some sort of fail safe when the batteries are TOO low? Because I could not do anything. Pressing any key turns it off completely, and turning it on would just display "Pr error" again.

Edited: 2 Jan 2012, 8:28 a.m.

I have been using my 15C LE since October and it is still on its original batteries. Usage is anywhere from 2 to 10 hours a week.

Quote:

---

Hmmm, is there any reason why the HP 15c LE does this but not the HP 12c+?

---

The keyboard scanning code in the 15C LE appears to not be the same as the code used in the 12C+, if it were the 20ma key-down current draw would not happen. Both the 12C+ and the 15C LE have poorly functioning low battery warning code as well as non-functioning brownout detection. Translation: it's incredibly easy to lose memory with low batteries, as you apparently have already discovered.

Quote:

---

Here's a summary of the known problems. You'll find more details, if you want them, by searching this forum.

---

Is there also a list of known problems or bugs for the HP35s ?

Thank you,

Kees.

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=735

Power saving on this type of device (with the added complication of the supply by two coin cells) is more of an art than exact science. The WP 34S is essentially the same device with a slightly more demanding display. I've put considerable effort into the power saving.

There are several modes of operation with varying demands on the power source. From full speed (1) to half speed (2) to medium speed (3) to idle mode (4) to deep sleep (5) to backup (6).

I know that (1) is too demanding on the coin cells and thus disabled when the battery voltage falls below a certain threshold. (2) is tolerable but the time for some computations increases noticeably. (3) is fine for routine tasks like keyboard scan but not for any serious computations. (4) allows interrupts to be active because the kernel is running but the processor clock is stopped unless an interrupt occurs; all RAM is active in this mode; I keep the calculator in this state for some tenths of a second to allow house keeping(*) and very fast reaction to user input before switching to the next state. (5) shuts down much of the device but the display is still showing; this is the mode you will see most of the time when the calculator waits for user input; the keyboard is active in a special wake-up mode, restarting the processor; this costs a little in terms of processor cycles because all state in the 4KB working RAM is lost and has to be rebuilt. (6) is the state when the calculator is apparently off; only the 2KB backup RAM are kept alive.

Choosing the best of these mode for the varying requirements isn't easy...

(*) House keeping includes monitoring the battery voltage and scanning the keyboard.

Edited: 2 Jan 2012, 5:55 p.m.

Hi Marcus,

I wonder (with little hope) if there is a hardware pin (or pad, trace or whatever) that may be used to signal the power state of WP34S. Such signal may control an external power supply, leaving the CR-2032s just for RAM backup purposes when everything else is turned off. When the calculator is not sleeping, the external power supply should turn itself on, and supply the needed current without exhausting the CR2032s. Such power supply may be just a simple circuit powered by two AAA batteries, and located on a yet-to-be-created holder fixed to the back of the WP34S.

(A less-polished implementation may use just a couple of AAA batteries and steering diodes).

Do these problems pertain only to the LE or do some of these pertain to the original one as well? Is there a bug list for the original someplace here or elsewhere?

There's nothing mentioned here... Link

Regards,

John

There sure isn't. Thank you.

Hi Katie,

I confirmed the high current draw issue of the 15C LE on the recently arrived my 15C LE.

The measurement have been done using a current sense resistor and a digital oscilloscope, and found an interesting behavior at a key press.

Confirmation of the High power comsumption issue of the HP-15C LE.

Regards,

Lyuka

Edited: 3 Jan 2012, 7:20 a.m.

Setting a pin to high when not idling is certainly possible. There are pads on the board which might be interfaced. What you would need to implement in hardware is something that disconnects the coin cells while the power supply is active.

You can run the calculator without any coin cells by feeding power through the serial connector or the jtag connector. Before you disconnect the power, just do an ON+STO backup to flash. The restore will be automatic with the next power on after a memory fail.

I'm a bit envious. ;-)

This is exactly the kind of measurements I'd like to see for WP 34S. Test cases would be off, on (idle), deep sleep, wake-up (after half a second of idling the calculator goes to deep sleep; a key stroke will wake it up), a simple operation (ENTER), demanding operation (LOG, program), and flash write (ON+STO). This would help to identify any bugs in my power saving scheme.

Another test would involve a gradual lowering of the supply voltage to test the brown out detection algorithm. With the battery symbol lit, the above tests should give different results because high speed is disabled (you can force this with the SLOW command).

All of the bugs or issues described in the 15c LE bug list article pertain only to the new 15c Limited Edition running firmware revision date 2011-04-15. However, after the 15c LE was released, an issue with the original was discovered, as described in this thread.

Quote:

---

What you would need to implement in hardware is something that disconnects the coin cells while the power supply is active.

---

I prefer Linear technology's LTC4413 for that purpose.

Lyuka

Lyuka,

Nicely done!

I'm not sure which part of the waveform you are revering to as "interesting", the little dip right after the key is pressed? Also, is the 42ma current spike an artifact of the way you did made the measurements, perhaps switching power on?

-Katie

Edited: 3 Jan 2012, 10:10 a.m.

Katie,

Quote:

---

the little dip right after the key is pressed

---

The high current spike might cause memory error when the battery's internal resistance got high.

Lyuka

Edited: 7 Jan 2012, 12:44 p.m.

I converted my HP-30b (repurposed to a WP-34s) to 2x AAAA-style cells taken from a 9V battery. Mounted behind the screen.

Hole cut in the casing to accomodate the 2 cells:



Just right to fit the cover back on and hold it all in place:




NOTE: These cells that I extracted from the 9V battery had THE OPPOSITE polarity to that expected.

I applaud your ingenuity!

It looks like you need to solder in replacement cells, I would think that this would be more inconvenient than keeping around a large bunch of spare 2032 cells.

Well, for me that is not a problem, I am quite happy to solder. These cells are from a 9V battery (thanks to your mention of it :-) and come nicely tabbed together and can be separated into 3 pairs, so it's just a quick desolder and resolder. I can pop in a CR2032 to save the memory whilst doing so. Also I paid £7.00 for 10 Procell 9v, that's £0.12 (or ~USD 0.20) per cell. I don't think I can find CR2032 cells at that price (for a decent brand).

Anyway, it is also somewhat of a proof of concept. I think this shows that with some internal re-design and no increase in dimentions, these batteries can used.

I have just completed a write-up on this: Installing AAAA batteries on the HP-30b

Edited: 3 Jan 2012, 7:11 p.m.

Quote:

---

(A less-polished implementation may use just a couple of AAA batteries and steering diodes).

---

There is benefit in simple, SoC independent switching as
this is arguably the definitive point to assess actual
current draw. Other considerations exist once the SoC is in the
decision loop such as detecting the external power supply
is actually present and supplying an in-tolerance voltage
under the prospective load. You'd likely still want to
draw from the internal coin cells if that was the only
viable power source.

I'd start with an analog approach using an unadorned mosfet
high-side switch in series with the coin cells, the gate of
which can be driven off by the external supply when it is within
usable tolerance.

Conserving current draw is of course part of a well thought
out design. But I think a more complete approach is to plan
for the eventuality of a brownout and assure all user
context is captured in nonvolatile storage. The worst case
inconvenience for a cell/battery giving up the ghost should be
finding a replacement, but not recovering data.

I assume SoC means "system on a chip", please confirm.

I think that the CR2032s should always be kept installed, so to maintain the non-volatile RAM contents. The steering-diodes (or, better, your switch, or the "ideal diodes" suggested in a previous post) should help avoiding the drainage of the coin cells while running programs.

If a small, switching power supply is to be used, it may be important to knnow the power status of the system, in order to turn off such power supply when appropriate (CR2032s will then supply the standby power). If plain AAA (or AAAA) cells are series connected without a switching power supply, there is a chance that, if their voltage drops below a certain level, the steering circuit will put them off-line, and the CR2032s will unexpectedly be at the front line again.

In any case, the "low battery" condition acquires many new meanings, and more analysis is due to avoid undetected situations which may end in data losses. And backing everything to flash all the time is limited by the maximum number of reliable write cycles available.

Please disregard any idiomatic mistake.

Quote:

---

In any case, the "low battery" condition acquires many new meanings, and more analysis is due to avoid undetected situations which may end in data losses. And backing everything to flash all the time is limited by the maximum number of reliable write cycles available.

---

Twenty thousand writes to flash according to the manual. I don't think you can achieve this with manual writes to flash every time you are about to change batteries.

Quote:

---

I assume SoC means "system on a chip", please confirm.

---

Yes.

Quote:

---

If a small, switching power supply is to be used, it may be important to knnow the power status of the system, in order to turn off such power supply when appropriate (CR2032s will then supply the standby power).

---

I wasn't envisioning a boot regulator in that picture.
If headroom is needed above the coin cell 3V, another
cell can be added in the external pack which also
simplifies isolation of the two power sources.
Alternatively if a boot regulator is used to create the
headroom it could be enabled via sensing the load current.

Quote:

---

If plain AAA (or AAAA) cells are series connected without a switching power supply, there is a chance that, if their voltage drops below a certain level, the steering circuit will put them off-line, and the CR2032s will unexpectedly be at the front line again.

---

As long as the external source is isolated, it is possible to
sense its voltage and make the decision of whether it is
suitable to power the load independent of the coin cell voltage.
Some hysteresis or memory would be needed in the voltage
sensing to prevent either oscillation or partial biasing of the
switch. Eg: a partially exhausted external supply may be sensed
at suitable voltage until connected to the load, after which
it droops out of tolerance, after which it is disconnected
and recovers back within tolerance, etc.. In that scenario the
coin cells are left enabled until the external supply is serviced.

I intended to mean "saving data to flash frequently", because it may be not clear if the CR32s are about to die...