I didn't believe they could be any worse. Recall that the "used" cell lasted 103 days and the first cell from the packet lasted 35 days.
The second cell I tested only lasted 24 days.
Lesson well and truly learned.
A blog about homebrew projects for Ham Radio. I cover aerials, test equipment, transmitters, both QRP and QRO, receivers and transceivers. The emphasis is on design and building. Generally I have boards and parts available at a modest cost. If you need more details, like a board layout, or any questions please ask. I'm more than happy to help.
I didn't believe they could be any worse. Recall that the "used" cell lasted 103 days and the first cell from the packet lasted 35 days.
The second cell I tested only lasted 24 days.
Lesson well and truly learned.
More fully explained in this post but briefly I am using a control battery to confirm if any degradation is due to float charging or simply the passage of time and high ambient temperatures. Apart from the time being tested the battery remains in a CC/CV charger floating at 3.93V. This charges the cell to approximately 70% of capacity then floats at this voltage.
Having established a base line for the cell capacity when fully charged I have now floated one cell at 3.93V for just over three months with 7 discharge tests during that period. After the third test where I had minor contact resistance issues I soldered a connector onto the cell for discharge testing for the fourth and onward tests.
Looking at the discharge tests of the battery left on float charge at 3.93V there is as yet no meaningful degradation in capacity. Also shown below is the capacity of the control cell, which was stored at about 50% capacity before being recharged for the test, and the test cell after fully charging.
Both the control and test batteries recorded an improvement in capacity of almost 5% for the second test compared to the original test.
It appears float charging at 3.93V, or 70% capacity, does no harm to a Li Ion battery. I will continue the testing for another 3 months to see what happens.
After several months of not needing backup lighting we suffered a week of regular power interruptions due to an equipment failure on the grid feeding our suburb. While very inconvenient it did highlight how useful automatic backup lighting can be.
I have made the following changes since V1.0:
Switching to the LiFePO4 battery was a mixed blessing. The run time is impressively long though I could have achieved this with a different Li-Ion battery. And potentially the life in cycles means the backup lights might last for at least my lifetime.
For a while I had more lights than I could keep on charge. So I was forever having to manually connect and disconnect. Once I forgot to do this and the battery dropped below 3.0V. Which meant the micro wouldn't trigger the charging circuit and the cell kept going flat even though I thought it was on charge. The result was a ruined LiFePO4 battery. A change in hardware fixed this.
Most of all I slept easy knowing there would be no spontaneous combustion risk, unlike a li-ion battery which has a very small risk of bursting into fire.
This is almost perfect. Only a few cents more expensive than an ATTINY device and presently has better availability. The ability to reprogram or adjust parameters via a serial cable as needed was a huge improvement over the ATTINY development landscape of assembly language and write / burn cycles.
The only downside was a battery voltage below 3V means it goes into reset which prevents the battery charging since the micro was controlling a pass transistor. That's been fixed. The presence of a charging voltage now turns on the pass transistor and the micro is not involved. The micro merely senses the charging voltage is present and controls the lighting accordingly.
It meant I could alter things like on and off periods very easily by connecting the light to a serial port. And the button could be programmed to do one thing while on charge and another when there was no power as I thought up new applications.
The CPU clock is now down to 15kHz which means the micro draws only 0.5mA. So once the battery voltage falls through 3.1V and the light is held off, the battery can run for a long time before the micro goes into reset and halts. Once power is restored and the battery voltage rises everything goes back to how it should be.
This proved to be the most frustrating part of V2.0 due to tolerances. By which I mean the led driver, supposedly turns off at 27V but in practice it can be lower due to tolerances. Using 3 high intensity leds with a 9V rating doesn't mean they clamp to a 27V level. It depends on the current being forced into the leds. More current means a higher voltage.
Once I realised this was why sometimes a board would work and other times it refused to it was a lot smoother sailing!
I think I have all the bugs resolved now. In the New Year I hope to write up this project in more detail.
A really bright backup light can prove immensely useful. And being able to unplug the light to use as an inspection lamp or similar has been proved to be very useful. The only thing I would change if it were possible would be to use a LiFePO4 battery more like the form factor shown below. The large cylindrical LiFePO4 cell constrains the sort of case I can use.
As mentioned in this post I used a 22k resistor to program the boost convertor current. However, it made no difference to the results. A large number of the tested inductors lie withing the recommended range of 4.7-22uH yet refuse to work.
I set the output voltage a little higher and repeated the measurements. Destroyed yet another MT3608L in the process. They are not very robust.
When I sat down to look closely at the data it revealed that:
Curious that 22uH wirewound inductors are atypical |
I was going to investigate the sweet sport for the MT9284 boost convertors. Instead, after some reflection, I brought some MT3609L boost convertors. As expected, with the lower resistance of the switching element (FET) the efficiency was much higher, around 90% measured, than I achieved with the MT9284 (50-60%).
However, two things really stood out. Firstly, a large number of inductors which work in the MT9284 circuit simply do not work with a MT3608L for reasons I do not presently understand. The MT3608L datasheet recommends an inductor of 4.7uh to 22uH. With the exception of two different 8.2uH inductors and one 3.3uH inductor, I found 22uH was the minimum inductance that would work.
Secondly, for the three 22uH inductors tested I achieved the following efficiencies:
22uh MT3608L MT3608L LED Power MT9284 MT9284 LED Power
small 24% 0.008W 20% 0.49W
large 24% 0.008W 52% 1.3W
Ferrite Chip 51% 0.023W 18% 0.47W
With a similar switching frequency and the same 4 meters being used to measure voltage and current simultaneously the results for make little sense to me.
I have the output current pin floating which the datasheet suggesting "The OC pin can be floating, the
current limit will be set by Internal 2.5A current limit." I will try attaching a 22k resistor to program the output current to 2.4Amps to see if this makes any difference.