- 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) 04 Feb '21

04 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

Specs for LTM-1
by Burns Fisher (AMSAT) 01 Jun '20

01 Jun '20

I was exchanging some mail with Dan yesterday, and I realized that we will want to give temperature specs(among other things) on LTM-1. This is a question about whether anything has been said to potential customers yet, and a reminder that we will want to do that. 73, Burns Fisher, WB1FJ *AMSAT(R) Flight Software*

2 1

Scheduled automatic changes on LTM-1 and Golf?
by Burns Fisher (AMSAT) 18 May '20

18 May '20

I may have mentioned this before, but saw no answer. But the behavior of HO-107, and someone mentioning the schedule for AO-27 got me thinking about it again. This question is largely for the ops team: Suppose that the LTM-1 and Golf-Tee had the capability of commanding a schedule of operations. Let's say you could upload one or more sequences of commands labelled n. What would a schedule look like? Would it be "every n hours execute sequence x" realizing that 'n' is not terribly exact and would drift against UTC. Would it be "do sequence x entering eclipse and sequence y exiting eclipse? Would it be "Execute sequence x when I send an "execute sequence x" command? I think those are all possible, at least if the sequences are simple. No promises--there is a lot of software to do to make Golf-Tee and LTM-1 work at all, but if I get any feedback on these general ideas, I can write something up to prioritize and potentially keep in our back pocket for implementation as a "may" rather than a "must". 73, Burns Fisher, WB1FJ *AMSAT(R) Flight Software*

3 5

SAFE mode and HuskySat-1
by Mark Hammond 17 May '20

17 May '20

Hi All, Burns has given some background, but I don't quite grasp how to find and use SAFE mode occurrences on HS-1, to help see possible correlations with other events (like the changes in FWD power). In looking at some of the data, is there a good correlation between VGA Control voltage and SAFE mode? Here is my shot at something---I think if in SAFE mode, VGA Control V will be 0. But I don't know if VGA Control voltage being at 0 means it's in SAFE mode. Meaning, how else can VGA Control V go to 0? Just looking for some telemetry points that go to "X" when in SAFE mode, so it's easier to see SAFE mode events while graphing, while trying to get some basic understanding of what all is happening. Thanks! -- Mark L. Hammond [N8MH]

3 4

Looks like FWD power commanded down 1045u 5/15/20
by Mark Hammond 15 May '20

15 May '20

Hi all, Last night, Drew did some commanding. The bird had been going in and out of SAFE mode, so he sent several commands. I'll let him cover, but basically power to -18 and EPS to ON, as I recall. He also commanded it into HEALTH mode a time or two, but it would return to SAFE. At the send of the pass, it was in SAFE mode, and FWD power was still showing at 325mW. A quick check of the telemetry data on the web this morning showed it was in HEALTH mode, FWD power at 325mW. So about 1045utc 15 May 20, I sent some commands to try and set the power to -19, and by golly it heard me and the power dropped to about 124mW. So, at my LOS still in HEALTH mode, power showing 125mW. We'll see where it goes from here, but that has to be better on the power budget I'd think. PA cuirrent went down also, from like 225 mA to 125 mA. So that makes sense to me... 73, -- Mark L. Hammond [N8MH]

2 1

Radio and safe mode behavior
by Burns Fisher (AMSAT) 14 May '20

14 May '20

I have done a lot of examination of the telemetry sent today from HS-1. This is a narrative of what I believe to be the sequence of events. As most of us are aware, HS-1 has been operating at about 17mW of power for several months without the transponder on. Turning up the digital gain by 3dB or more had only a minimal effect (maybe up to 18 or 19 mW). Turning on the transponder last weekend had little effect. It's not clear (to me at least) whether the transponder downlink power maxed out at 20mW or so, but at the very least, we know that a strong uplink signal appeared to modulate and/or take power away from the beacon. At approximately 0456z today the power (as read by the telemetry) jumped to over 300mW. This does not appear to be related to temperature, although it should be no surprise that the RxTx temperature showed a rise shortly afterwards. In addition, there was no obvious change in bus voltage preceding the occurrence. At approximately 0720z today, 14May, HS-1 went into safe mode. This is likely because the bus voltage went below the auto-safe threshold (there is no other reason that this will happen autonomously--I don't believe that the UW components can command it), although looking at the bus voltage graph, it is not especially low at that time. It could just have been a pulse that happened at a different time from the telemetry being read. In the meantime when the beacon was on, the radio power was still high (although varying--this could easily be telemetry data collection issues) HS1 came OUT of safe mode back to health mode at about 0854z. Again, this is probably related to the bus voltage, but I just can't see it on the graph. This made little difference in the output power. At about 1120 there was a brief bus voltage drop from about 6.2 to about 5.8V. which sent it into safe mode again. In the middle of this safe mode, the RF power dropped back to 20-ish mW. Health mode was restored around 1250, and the RF power remained at 20-ish mW. Between 1252 and 1255, 10 commands were received. All the commands visible in the telemetry were CAN commands, which I assume were to turn on the EPS. We did not have enough telemetry to see all 10 commands, but Drew states that he sent telemetry power commands, so those were doubtless the ones that did not show. Indeed the telemetry power appears to have dropped a bit, consistent with reducing digital gain. rc_eps_batt_5 and batt_2 are now sending telemetry, indicating that the restart of the EPS was successful. 73, Burns Fisher, WB1FJ *AMSAT(R) Flight Software*

1 1

The transmitter power
by Burns Fisher (AMSAT) 14 May '20

14 May '20

Dan and Marc, I put you explicitly on this mail, but you should have gotten a previous narrative of the weird goings-on with HuskySat this morning. If you did not, it means you are not on a mailing list that you should be on. Given that the HuskySat transmitter suddenly jumped up in power for a few hours and then went back to its old behavior, I'm hoping there might be some more info here for you to help diagnose the problem. If there is anything we can do about it for HS-1, great, but even more importantly, do we need to make any changes on Golf-Tee and the LTM to prevent this happening? I can get telemetry on as many different parameters as might be useful to you. Please tell me what info would be helpful! Thanks and 73, Burns Fisher, WB1FJ *AMSAT(R) Flight Software*

1 0

LTM-1 BOMs
by Jerry Buxton 27 Mar '20

27 Mar '20

Hi Guys, We have an opportunity for someone who knows what they are doing, to look at LTM-1 and possibly determine the EAR classification. As soon as they are ready, I would like to send the BOMs and schematics to him so he can start looking. It's crucial to propagating LTM-1 in fact he represents a Mexican CubeSat that was interested in (but declined for now) that we were looking to provide a ride to another amateur radio. If you would let me know where your documents are on the SVN once you have completed any redesign, or if none was needed then where I can find the current schematic and BOM, I will get these off to him to start looking. It is understood that testing of the redesign might need tweaks but we have a good head start especially with those that do not need to change. Thanks! -- Jerry Buxton, NØJY Vice President - Engineering Radio Amateur Satellite Corp. (AMSAT)

3 2

Initial ICD for LTM-1
by Burns Fisher (AMSAT) 24 Mar '20

24 Mar '20

I sent this out to a few people before this list came into being, but just so it is recorded: I've written the first pass of a electrical/data ICD for LTM-1. It's in the Fox SVN (given that is where most other stuff derived from Fox is) as follows: LTM-1/Electrical ICD.docx Any comments are welcome, but realize that I have not looked at it for a few weeks and never intended to be a final product. If you don't have access to the Fox SVN and want a copy, let me know. 73, Burns Fisher, WB1FJ *AMSAT(R) Flight Software*

1 0