Jonathan,

This is a complicated issue that will require some time to study.

First the Excel spread sheet I sent is a early look at currents needed. Since I put that together some of the parts have changed and some have been added.
I am sure we have a power issue but taking the position of just trying to get everything we want done then we can back down on capability and reduce power later.
There is not a limit or budget on power at this time.

Each time you add one of these current monitors to the design you introduce another part that can fail due to latch-up and other reasons.

The action taken for each monitor added may be different. Latch-ups are possible from radiation exposure. These can be single event or they can result in a hard failure of a part. When there is an event and high current the plan may be to power down and wait for a period of time and then try to restart. If it is the processor with an issue then you are restarting everything if it is a sub circuit then you may be able to do a quick recycle. There are different types of current monitors to help you with your action plan. It may also be necessary to build a subcircuit to get the results needed.

It is likely that we never see this happen but if it does happen we will want to capture the event in some way. If a problem is happening in orbit  in a particular die/circuit we may be able to work around the problem. If it is the processor that is more difficult to capture events. The processor and memory will have larger die size and more gates so more likely that if we do have any events these will be the parts with a problem.

I worked on optical ICs and since these were exposed to light we had to be careful not create an issue with latch-up. When a new design comes out of wafer fab it is one of the early test you do to see if you have issues. If you find a problem you have try and fix it by changing the die layout, adding more metal or modify the circuit. When a device is “radiation harden” this should also be done and hopefully the TMS570 had this done. Still could fail with radiation though.

These are some of my thoughts.

Bob

On Jan 24, 2023, at 4:54 PM, Jonathan Brandenburg (KF5IDY) via pacsat-dev <pacsat-dev@amsat.org> wrote:

Now that you mention it, not my forté either! I was working in the abstract without really thinking about what a latchup actually results in… I think I was just assuming “super high” current without any real idea of what that really means.

I conceptually like the idea of each “subsystem” having its own current limiter that is tuned to that particular device. Takes a bit of real estate but these are small chips.
Jonathan

Sent from my iPad

On Jan 24, 2023, at 5:43 PM, Burns Fisher (AMSAT) <wb1fj@fisher.cc> wrote:


Not really my forté but I’d worry that a higher current load switch for two devices would allow a higher current due to a SEU on a single device. Too much current and device fails before the load switch cuts it off?

On Wed, Jan 25, 2023 at 11:37 AM Jonathan Brandenburg via pacsat-dev <pacsat-dev@amsat.org> wrote:
On 1/19/23 17:40, Rich Gopstein via pacsat-dev wrote:
> Burns might remember the details (or Zach certainly would), but one of
> those parts was undersized for the RT-IHU and would cut out when we
> were transmitting with the ax5043.  I think we had to back down the
> xmit power in order for the device not to reset.
>
>
It didn't take a whole lot of research for me to figure this one out.
The FPF2001 used on the Fox boards has a fixed current limit of 50mA. I
can see that could be sufficient for the Fox IHU since it uses a low
power processor and doesn't have transceivers or the power amplifier.
The direct replacement part for the FPF2001 is the TI TPS22942 and it
appears to be pin compatible with a fixed limit of 100mA. Would a 100mA
be a problem on Fox? I wouldn't think it would cause failure in the 10ms
it takes to blank the current but I make that statement without any real
basis. Perhaps the 40mA limit of the TI TPS22942 would be sufficient.

Anyway, back to PACSAT...

With the higher current capacity of the MAX4995, adjustable between 0
and 600 mA, it could be the better choice than the fixed TI TPS22942.
I'm not aware of flight experience with either so I tend to look to the
MAX4995 with the adjustable and higher current limits. With this
decision and looking at the approach employed on the RT-IHU I could see
the following:

1 - The TMS570 and associated circuitry get their own MAX4995. As a
first order pass contained in Bob Stricklin's spreadsheet the current
requirement is 458.3mA, within the MAX4995's capabilities. If we want to
further "derate" we could put the TMS570 on one MAX4995 and have a
second MAX4995 for the peripherals.

2 - All five AX5043's require 100mA. Would we want to have 2 of the
AX5043's on one MAX4995 and the remaining AX5043's on the other MAX4995
in case one MAX4995 fails prematurely? The value of this would depend on
all the AX5043's being equivalent in function (i.e., all could be used
for command and/or telemetry). This only takes care of this particular
failure mode and still leaves a lot of other failure modes in which an
early MAX4995 death would leave the system INOP so there may be limited
value in using two MAX4995's for the AX5043's.

3 - Finally, the amplifier/pre-amp is an additional 415mA. Again, if we
want to "derate" we could put the power amp on it's own MAX4995.


It looks like we need a minimum of 3 MAX4995's and a possible max of 6
MAX4995's. (With further analysis, we might need one more to split the
1.2V and 3.3V power lines to the TMS570.) The MAX4995 are small chips so
don't require a lot of real estate. We can discuss the risk vs reward of
using more MAX4995's at some point.

I welcome comments

Jonathan


--
Jonathan Brandenburg
Radio Amateur Satellite Corporation
1-214-213-1066


-----------------------------------------------------------

pacsat-dev mailing list -- pacsat-dev@amsat.org
View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
To unsubscribe send an email to pacsat-dev-leave@amsat.org
Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
--
73,

Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software

-----------------------------------------------------------

pacsat-dev mailing list -- pacsat-dev@amsat.org
View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org
To unsubscribe send an email to pacsat-dev-leave@amsat.org
Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org