- Ltm - mailman.amsat.org

Re: Fwd: From Keith, VA3KSF / KB1SF
by Jerry Buxton 09 Jan '23

09 Jan '23

On 1/9/2023 10:25, Paul Stoetzer via Ltm wrote: > Good morning, > > Do we have the potential capacity to support this project with an LTM? > Hi Paul, Yes, we have the /potential capacity/ for one or two LTM. The actual depends primarily on when it would be needed, and the number e.g. suggested at least an Engineering Model and a Flight Model. Frequencies must be coordinated with IARU early on and will need to be known before delivery of any units whether engineering or flight. Another capacity factor will be support, for integration and any other that the customer expects. That will weigh out against how much time we have to meet support beyond the expected base level of EM/FM, manual, and some help with difficulties or bugs in getting it talking to their spacecraft bus. And then cost, a one or two-off (EM, FM) build is more expensive than 5 or 10 so AMSAT should consider whether we want to do a run to have others available for yet-unknown disposition or just serve customers on an as-needed basis. Since we generally do not want to charge anyone for the LTM (in-kind would probably be smart but is up to you, not Engineering) then whatever costs we will absorb should fit our vision and due diligence on spending. And there are other factors IMO with that cost such as how long the mission will last. I would expect them to operate the amateur radio until the spacecraft demise, not just until their experiments are done. I would expect the best possible orbit to extend that life and in that, with Keith's mention of OD regs US vs. Canada if they can go higher and longer, it makes sense to perhaps consider a minimum orbit lifetime of x years for the cost to us for the LTM and support. Like, not an ISS deploy for six months or a year IMO. Summary: Yes, we have the potential capacity. What exactly that means in terms of all of the above, is the real question. I see no, or negative, value in saying we'll provide this free-to-hamsats LTM sure thing let's go only to fail for whatever eventualities (including supply chain). The risk of losing any future chances by failure far outweighs over-optimism on meeting the sales pitch. "AMSAT has been offering a fully tested cubesat transponder suite to those groups interested in building and launching "amateur radio qualified" experiments into earth orbit" is a sales pitch that does bother me. Perhaps we should consider finding some better coincidence of sales pitch vs. realism. We do not want to own, or expect to be given, any or all LTM we give away. You have it (our) radio, you license it, you operate it, you own it, you keep it. I think Keith is on that but it's not apparent in this email. It has to be, in whatever sales pitch. And what is a "transponder suite", anyway? Jerry Buxton, NØJY Vice President - Engineering Radio Amateur Satellite Corp. (AMSAT)

1 0

Re: Fwd: From Keith, VA3KSF / KB1SF
by Burns Fisher (AMSAT) 09 Jan '23

09 Jan '23

The first thing we would need to know is their timeframe including how much of their design is “in stone”. Beyond saying that I’ll let Eric and Jerry take over 73 Burns Wb1FJ On Mon, Jan 9, 2023 at 11:25 AM Paul Stoetzer via Ltm <ltm(a)amsat.org> wrote: > Good morning, > > Do we have the potential capacity to support this project with an LTM? > > 73, > > Paul, N8HM > > ---------- Forwarded message --------- > From: Keith Baker <va3ksf(a)cogeco.ca> > Date: Mon, Jan 9, 2023 at 11:22 AM > Subject: From Keith, VA3KSF / KB1SF > To: ve3gso <ve3gso(a)gmail.com>, Rick Brown <ve3img(a)gmail.com>, n8hm < > n8hm(a)amsat.org> > > > Hello David, Rick and Paul, > > First, to Rick, many thanks for your kind reception to my satellite talk > on Thursday evening. The feedback I've since received has been most > positive, so apparently nobody fell asleep during my presentation! > > And to David, with this email I'm pulling Paul Stoetzer, our current AMSAT > Executive Vice President into the conversation regarding the satellite > project you are involved with at the University of Western Ontario (UWO). > > As I noted during our discussions on Thursday evening, for the last few > years, AMSAT has been offering a fully tested cubesat transponder suite to > those groups interested in building and launching "amateur radio qualified" > experiments into earth orbit. Also, at one time, AMSAT and a group in > Canada were in conversations about negotiating a collaborative agreement so > as to work together on satellite projects of mutual interest. However, as > I'm now *well* out of the loop as to the current status of that process, > I believe it would still be in both group's mutual interest to continue > pursuing such an agreement, particularly now that the US FCC's licensing > requirements as regards orbital debris mitigation have become *far* more > stringent than in the past. > > Paul, I would *very* much appreciate you putting David McCarter ( > [email protected])...the London Amateur Radio Club's contact with the > group at UWO who are in the process of assembling their cubesat... into > contact with the appropriate regulatory and/or engineering folks at AMSAT > so as to possibly explore these cooperative ideas further. > > 73, > > Keith Baker > KB1SF / VA3KSF > Past President > Radio Amateur Satellite Corporation (AMSAT) > > > > > ----------------------------------------------------------- > > Ltm mailing list -- ltm(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to ltm-leave(a)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*

1 0

Fwd: From Keith, VA3KSF / KB1SF
by Paul Stoetzer 09 Jan '23

09 Jan '23

Good morning, Do we have the potential capacity to support this project with an LTM? 73, Paul, N8HM ---------- Forwarded message --------- From: Keith Baker <va3ksf(a)cogeco.ca> Date: Mon, Jan 9, 2023 at 11:22 AM Subject: From Keith, VA3KSF / KB1SF To: ve3gso <ve3gso(a)gmail.com>, Rick Brown <ve3img(a)gmail.com>, n8hm < n8hm(a)amsat.org> Hello David, Rick and Paul, First, to Rick, many thanks for your kind reception to my satellite talk on Thursday evening. The feedback I've since received has been most positive, so apparently nobody fell asleep during my presentation! And to David, with this email I'm pulling Paul Stoetzer, our current AMSAT Executive Vice President into the conversation regarding the satellite project you are involved with at the University of Western Ontario (UWO). As I noted during our discussions on Thursday evening, for the last few years, AMSAT has been offering a fully tested cubesat transponder suite to those groups interested in building and launching "amateur radio qualified" experiments into earth orbit. Also, at one time, AMSAT and a group in Canada were in conversations about negotiating a collaborative agreement so as to work together on satellite projects of mutual interest. However, as I'm now *well* out of the loop as to the current status of that process, I believe it would still be in both group's mutual interest to continue pursuing such an agreement, particularly now that the US FCC's licensing requirements as regards orbital debris mitigation have become *far* more stringent than in the past. Paul, I would *very* much appreciate you putting David McCarter ( [email protected])...the London Amateur Radio Club's contact with the group at UWO who are in the process of assembling their cubesat... into contact with the appropriate regulatory and/or engineering folks at AMSAT so as to possibly explore these cooperative ideas further. 73, Keith Baker KB1SF / VA3KSF Past President Radio Amateur Satellite Corporation (AMSAT)

1 0

LIHU Code Loader upgraded to Python3
by Burns Fisher (AMSAT) 01 Feb '22

01 Feb '22

Just to record for posterity, the code loader for the LIHU has been upgraded to work on Python3. (Python2, on which it used to run, has been deprecated and will start disappearing from host systems shortly--it already is gone from the latest Raspberry Pi Raspian). As you may know this loader can work either with two different configurations on the LIHU: One is designed for the USB flash loader, and one for serial. USB is currently more critical since it will be used by the University of Maine in MESAT1. I have not tested the upgrade on the serial loader (which will be used by Golf) yet. This loader is on gitHub at burnsfisher/pyMicroloader. It is intended to be generic; it is fairly easy to add new flash loader support--it's just a new class to write. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

New SVN section for LTM
by Burns Fisher (AMSAT) 16 Apr '21

16 Apr '21

In consultation with Eric, I created a new subtree in the golf SVN tree (at the same level as Golf-TEE and Golf-1) called LTM. Below that is "generic" and then a folder for specific partners, currently MESat from the University of Maine. At the moment, the generic section holds the generic ICD, and the Maine folder holds the ICD with a not-yet-filled-in MESat-specific appendix. 73, Burns Fisher, WB1FJ *AMSAT(R) Flight Software*

1 0

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

Power
by Jerry Buxton 18 Jun '20

18 Jun '20

Quick question, what is the max power out can we get from LTM-1 and is there a possibility of adding an "external amplifier" to the stack? e.g. fits on QTH/QSH bus maybe and input is just the output of the transponder, picture your rig and the amp in your shack. No power supply considerations, just raw what if for the transponder. Thanks! -- Jerry Buxton, NØJY Vice President - Engineering Radio Amateur Satellite Corp. (AMSAT)

5 6