Battery switching without tears

On Tuesday, April 7, 2020 at 8:58:53 PM UTC-7, 2G wrote:
On Tuesday, April 7, 2020 at 8:06:46 PM UTC-7, Andy Blackburn wrote:
I put a power resistor in the circuit to keep the current surge down. I undersized the capacitor so if I mess up on the with rotation I can lose power. Typically I'll shut off some non-essential equipment to lower the draw if I really don't want a computer reset.

Andy

On Sunday, April 5, 2020 at 8:45:30 AM UTC-7, jfitch wrote:

What is the inrush current when you first switch the power on? Must not be enough to blow the fuse, but that'd be something I'd want to O'scope with a current probe.

You didn't say what the resistor size was. There is already a resistor in the circuit - it is called the internal resistance of the battery,wiring resistance, switch contact resistance and the equivalent series resistance (ESR) of the capacitor.

I forgot to mention that aluminum electrolytic capacitors have very significant inductance at frequencies above 10 KHz. Inductance (also called a choke because they choke off current) limits inrush current. The joules of energy being transferred is pretty low (about 0.6 J), but I have no problem with adding a small series resistor (1 ohm - don't worry about the wattage as very little power is supplied by the cap).

Tom

At 04:20 08 April 2020, 2G wrote:
On Tuesday, April 7, 2020 at 8:58:53 PM UTC-7, 2G wrote:
On Tuesday, April 7, 2020 at 8:06:46 PM UTC-7, Andy Blackburn wrote:
I put a power resistor in the circuit to keep the current surge down.
I=
undersized the capacitor so if I mess up on the with rotation I can lose
p=
ower. Typically I'll shut off some non-essential equipment to lower the
dra=
w if I really don't want a computer reset.
=20
Andy
=20
On Sunday, April 5, 2020 at 8:45:30 AM UTC-7, jfitch wrote:
=20
What is the inrush current when you first switch the power on? Must
n=
ot be enough to blow the fuse, but that'd be something I'd want to
O'scope
=
with a current probe.
=20
You didn't say what the resistor size was. There is already a resistor
in=
the circuit - it is called the internal resistance of the battery,wiring
r=
esistance, switch contact resistance and the equivalent series resistance
(=
ESR) of the capacitor.

I forgot to mention that aluminum electrolytic capacitors have very
signifi=
cant inductance at frequencies above 10 KHz. Inductance (also called a
chok=
e because they choke off current) limits inrush current. The joules of
ener=
gy being transferred is pretty low (about 0.6 J), but I have no problem
wit=
h adding a small series resistor (1 ohm - don't worry about the wattage
as
=
very little power is supplied by the cap).

Tom

Has anyone reported this problem to LXV, and if so what was their response
please? There seems to be an opportunity for a firmware fix to this
problem, not requiring any additional hardware.

In the specification for Flight Recorders, a new IGC file is not started if
power has been interrupted for less than one minute. This is to allow a
change of battery, breaker reset or change a fuse. Exactly the problem we
are discussing.

If the LX firmware were enhanced to inhibit re-calculating QNH where power
has been lost for less than n seconds, this problem goes away.

Discuss.

Has anyone reported this problem to LXV, and if so what was their response
please? There seems to be an opportunity for a firmware fix to this
problem, not requiring any additional hardware.

In the specification for Flight Recorders, a new IGC file is not started if
power has been interrupted for less than one minute. This is to allow a
change of battery, breaker reset or change a fuse. Exactly the problem we
are discussing.

If the LX firmware were enhanced to inhibit re-calculating QNH where power
has been lost for less than n seconds, this problem goes away.

Discuss.


The LXNav manual says that the internal logger will continue to operate 'for a short time' if power is lost. The manual also says that the proper shutdown procedure should always be used, eg when changing batteries, since if power is suddenly cut the operating system may be scrambled.

On Wed, 08 Apr 2020 06:43:22 -0700, towsked wrote:


Has anyone reported this problem to LXV, and if so what was their
response please? There seems to be an opportunity for a firmware fix to
this problem, not requiring any additional hardware.

In the specification for Flight Recorders, a new IGC file is not
started if power has been interrupted for less than one minute. This is
to allow a change of battery, breaker reset or change a fuse. Exactly
the problem we are discussing.

If the LX firmware were enhanced to inhibit re-calculating QNH where
power has been lost for less than n seconds, this problem goes away.

Discuss.


The LXNav manual says that the internal logger will continue to operate
'for a short time' if power is lost. The manual also says that the
proper shutdown procedure should always be used, eg when changing
batteries, since if power is suddenly cut the operating system may be
scrambled.

What OS does LXNav use these days?

I'm asking because this sounds remarkably like similar problems with
WinCE, where it was well-known that powering off without shutting down
properly was almost as certain to corrupt the SD card as yanking the
card out of a running PDA.


--
Martin | martin at
Gregorie | gregorie dot org

On 4/8/20 7:54 AM, Martin Gregorie wrote:
On Wed, 08 Apr 2020 06:43:22 -0700, towsked wrote:


Has anyone reported this problem to LXV, and if so what was their
response please? There seems to be an opportunity for a firmware fix to
this problem, not requiring any additional hardware.

In the specification for Flight Recorders, a new IGC file is not
started if power has been interrupted for less than one minute. This is
to allow a change of battery, breaker reset or change a fuse. Exactly
the problem we are discussing.

If the LX firmware were enhanced to inhibit re-calculating QNH where
power has been lost for less than n seconds, this problem goes away.

Discuss.


The LXNav manual says that the internal logger will continue to operate
'for a short time' if power is lost. The manual also says that the
proper shutdown procedure should always be used, eg when changing
batteries, since if power is suddenly cut the operating system may be
scrambled.

What OS does LXNav use these days?

I'm asking because this sounds remarkably like similar problems with
WinCE, where it was well-known that powering off without shutting down
properly was almost as certain to corrupt the SD card as yanking the
card out of a running PDA.



The Stratux ads-b receiver has the same issue, high probability of
corrupting the memory if you don't shut it down manually before removing
power. Developers are aware of the problem, but haven't come up with a
proper fix.

Runs an embedded linux, they're not storing any data during normal
operation, so baffling why that's so hard to fix.

-Dave

I havent had to switch batteries in flight lately but my power flarm will reset and start a new log it interupted in flight. Very annoying as I use it almost exclusively for logging as its download is very fast and simple. My backup logger is the venerable SN10B, it does not reset and continues right where it left off, Thanks YO! I have thought about adding a cap to the circuit for the powerflarm. Lots of good ideas here so far but I am trying to keep it as simple as possible.

On Wednesday, April 8, 2020 at 12:00:15 PM UTC-4, wrote:
... the venerable SN10B, it does not reset and continues right where it
left off, Thanks YO!

Yes, I designed SN10 this way decades ago, because, Big Surprise!!
....glider instruments see power interruptions !!!
The SN10 has an internal short-term backup supply.
When the power is interrupted, it does a smooth shut-down (OS I wrote).
SN10 memory has a long-term backup battery, and next time power is applied,
the SN10 resumes wherever it left off. SN10s never do a hard reboot unless
new software is installed.

Of course, we have had SN10s damaged when customers added a capacitor
to their logger (powered thru SN10), and the inrush current eventually
blew up the SN10 power switch. Also some loggers had giant internal caps
to try prevent corruption, however...

Sensible design dictates avionics have internal short-term supplies
with power-interrupt sensing and implement smooth shutdown, especially
where they write to flash for logging, saving configuration, etc.
Otherwise things like SD cards or internal flash get corrupted with
data loss when power is interrupted during a write operation.
Of course, lots of design out there is not sensible...

Hope that helps clear some of the confusion,
Best Regards, Dave

On Wed, 08 Apr 2020 08:57:43 -0600, kinsell wrote:

Runs an embedded linux, they're not storing any data during normal
operation, so baffling why that's so hard to fix.

When does it commit data to non-volatile memory, i.e. does in
intentionally buffer it and only commit at intervals or as part of
shutting down?

FWIW The same problem occurs with Raspberry Pis.

As you may or may not know, these run a Debian Linux clone as their OS
and use SD cards for non-volatile memory by default. Much of the time
people can get away with simply pulling the plug when the Pi appears to
be idle, but if you do that while the Pi is flushing its caches to its SD
card or, more rarely, the card is in the middle of a wear-levelling
process, then the SD card will become corrupted and possibly permanently
damaged if it was wear-levelling when the power vanished. Which is why
everybody soon learns to shut the Pi down with a 'sudo stop' command
before powering it off. I think its worse with SD cards simply because
their internal controllers and cheap, rather basic and have no power
buffering. Use an SSD instead or, even better, a hard drive and the
problem largely goes away because ext4 is a journalling filesystem, so
has built-in recovery.

I agree this is a tricky problem, and maybe best solved with some sort of
cheap'n cheerful UPS. Here's a suggestion along those lines:

Pimoroni sell the PowerBoost 1000 Charger, a small and fairly cheap UPS
circuit ($US 19.39 from Amazon), which you connect between a 5v power
supply and the device you want to power via a UPS socket. You also
connect a suitable sized 1S (3.7 volt) Lithium-ion battery to it - the
sort used to power small RC models would be fine - and there's a power
buffer for any UPS-powered device that doesn't have an internal battery.
Its good to supply up to 1000mA provided that the battery is rated for
that current. Some soldering is needed.

It comes with a selection of sockets, but they're all sat loosely in
place on the board so you can solder the ones you want on, sling the
others and solder any permanent connections you need.

I have one but haven't used it yet - I'm planning to make a PDA from a 4"
touch screen and a Pi Zero WL and use this Pimoroni plus an RC model 1S
LiPO battery to power it. Add a case made from epoxyboard and it should
be ready to rock'n roll.


--
Martin | martin at
Gregorie | gregorie dot org

On Wednesday, April 8, 2020 at 12:58:39 PM UTC-4, Martin Gregorie wrote:
On Wed, 08 Apr 2020 08:57:43 -0600, kinsell wrote:

Runs an embedded linux, they're not storing any data during normal
operation, so baffling why that's so hard to fix.

When does it commit data to non-volatile memory, i.e. does in
intentionally buffer it and only commit at intervals or as part of
shutting down?

A common problem is forgetting to put /tmp in RAM.
Leaving it on a uSD will eventually end badly.


FWIW The same problem occurs with Raspberry Pis.

As you may or may not know, these run a Debian Linux clone as their OS
and use SD cards for non-volatile memory by default. Much of the time
people can get away with simply pulling the plug when the Pi appears to
be idle, but if you do that while the Pi is flushing its caches to its SD
card or, more rarely, the card is in the middle of a wear-levelling
process, then the SD card will become corrupted and possibly permanently
damaged if it was wear-levelling when the power vanished. Which is why
everybody soon learns to shut the Pi down with a 'sudo stop' command
before powering it off. I think its worse with SD cards simply because
their internal controllers and cheap, rather basic and have no power
buffering. Use an SSD instead or, even better, a hard drive and the
problem largely goes away because ext4 is a journalling filesystem, so
has built-in recovery.

I agree this is a tricky problem, and maybe best solved with some sort of
cheap'n cheerful UPS. Here's a suggestion along those lines:

Pimoroni sell the PowerBoost 1000 Charger, a small and fairly cheap UPS
circuit ($US 19.39 from Amazon), which you connect between a 5v power
supply and the device you want to power via a UPS socket. You also
connect a suitable sized 1S (3.7 volt) Lithium-ion battery to it - the
sort used to power small RC models would be fine - and there's a power
buffer for any UPS-powered device that doesn't have an internal battery.
Its good to supply up to 1000mA provided that the battery is rated for
that current. Some soldering is needed.

It comes with a selection of sockets, but they're all sat loosely in
place on the board so you can solder the ones you want on, sling the
others and solder any permanent connections you need.

I have one but haven't used it yet - I'm planning to make a PDA from a 4"
touch screen and a Pi Zero WL and use this Pimoroni plus an RC model 1S
LiPO battery to power it. Add a case made from epoxyboard and it should
be ready to rock'n roll.

Another Pi solution is this one with superCap: https://juice4halt.com/
Beware the window before supercap completely charged (should finish
shortly after boot)...

Enjoy,
Best Regards, Dave

On 4/8/20 10:58 AM, Martin Gregorie wrote:
On Wed, 08 Apr 2020 08:57:43 -0600, kinsell wrote:

Runs an embedded linux, they're not storing any data during normal
operation, so baffling why that's so hard to fix.

When does it commit data to non-volatile memory, i.e. does in
intentionally buffer it and only commit at intervals or as part of
shutting down?

FWIW The same problem occurs with Raspberry Pis.

As you may or may not know, these run a Debian Linux clone as their OS
and use SD cards for non-volatile memory by default. Much of the time
people can get away with simply pulling the plug when the Pi appears to
be idle, but if you do that while the Pi is flushing its caches to its SD
card or, more rarely, the card is in the middle of a wear-levelling
process, then the SD card will become corrupted and possibly permanently
damaged if it was wear-levelling when the power vanished. Which is why
everybody soon learns to shut the Pi down with a 'sudo stop' command
before powering it off. I think its worse with SD cards simply because
their internal controllers and cheap, rather basic and have no power
buffering. Use an SSD instead or, even better, a hard drive and the
problem largely goes away because ext4 is a journalling filesystem, so
has built-in recovery.

I agree this is a tricky problem, and maybe best solved with some sort of
cheap'n cheerful UPS. Here's a suggestion along those lines:

Pimoroni sell the PowerBoost 1000 Charger, a small and fairly cheap UPS
circuit ($US 19.39 from Amazon), which you connect between a 5v power
supply and the device you want to power via a UPS socket. You also
connect a suitable sized 1S (3.7 volt) Lithium-ion battery to it - the
sort used to power small RC models would be fine - and there's a power
buffer for any UPS-powered device that doesn't have an internal battery.
Its good to supply up to 1000mA provided that the battery is rated for
that current. Some soldering is needed.

It comes with a selection of sockets, but they're all sat loosely in
place on the board so you can solder the ones you want on, sling the
others and solder any permanent connections you need.

I have one but haven't used it yet - I'm planning to make a PDA from a 4"
touch screen and a Pi Zero WL and use this Pimoroni plus an RC model 1S
LiPO battery to power it. Add a case made from epoxyboard and it should
be ready to rock'n roll.



The Stratux project does run on a Rspberry Pi using the micro-SD for
storage. Yes, running other software on that hardware can lead to the
same file system corruption problem. What's interesting is I can load
FlightAware software on the same hardware and never see the problem. In
both applications, there is no user data that needs to be stored to
flash memory, other than a tiny bit of configuration data when they are
first set up. It is possible to run on a read-only file system, if some
provision is made for the configuration data. People have experimented
with this, but the images distributed for Stratux have never had a
solution that I'm aware of.

So many devices these days have a computer with flash memory. If your
smart TV becomes unbootable after a power fail, would that be considered
acceptable? Of course not. But for some reason Stratux doesn't seem to
get fixed. Putting a UPS on a microcomputer seems like an ugly Band-Aid
(rtm) that shouldn't be necessary. Just a simple file system check on
power up might be adequate. There's a Sentry Mini receiver available
now for just $300, I'll bet it doesn't lose its mind if you just pull power.

-Dave