Another note that may be of interest.

In the 1990 Microsats, the 256kb of ram was a RAD tolerant component.  It didn't suffer from degradation due to total dose, but it was susceptible to single event upsets, which we always saw when the satellites passed through the South Atlantic Anomaly (and occasionally over the poles).  Those chips stored 10 bits for an 8 bit byte and when reading it you got the right value even though one bit had flipped.  But that bit stayed flipped until it was read then written. So the low level OS code (BEKTEK kernal from Harold Price) "washed" blocks of memory fast enough that all 256k got done in about 10 minutes. The idea was to be sure the errors were washed out before the next pass through the SAA.  But if two bits in the same byte got flipped the wrong value would be fetched.  As I recall we think that only happened a couple of times in the two that I managed for about 10 years, but of course there was no way to know for sure.  Since that memory stored the code it hung when there was a double bit error.  There were registers available that could be pulled and downloaded that showed where each flipped bit was. The idea there was to see if a chip or cell in a chip was experiencing more bit errors.  I looked at years of that data and there was no pattern to bit flips.

There was a hardware watchdog circuit.  Very simple.  A 2N2222 (off the shelf), a cap and a resistor that formed a time delay circuit. The low level OS code "stroked" it every few ms.  That is, a GPIO pin on the processor was pulsed to push a bit of charge into the timer.  That code was a bit higher in the OS code.  If any of the tasks hung, the bit didn't get stroked, the delay circuit ran out of charge and pulled the reset pin of the processor low.   We then reloaded all the OS and tasks.

After something like 4 years the code began to reset after only a few hours or days.  Harold tracked that down to the watchdog timer resetting the processor.  He figured out the 2N2222 was degraded from radiation so the circuit wasn't holding the voltage up as long.  He moved the I/O pin pulsing function to a routine that ran about 10 times more often. That kept those birds going for another 10 years or so.

One huge and I think innovative feature was that a task could be unloaded and new one uploaded and started without having to reload the rest of the tasks.  We did that hundreds of times.  We could change the code of a task, unload the running version, upload and start the new, usually all in a single pass.  Note that tasks were typically about 10k bytes, not the bloated Windoz flavored stuff that is used today.

The larger (2.5 Mb if I remember right) memory used for the store and forward messages used Huffman encoding.  Sort of the same thing but the checking was done in software and that memory wasn't washed.  That memory used round robin storage so old messages got deleted when space was needed for new ones.  The average message life, when lots of users were on, was probably about 10 days.  As long as there were only single bit errors in a byte the fetched bytes were good.  But double bit errors resulted in bad data - an occasional bad character in a message.   But..  after six months or so the File Allocation Table for the messages files would get corrupted from double bit errors and the file system task would hang.  If it just couldn't fetch messages we could unload and reload it. But most of the time it hung to the point where it would not take the command to unload itself and we had to dump and reload all the code.  That took a day or two of passes.

Another innovation I don't see in use today: We could send a "fire code" to reset the satellite at any time.  It was a string of bits (not a valid HDLC frame) that was decoded by a single chip, that then pulled the processor reset pin low.  It never failed to work. That was a Lyle Johnson invention.

So lots of innovations in those birds, both hardware and software.

Jim

On 2/2/2024 6:50 PM, David Spoelstra via AMSAT-BB wrote:

Zach N0ZGO -

I am fascinated by your comment about the processor "has features which make it more robust". Can you elaborate please?

And to everyone else that posted about the different processors used, thanks! I was a HW/SW engineer for years and developed several in-circuit emulators for Tektronix. Later in my career I taught microcontroller programming at college. I passed some of your info to the current professor there to inspire the students.

-David, N9KT

On Thu, Feb 1, 2024 at 11:27 AM Zach Metzinger via AMSAT-BB [email protected] wrote:

On 2/1/24 10:07, Paul Stoetzer via AMSAT-BB wrote:
> AMSAT's PACSAT board - a modern version of the microsats - uses a
> TMS-570, which is an ARM Cortex-R, running at up to 160 MHz with
1280K
> of flash storage and 192K of RAM. MRAM will be used for BBS storage.

The TI TMS570 "Hercules" processor is also used on the Golf RT-IHU,
which will be the successor to the STM32 IHU used on the Fox series.

It is important to note that the low-Earth orbit environment is much
more forgiving than MEO and HEO. Radiation tolerance is an important
factor when choosing hardware for these higher orbits, which drove
the
selection of this specific COTS (common off-the-shelf) processor.
It is
not a SOI (silicon on insulator) radiation-hard processor, but has
features which make it more robust than, say, your off-the-shelf
STM32
or ATMega64.

73,

--- Zach
N0ZGO

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

Sent via AMSAT-BB(a)amsat.org <http://amsat.org>. AMSAT-NA makes
this open forum available
to all interested persons worldwide without requiring membership.
Opinions expressed
are solely those of the author, and do not reflect the official
views of AMSAT-NA.
Acceptable Use and Privacy Policies available at
https://www.amsat.org/about-amsat/

View archives of this mailing list at
https://mailman.amsat.org/hyperkitty/list/[email protected]
To unsubscribe send an email to amsat-bb-leave(a)amsat.org
<http://amsat.org>
Manage all of your AMSAT-NA mailing list preferences at
https://mailman.amsat.org

---

Sent via AMSAT-BB(a)amsat.org. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Acceptable Use and Privacy Policies available athttps://www.amsat.org/about-amsat/

View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to amsat-bb-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences athttps://mailman.amsat.org