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
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 <amsat-bb@amsat.org> 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. 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/amsat-bb@amsat.org
To unsubscribe send an email to amsat-bb-leave(a)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 at https://www.amsat.org/about-amsat/ View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/amsat-bb@amsat.org To unsubscribe send an email to amsat-bb-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org