RFOXiA LogoRFOXiA Club
← Back to DevHub

MultiNav Pro+ Power Kit - super-cap behavior during a hard power cut?

Cody MurphyJune 15, 2026
So I've been integrating the Power/Program Kit into a remote sensor node that's going to sit outdoors for months at a time, and one thing I can't find a clear answer on is how the super-cap system actually behaves when there's a sudden hard power loss - like if the solar panel input just drops completely (cloud cover, panel failure, whatever). Does the super-cap kick in automatically with no gap in power to the module, or is there a brief dropout while the handoff happens? Even a few milliseconds matters for me because I'm running continuous GNSS logging and I really don't want to lose fix state or corrupt a write mid-session.
💬 1 replies👍 0 likes👁 0 views

💬 Want to join this discussion?

Join the Community on RFOXiA Club →

Replies

AdamJune 15, 2026
@Cody Murphy good question, and honestly this is one of the more important edge cases for anyone running the kit in a long-term outdoor deployment.
 
The supercapacitor design inherently handles this better than a battery-based system would — supercaps can source current almost instantaneously with no chemical reaction delay, so the handoff on a hard input drop is going to be much cleaner than you'd get from a LiPo with a protection circuit in the way. That said, I'd want to flag this specific question to Moamen directly rather than give you a confident answer on the exact dropout window, because the behavior really depends on how the power management circuitry is implemented — whether there's a diode-OR arrangement, an ideal diode controller, or active switching between the input rail and the supercap bank. Each of those has a different transition characteristic, and a few milliseconds is exactly the margin where it matters which one is in use.
 
For your use case — continuous GNSS logging with active writes — I'd honestly suggest also handling this on the firmware side regardless of how clean the handoff is. A brief write-safe flag before committing to flash, or using a circular buffer that only finalizes records after confirming stable power, will protect you from the occasional edge case that hardware alone can't guarantee. The Dev Hub would be a good place to post this and get Moamen's eyes on it — he's pretty hands-on with technical questions like this and can give you the actual circuit behavior straight from the design.

💬 Want to join this discussion?

Join the Community on RFOXiA Club →