I’m trying to find the easiest and hopefully most reliable way to power T-Beams with LiFePO4 cells, their voltage being significantly lower than Li-ions.
Is there an easy way to bypass the AXP192?
Thanks
I’m trying to find the easiest and hopefully most reliable way to power T-Beams with LiFePO4 cells, their voltage being significantly lower than Li-ions.
Is there an easy way to bypass the AXP192?
Thanks
The AXP can be configured to support lifepo4 cells by setting the maximum charge voltage.
axp.setChargingTargetVoltage(AXP202_TARGET_VOL_4_1V);
That’s the lowest it’ll go (4.1V) but should work. Google says max charge voltage for lifepo4 is 4.2, so that’s below the max.
Thanks, but I’m not really interested in using the AXP192 to charge a LiFePO4, despite being certainly an interesting proposition for other use cases.
I just want to power T-Beam from a single LiFePO4 cell, which is only possibile for the very first part of the discharge curve, due to the AXP192 low-voltage protection configured for Li-ions.
Hmm… it’s not so easy to bypass the AXP entirely because it creates multiple voltage rails.
This should disable the charger of the AXP:
axp.enableChargeing(false);
I think the chip will turn itself off at 3.0v. I can’t find how to change that setting, you or someone may have better luck.
I just found the discharge curves for LiFePO4, 3.0 is a good cutoff value.
Yeah, that’s the main issue. I’d need to power the AXP192 to get the ULV output, and bypass it for the 3,3 V rail…
Exactly!
Thank you, it’s interesting to know older revisions probably made it easier.
@mc-hamster I’ve contacted the author of the MPPT board and he suggests trying to disable charging with:
axp.enableChargeing(false)
If this works, it might also let the voltage go lower than 3,3 V, possibly 3 V, which would be perfect for LiFePO4.
I’d like your opinion on that, before I set up and debug a building environment only to see my dreams crushed by the “whole world is on Li-ion” hard-coded defaults
Lol … that was my suggestion above.
That’s embarassing… this weekend has taken a heavy toll on my brain
If you can get a build environment going, I think it’ll be 4 or 5 lines of code to expose that as a configuration option.
As I feared, I’m having issues with compiling. I’ve followed these instructions in a Ubuntu VM and that’s the output:
src/Power.cpp: In member function 'bool Power::axp192Init()':
src/Power.cpp:335:13: error: expected ';' before 'readPowerStatus'
readPowerStatus();
^
*** [.pio/build/tbeam/src/Power.cpp.o] Error 1
I won’t merge this back (it has other possibly unstable code), but I made the change for ya. It just turns off the charger and doesn’t hook into any settings of any sort. Consider this a proof of concept.
It compiles just file.
Indeed it compiles fine, even I could do it!
Alas, the T-Beam still shuts down at an indicated 3,27 V input, which BTW it’s still far below minimum voltage input as per the AXP192 specs (3,8 V).
That’s it, I’d need a different MPPT charger and swap LiFePO4 cells with Li-ion
Cheers
You could try going into a 3.3v Boost converter to maintain 3.3 when the voltage drops to 2.8v until the controller shuts you down.
I could, but that would go against power-efficiency. It’ll be easier and probably more efficient using a MPPT charger designed for Li-ion voltages.
I’d still much rather use LiFePO4 cells, though.
axp.setPowerDownVoltage(mV) can lower the power cutoff limit down to 2.6V
Wow, that could be a game-changer! I’ll test it as soon as I can and report back.
Cheers,
Andrea
So I’ve put
axp.setPowerDownVoltage(2600)
where I thought could fit, i.e. line 264 of Power.cpp and unfortunately compilation failed saying
error: 'class AXP20X_Class' has no member named 'setPowerDownVoltage'
I’m no programmer, but I find it odd, since according to the link above it should be in that class, which is also declared at the beginning of the file. But again, my knowledge of that is minimal.
Any suggestion are welcome!
From the link above, the new method has not yet been released. Once they’ve certified the new method and released it, meshtastic will need to pull their changes and then do a (very quick) round of tests before it can be used for this project.
If you build the code yourself, you can bring in their change directly by updating platform.ini in your fork and pointing to their repository.