- pacsat-dev - mailman.amsat.org

Re: Memory Problem on PacSatSW
by Bob Stricklin 15 Jan '24

15 Jan '24

OK will have a look at this. Found this note also which probably applies to us also: On MSP430 (or other) devices with limited RAM, the linker may fail to allocate the .bss or other sections allocated to RAM. The .bss section is for uninitialized global variables, and goes into RAM, along with stack (.stack) and heap (.sysmem) sections . If the code has a large number of global variables, you may run out of RAM space. If this is the case, you may consider making some of the variables const so they go into the .const section instead (which gets placed in FLASH instead of RAM). From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Monday, January 15, 2024 6:38 PM To: Jim McCullers <wa4cwi(a)bellsouth.net> Cc: Pacsat Dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: Memory Problem on PacSatSW When you mentioned the heap, you reminded me: FreeRTOS has a heap, which is essentially just a big array. The only thing it gets used for is allocating task stacks and the structures that represent semaphores, queues, etc. And they way that I have used the OS, they get allocated but never released. But the thing I meant to say is that allocating smaller stacks does not use less memory from the linker's point of view because the array that the stacks are allocated from is not changed. There is a routine you can use to ask how much heap is free. After it is all booted up, unless the new code uses it differently than I did, any "free heap" is wasted. I think the size of the heap is an OS parameter in one of the free rtos header files. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, Jan 15, 2024 at 7:31 PM Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: My version of CSS is either different or how did you turn on the green lines with summary data? I get a popup status message with similar info but not as stable or detailed as yours. On my system, I’m showing 80% utilization. The majority is in ucHeap (about 131k). I’ll bet on a function somewhere allocating a chunk of memory or repeatedly doing so and never using or releasing it. Should be ‘fun’ to find. Jim McCullers WA4CWI Looks like we have an issue with memory usage in RAM If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob [cid:image001.png@01DA47F2.8D773AF0] ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Memory Problem on PacSatSW
by Burns Fisher (AMSAT) 15 Jan '24

15 Jan '24

When you mentioned the heap, you reminded me: FreeRTOS has a heap, which is essentially just a big array. The only thing it gets used for is allocating task stacks and the structures that represent semaphores, queues, etc. And they way that I have used the OS, they get allocated but never released. But the thing I meant to say is that allocating smaller stacks does not use less memory from the linker's point of view because the array that the stacks are allocated from is not changed. There is a routine you can use to ask how much heap is free. After it is all booted up, unless the new code uses it differently than I did, any "free heap" is wasted. I think the size of the heap is an OS parameter in one of the free rtos header files. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Jan 15, 2024 at 7:31 PM Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > My version of CSS is either different or how did you turn on the green > lines with summary data? > > I get a popup status message with similar info but not as stable or > detailed as yours. > > > > On my system, I’m showing 80% utilization. > > The majority is in ucHeap (about 131k). > > I’ll bet on a function somewhere allocating a chunk of memory or > repeatedly doing so and never using or releasing it. > > Should be ‘fun’ to find. > > > > Jim McCullers > > WA4CWI > > > > > > > > Looks like we have an issue with memory usage in RAM > > > > If you load up CCS with the current project PacSatSW and build it then you > can select VIEW -> Memory Allocation and look at the tab. You will see the > package needs 154K or RAM and the Launpad has 191K. In the case of the > TMS570LS0914 we have 128K max. > > You can expand RAM and the subfolders and see where the memory is being > used. > > > > I worked for the last few days getting a HalCoGen setup for the LS0914 and > then murging this HCG file with the code of the Launcpad project. After > working through some issues it built but when it ran the linker it errored > out with not enough memory. So faked it out and told the linker I had more > memory. Then it would build and generate a .out file and the Memory > Allocation info. It matches the launch pad build. > > > > Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, > move buffers to external memory, or take out code. > > > > I will be looking for things here to try and complete a basic build of the > code for the LS0914. Please look for ideas and post any that you come up > with. We probably should target RAM usage at about 80% of the max or about > 100KB. We could change processors later but that would need some study. > > > > Bob > > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Memory Problem on PacSatSW
by Jim McCullers 15 Jan '24

15 Jan '24

My version of CSS is either different or how did you turn on the green lines with summary data? I get a popup status message with similar info but not as stable or detailed as yours. On my system, I'm showing 80% utilization. The majority is in ucHeap (about 131k). I'll bet on a function somewhere allocating a chunk of memory or repeatedly doing so and never using or releasing it. Should be 'fun' to find. Jim McCullers WA4CWI Looks like we have an issue with memory usage in RAM If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob

1 0

Re: Memory Problem on PacSatSW
by Burns Fisher (AMSAT) 15 Jan '24

15 Jan '24

Is there a variant of the TMS570LS0914 that has more memory? That might be the easiest fix. Note that what you call "external memory", really MRAM, is relatively slow. MRAM is also fairly small. It's big advantage is that it is non-volatile and fairly radiation resistant (and has a lot of space heritage with AMSAT and others). 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Jan 15, 2024 at 4:16 PM Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Since it ran and worked I never explored memory usage. > > I have to reconnect the development system and will cross check your > findings. > > That’s far more ram than I would have expected. > > > > Jim > > WA4CWI > > > > > > Looks like we have an issue with memory usage in RAM > > > > If you load up CCS with the current project PacSatSW and build it then you > can select VIEW -> Memory Allocation and look at the tab. You will see the > package needs 154K or RAM and the Launpad has 191K. In the case of the > TMS570LS0914 we have 128K max. > > You can expand RAM and the subfolders and see where the memory is being > used. > > > > I worked for the last few days getting a HalCoGen setup for the LS0914 and > then murging this HCG file with the code of the Launcpad project. After > working through some issues it built but when it ran the linker it errored > out with not enough memory. So faked it out and told the linker I had more > memory. Then it would build and generate a .out file and the Memory > Allocation info. It matches the launch pad build. > > > > Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, > move buffers to external memory, or take out code. > > > > I will be looking for things here to try and complete a basic build of the > code for the LS0914. Please look for ideas and post any that you come up > with. We probably should target RAM usage at about 80% of the max or about > 100KB. We could change processors later but that would need some study. > > > > Bob > > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Memory Problem on PacSatSW
by Jim McCullers 15 Jan '24

15 Jan '24

Since it ran and worked I never explored memory usage. I have to reconnect the development system and will cross check your findings. That's far more ram than I would have expected. Jim WA4CWI Looks like we have an issue with memory usage in RAM If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob

1 0

Memory Problem on PacSatSW
by Bob Stricklin 15 Jan '24

15 Jan '24

Looks like we have an issue with memory usage in RAM. If you load up CCS with the current project PacSatSW and build it then you can select VIEW -> Memory Allocation and look at the tab. You will see the package needs 154K or RAM and the Launpad has 191K. In the case of the TMS570LS0914 we have 128K max. You can expand RAM and the subfolders and see where the memory is being used. I worked for the last few days getting a HalCoGen setup for the LS0914 and then murging this HCG file with the code of the Launcpad project. After working through some issues it built but when it ran the linker it errored out with not enough memory. So faked it out and told the linker I had more memory. Then it would build and generate a .out file and the Memory Allocation info. It matches the launch pad build. Probably need to look for ways to reduce RAM needed. Reduce buffer sizes, move buffers to external memory, or take out code. I will be looking for things here to try and complete a basic build of the code for the LS0914. Please look for ideas and post any that you come up with. We probably should target RAM usage at about 80% of the max or about 100KB. We could change processors later but that would need some study. Bob [cid:image001.png@01DA47C3.B189E4D0]

1 0

Re: Using the Load-Pull Technique in RF Power Amplifier Design - Technical Articles
by Jim McCullers 12 Jan '24

12 Jan '24

Will give it read. Thanks Jim

1 0

Using the Load-Pull Technique in RF Power Amplifier Design - Technical Articles
by Bob Stricklin 12 Jan '24

12 Jan '24

https://www.allaboutcircuits.com/technical-articles/load-line-analysis-esti…

1 0

Re: Issue with touch in project
by Bob Stricklin 12 Jan '24

12 Jan '24

Yes, I am tracking Problems and also watching Console as things compile and post. Errors show up in Console that do not make it to Problems I noticed. I am now getting a clean build. You can turn all windows on in View Tab and with the icons on the left of screen. CCS arbitrarily turns them off I notice. Probably a way to override this with a personal IDE setup. I think under Window. I am not trying to say I have masted this. Still learning. Like I use the project view all the time and finally found the paste/folder icon on the left brings it up. I was using Window - ShowView. I have learned we are good on I2C and the Serial Port. Just have to check addresses used in CCS devices . H files. Working on SPI for AX5043s now and making sure there are no outputs in HalCoGen config on pins that will be driving outputs from other devices. I see what needs to be done just need to work through it. Hope to try testing this tomorrow. Any feedback is appreciated. I posted an order to mouser today for a few parts needed. Will have them Monday Maybe. Weather here may stop delivery. Ice possible. Bob On Jan 12, 2024, at 3:09 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: Of course it is always difficult to find featuers in Eclipse-based IDEs, but on my CCS, there is a tab labelled "Problems" when I compile. That clearly shows all the compile errors. I think you can get it turned on by the menu (3 vertical dots) on that window below the source editor. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Fri, Jan 12, 2024 at 3:52 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Thank you for the posting Burns. I moved my CCS file from Windows back to Linux. Then I removed the touch in preconfigure and built the project. BTW it had my directory path there so our friends at TI may have played this touch command there. i see some error msg go by but can not find them after build is complete and I get a out file. Moved the project back to Windows and built there now I do not see an issue and I get a out file. I will continue to use HCG to try and make changes now to setup the serial port for this PCB build. I need to be able to go in and out of HCG and rebuild the project to get all the hardware changes made. I will be carefully saving copy of the project to make sure I do not have issues. One of the things I have done is to remove all references to CAN from the project. I have renamed it PacSat_DevSW. Bob On Jan 12, 2024, at 8:18 AM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: That location on disk is on my Linux build system. Most things one writes in the IDE you can talk about relative to the base directory of the code (see for example the way header file locations are specified) but either I added this before I knew about talking about the base, or it is not possible (since this looks like it might be a shell script). The only reason for this was so that when you boot the software and/or do "show status" I think, it would tell you when it was built. The idea is that this would tell you if the code might be different even if you did not update the version number. As I recall, there is a built-in in gcc that, at compile time, creates as text the current time and gcc version. I just use those as constants to print. I don't know why you get errors when you remove it. What kind of errors? But certainly you could replace my location with your own. Or perhaps (even better) there is a symbol you can use for the base location of the project in any build environment. (Actually, touch is a Linux command, so this would probably not work on Windows???) 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Jan 11, 2024 at 11:05 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Burns, It seems to me this line of code is referring to a folder that would be on the users system under his home directory called gitRepos. I have looking in Windows under user and my name (home folder) and on my linux computer which I built this code and not seeing this on either one. I do see errors referring to the touch. When I remove it I have lots of errors. It looks like something that was put in place a long time ago when the project was just rt-ihu. With the line in place the project will build but I don’t like seeing the errors. I have used touch to force creation of a file but did not know you could sweep through a project and update times to current time. I see it is used for this according to "man touch". I wonder if an older version of CCS was not handling time the way people wanted and this was a work around? Maybe I could fix this by changing the touch path to match my current system project path info. Am I really that worried about changing a time stamp? Strange how this causes issue when removed. Maybe the Makefile is not keeping up with project properties changes real time. Changing all the dates would force a make -B I haven’t figured out if Build Project generates a new Makefile on every build cycle. Bob On Jan 11, 2024, at 9:42 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I think console routines fetches the time that the compile happened, so rebuilding it forces it to include the time of the compile regardless of whether anything else has changed in that routine. Touch should just change the date on the file so make will always compile it. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Jan 11, 2024 at 10:38 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: <PacSatSW_Issue.jpeg> Here is the location of the “touch” issue? What is this for? Why does it break things if you remove it? ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://mailman.amsat.org/> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://mailman.amsat.org/> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://mailman.amsat.org/> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org <Screenshot from 2024-01-12 16-06-11.png> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Issue with touch in project
by Burns Fisher (AMSAT) 12 Jan '24

12 Jan '24

Of course it is always difficult to find featuers in Eclipse-based IDEs, but on my CCS, there is a tab labelled "Problems" when I compile. That clearly shows all the compile errors. I think you can get it turned on by the menu (3 vertical dots) on that window below the source editor. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, Jan 12, 2024 at 3:52 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Thank you for the posting Burns. > > I moved my CCS file from Windows back to Linux. Then I removed the touch > in preconfigure and built the project. BTW it had my directory path there > so our friends at TI may have played this touch command there. > > i see some error msg go by but can not find them after build is complete > and I get a out file. > > Moved the project back to Windows and built there now I do not see an > issue and I get a out file. > > I will continue to use HCG to try and make changes now to setup the serial > port for this PCB build. > > I need to be able to go in and out of HCG and rebuild the project to get > all the hardware changes made. I will be carefully saving copy of the > project to make sure I do not have issues. > > One of the things I have done is to remove all references to CAN from the > project. I have renamed it PacSat_DevSW. > > Bob > > > On Jan 12, 2024, at 8:18 AM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> wrote: > > That location on disk is on my Linux build system. Most things one writes > in the IDE you can talk about relative to the base directory of the code > (see for example the way header file locations are specified) but either I > added this before I knew about talking about the base, or it is not > possible (since this looks like it might be a shell script). > > The only reason for this was so that when you boot the software and/or do > "show status" I think, it would tell you when it was built. The idea is > that this would tell you if the code might be different even if you did not > update the version number. As I recall, there is a built-in in gcc that, > at compile time, creates as text the current time and gcc version. I just > use those as constants to print. > > I don't know why you get errors when you remove it. What kind of errors? > But certainly you could replace my location with your own. Or perhaps > (even better) there is a symbol you can use for the base location of the > project in any build environment. (Actually, touch is a Linux command, so > this would probably not work on Windows???) > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Thu, Jan 11, 2024 at 11:05 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Burns, >> >> It seems to me this line of code is referring to a folder that would be >> on the users system under his home directory called gitRepos. >> I have looking in Windows under user and my name (home folder) and on my >> linux computer which I built this code and not seeing this on either one. >> I do see errors referring to the touch. When I remove it I have lots of >> errors. >> >> It looks like something that was put in place a long time ago when the >> project was just rt-ihu. >> >> With the line in place the project will build but I don’t like seeing the >> errors. >> >> I have used touch to force creation of a file but did not know you could >> sweep through a project and update times to current time. I see it is used >> for this according to "man touch". >> >> I wonder if an older version of CCS was not handling time the way people >> wanted and this was a work around? >> >> Maybe I could fix this by changing the touch path to match my current >> system project path info. >> >> Am I really that worried about changing a time stamp? >> >> Strange how this causes issue when removed. Maybe the Makefile is not >> keeping up with project properties changes real time. >> Changing all the dates would force a make -B >> I haven’t figured out if Build Project generates a new Makefile on every >> build cycle. >> >> Bob >> >> >> On Jan 11, 2024, at 9:42 PM, Burns Fisher (AMSAT) via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >> I think console routines fetches the time that the compile happened, so >> rebuilding it forces it to include the time of the compile regardless of >> whether anything else has changed in that routine. >> >> Touch should just change the date on the file so make will always compile >> it. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Thu, Jan 11, 2024 at 10:38 PM Bob Stricklin via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> <PacSatSW_Issue.jpeg> >>> >>> Here is the location of the “touch” issue? >>> >>> What is this for? >>> >>> Why does it break things if you remove it? >>> >>> ----------------------------------------------------------- >>> >>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>> View archives of this mailing list at >>> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>> Manage all of your AMSAT-NA mailing list preferences at >>> https://mailman.amsat.org >>> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> >> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0