I found the three year old Tadiran batteries (TL-5101/P) that i described in the previous blog post to have too high internal resistance to be suitable for use in Sportident base stations. The datasheet of those batteries also only talk about a discharge current of up to 2 mA and the base stations use more than that for peak current. Therefore I ordered new batteries of another brand, namely SAFT LS14250 CNA. The datasheet of SAFT LS14250 recommends a maximum discharge current of 35 mA and it has near full capacity at 10 mA of current, so this seems like a much better choice for the application.
Naturally, I was curious as to what the voltage delay looked like for LS14250, so I hooked up my battery tester with the same software as before. I ran two tests on the same battery with about 5 minutes of delay in between. The plots below shows the results.
In the first run, which takes place presumably at least many days (perhaps months or years) since the battery was last delivering any current), we see the voltage under load starting out at about 2.95 V and it recovers to 3.45 V after about 15 s.
In the second runt, the initial voltage under load is above 3.4 V and it peaks at almost 3.5 V after 1.5 s. It then sags down a bit, but stays about 15 mV above the first trace between 20 and 60 s.
So the voltage delay phenomenon is (as expected) very evident also in this battery model. Also, the SAFT LS14250 seems to be much more suited for the application than the Tadiran TL-5101/P.
Update on 2015-07-11:
I also needed to change batteries on some SI master (BSM7) units and these have AA-size (14500) batteries with higher capacity than the 1/2 AA size 14250 discussed above. I tested a new SAFT 14500 battery (which has a highest recommended discharge current of 50 mA) twice with the 5 mA one-minute test. The results are shown in the plot below.
The voltage delay effect is evident also in this test, but strangely enough the curves look qualitatively different compared to the LS14250 curves. In the first run, the voltage dips during the first second before it starts to recover and reaches a peak after about 25 seconds followed by a slow decay. The initial dip is a new feature.
The second test of the same battery, ten minutes later, shows a quick recovery that peaks after three seconds after which the voltage slowly decays. After about 15 seconds, the voltage dips below that of the first run, unlike what happened when testing the LS14250 battery in which case the voltage during the second run stayed above that of the first run for the full minute.
The intricacies of battery behavior are apparently complicated, but tentatively one can conclude that a “voltage delay” effect that takes place for 1-15 seconds when the battery is being loaded after a (long) time of storage is repeatable based on the findings of these few tests.
11 thoughts on “More On Voltage Delay in Lithium Thionyl Chloride Batteries”
(1) you write that the Tadiran batteries are not suitable for SPORTident usage. How does this become apparent – do the stations fail on high-current tasks (like beeping and LED-lighting when punched with a SI-chip) or what?
(2) with regard to the new Air+-modes (SIAC) and their increased power demands, I am looking at possibly using the slightly larger 14330 batteries for the BSx8 stations. Xeno makes the model XL-055F for example. The 33mm long batteries are probably a very tight fit, but they might just fit into the space. Compared to the SAFT 14250 (rated at 1200mAh) the XENO 14330 are rated at 1650mAh, that’s a nice 38% increase :) Do you have any thoughts on this replacement?
The Sportident units consume (according to my measurements) 5-8 mA when doing some tasks, like beeping and perhaps also while trying to talk to an SI card. The kind of Tadiran battery I had on hand (TL-5101/P) is specified only up to 2 mA and the SI-unit complains about low battery even when the battery is new. I guess there are other (more expensive) Tadiran batteries that may wok better.
Electrically I think the 2/3 AA battery you mention will work fine provided you can fit it in the unit and connect to it reliably. Does it come in a version with solder lugs or axial leads? I doubt it is a good idea to solder directly to the ends of the battery body.
Thanks for your info.
Your low-batt warning on the old Tadirans could be explained by what the SI firmware developer told me some time ago: voltage measurement is done exactly at the moment when LED and beeper is on. So under these load conditions, the batt voltage on your batts probably doesn’t hold up, drops below 3.1 Volts, and that is the threshold for the batt-symbol in the LCD – and below 3.0 Volts with added 4-times beep.
Your TL-5101 have in fact been discontinued – see http://www.tadiran.com/index.php/products-to-be-discontinued – and the replacement TL-4902 looks as if it might be OK for the short pulses an SI-station requires.
And yes, the XENO batts I am looking at do come in both tab- and axial-wire-versions, I have now ordered 5 batteries with tabs to tests with, thinking that the tabs will save a little space compared to bending the axial wires by 90 degrees like SPORTident does on the 14250’s.
BTW, I would never dream of trying to solder directly to a lithium battery, I’d like to live for a few more years (mainly to do more orienteering :D )
Har det bra,
Thanks for the confirmation about the conditions under which the SI unit measures battery voltage.
I agree that TL-4902 is probably better suited to power an SI unit than the discontinued TL-5101, although the datasheet plots still only show performance for a 2 mA load (even though it says that 20 mA continuous current is acceptable). The 8.5 mA curve and the 35 mA maximum recommended continuous current of the SAFT LS14250 gives me more confidence though.
I think the reason I bought the TL-5101’s several years ago was the lower price and the fact that I did not study the datasheets as much as I should have (or perhaps at all). I also probably did not know the peak current that would be consumed. (Always read the datasheet!)
The tabs on your batteries will definitely protrude less than bent axial leads, so I think you made the right choice. Let me know how well you manage to fit them.
so, the Xeno 14330-sized batteries arrived last Friday and I have added them to two previously dead BSF8 stations.
The good news is, the battery is a perfect fit! The “egg” shaped BSF8 housing gives the battery exactly the space needed, so there’s no chance for the battery moving “sideways” any more. Funnily enough however, next time I *would* got for the axial wire version: for the tabbed version, you need to twist the tabs by 90 degrees along the tab-length to make them “flat” against the solder pads on the board. This twisting however leads to the tabs becoming rigid against even small movement sideways or up/down. My fear is that possible movement (dropping of station etc.) might therefore over time weaken either the cold-welded tabs at the battery end – or, even worse, tear off the solder pads on the SI board. So from this point of view the axial wires would be better, there certainly is enough space (but with less diameter due to the egg-shape closing in) to bend the wires towards the board.
The bad news is, even though sold as new, my supplier sent me 5 batteries actually manufactured in 2012, so the “passivation effect” (or voltage delay, as you call it here) had set in.
But, thanks to the load from the low-battery 5-beeps that SI has in its firmware on station activation, that effect was easily overcome, and the stations are now happy with the new batteries. I will not go into details about the firmware 6.23 bug with the invalid voltage reading, suffice to say the bug has bitten me a few times now too and is not nice…
Anyhow, the XENOs seem to be able to provide the necessary voltage even under load – punches (tested also clearing of SI-card5, the “longest” punch-process), beeps, blinks, even radio-transmissions (BSF8-SRR station) all work a charm. So, a success story!
Happy running to all!
I am glad that the Xeno 2/3 AA batteries fitted and surprised that the solder tabs were long enough to reach the PCB. I had expected that you would have to extend them with soldered-on wires. Even if that is not necessary, it could serve as a workaround to mechanically decouple the battery from the PCB. It would of course be more elegant if you can indeed fit the battery version with axial leads in the available space as you say.
I do not think I have been affected by the battery voltage bug (I assume you refer to the first issue on page 8 of the 6.23 release notes that I just found: http://www.sportident.com/images/software/si_boot_firmware_618_issue_notification_en.pdf ), even though I updated more than 200 units from 5.74 or 5.80 to 6.23. But I did not know of the bug when I did the update and maybe some of the low battery readings I got were due to that bug and that I therefore changed a few batteries unnecessarily.
I have not tried Config+ yet. The release notes say that a workaround is to do a Factory reset in Config+. Does that help in your case?
the twisted tabs were exactly long enough to reach the solder pads, no extension necessary. The axial version most certainly would fit (the battery body has the same size as for the tabbed version after all) and be more elegant regarding connection to the board.
Yes, the 623 bug I’m referring to is the voltage reading as per release notes http://www.sportident.com/images/software/si_boot_firmware_623_release_notes_en.pdf last page. I’m pretty sure you’d know if you’d been bitten – we are talking of voltage readings below 2.0 Volts in SICfg-classic and on the station LCD. From my findings it seems to only bite BSF8 stations, of the ca. 80 BSF8 I upgraded some 5 were affected, but of the ca. 90 BSF7 not a single one.
The factory reset of SICfg+ does help (and only that, the same function in SICfg-classic does NOT) – after reset the reading is correct. It seems however that the bug can “return” at any time – one of the two stations I added the XENO to had the bug directly after battery connection, I reset it, all was fine for a few hours, and then it bugged again! Another reset solved the problem until now, but who knows when it will come back. There are rumors that FW 6.xx also eats “already low batteries” faster than older FWs, possibly this is a side-effect of the bad voltage reading bug hindering the station from sleeping properly.
We’ll see if and when SI publishes a fixed FW…
Ouch. I am not in the mood for upgrading firmware again for all the SI stations I am maintaining. Even with four parallel master stations it takes a long time.
Now that I think of it, I had a weird failure of one station. It may or mat not be related to the voltage measurement bug. If I recall correctly, the sequence of events was this:
– The unit showed a very low voltage reading (2 V or so) after upgrading to 6.23.
– I opened it up to change the battery and measured the battery voltage with a DMM. It was indeed 2 V or thereabout.
– Then the station died completely (I am unsure exactly when in the sequence of events this happened).
– I might then have desoldered the old battery and connected the station to an external power supply to test it before I connected a new battery. I think I at first got it to work, but then it stopped working again.
– I looked around the PCB under a microscope and noticed something weird at one of the pins of the microcontroller. Closer inspection showed that the pin was more or less pulverized. The processor datasheet said that it was one of the power supply pins. I then noticed that the other power pins were also totally damaged.
My guess is that a huge amount of current has for some reason flown through the power pins such that they have melted (!). I am pretty sure I did not hook up the external power supply with the wrong polarity and anyway it was current limited to 80 mA or so, so I do not think I caused this by reverse power polarity. Could it be that the processor entered into latchup to effectively short its supplies and thus consume a large current?
It would be very bad if the new firmware can cause the processor to enter into a state where the processor starts consuming large amounts of current. The low voltage reading and the need for a reset to get out of that state is consistent with a huge current consumption of the processor.
If this hypothesis is correct, the low voltage reading is actually correct; the problem is rather that the processor is in a state where it consumes large amounts of current.
Have any of your stations that showed the bug died completely? If so, have you looked at the power pins of the processor?
Interesting and scary.
luckily(?), all the stations where I experienced the voltage-reading-bug recovered after one (or more) SICfg+-Resets, so I have not had any stations die completely on me.
Your theory of a possible latchup with resulting battery voltage loss makes sense, also the high current possibly toasting the VDD pins, depending on how fit the battery was. But I am unsure if a latchup on part of the uC with resulting massive current draw would still be recoverable at the same time by a different part of the processor initiating a reset – by a command given through inductive coupling no less! – I would expect the high current/low voltage to cause a general brownout of the processor, making the recovery impossible. But as said, all my occurances of voltage-bug were easily recoverable…
See also further communication options by PM :)
Good that your stations did not seem to be damaged by the bug. Maybe something entirely unrelated happened to my broken station. It would be interesting to measure the battery voltage using a voltmeter when the station is in the buggy state to see if the voltage is actually as low as indicated.
A true latchup cannot be recovered from unless the power is removed (as you probably know, a latchup is caused by a parasitic thyristor that triggers and it will not stop conducting until the current goes below a certain level, which will not happen unless power is removed). So I do not really think it could be a traditional latchup that is behind the bug in 6.23.
Maybe something more recoverable happens that causes the processor to draw lots of current. There are several items in the processor (MSP430F449) errata and although none of them mentions huge current draw it is hard to say if such a thing could happen due to a known processor bug. US13, “Unpredictable program execution” sounds a bit scary if it happens.
Maybe the processor has a “halt and catch fire”-instruction. ;-)