February 2021 - Ltm - mailman.amsat.org

Fox-1e Lessons and fixes?
by Burns Fisher (AMSAT) 21 Feb '21

21 Feb '21

We don't know exactly the root cause of Fox-1E (AO-109)'s current behavior. We do know that the behavior could be explained if the IHU never started up. Further, we know a few reasons that this could happen: 1) The 'attached' line (which normally senses if a USB umbilical is attached) is held high for some reason (short or whatever) 2) The flash program memory being corrupted even by a single bit will cause the CRC check to fail, and it will power cycle. If power cycling does to fix the problem, it will loop forever. 3) Other diagnostic tests of the processor failing (for example a memory test) will also cause the power cycle loop. It was decided to do this long before AO-85 was launched and despite never seeing any of these problems the code remains. While there is no knowing one of these really is the cause of AO-109's problems, I'd like to reduce the probability of a false signal or a flipped bit totally stops the processor, especially for LTM-1, but also for Golf-TEE. I consider the latter is a slightly lower priority since we also have the RT-IHU. And yes, I know the LIHU is supposed to be a backup to the RT-IHU. Problem 1 could be worked around by adding code in the boot loader and startup to continue after several hours even when attached is high. We would also need an "ignore umbilical" uplink command similar to the one that currently exists as a console command. Problems 2 and 3 are harder. Because these tests come immediately after boot, we have no way to "remember" across a power cycle what caused the power cycle. We have not yet started the SPI bus to write to MRAM, and we have made it a point not to write to the flash memory in orbit due to possible charge pump damage by radiation. If we could remember a count, we might try power cycling 3 or 4 times and then continue anyway if that did not fix the problem. We could also remove these tests entirely, and "let come what may" on the assumption that many bit flips will have only minor effects. Another possibility is to provide a hardware command that could be uplinked to tell the processor to continue in the face of these errors. The disadvantage is that this would use up our last possible hardware command on Golf-TEE and leave only a single hardware command on LTM-1. I'm just recording my thoughts for posterity on the mailing list, but any ideas are appreciated. 73, Burns Fisher, WB1FJ *AMSAT(R) Flight Software*

1 0

Debugging the LIHU/LTM IHU (Ignore--this is mainly for the archives)
by Burns Fisher (AMSAT) 17 Feb '21

17 Feb '21

When I first started writing the software for Fox-1 (which turned out to be AO-85) I was using the Eclipse IDE along with the gdb debugger and other hacked-together pieces. This worked great with debugging--single step, breakpoints, watchpoints, etc all worked fine. As we got to the end of development and I switched to compiling for release rather than debug, I stopped using the debugger. When I wanted to use it agan for Golf, having switched to the Atollic TrueStudio (a 'supported' bundle of Eclipse, gdb etc) I could never get debugging to work again. Today, I finally found the magic: 1) If I have the umbilical plugged in, the of course power-on stops in the USB loader. For some reason when it is in the USB loader, gdb can't connect over the ST-link SWD connection. 2) If I do NOT have the umbilical plugged in I can upload some code but it hangs. Why? Because without the umbilical, the code, as expected, does a checksum of itself and since the code has changed a bit every time (it incorporated the build time) the checksum fails, and it attempts to fire off the watchdog to power cycle. I've finally worked around these by putting "ifndef UNDEFINE_BEFORE_FLIGHT" around the test so it will only execute as we are preparing for flight. I'm just recording this for posterity in both the golf software list and the ltm list. 73, Burns Fisher, WB1FJ *AMSAT(R) Flight Software*

1 1

LTM Console/Program loader
by Burns Fisher (AMSAT) 05 Feb '21

05 Feb '21

Mainly to Eric to comfirm, I think. Right now on LIHU V2.1 we have USB lines on the PC104 connector. Did we decide that we were going back to using USB both for the console and for IHU code loading on the LTM? So we will just spec to the customer that they must have a USB connection somehow (their choice of actual connector) available on their umbilical? And if they have their own USB, it is up to them to include a hub or another USB pair. And no serial lines from the IHU to the PC104. That's ok with me at least as a first try. I just wanted to document it. 73, Burns Fisher, WB1FJ *AMSAT(R) Flight Software*

1 0

Status of LTM-1
by Burns Fisher (AMSAT) 03 Feb '21

03 Feb '21

It's been a long time since there was anything on this list, largely because there is a LOT in common between LTM-1 and the legacy side of Golf-TEE. But things are warming up, so here is a quick status report, partly to remind you that LTM-1 is still in play and partly to remind you that many of the Golf projects you are working on have another destination and deadline as well. First regarding "customers". AMSAT has signed a letter of agreement with The University of Maine (Eric Skoog's alma mater, and the state university of my home state) to provide an LTM-1 for their MESAT. They recently told us that they have been assigned to a launch with a delivery deadline for the completed satellite early next year. Obviously, this puts some additional pressure on us, since they will need flatsat-level hardware shortly. There is also at least one additional potential customer waiting for us. CURRENT STATUS As you no doubt recall, the LTM-1 consists of three boards: The RxTx, the ICR, and the LIHU. All of these are nearly identical to what we will use on Golf-TEE (the LIHU can be one rev earlier, but probably will not be for flight). In addition, there is software for the LIHU and customers will expect documentation. Here is where we are on these pieces: LIHU: We have two of the latest rev LIHUs populated and undergoing testing. There will be another rev for a Golf-only function, but the existing design should work for LTM-1 unless the testing finds design problems. RxTx: There is a new design that replaces Husky/1E obsolete parts, has more and switchable RF power, and which we intend to test far more thoroughly in an attempt to reduce the risk of HuskySat-type issues. (We don't yet know if the RxTx is related to 1E's issues). Two of these boards are under construction and Eric and I are anxiously awaiting one while the other will undergo thermal testing. ICR: There are no functional changes on the ICR compared to Husky and 1E, so existing ICRs can be used for bench testing. However, an updated design is required to replace obsolete components. This is in work. Software: The software for LTM-1 will be a branch off the Golf-TEE software with the RTIHU coordination code removed and with a more generalized telemetry collection scheme and downlink format. As the software person, I have avoided splitting off the new branch to reduce the amount of merging required as bug fixes are made (and minor features added) to the Golf-TEE code. That will include testing the support for the new RxTx and the new LIHU. Documentation: We will need thorough documentation (schematic, BOMs, gerbers, masks, etc etc for hardware, functional specs for software) for our customers and also because we will likely have the flight units commercially built. I assume the documentation has been done for devices that are in build, but we will want that documentation in SVN or Redmine soon. A fair bit of software documentation is in Redmine for Golf-TEE but more is required . It will be written as part of the design for what software gets changed as we split off from the Golf-TEE branch. My current thought is to use UMe as reviewers for some of this since they are our first guinea pigs (HuskySat uses the same basic software as LTM-1 and Golf-TEE, but much of the intercommunication with their satellite was custom designed). Continued thanks to everyone involved for all the work you are doing! 73, Burns Fisher, WB1FJ *AMSAT(R) Flight Software* *LTM-1 Engineering Contact and Annoyer-in-chief* (Jerry feel free to give me a better title!)

4 4