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

Re: Pacsat dev mtg 3/28/2024
by Burns Fisher (AMSAT) 28 Mar '24

28 Mar '24

I might be late. I have a meeting at 7 (eastern). 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Mar 28, 2024 at 1:33 PM Bill via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > Pacsat dev mtg 3/28/2024 > Thu, Mar 28, 2024 7:00 PM - 9:00 PM (CDT) > > Please join my meeting from your computer, tablet or smartphone. > > https://meet.goto.com/167541909 > > You can also dial in using your phone. > (For supported devices, tap a one-touch number below to join instantly.) > > United States: +1 (224) 501-3412 > - One-touch: tel:+12245013412,,167541909# > > Access Code: 167-541-909 > > Join from a video-conferencing room or system. > Dial in or type: 67.217.95.2 or inroomlink.goto.com > Meeting ID: 167 541 909 > Or dial directly: 167541909(a)67.217.95.2 or 67.217.95.2##167541909 > > > 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/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

Pacsat dev mtg 3/28/2024
by Bill 28 Mar '24

28 Mar '24

Pacsat dev mtg 3/28/2024 Thu, Mar 28, 2024 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/167541909 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (224) 501-3412 - One-touch: tel:+12245013412,,167541909# Access Code: 167-541-909 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 167 541 909 Or dial directly: 167541909(a)67.217.95.2 or 67.217.95.2##167541909 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: Meeting
by Burns Fisher (AMSAT) 21 Mar '24

21 Mar '24

Oh dear...looks like a small meeting...I can't make it either! Sorry about that! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Mar 21, 2024 at 6:29 PM Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Can’t make the meeting tonight. > > > > The board has been modified with Bob’s 1st method as it was well under > way before method two was conceived. > > Method two appears to be easier and probably preferred. > > > > I’ll begin testing this weekend on the work, then on to the receivers. > > > > Jim > > WA4CWI > > ----------------------------------------------------------- > > 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

Meeting
by Jim McCullers 21 Mar '24

21 Mar '24

Can't make the meeting tonight. The board has been modified with Bob's 1st method as it was well under way before method two was conceived. Method two appears to be easier and probably preferred. I'll begin testing this weekend on the work, then on to the receivers. Jim WA4CWI

1 0

Pacsat dev mtg
by Bill 21 Mar '24

21 Mar '24

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

1 0

Re: Digipeater
by Chris Thompson 21 Mar '24

21 Mar '24

Hi Bill, There are two ways. Firstly, it can send telemetry bytes in a UI packet. We already do this today and there is some telemetry that accumulates in the telemetry tab. It has not yet been updated to reflect all 4 receivers. Secondly, it can store telemetry in a file for later download. This will give telemetry across the orbit or Whole Orbit Data. This has not been implemented but the framework is in place. 73 Chris On Thu, Mar 21, 2024, 12:10 Bill Reed <bill(a)brconnect.com> wrote: > How can a satellite ihu send telemetry via pacsat. I would assume > commands via the pacsat console? > > Bill > On 3/21/2024 10:55 AM, Chris Thompson via pacsat-dev wrote: > > I have pushed version X0.2c to main. This includes the Digipeater. > > You can check the status of the digipeater with: > get status > > You can turn it on and off from the console with: > open digi > shut digi > > You can send a ground command from the version 0.46f of pacsat ground, > which can be downloaded here: > https://www.g0kla.com/pacsat/ > > The digipeater requires the via callsign to equal the callsign as setup in > the code. To simplify that I now print the callsigns at boot into the > console. > > I tested this with UISS, but would appreciate other tests. > > The digi is on or off for all receiver channels. We probably want to be > able to turn it on for just one of them, so I have reserved 4 bytes in MRAM > to hold some mode bits for each receiver channel. We can then configure a > channel to be command only, or to optionally support broadcast, uplink or > digi packets. The bytes are there but the rest of the code and commands > needs to be written. Given I inserted new bytes you will need to run pre > flight init or maybe even init new proc. > > With that said, I won't be able to make the meeting tonight due to a clash > with another meeting. Send questions or comments here via email. We can > also discuss next time. > > 73 > Chris > > -- > 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/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: Digipeater
by Bob Stricklin 21 Mar '24

21 Mar '24

This all sounds very cool. I will do some testing. Bob On Mar 21, 2024, at 10:55 AM, Chris Thompson via pacsat-dev <pacsat-dev(a)amsat.org> wrote: I have pushed version X0.2c to main. This includes the Digipeater. You can check the status of the digipeater with: get status You can turn it on and off from the console with: open digi shut digi You can send a ground command from the version 0.46f of pacsat ground, which can be downloaded here: https://www.g0kla.com/pacsat/ The digipeater requires the via callsign to equal the callsign as setup in the code. To simplify that I now print the callsigns at boot into the console. I tested this with UISS, but would appreciate other tests. The digi is on or off for all receiver channels. We probably want to be able to turn it on for just one of them, so I have reserved 4 bytes in MRAM to hold some mode bits for each receiver channel. We can then configure a channel to be command only, or to optionally support broadcast, uplink or digi packets. The bytes are there but the rest of the code and commands needs to be written. Given I inserted new bytes you will need to run pre flight init or maybe even init new proc. With that said, I won't be able to make the meeting tonight due to a clash with another meeting. Send questions or comments here via email. We can also discuss next time. 73 Chris -- Chris E. Thompson chrisethompson(a)gmail.com<mailto:chrisethompson@gmail.com> g0kla(a)arrl.net<mailto:g0kla@arrl.net> ----------------------------------------------------------- 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

Digipeater
by Chris Thompson 21 Mar '24

21 Mar '24

I have pushed version X0.2c to main. This includes the Digipeater. You can check the status of the digipeater with: get status You can turn it on and off from the console with: open digi shut digi You can send a ground command from the version 0.46f of pacsat ground, which can be downloaded here: https://www.g0kla.com/pacsat/ The digipeater requires the via callsign to equal the callsign as setup in the code. To simplify that I now print the callsigns at boot into the console. I tested this with UISS, but would appreciate other tests. The digi is on or off for all receiver channels. We probably want to be able to turn it on for just one of them, so I have reserved 4 bytes in MRAM to hold some mode bits for each receiver channel. We can then configure a channel to be command only, or to optionally support broadcast, uplink or digi packets. The bytes are there but the rest of the code and commands needs to be written. Given I inserted new bytes you will need to run pre flight init or maybe even init new proc. With that said, I won't be able to make the meeting tonight due to a clash with another meeting. Send questions or comments here via email. We can also discuss next time. 73 Chris -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: RX Device Decode
by Bob Stricklin 14 Mar '24

14 Mar '24

This is clear and helpful. Thanks On Mar 14, 2024, at 8:45 PM, Chris Thompson via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I pushed my latest code to main including the fix to the TX channel number. Here is my decode of the RX devices. RX Channel C – 145.840 0 - U405 Single Ended 35 N2HET1_9 AX5043_SEL3 U405-14 RX3 SEL Position 0 22 GIOA_7 AX5043_IRQ_RX3 U405-19 RX3_IRQ Position 0 AX5043 RX Device 3 - AX5043Dev2 RX Channel B – 145.810 1 - U305 Differential 33 N2HET1_7 AX5043_SEL2 U305-1 RX2 Select Position 1 126 GOIB_0 AX5043_IRQ_RX2 U305-19 RX2 IRQ` Position 1 AX5043 RX Device 2 - AX5043Dev1 RX Channel A – 145.780 2 - U205 Differential 24 N2HET1_3 AX5043_SEL1 U205-14 RX1_SEL Position 2 --- CONMFIRMED SIGNAL 5 GIOA_1 AX5043_IRQ_RX1 U205-19 RX1_IRQ Position 2 AX5043 RX Device 1 - AX5043Dev0 RX Channel D – 145.870 3 - U505 Differential 36 N2HET1_4 AX5042_SEL4 U505-14 RX4 SEL Position 3 14 GIOA_5 AX5043_IRQ_RX4 U505-19 RX4_IRQ Position 3 AX5043 RX Device 4 - AX5043Dev3 73 Chris -- Chris E. Thompson chrisethompson(a)gmail.com<mailto:chrisethompson@gmail.com> g0kla(a)arrl.net<mailto:g0kla@arrl.net> ----------------------------------------------------------- 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: RX Device Decode
by BILL 14 Mar '24

14 Mar '24

Thanks. ⁣Get BlueMail for Android On Mar 14, 2024, 20:45, at 20:45, Chris Thompson via pacsat-dev <pacsat-dev(a)amsat.org> wrote: >I pushed my latest code to main including the fix to the TX channel >number. > >Here is my decode of the RX devices. > > > >RX Channel C – 145.840 > >0 - U405 > >Single Ended > >35 N2HET1_9 AX5043_SEL3 U405-14 RX3 SEL Position 0 > >22 GIOA_7 AX5043_IRQ_RX3 U405-19 RX3_IRQ Position 0 > >AX5043 RX Device 3 - AX5043Dev2 > > > > > >RX Channel B – 145.810 > >1 - U305 > >Differential > >33 N2HET1_7 AX5043_SEL2 U305-1 RX2 Select Position 1 > >126 GOIB_0 AX5043_IRQ_RX2 U305-19 RX2 IRQ` Position 1 > >AX5043 RX Device 2 - AX5043Dev1 > > > >RX Channel A – 145.780 > >2 - U205 > >Differential > >24 N2HET1_3 AX5043_SEL1 U205-14 RX1_SEL Position 2 --- >CONMFIRMED >SIGNAL > >5 GIOA_1 AX5043_IRQ_RX1 U205-19 RX1_IRQ Position 2 > >AX5043 RX Device 1 - AX5043Dev0 > > > >RX Channel D – 145.870 > >3 - U505 > >Differential > >36 N2HET1_4 AX5042_SEL4 U505-14 RX4 SEL Position 3 > >14 GIOA_5 AX5043_IRQ_RX4 U505-19 RX4_IRQ Position 3 > >AX5043 RX Device 4 - AX5043Dev3 > > >73 > >Chris > >-- >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/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

RX Device Decode
by Chris Thompson 14 Mar '24

14 Mar '24

I pushed my latest code to main including the fix to the TX channel number. Here is my decode of the RX devices. RX Channel C – 145.840 0 - U405 Single Ended 35 N2HET1_9 AX5043_SEL3 U405-14 RX3 SEL Position 0 22 GIOA_7 AX5043_IRQ_RX3 U405-19 RX3_IRQ Position 0 AX5043 RX Device 3 - AX5043Dev2 RX Channel B – 145.810 1 - U305 Differential 33 N2HET1_7 AX5043_SEL2 U305-1 RX2 Select Position 1 126 GOIB_0 AX5043_IRQ_RX2 U305-19 RX2 IRQ` Position 1 AX5043 RX Device 2 - AX5043Dev1 RX Channel A – 145.780 2 - U205 Differential 24 N2HET1_3 AX5043_SEL1 U205-14 RX1_SEL Position 2 --- CONMFIRMED SIGNAL 5 GIOA_1 AX5043_IRQ_RX1 U205-19 RX1_IRQ Position 2 AX5043 RX Device 1 - AX5043Dev0 RX Channel D – 145.870 3 - U505 Differential 36 N2HET1_4 AX5042_SEL4 U505-14 RX4 SEL Position 3 14 GIOA_5 AX5043_IRQ_RX4 U505-19 RX4_IRQ Position 3 AX5043 RX Device 4 - AX5043Dev3 73 Chris -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: Pacsat dev mtg 3-14-2024
by Chris Thompson 14 Mar '24

14 Mar '24

Attached is a short discussion document for the Digipeater. 73 Chris On Thu, Mar 14, 2024 at 2:26 PM Bill via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > Pacsat dev mtg 3-14-2024 > Thu, Mar 14, 2024 7:00 PM - 9:00 PM (CDT) > > Please join my meeting from your computer, tablet or smartphone. > > https://meet.goto.com/987217125 > > You can also dial in using your phone. > (For supported devices, tap a one-touch number below to join instantly.) > > United States: +1 (872) 240-3412 > - One-touch: tel:+18722403412,,987217125# > > Access Code: 987-217-125 > > Join from a video-conferencing room or system. > Dial in or type: 67.217.95.2 or inroomlink.goto.com > Meeting ID: 987 217 125 > Or dial directly: 987217125(a)67.217.95.2 or 67.217.95.2##987217125 > > > 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/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 > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: Pacsat dev mtg 3-14-2024
by Burns Fisher (AMSAT) 14 Mar '24

14 Mar '24

My other meeting is tonight so I won't be there. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Mar 14, 2024 at 2:26 PM Bill via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > Pacsat dev mtg 3-14-2024 > Thu, Mar 14, 2024 7:00 PM - 9:00 PM (CDT) > > Please join my meeting from your computer, tablet or smartphone. > > https://meet.goto.com/987217125 > > You can also dial in using your phone. > (For supported devices, tap a one-touch number below to join instantly.) > > United States: +1 (872) 240-3412 > - One-touch: tel:+18722403412,,987217125# > > Access Code: 987-217-125 > > Join from a video-conferencing room or system. > Dial in or type: 67.217.95.2 or inroomlink.goto.com > Meeting ID: 987 217 125 > Or dial directly: 987217125(a)67.217.95.2 or 67.217.95.2##987217125 > > > 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/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

Pacsat dev mtg 3-14-2024
by Bill 14 Mar '24

14 Mar '24

Pacsat dev mtg 3-14-2024 Thu, Mar 14, 2024 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/987217125 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (872) 240-3412 - One-touch: tel:+18722403412,,987217125# Access Code: 987-217-125 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 987 217 125 Or dial directly: 987217125(a)67.217.95.2 or 67.217.95.2##987217125 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Telemetry
by Bill Reed 10 Mar '24

10 Mar '24

Is there a pacsat console command to downlink telemetry?

1 0

Re: RTC
by Bob Stricklin 08 Mar '24

08 Mar '24

Thanks for the report. Thats cool! I will be giving it a try. Bob On Mar 8, 2024, at 8:19 AM, Chris Thompson via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Bob, I left Blinky unplugged overnight and it started up this morning with the correct time from the RTC. So that is now working. The code change is in the main branch. 73 Chris -- Chris E. Thompson chrisethompson(a)gmail.com<mailto:chrisethompson@gmail.com> g0kla(a)arrl.net<mailto:g0kla@arrl.net> ----------------------------------------------------------- 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

RTC
by Chris Thompson 08 Mar '24

08 Mar '24

Bob, I left Blinky unplugged overnight and it started up this morning with the correct time from the RTC. So that is now working. The code change is in the main branch. 73 Chris -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Pacsat dev mtg 3/7/2024
by Bill 07 Mar '24

07 Mar '24

Pacsat dev mtg Thu, Mar 7, 2024 7:00 PM - 9:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/317052117 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-3112 - One-touch: tel:+15713173112,,317052117# Access Code: 317-052-117 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 317 052 117 Or dial directly: 317052117(a)67.217.95.2 or 67.217.95.2##317052117 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: Blinky Transmiter
by Bob Stricklin 06 Mar '24

06 Mar '24

Jim, I sacrificed one of the little jumpers with the black thin coax. I probably should not cut more. I was going to order more from China but have not yet. Scope is HP 54522A 500 MHz. Purchased on eBay. Bob ________________________________ From: Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Wednesday, March 6, 2024 9:00 AM To: Bob Stricklin <bstrick(a)n5brg.com>; 'Pacsat Dev' <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: Blinky Transmiter Thanks for the box. At the moment it’s hanging. The smallest coax I have is RG-174. I do have a few connectors with the same you use on the board to SMA and can sacrifice one except the coax is the transparent stiff variety, not certain of the number. If your is more flexible and you can space an few inches send some with the box. Otherwise I can make something work. Need to raid the scrap cable bin. What scope do you have? Now wish I had bought a 200mhz but settled for 100 and 4-channels analog. Digital scope is also 100mhz. Hope to finish my RF probe tonight and test. Jim Jim, Thanks for your report. I did reconnect the transformer to the 4X splinters using the fine coax and things seem to be working fine that way. I have not tried it with packet data yet but will do that when I can. The image below is the dif input to one of the receivers. The south trace is offset by 1 cm so we can it it better. Phasing looks good. Noise is due to poor ground in my setup mostly I feel. I received my 3D printer and I have printed three more of the plastic boxes for the programming board. I will mail you and Chris one maybe tomorrow. Bob [cid:image001.png@01DA6FA4.B5237350] On Mar 5, 2024, at 4:02 PM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I did some analysis on Blinky’s transmitter last night and did not see the spurs Bob saw on his board. My experience with using a spectrum analyzer close in looking for spurs or phase noise is limited so more analysis is needed. I did look at the harmonics and the second was down 48 db from the fundamental (+15 to -33 dbm). The third harmonic was in the noise and undetectable. Now, for receiver board surgery. Jim McCullers WA4CWI ----------------------------------------------------------- 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/>

1 0

Re: Blinky Transmiter
by Jim McCullers 06 Mar '24

06 Mar '24

Thanks for the box. At the moment it’s hanging. The smallest coax I have is RG-174. I do have a few connectors with the same you use on the board to SMA and can sacrifice one except the coax is the transparent stiff variety, not certain of the number. If your is more flexible and you can space an few inches send some with the box. Otherwise I can make something work. Need to raid the scrap cable bin. What scope do you have? Now wish I had bought a 200mhz but settled for 100 and 4-channels analog. Digital scope is also 100mhz. Hope to finish my RF probe tonight and test. Jim Jim, Thanks for your report. I did reconnect the transformer to the 4X splinters using the fine coax and things seem to be working fine that way. I have not tried it with packet data yet but will do that when I can. The image below is the dif input to one of the receivers. The south trace is offset by 1 cm so we can it it better. Phasing looks good. Noise is due to poor ground in my setup mostly I feel. I received my 3D printer and I have printed three more of the plastic boxes for the programming board. I will mail you and Chris one maybe tomorrow. Bob On Mar 5, 2024, at 4:02 PM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > wrote: I did some analysis on Blinky’s transmitter last night and did not see the spurs Bob saw on his board. My experience with using a spectrum analyzer close in looking for spurs or phase noise is limited so more analysis is needed. I did look at the harmonics and the second was down 48 db from the fundamental (+15 to -33 dbm). The third harmonic was in the noise and undetectable. Now, for receiver board surgery. Jim McCullers WA4CWI ----------------------------------------------------------- pacsat-dev mailing list -- <mailto:pacsat-dev@amsat.org> pacsat-dev(a)amsat.org View archives of this mailing list at <https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to <mailto:pacsat-dev-leave@amsat.org> pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at <https://mailman.amsat.org/> https://mailman.amsat.org

1 0

Re: Blinky Transmiter
by Bob Stricklin 05 Mar '24

05 Mar '24

Jim, Thanks for your report. I did reconnect the transformer to the 4X splinters using the fine coax and things seem to be working fine that way. I have not tried it with packet data yet but will do that when I can. The image below is the dif input to one of the receivers. The south trace is offset by 1 cm so we can it it better. Phasing looks good. Noise is due to poor ground in my setup mostly I feel. I received my 3D printer and I have printed three more of the plastic boxes for the programming board. I will mail you and Chris one maybe tomorrow. Bob [cid:D1F394D9-48CB-4B61-913A-21265908B344@StricklinRanch.com] On Mar 5, 2024, at 4:02 PM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I did some analysis on Blinky’s transmitter last night and did not see the spurs Bob saw on his board. My experience with using a spectrum analyzer close in looking for spurs or phase noise is limited so more analysis is needed. I did look at the harmonics and the second was down 48 db from the fundamental (+15 to -33 dbm). The third harmonic was in the noise and undetectable. Now, for receiver board surgery. Jim McCullers WA4CWI ----------------------------------------------------------- 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/>

1 0

Blinky Transmiter
by Jim McCullers 05 Mar '24

05 Mar '24

I did some analysis on Blinky's transmitter last night and did not see the spurs Bob saw on his board. My experience with using a spectrum analyzer close in looking for spurs or phase noise is limited so more analysis is needed. I did look at the harmonics and the second was down 48 db from the fundamental (+15 to -33 dbm). The third harmonic was in the noise and undetectable. Now, for receiver board surgery. Jim McCullers WA4CWI

1 0

Re: Chrs and others asked for details about initialization comands. Here they are:
by Burns Fisher (AMSAT) 01 Mar '24

01 Mar '24

Thanks, Bob. I just realized that I changed "raise/lower rx freq" to take the number of the receiver as well. And also Chris mentioned that the device numbers are inconsistent. I *intended* the receivers to be numbered Rx1 Rx2 Rx3 and Rx4 and then Tx. I think those are 5043 number 0,1,2,3,4 (in the places where you want to use the device number). This may not be the best way to do it. Maybe the receiver 5043s should be number 0 1 2 3 to match the device numbers, but somewhere I saw the numbers were 1-based and that is what I used. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, Mar 1, 2024 at 12:39 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Nice job on this documenttion Burns. > > Bob > > On Mar 1, 2024, at 10:34 AM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > *init new proc: * > Does some initialization that should only be done one time. > Specifically: > --Finds the right size for MRAM etc (which wipes out previous contents). > --Initializes the values for things that are generally going to be tweaked > on the bench, and not after the satellite is assembled, namely the default > values of the 4 Rx frequencies, the Tx frequency and the values of the high > and low power. > ++++Note that these values are at the early address of the MRAM, so if you > add stuff to MRAM, these locations should not change. > --Does "clear mram" (see below) > > *preflight init* > --Initializes all values in MRAM that want to be fresh when first > launched. For example, Min/Max values, Epoch, time, startup state, > autosafe voltages, frequency of saving WOD, etc. (Maybe some of these are > not relevant for PacSat) > --Initializes the MRAM version number. (See below) > --Probably by rights it should format the filesystem too. Right now, it > zaps the MRAM so 'main' sees that the file system can't be initialized and > formats it. A bit convoluted. > --Clears the "in orbit" flag so that the satellite code waits about 50 > minutes after power on before transmitting or doing anything else other > than waiting. This is so it can clear the Launch Vehicle. > > *clear mram* > --The same as preflight init, except that it SETS the "in orbit" flag. and > starts right away. > > *Note on the "default frequency"* > Currently the Rx default freqs are all the same. Fix in > "IHUInitSaved", module nonvolManagement.c. I'd change from a do to 4 > WriteMRAMReceiveFreq calls each with a different DCT_DEFAULT_RX_FREQ > (defined in config.h. Look for comment "AX5043 radio constants". > In the module "nonvolManagement.c" there are routines called > ReadMRAMReceiveFreq (which takes an integer indicating the receiver number > as an argument). This routine/macro reads the value and its check value > out of MRAM. If the checkvalue is wrong, it returns DCT_DEFAULT_RX_FREQ. > Note that it does NOT write the default Rx frequency back. It would be > best to arrange to return the defualt frequency for the specifiied receiver > on error rather than the generic frequency. > > *Note on "raise/lower rx freq" etc* > These routines allow you to tweak (or more) the receive and transmit > frequencies. You specify the amount you want to tweak by (example: "raise > rx freq 10" raises the frequency by 10Hz. It will be changed immediately > for testing purposes, but it is not saved in MRAM until you give the > command "save freq". If you do not issue 'save freq' the frequency will > revert to the currently saved value on the next reboot. Please don't > change the frequencies anywhere else, or this whole scheme will be broken. > You really need to be able to tweak frequencies on individual boards due to > differing crystals, caps, etc, and you do not want to have to redo those > tweaks each time you clear mram or preflight init. > > *Notes on the MRAM version number:* > In MRAMmap.h, there is a #define for a version number (currently 6). This > value should be changed anytime you change something in the MRAM map. It > works by being written into the MRAM itself. The flight software compares > what is in the MRAM to what is MRAMmap.h and will complain frequently if > they do not match. (This has saved me a number of times! Before I put > this feature in I spent hours figuring out why something did not work, and > it was only because the MRAM was screwed up!) Either "clear mram" or > "preflight init" updates the version number in MRAM, and of course puts > stuff in its new location. Please do not comment out the prints that > complain about the version number--you really do not want to do any testing > if the version number is wrong! > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > ----------------------------------------------------------- > > 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

Re: Chrs and others asked for details about initialization comands. Here they are:
by Bob Stricklin 01 Mar '24

01 Mar '24

Nice job on this documenttion Burns. Bob On Mar 1, 2024, at 10:34 AM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: init new proc: Does some initialization that should only be done one time. Specifically: --Finds the right size for MRAM etc (which wipes out previous contents). --Initializes the values for things that are generally going to be tweaked on the bench, and not after the satellite is assembled, namely the default values of the 4 Rx frequencies, the Tx frequency and the values of the high and low power. ++++Note that these values are at the early address of the MRAM, so if you add stuff to MRAM, these locations should not change. --Does "clear mram" (see below) preflight init --Initializes all values in MRAM that want to be fresh when first launched. For example, Min/Max values, Epoch, time, startup state, autosafe voltages, frequency of saving WOD, etc. (Maybe some of these are not relevant for PacSat) --Initializes the MRAM version number. (See below) --Probably by rights it should format the filesystem too. Right now, it zaps the MRAM so 'main' sees that the file system can't be initialized and formats it. A bit convoluted. --Clears the "in orbit" flag so that the satellite code waits about 50 minutes after power on before transmitting or doing anything else other than waiting. This is so it can clear the Launch Vehicle. clear mram --The same as preflight init, except that it SETS the "in orbit" flag. and starts right away. Note on the "default frequency" Currently the Rx default freqs are all the same. Fix in "IHUInitSaved", module nonvolManagement.c. I'd change from a do to 4 WriteMRAMReceiveFreq calls each with a different DCT_DEFAULT_RX_FREQ (defined in config.h. Look for comment "AX5043 radio constants". In the module "nonvolManagement.c" there are routines called ReadMRAMReceiveFreq (which takes an integer indicating the receiver number as an argument). This routine/macro reads the value and its check value out of MRAM. If the checkvalue is wrong, it returns DCT_DEFAULT_RX_FREQ. Note that it does NOT write the default Rx frequency back. It would be best to arrange to return the defualt frequency for the specifiied receiver on error rather than the generic frequency. Note on "raise/lower rx freq" etc These routines allow you to tweak (or more) the receive and transmit frequencies. You specify the amount you want to tweak by (example: "raise rx freq 10" raises the frequency by 10Hz. It will be changed immediately for testing purposes, but it is not saved in MRAM until you give the command "save freq". If you do not issue 'save freq' the frequency will revert to the currently saved value on the next reboot. Please don't change the frequencies anywhere else, or this whole scheme will be broken. You really need to be able to tweak frequencies on individual boards due to differing crystals, caps, etc, and you do not want to have to redo those tweaks each time you clear mram or preflight init. Notes on the MRAM version number: In MRAMmap.h, there is a #define for a version number (currently 6). This value should be changed anytime you change something in the MRAM map. It works by being written into the MRAM itself. The flight software compares what is in the MRAM to what is MRAMmap.h and will complain frequently if they do not match. (This has saved me a number of times! Before I put this feature in I spent hours figuring out why something did not work, and it was only because the MRAM was screwed up!) Either "clear mram" or "preflight init" updates the version number in MRAM, and of course puts stuff in its new location. Please do not comment out the prints that complain about the version number--you really do not want to do any testing if the version number is wrong! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- 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

Chrs and others asked for details about initialization comands. Here they are:
by Burns Fisher (AMSAT) 01 Mar '24

01 Mar '24

*init new proc: * Does some initialization that should only be done one time. Specifically: --Finds the right size for MRAM etc (which wipes out previous contents). --Initializes the values for things that are generally going to be tweaked on the bench, and not after the satellite is assembled, namely the default values of the 4 Rx frequencies, the Tx frequency and the values of the high and low power. ++++Note that these values are at the early address of the MRAM, so if you add stuff to MRAM, these locations should not change. --Does "clear mram" (see below) *preflight init* --Initializes all values in MRAM that want to be fresh when first launched. For example, Min/Max values, Epoch, time, startup state, autosafe voltages, frequency of saving WOD, etc. (Maybe some of these are not relevant for PacSat) --Initializes the MRAM version number. (See below) --Probably by rights it should format the filesystem too. Right now, it zaps the MRAM so 'main' sees that the file system can't be initialized and formats it. A bit convoluted. --Clears the "in orbit" flag so that the satellite code waits about 50 minutes after power on before transmitting or doing anything else other than waiting. This is so it can clear the Launch Vehicle. *clear mram* --The same as preflight init, except that it SETS the "in orbit" flag. and starts right away. *Note on the "default frequency"* Currently the Rx default freqs are all the same. Fix in "IHUInitSaved", module nonvolManagement.c. I'd change from a do to 4 WriteMRAMReceiveFreq calls each with a different DCT_DEFAULT_RX_FREQ (defined in config.h. Look for comment "AX5043 radio constants". In the module "nonvolManagement.c" there are routines called ReadMRAMReceiveFreq (which takes an integer indicating the receiver number as an argument). This routine/macro reads the value and its check value out of MRAM. If the checkvalue is wrong, it returns DCT_DEFAULT_RX_FREQ. Note that it does NOT write the default Rx frequency back. It would be best to arrange to return the defualt frequency for the specifiied receiver on error rather than the generic frequency. *Note on "raise/lower rx freq" etc* These routines allow you to tweak (or more) the receive and transmit frequencies. You specify the amount you want to tweak by (example: "raise rx freq 10" raises the frequency by 10Hz. It will be changed immediately for testing purposes, but it is not saved in MRAM until you give the command "save freq". If you do not issue 'save freq' the frequency will revert to the currently saved value on the next reboot. Please don't change the frequencies anywhere else, or this whole scheme will be broken. You really need to be able to tweak frequencies on individual boards due to differing crystals, caps, etc, and you do not want to have to redo those tweaks each time you clear mram or preflight init. *Notes on the MRAM version number:* In MRAMmap.h, there is a #define for a version number (currently 6). This value should be changed anytime you change something in the MRAM map. It works by being written into the MRAM itself. The flight software compares what is in the MRAM to what is MRAMmap.h and will complain frequently if they do not match. (This has saved me a number of times! Before I put this feature in I spent hours figuring out why something did not work, and it was only because the MRAM was screwed up!) Either "clear mram" or "preflight init" updates the version number in MRAM, and of course puts stuff in its new location. Please do not comment out the prints that complain about the version number--you really do not want to do any testing if the version number is wrong! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Slides I showed tonight
by Bob Stricklin 29 Feb '24

29 Feb '24

1 0