[34S] battery warning indicator / question

[John Galt]

How do you determine when it's necessary to replace the two coin cells in a WP 34S?

I'm asking what people do in general practice. A description of the algorithm that activates the battery icon would be nice, if someone knowledgeable enough could describe it. It doesn't seem as useful as battery indicators in HP calculators, which can appear and remain visible for a long time before it's really necessary to replace them.

I suspect it is not possible to completely duplicate the behavior of the HP 30b battery indicator, but the usefulness of its implementation is less than ideal in the 34S.

The reason for asking is that it may appear briefly while doing a particularly demanding task, only to disappear later.

I'm not really concerned with losing information because I know how to back up to flash memory once in a while. I just want to know when others consider it's a good idea to replace the batteries: upon first noticing the battery indicator? When using BATT and noticing 2.9 or anything below 3? Something else?

Would it be possible (or would it even be desirable) to latch the battery indicator in software, so that once it appears it stays until the batteries are replaced?

Does HP use some super-secret algorithm that our resident 34S firmware programmers are unable to duplicate?

The problem is, if the batteries are somewhat depleted, the 34S will just crash without warning and "Restored" will appear. I am more motivated by curiosity than anything else, and am intentionally using weak batteries so I can understand how the calculator will fail when using them. I have also used a real power supply to determine the voltage at which the calculator will fail. The current can be limited but it's difficult for me to duplicate the behavior of real batteries that fail under load.

[BarryMead]

I don't know how they currently implement the low battery indicator, but I do have an idea of one way to potentially improve the reliability of the low battery indication. I think your idea of "Latching" the low battery indicator is a good one, but might need to be combined with a "Heavy Load Intelligent Sampling Time", and hysteresis to give a more representative indication of the battery life left in the cells. There may be a smart way to implement heavy load sampling. I do know that from time to time the CPU clock frequency gets changed. Perhaps whenever the software decides to increase the CPU clock rate for a program or internal operation, it could check the battery voltage at the point when it is about to reduce the clock frequency again. This should coincide with the time one would expect to see the lowest battery voltage measurements. And of course the hysteresis would be used to ensure that the low battery indicator is not cleared unless the voltage goes back above a higher level than the low level that made it come on.

Could someone who is more familiar with the firmware weigh in on this one? Would an idea like this help improve the validity of the Battery Indicator, or prevent waiting too long to change batteries until you get the "Restored" error.

[Marcus von Cube]

(03-11-2015 05:51 AM)BarryMead Wrote:  Could someone who is more familiar with the firmware weigh in on this one?

Let me try. I do sample the current voltage before I let the software increase the processor speed but the sampling algorithm is a bit tricky: There is no A/D converter which can be easily read out. Sampling can only be done in larger intervals because the circuit is a quite primitive brown out detector. The second cause of grief is the behavior of the coin cells when they become weak. After some time without load they recover quite well but as soon as the load increases the internal resistance causes a severe voltage drop which may become too much for the processor to work reliably. The voltage detection algorithm is just too slow to cope with these conditions.

My advice: If you see the first "Reset" or "Restored" message switch to SLOW mode or change the cells.

[John Galt]

Thank you Marcus.

What do you think about latching the battery icon? My thinking is that once the battery icon illuminates, the user is constantly reminded of the need to replace them, even if the need is not imminent the very first time it appears.

It would then be up to the user to decide upon a reasonable period of time, given prior personal experience using the calculator in its usual manner, for which he knows replacement can be put off. For example, when the battery alert first appears on my HP 50g, I know I have at least a few days to replace them, given my normal work habits.

The latch bit could conceivably be a user-accessible flag, unless there is a leftover bit you know of that could serve the purpose.

I was also wondering if the battery icon could be illuminated for a minimum amount of time (some number of seconds or minutes), but that might require relying upon the real time clock which not all users will have.

Just a thought. If I knew how to do it myself I would have done so already!

[Paul Dale]

How would one distinguish a change of battery from a battery that has substantially recovered after a rest?

Pretty much everything is turned off between key presses.....


- Pauli

[John Galt]

(03-11-2015 11:51 PM)Paul Dale Wrote:  How would one distinguish a change of battery from a battery that has substantially recovered after a rest?

That is the reason I was wondering if the battery indicator could be illuminated for some minimum period of time (seconds or minutes). After that, if the battery voltage recovers to some minimum threshold, software could extinguish it and reset the latch algorithm.

If that is not possible, the user would need to reset the bit manually.

Come to think of it, I believe that's the way it works on a 50g. If batteries recover enough during the idle time between key presses, the next keypress extinguishes the battery alert. When it stops doing that it's really time to replace them.

[MarkHaysHarris777]

hi John, ... the battery indicator is mostly useless (its nobodies fault, it just is). The reason for this has already been hinted at... but, most of the time the calculator is idle and the current is for the most part zero. The cells have a chance to recover a surface voltage that will read very near perfect!-- 2.9 or 3.0/ but, the cells are dead. Marcus has said if you see 'reset' but, I would add that if the machine takes a couple of seconds to power on (Marcus can fill in the details) ...the machine makes a calibration of the crystal when the power cuts out... my new 30b was doing this right out of the box, because it had weak cells. I replaced the cells and the problem vanished.

To check the coin cells you need to do the very thing you would do if checking the battery in your vehicle... check the voltage under load of significant current. You can do this with your calcualtor by putting the machine into a tight nop loop and then measure the voltage and current. If the machine steps into slow mode, replace the cells. if the voltage drops much below 2.7 in a tight loop replace the cells. Having said that, that is ONLY if you're going to be doing coding, program loops, or updating. If you're only going to be doing that occasional calculation (manual from the keyboard) one a day, don't worry about it... those little coin cells will last 7 months.

Hope this helps.

Cheers,
marcus

[Marcus von Cube]

(03-12-2015 12:33 AM)MarkHaysHarris777 Wrote:  Marcus has said if you see 'reset' but, I would add that if the machine takes a couple of seconds to power on (Marcus can fill in the details) ...the machine makes a calibration of the crystal when the power cuts out...

This is only visible with the crystal enabled firmware which starts the oscillator at a cold power up. The standard firmware comes up almost instantly.

[matthiaspaul]

For those who can modify the calculator hardware, there are several options to at least improve the situation:

- A low-leakage low-ESR capacitor (perhaps 10-47uF) should be added in parallel to C17/C16/C15 as close to the CPU as possible. This is particularly important for those who have added the USB extension, because then VBAT is routed through circuitry on the USB board and via long and thin wires, which will increase the voltage drops under load. Low leakage and clean soldering is important here because otherwise this will have the reverse effect.

- If an IR-LED is present, its anode should be decoupled from VBAT by a small resistor (perhaps 10R) and bypassed to GND with another low-leakage capacitor (ca. 10uF).

This should help to stabilize the weak VBAT plane considerably and even extend the battery life somewhat. See also:

http://www.ti.com/lit/wp/swra349/swra349.pdf

If the USB board is installed, it is easy to derive an "EXTERNAL_POWER_GOOD" signal from it. It requires just one more wire between the cathode (which is *not* connected to R4) of the common-anode dual-diode D1 and one of the controller's free I/Os. (It might be possible to make the presence of this feature auto-detectable by the firmware without increasing power consumption, otherwise it would require a special firmware image. The firmware overhead wouldn't be more than a couple of bytes, so it wouldn't harm. We should just "standardize" on the I/O to be used for this purpose.) If the signal indicates that an external power supply is present, high speed is allowed (or even automatically enabled regardless of the measured battery voltage). If no external power supply is present, the firmware should be much more conservative about allowing the calculator to run at high speed, so that it will not reset before the battery is actually exhausted. After all, speed is hardly important on a calculator, whereas high reliability and long battery life are.

See also: http://www.hpmuseum.org/forum/thread-294...l#pid28498

Adding yet another wire, we could also enable one of the A/D converters to measure the battery voltage, however, this has a number of disadvantages:

- not applicable if the calculator should not be opened
- increased power consumption compared to the BOD solution
- extra code necessary to handle A/D conversions (so far none of the A/Ds were used, so no code dealing with the A/D converter is present at all right now)

I guess it would be possible to further tweak the existing power management algorithm somewhat (beyond just setting the thresholds to more conservative values), but it is a bit too early (for me) to make actual suggestions, since I haven't run into such low battery conditions myself with this calculator and this would certainly help to get a better sense for the underlying problem and possible solutions.

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-3078.html
http://www.hpmuseum.org/forum/thread-3077.html

[matthiaspaul]

(03-12-2015 12:21 PM)matthiaspaul Wrote:  For those who can modify the calculator hardware, there are several options to at least improve the situation:

- A low-leakage low-ESR capacitor (perhaps 10-47uF) should be added in parallel to C17/C16/C15 as close to the CPU as possible. This is particularly important for those who have added the USB extension, because then VBAT is routed through circuitry on the USB board and via long and thin wires, which will increase the voltage drops under load. Low leakage and clean soldering is important here because otherwise this will have the reverse effect.

As you know, the HP 15c Limited Edition is based on a hardware very similar to that of the HP 20b and 30b. They use the same Atmel AT91SAM7L128 controller (but in a different package), and some of the external parts differ slightly. Using the original firmware current peaks up to 40-44mA have been observed in the HP 15c LE, which could cause "Pr Error" messages in the calculator. While the situation in the WP 34S may differ as it is uses a completely different firmware, the scenario is nevertheless comparable. I just found an article suggesting a solution similar to the one proposed by me above:

http://www.finetune.co.jp/~lyuka/interes...c/hp15cle/

By adding a multi-layer ceramic capacitor (MLCC) TDK C3225X5R0J107M (100uF/6.3V/X5R in 3225 package) they could reduce these spikes down to less than the half (18mA), which is in the normal peak current range for this calculator. Using a cheaper Murata GRM31CF10J107ZE01 capacitor, the current was reduced down to at least 21mA - still good.

Also recommended by them are:

- Murata GRM32ER60J107ME20L, 100uF/6.3V/X5R/3225
- TDK C3216X5R0J107M, 100uF/6.3V/X5R/3216
- Taiyo Yuden JMK316BJ107ML-T, 100uF/6.3V/X5R/3216

In my post above I did not specifically recommend 100uF capacitors because they typically have higher leak currents than 10-47uF capacitors, but you will have to study the datasheets yourself as the exact capacitor models frequently change with advancements in technology.

While a low ESR (combined with relatively high capacitance) is the important parameter to reduce such current spikes, the low leak current is important to not reduce the battery life through leak currents when the calculator is not used. So, if you find multiple capacitors with about equal low ESR and low leak current, go for the higher capacitance, for as long as the nominal voltage is 5V or higher. If the other parameters are equally good, choose X7R over X5R.

Greetings,

Matthias

[John Galt]

Thank you Matthias!

For those interested, I have found wide differences in performance from various battery manufacturers. For example. The Panasonic batteries I had originally been using perform poorly under load, when weak. By that I mean their voltage drops precipitously when current exceeds a certain value (which I have not yet determined). On the other hand Maxell battery voltage appear to decrease in a more linear fashion under load, when they become weak.

Using BATT (to be sure, a crude means of determining what's going on) and using a program loop storing its value in memory until the calculator shuts down yields voltages of 2.6 or 2.7 with the Panasonic batteries. Maxells consistently record 2.5, and the battery icon gives much more warning when they're about to fail.

Admittedly this is a very unscientific test, but the problem I was complaining about is going to be very heavily influenced by the type of batteries one uses.

Limiting current is a very good idea, and it seems easily accomplished.

Ideally, a WP 34S would benefit from a power supply better than what the 30b hardware offers us.

[MarkHaysHarris777]

(03-31-2015 01:24 AM)John Galt Wrote:  Ideally, a WP 34S would benefit from a power supply better than what the 30b hardware offers us.

Yes, and no. For all practical purposes the coin cell approach was (and is) very cool. I'm not really having any difficulty with power on my WP34s units. The one exception is 'extreme' programming where long periods of time are spent looping through some iterative calculation that takes more than a few minutes to complete. Then, its better to have a docking station which supplies the 3 volts with ample mAHs <sorry for the pun>

I'm not sure I buy the battery analysis though. I have used Panasonic and Maxwell and have not noticed any difference in their performance. Maybe you just got some bad cells (bad shelf life)?

Cheers,
marcus

[Paul Dale]

If you use the statistical functions heavily, you'll encounter the battery problems far sooner. They are very intensive, by far the worst of the built in operations.

Is there any way the device could measure the current current usage and dynamically adjust the clock speed with the aim of keeping this semi-constant or at least below something the batteries can consistently deliver? Additional hardware would be required I'm sure but how difficult would this be? There are analogue to digital converted exposed inside the device I believe if they are of any help.


- Pauli

[Bernd Grubert]

Hello.
What about adding a gold cap as a back-up power source for demanding calculation? The required capacity can be calculated from the maximum current during calculations. The gold cap would be charged when the Li-battery recovers and would support it when there are demanding applications.
Regards
Bernd

[Paul Dale]

The worst case statistical computations that we currently know about have an elapsed run time of about ten seconds.

It would be an impressive capacitor to hold that much charge and remain within the calculator case.


Still, a decent idea and a mitigator for some transients.


- Pauli

[Bernd Grubert]

(03-31-2015 10:10 AM)Paul Dale Wrote:  The worst case statistical computations that we currently know about currently have an elapsed run time of about ten seconds.

@Pauli: Do you know how large approximately the current drain is under these conditions?

Regards
Bernd

[BartDB]

OR

Just put better batteries in:
Installing AAAA batteries on the HP-30b

Best regards.

[Paul Dale]

(03-31-2015 02:01 PM)Bernd Grubert Wrote:  @Pauli: Do you know how large approximately the current drain is under these conditions?

No.


Pauli

[Marcus von Cube]

(03-31-2015 02:01 PM)Bernd Grubert Wrote:  Do you know how large approximately the current drain is under these conditions?

Whenever a computation takes longer than a fraction of a second, the speed is increased (in two steps) up to the maximum speed of some 30 MHz. As a rule of thumb you can assume 1mA/MHz.

[Bernd Grubert]

(04-01-2015 04:15 PM)Marcus von Cube Wrote:  Whenever a computation takes longer than a fraction of a second, the speed is increased (in two steps) up to the maximum speed of some 30 MHz. As a rule of thumb you can assume 1mA/MHz.

Thanks for the information. I also found some values in this thread.
Here is a capacitor with 1.5F: EDLSG155V5R5C which would fit into the calculator, if I cut out the inner cover. I think the biggest problem is not the capacity but the internal resistance of the capacitor. It is 30 Ohm which causes in a voltage drop of 0.3V @ 10mA.

@Marcus: Do you know the voltage threshhold at which the calculator resets?

Regards
Bernd