June 2024 - pacsat-dev - mailman.amsat.org

Re: Pacsat dev mtg 6/27/2024
by Fevig, Ronald 28 Jun '24

28 Jun '24

Hello Bill, I apologize to you and the Pacsat group. I somehow forgot we had a meeting last night. I'll blame it on my mind getting too cluttered due to a very busy week. I now set a weekly alarm on my cell phone to remind me of our Thursday evening meetings. By the way, we flew a high-altitude balloon last Wednesday, June 26. The payload, a VHF/UHF cross-band repeater, ascended to almost 97,000' and landed in a heavily wooded area. We are still figuring out how to retrieve it. Repeater functionality was passable, but certainly not optimal. A picture of the students and balloon moments before launch is attached. 73 Ron N0UCV -----Original Message----- From: Bill via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Thursday, June 27, 2024 1:27 PM To: pacsat-dev(a)amsat.org Subject: [pacsat-dev] Pacsat dev mtg 6/27/2024 Pacsat dev mtg 6/27/2024 Thu, Jun 27, 2024 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/596395037 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (312) 757-3121 - One-touch: tel:+13127573121,,596395037# Access Code: 596-395-037 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 596 395 037 Or dial directly: 596395037(a)67.217.95.2 or 67.217.95.2##596395037 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] 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

Pacsat dev mtg 6/27/2024
by Bill 27 Jun '24

27 Jun '24

Pacsat dev mtg 6/27/2024 Thu, Jun 27, 2024 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/596395037 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (312) 757-3121 - One-touch: tel:+13127573121,,596395037# Access Code: 596-395-037 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 596 395 037 Or dial directly: 596395037(a)67.217.95.2 or 67.217.95.2##596395037 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: Pacsat dev mtg 6/20/2024
by Corey Minyard 20 Jun '24

20 Jun '24

Something just came up, I will not be able to make the meeting tonight. -corey On Thu, Jun 20, 2024 at 2:06 PM Bill via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > Pacsat dev mtg 6/20/2024 > Thu, Jun 20, 2024 7:00 PM - 9:00 PM (CDT) > > Please join my meeting from your computer, tablet or smartphone. > > https://meet.goto.com/345193165 > > You can also dial in using your phone. > (For supported devices, tap a one-touch number below to join instantly.) > > United States: +1 (571) 317-3122 > - One-touch: tel:+15713173122,,345193165# > > Access Code: 345-193-165 > > Join from a video-conferencing room or system. > Dial in or type: 67.217.95.2 or inroomlink.goto.com > Meeting ID: 345 193 165 > Or dial directly: 345193165(a)67.217.95.2 or 67.217.95.2##345193165 > > > Get the app now and be ready when your first meeting starts: > https://meet.goto.com/install > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] > 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

Pacsat dev mtg 6/20/2024
by Bill 20 Jun '24

20 Jun '24

Pacsat dev mtg 6/20/2024 Thu, Jun 20, 2024 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/345193165 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (571) 317-3122 - One-touch: tel:+15713173122,,345193165# Access Code: 345-193-165 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 345 193 165 Or dial directly: 345193165(a)67.217.95.2 or 67.217.95.2##345193165 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: Cursory look at compression on Pacsat
by Chris Thompson 18 Jun '24

18 Jun '24

I think that looks really useful. Especially given someone else already did a Java port. I think we would use this at the file level, reading from an uncompressed file and creating a compressed one. 73 Chris On Tue, Jun 18, 2024 at 2:03 PM Corey Minyard via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > The most popular library seems to be heatshrink, at > https://github.com/atomicobject/heatshrink. There is a Java > implementation at https://github.com/markrileybot/heatshrink-java/ > > However, the C implementation hasn't been updated in 9 years. Not sure > what to make of that. It has a moderate number of issues. But it still > seems to be very popular. > > Tons of other libraries are available, but this seems the most used. > > -corey > > On Tue, Jun 18, 2024 at 11:13 AM Chris Thompson via pacsat-dev > <pacsat-dev(a)amsat.org> wrote: > > > > I think this is worth pursuing. If it's a simple algorithm then we > could port to java. Or have a standalone C executable that the ground > station runs. > > > > This would mainly be to compress logs, experiment data or telemetry > before it is downloaded. Uploading compressed data that the spacecraft can > uncompress is a separate use case if we want patch configuration or code. > > > > In a third seperate use case we can already compress large files and > upload them for later download. The spacecraft just treats them as binary > data and the ground stations do all the work. > > > > 73 > > Chris > > > > On Sun, Jun 16, 2024, 18:39 Corey Minyard via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> > >> I spent some time looking at implementations of compression > >> algorithms. As Bob pointed out, memory can be an issue with these > >> libraries. I was hoping to say that zlib (gzip) would be suitable, > >> but its minimum memory requirement appears to be 128K. There appears > >> to be a way to reduce that, but it's still probably going to be too > >> big. Later, better algorithms like bzip are going to be even more > >> memory intensive. > >> > >> I searched around and there are a large number of compression > >> libraries that are free and designed for microcontrollers, with memory > >> requirements in the hundreds of bytes (or even less!). None are as > >> good as even zlib, but they are better than LZW (compress) and would > >> be adequate. Also, more critically, they are designed to compress > >> small amounts of data efficiently. The trouble then becomes finding > >> one with a Java implementation, if we are planning to send the > >> compressed data over the download or uplink. > >> > >> Is this something worth pursuing? > >> > >> -corey - AE5KM > >> > >> ----------------------------------------------------------- > >> > >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org > >> View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > >> 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/[email protected] > > 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/[email protected] > 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 > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: Cursory look at compression on Pacsat
by Corey Minyard 18 Jun '24

18 Jun '24

The most popular library seems to be heatshrink, at https://github.com/atomicobject/heatshrink. There is a Java implementation at https://github.com/markrileybot/heatshrink-java/ However, the C implementation hasn't been updated in 9 years. Not sure what to make of that. It has a moderate number of issues. But it still seems to be very popular. Tons of other libraries are available, but this seems the most used. -corey On Tue, Jun 18, 2024 at 11:13 AM Chris Thompson via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > I think this is worth pursuing. If it's a simple algorithm then we could port to java. Or have a standalone C executable that the ground station runs. > > This would mainly be to compress logs, experiment data or telemetry before it is downloaded. Uploading compressed data that the spacecraft can uncompress is a separate use case if we want patch configuration or code. > > In a third seperate use case we can already compress large files and upload them for later download. The spacecraft just treats them as binary data and the ground stations do all the work. > > 73 > Chris > > On Sun, Jun 16, 2024, 18:39 Corey Minyard via pacsat-dev <pacsat-dev(a)amsat.org> wrote: >> >> I spent some time looking at implementations of compression >> algorithms. As Bob pointed out, memory can be an issue with these >> libraries. I was hoping to say that zlib (gzip) would be suitable, >> but its minimum memory requirement appears to be 128K. There appears >> to be a way to reduce that, but it's still probably going to be too >> big. Later, better algorithms like bzip are going to be even more >> memory intensive. >> >> I searched around and there are a large number of compression >> libraries that are free and designed for microcontrollers, with memory >> requirements in the hundreds of bytes (or even less!). None are as >> good as even zlib, but they are better than LZW (compress) and would >> be adequate. Also, more critically, they are designed to compress >> small amounts of data efficiently. The trouble then becomes finding >> one with a Java implementation, if we are planning to send the >> compressed data over the download or uplink. >> >> Is this something worth pursuing? >> >> -corey - AE5KM >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] >> 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/[email protected] > 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: Cursory look at compression on Pacsat
by Chris Thompson 18 Jun '24

18 Jun '24

I think this is worth pursuing. If it's a simple algorithm then we could port to java. Or have a standalone C executable that the ground station runs. This would mainly be to compress logs, experiment data or telemetry before it is downloaded. Uploading compressed data that the spacecraft can uncompress is a separate use case if we want patch configuration or code. In a third seperate use case we can already compress large files and upload them for later download. The spacecraft just treats them as binary data and the ground stations do all the work. 73 Chris On Sun, Jun 16, 2024, 18:39 Corey Minyard via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I spent some time looking at implementations of compression > algorithms. As Bob pointed out, memory can be an issue with these > libraries. I was hoping to say that zlib (gzip) would be suitable, > but its minimum memory requirement appears to be 128K. There appears > to be a way to reduce that, but it's still probably going to be too > big. Later, better algorithms like bzip are going to be even more > memory intensive. > > I searched around and there are a large number of compression > libraries that are free and designed for microcontrollers, with memory > requirements in the hundreds of bytes (or even less!). None are as > good as even zlib, but they are better than LZW (compress) and would > be adequate. Also, more critically, they are designed to compress > small amounts of data efficiently. The trouble then becomes finding > one with a Java implementation, if we are planning to send the > compressed data over the download or uplink. > > Is this something worth pursuing? > > -corey - AE5KM > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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: Launchpad for Ron
by Chris Thompson 17 Jun '24

17 Jun '24

Ok, I can't reproduce that. I checked out the LaunchPad branch and flashed the LaunchPad here. It does not reset every 10 seconds. It runs fine with a changed callsign. With "monitor on" I can see a received packet from the ground. Some things to note. If the RxTask was not working then that was perhaps causing the watchdog to reset. I don't see anything that would cause that, but perhaps the initial setup hangs or the read RSSI hangs. That would trigger the watchdog. But with that said get AX is reading from the Chip it seem... You should try to reset the frequencies to their default values. Rhe 900MHz frequency does not look like it ranged correctly so perhaps that caused the init to fail. You can't reset everything with "init new proc" because it looks like that was not defined at this time. But you should be able to use the command "lower rx freq" and then "save freq". But there is a maximum amount you can lower it as I remember... If it is a new LaunchPad from TI then I seem to remember that Jim had some setup instructions. There was a jumper or two to add or remove. Did you do those changes? Or was this the working LunchPad board from Bob which already had those changes? 73 Chris On Mon, Jun 17, 2024 at 4:26 PM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I will try to reproduce that here. To see if it is a hardware issue, or > not. > > 73 > Chris > > On Mon, Jun 17, 2024 at 1:05 PM Bill Reed via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> I received Bob's launchpad and have found the following: >> >> I am using the Launchpad branch on github.com/AMSAT-NA/PacSatSW >> >> I edited the config.h file to change the pacsat callsign to Ron's call - >> k0UND >> >> I started testing and found that the launchpad would transmit OK but it >> didn't receive. >> >> I connected the console and found that the launchpad was resetting every >> 10 seconds. >> The reset was precede by "WDxx" >> >> I assumed that the Watchdog was causing the reset and I commented out >> "#define WATCHDOG ENABLE" >> This change stopped the resets but it still didn't receive. >> >> Pacsat>get ax5043 status provided: >> >> AX5043 dev 1 TX: >> FIFOSTAT: 21 >> PWRMODE:: 0d >> XTALCAP: 0 >> PLLLOOP: 0a >> PLLCPI: 10 >> PLLVCOI: 97 >> PLLRANGINGA: 49 >> PLLVCODIV: 24 >> FREQ 435759999 Hz >> MODULATION: a >> TXPWRCOEFFB0: 20 >> TXPWRCOEFFB1: 0 >> >> AX5043 dev 0 RX: >> FIFOSTAT: 00 >> PWRMODE: 05 >> XTALCAP: 0 >> PLLLOOP: 09 >> PLLCPI: 08 >> PLLVCOI: 97 >> PLLRANGINGA: 08 >> PLLVCODIV: 30 >> FREQ 915300000 Hz >> MODULATION: 8 >> TXPWRCOEFFB0: 20 >> TXPWRCOEFFB1: 0 >> >> It looks like the RX dev 0 FIFOSTAT:00 and FREQ 915300000 Hz >> could indicate a problem. >> >> Frequency should read FREQ 145835000 Hz >> >> Could this be an AX5043 chip problem? >> >> Any suggestions on what I might do for additional debugging? >> >> Does anyone have an available launchpad I can send to Ron? >> >> Bill >> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> 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 >> > > > -- > Chris E. Thompson > chrisethompson(a)gmail.com > g0kla(a)arrl.net > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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 > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: Launchpad for Ron
by Chris Thompson 17 Jun '24

17 Jun '24

I will try to reproduce that here. To see if it is a hardware issue, or not. 73 Chris On Mon, Jun 17, 2024 at 1:05 PM Bill Reed via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I received Bob's launchpad and have found the following: > > I am using the Launchpad branch on github.com/AMSAT-NA/PacSatSW > > I edited the config.h file to change the pacsat callsign to Ron's call - > k0UND > > I started testing and found that the launchpad would transmit OK but it > didn't receive. > > I connected the console and found that the launchpad was resetting every > 10 seconds. > The reset was precede by "WDxx" > > I assumed that the Watchdog was causing the reset and I commented out > "#define WATCHDOG ENABLE" > This change stopped the resets but it still didn't receive. > > Pacsat>get ax5043 status provided: > > AX5043 dev 1 TX: > FIFOSTAT: 21 > PWRMODE:: 0d > XTALCAP: 0 > PLLLOOP: 0a > PLLCPI: 10 > PLLVCOI: 97 > PLLRANGINGA: 49 > PLLVCODIV: 24 > FREQ 435759999 Hz > MODULATION: a > TXPWRCOEFFB0: 20 > TXPWRCOEFFB1: 0 > > AX5043 dev 0 RX: > FIFOSTAT: 00 > PWRMODE: 05 > XTALCAP: 0 > PLLLOOP: 09 > PLLCPI: 08 > PLLVCOI: 97 > PLLRANGINGA: 08 > PLLVCODIV: 30 > FREQ 915300000 Hz > MODULATION: 8 > TXPWRCOEFFB0: 20 > TXPWRCOEFFB1: 0 > > It looks like the RX dev 0 FIFOSTAT:00 and FREQ 915300000 Hz > could indicate a problem. > > Frequency should read FREQ 145835000 Hz > > Could this be an AX5043 chip problem? > > Any suggestions on what I might do for additional debugging? > > Does anyone have an available launchpad I can send to Ron? > > Bill > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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 > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Launchpad for Ron
by Bill Reed 17 Jun '24

17 Jun '24

I received Bob's launchpad and have found the following: I am using the Launchpad branch on github.com/AMSAT-NA/PacSatSW I edited the config.h file to change the pacsat callsign to Ron's call - k0UND I started testing and found that the launchpad would transmit OK but it didn't receive. I connected the console and found that the launchpad was resetting every 10 seconds. The reset was precede by "WDxx" I assumed that the Watchdog was causing the reset and I commented out "#define WATCHDOG ENABLE" This change stopped the resets but it still didn't receive. Pacsat>get ax5043 status provided: AX5043 dev 1 TX: FIFOSTAT: 21 PWRMODE:: 0d XTALCAP: 0 PLLLOOP: 0a PLLCPI: 10 PLLVCOI: 97 PLLRANGINGA: 49 PLLVCODIV: 24 FREQ 435759999 Hz MODULATION: a TXPWRCOEFFB0: 20 TXPWRCOEFFB1: 0 AX5043 dev 0 RX: FIFOSTAT: 00 PWRMODE: 05 XTALCAP: 0 PLLLOOP: 09 PLLCPI: 08 PLLVCOI: 97 PLLRANGINGA: 08 PLLVCODIV: 30 FREQ 915300000 Hz MODULATION: 8 TXPWRCOEFFB0: 20 TXPWRCOEFFB1: 0 It looks like the RX dev 0 FIFOSTAT:00 and FREQ 915300000 Hz could indicate a problem. Frequency should read FREQ 145835000 Hz Could this be an AX5043 chip problem? Any suggestions on what I might do for additional debugging? Does anyone have an available launchpad I can send to Ron? Bill

1 0