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

Re: Dev meeting 5/30/2024 discussions
by Burns Fisher (AMSAT) 31 May '24

31 May '24

I have no problem with that as long as Cameron is not doing something for Golf (to be clear, Zach designed RTIHU V1.0 and V1.1. Cameron did V1.2, and may be called on to do a V1.3 cleanup.) I think that Cameron is working with Jeff Vollin and maybe some others on thruster research (an ASCENT program, I'd say). The point being some negotiation might be a good idea with Mike and/or Eric and Cameron himself. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, May 31, 2024 at 9:01 AM Bill Reed via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Here is my summary of our discussions last night. > > Topic 1: > Mike Moore and the Fox Plus project have selected pacsat as one of the > payloads on their second > Fox Plus satellite, with launch planned for late 2025. > We feel that we should support that launch with our current version 1 > design. Consequently this > moves our ASCENT project to the status of a flight hardware provider. I > think we can support that > effort with the funds that remain from the ASCENT project. > The most significant task facing us is the clean up and build of the > existing pacsat prototype. In order > to accomplish that end, we need to add to our development team. I would > like to ask Cameron Castillo, > who did much of the RT-IHU layout, if he would join our engineering team > and help us complete our > Blinky layout. > > Topic 2: > I would like to ask Ron Fevig, N0UCV, if he would like to join our > engineering team. I would ask > him to do additional pacsat testing ( initially with our launchpad > hardware ) and provide documentation > for the pacsat user. Ron is currently an Amsat life member and a > professor at the University of North Dakota > Department of Space Studies. He is considering pacsat for a future > launch that is TBD. > > I solicit your opinions on these 2 Topics and I will not move forward > with implementation until I > have heard everyone's response. ( Chris and Bob responded last night) > > Bill > ( cell is 214 437-9555 if you want to discuss ) > > > ----------------------------------------------------------- > > 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: New Project
by Chris Thompson 31 May '24

31 May '24

I doubt the wooden transistors have much gain but perhaps a very low noise figure. Or perhaps they have forgotten to mention that it is still 90% silicon, metal and fiberglass with a wood shell... On Fri, May 31, 2024, 11:37 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Interesting thermal issues, I should think. > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Fri, May 31, 2024 at 11:20 AM Jim McCullers via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Notty Pine Sat >> >> >> >> >> https://gizmodo.com/japan-launching-wooden-satellite-mitigate-debris-185150… >> >> >> >> Burns in a blaze of glory! >> >> ----------------------------------------------------------- >> >> 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: New Project
by Burns Fisher (AMSAT) 31 May '24

31 May '24

Interesting thermal issues, I should think. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, May 31, 2024 at 11:20 AM Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Notty Pine Sat > > > > > https://gizmodo.com/japan-launching-wooden-satellite-mitigate-debris-185150… > > > > Burns in a blaze of glory! > > ----------------------------------------------------------- > > 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: Dev meeting 5/30/2024 discussions
by Jim McCullers 31 May '24

31 May '24

Sorry I had to moss the meeting last night. Appears it might be interesting. Bill, I would appreciate a call to discuss the discussion. Late Sunday afternoon might be best due to weekend family issues. It would be good to know how far ahead UND is on their design. If still in the early stage it would be benefical to have them use the RT-IHU layout and 104 connector pinouts to reduce the need of another board layout. The lack of a universal standard on that connector at least to the physical location is baffling. Bill, I might be able to call this afternoon. I'm waiting on my son to call with his plans for the day. He's in town for the weekend. Jim McCullers WA4CWI Here is my summary of our discussions last night. Topic 1: Mike Moore and the Fox Plus project have selected pacsat as one of the payloads on their second Fox Plus satellite, with launch planned for late 2025. We feel that we should support that launch with our current version 1 design. Consequently this moves our ASCENT project to the status of a flight hardware provider. I think we can support that effort with the funds that remain from the ASCENT project. The most significant task facing us is the clean up and build of the existing pacsat prototype. In order to accomplish that end, we need to add to our development team. I would like to ask Cameron Castillo, who did much of the RT-IHU layout, if he would join our engineering team and help us complete our Blinky layout. Topic 2: I would like to ask Ron Fevig, N0UCV, if he would like to join our engineering team. I would ask him to do additional pacsat testing ( initially with our launchpad hardware ) and provide documentation for the pacsat user. Ron is currently an Amsat life member and a professor at the University of North Dakota Department of Space Studies. He is considering pacsat for a future launch that is TBD. I solicit your opinions on these 2 Topics and I will not move forward with implementation until I have heard everyone's response. ( Chris and Bob responded last night) Bill ( cell is 214 437-9555 if you want to discuss ) ----------------------------------------------------------- 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

New Project
by Jim McCullers 31 May '24

31 May '24

Notty Pine Sat https://gizmodo.com/japan-launching-wooden-satellite-mitigate-debris-1851508 941 Burns in a blaze of glory!

1 0

Dev meeting 5/30/2024 discussions
by Bill Reed 31 May '24

31 May '24

Here is my summary of our discussions last night. Topic 1: Mike Moore and the Fox Plus project have selected pacsat as one of the payloads on their second Fox Plus satellite, with launch planned for late 2025. We feel that we should support that launch with our current version 1 design. Consequently this moves our ASCENT project to the status of a flight hardware provider. I think we can support that effort with the funds that remain from the ASCENT project. The most significant task facing us is the clean up and build of the existing pacsat prototype. In order to accomplish that end, we need to add to our development team. I would like to ask Cameron Castillo, who did much of the RT-IHU layout, if he would join our engineering team and help us complete our Blinky layout. Topic 2: I would like to ask Ron Fevig, N0UCV, if he would like to join our engineering team. I would ask him to do additional pacsat testing ( initially with our launchpad hardware ) and provide documentation for the pacsat user. Ron is currently an Amsat life member and a professor at the University of North Dakota Department of Space Studies. He is considering pacsat for a future launch that is TBD. I solicit your opinions on these 2 Topics and I will not move forward with implementation until I have heard everyone's response. ( Chris and Bob responded last night) Bill ( cell is 214 437-9555 if you want to discuss )

1 0

Pacsat dev mtg 5/30/2024
by Bill 30 May '24

30 May '24

Should be an interesting meeting tonight. We need to make some key decisions regarding Fox-Plus and University of North Dakota. Pacsat dev mtg 5/30/2024 Thu, May 30, 2024 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/460114245 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-3311 - One-touch: tel:+18722403311,,460114245# Access Code: 460-114-245 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 460 114 245 Or dial directly: 460114245(a)67.217.95.2 or 67.217.95.2##460114245 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Pacsat dev mtg 5/30/2024
by Bill 30 May '24

30 May '24

Should be an interesting meeting tonight. We need to make some key decisions regarding Fox-Plus and University of North Dakota. Pacsat dev mtg 5/30/2024 Thu, May 30, 2024 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/460114245 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-3311 - One-touch: tel:+18722403311,,460114245# Access Code: 460-114-245 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 460 114 245 Or dial directly: 460114245(a)67.217.95.2 or 67.217.95.2##460114245 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: Fwd: pacsat on foxplus
by Jim McCullers 29 May '24

29 May '24

Definitely need the PCB layout. Good start. Are they V/U? Who’s building the antenna combiners? Jim FYI Attached is the preliminary Combo LIHU / Fox-Plus IHU PC104 connector. I have not "published" it yet as I'm waiting for feedback from the PCB designer. But I don't think it will change. PACSAT would get its power from the 5v_sw_1 or the 3v3_sw_1 depending on what you need. Both come from the ISISPACE EPS we are using. The [Rn] shown are zero ohm resistors which are populated for LIHU but not for Fox-Plus. Thanks, Mike On 5/29/24 11:33, Bill Reed wrote: Thanks. And can you direct me to your document for the Fox-Plus PC104? On 5/29/2024 10:10 AM, Mike Moore wrote: Very rough estimate for Fox-Plus-A is Q3 2025, with Fox-Plus-B to follow soon thereafter (Q4?) Mike K4MVM On 5/29/24 11:00, Bill Reed wrote: Do you have a rough estimate for a launch date? On 5/29/2024 9:45 AM, Mike Moore wrote: Bill, I am definitely interested in flying PACSAT. We will not be able to fly it on Fox-Plus-A (the first Fox-Plus) but want to put it on Fox-Plus-B. It would be flown as an experimental payload, so could be turned on and off by the OBC. The interface would be via the PC104 connector, so you will need to adapt to the Fox-Plus PC104. I will be on tonight's meeting, but I am going out of town on vacation for about 2 weeks starting tomorrow. Thanks and 73, Mike K4MVM On 5/28/24 16:05, Bill Reed wrote: Mike, I have heard rumors that the foxplus team might be interested in flying pacsat on a future flight. Can we discuss this at some point to see if a future flight might be possible. The pacsat team is completing the ASCENT proof of concept and we are evaluating what our next steps might be. Bill Reed Pacsat team lead bill(a)brconnect.com <mailto:bill@brconnect.com> Cell 214 437 9555

1 0

Re: Fwd: pacsat on foxplus
by Chris Thompson 29 May '24

29 May '24

Very good to hear. Thanks for forwarding. In addition to updating our connector it would be good to layout a timeline for work on other changes and testing. 73 Chris On Wed, May 29, 2024, 17:18 Bill Reed via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > FYI > > > -------- Forwarded Message -------- > Subject: Re: pacsat on foxplus > Date: Wed, 29 May 2024 12:47:02 -0400 > From: Mike Moore <k4mvm.22(a)gmail.com> <k4mvm.22(a)gmail.com> > To: Bill Reed <bill(a)brconnect.com> <bill(a)brconnect.com> > > Attached is the preliminary Combo LIHU / Fox-Plus IHU PC104 connector. I > have not "published" it yet as I'm waiting for feedback from the PCB > designer. But I don't think it will change. PACSAT would get its power from > the 5v_sw_1 or the 3v3_sw_1 depending on what you need. Both come from the > ISISPACE EPS we are using. The [Rn] shown are zero ohm resistors which are > populated for LIHU but not for Fox-Plus. > > Thanks, > > Mike > > > On 5/29/24 11:33, Bill Reed wrote: > > Thanks. And can you direct me to your document for the Fox-Plus PC104? > > On 5/29/2024 10:10 AM, Mike Moore wrote: > > Very rough estimate for Fox-Plus-A is Q3 2025, with Fox-Plus-B to follow > soon thereafter (Q4?) > > Mike K4MVM > > > > On 5/29/24 11:00, Bill Reed wrote: > > Do you have a rough estimate for a launch date? > > On 5/29/2024 9:45 AM, Mike Moore wrote: > > Bill, > > I am definitely interested in flying PACSAT. We will not be able to fly it > on Fox-Plus-A (the first Fox-Plus) but want to put it on Fox-Plus-B. It > would be flown as an experimental payload, so could be turned on and off by > the OBC. The interface would be via the PC104 connector, so you will need > to adapt to the Fox-Plus PC104. > > I will be on tonight's meeting, but I am going out of town on vacation for > about 2 weeks starting tomorrow. > > Thanks and 73, > > Mike K4MVM > > > On 5/28/24 16:05, Bill Reed wrote: > > Mike, > > I have heard rumors that the foxplus team might be interested in flying > pacsat on a future flight. > > Can we discuss this at some point to see if a future flight might be > possible. The pacsat team is > completing the ASCENT proof of concept and we are evaluating what our next > steps might be. > > Bill Reed > Pacsat team lead > bill(a)brconnect.com > Cell 214 437 9555 > > > ----------------------------------------------------------- > > 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

Fwd: pacsat on foxplus
by Bill Reed 29 May '24

29 May '24

FYI -------- Forwarded Message -------- Subject: Re: pacsat on foxplus Date: Wed, 29 May 2024 12:47:02 -0400 From: Mike Moore <k4mvm.22(a)gmail.com> To: Bill Reed <bill(a)brconnect.com> Attached is the preliminary Combo LIHU / Fox-Plus IHU PC104 connector. I have not "published" it yet as I'm waiting for feedback from the PCB designer. But I don't think it will change. PACSAT would get its power from the 5v_sw_1 or the 3v3_sw_1 depending on what you need. Both come from the ISISPACE EPS we are using. The [Rn] shown are zero ohm resistors which are populated for LIHU but not for Fox-Plus. Thanks, Mike On 5/29/24 11:33, Bill Reed wrote: > Thanks. And can you direct me to your document for the Fox-Plus PC104? > > On 5/29/2024 10:10 AM, Mike Moore wrote: >> Very rough estimate for Fox-Plus-A is Q3 2025, with Fox-Plus-B to >> follow soon thereafter (Q4?) >> >> Mike K4MVM >> >> >> >> On 5/29/24 11:00, Bill Reed wrote: >>> Do you have a rough estimate for a launch date? >>> >>> On 5/29/2024 9:45 AM, Mike Moore wrote: >>>> Bill, >>>> >>>> I am definitely interested in flying PACSAT. We will not be able to >>>> fly it on Fox-Plus-A (the first Fox-Plus) but want to put it on >>>> Fox-Plus-B. It would be flown as an experimental payload, so could >>>> be turned on and off by the OBC. The interface would be via the >>>> PC104 connector, so you will need to adapt to the Fox-Plus PC104. >>>> >>>> I will be on tonight's meeting, but I am going out of town on >>>> vacation for about 2 weeks starting tomorrow. >>>> >>>> Thanks and 73, >>>> >>>> Mike K4MVM >>>> >>>> >>>> On 5/28/24 16:05, Bill Reed wrote: >>>>> Mike, >>>>> >>>>> I have heard rumors that the foxplus team might be interested in >>>>> flying pacsat on a future flight. >>>>> >>>>> Can we discuss this at some point to see if a future flight might >>>>> be possible. The pacsat team is >>>>> completing the ASCENT proof of concept and we are evaluating what >>>>> our next steps might be. >>>>> >>>>> Bill Reed >>>>> Pacsat team lead >>>>> bill(a)brconnect.com >>>>> Cell 214 437 9555 >>>>>

1 0

Bob Madison
by Bill Reed 25 May '24

25 May '24

Bob Madison is TBD.

1 0

Re: Quick tutorial on adding a console command to PacSat sw
by Bob Madison 24 May '24

24 May '24

Sounds like we need to do some code cleanup, refactoring, etc. Also some documentation. Comments? Bill On 5/24/2024 9:35 AM, Burns Fisher (AMSAT) via pacsat-dev wrote: > This is just how to add a command. I'll give an example that could > easily be used for temporarily raising the power. Adding it to the > MRAM requires additional work. > > This is all in the module ConsoleTask.c. I'll use the existing > command "raise tx freq" as an example. You need both the command > itself (raise tx freq) which can be any lower case string, and a label > (RaiseTxFreq) which has to be name that will work for a C variable. > > I'll use 'raise tx power' as an example to add, but you can look at > "raise tx freq" as an existing example. > > First create the label by adding it to the list of enums around line > 85. It does not matter where it goes in that list of enums. > enum { > nada=0 > ,getTemp > ,reset > ,resetBoth > ,startWD > ,preflight > ,raiseTxFreq <---- > > etc etc > } > > The commands are in three groups: Setup Commands, Debug Commands, and > Common Commands. Which one you choose only matters insofar as it > determines which help command they show up on. (helpall, helpdevo, > helpsetup, help). Anyway, chose one and add the new command. Example: > > commandPairs setupCommands[] = { > {"init new proc","Init DCT stuff that > will be set once for each unit",initSaved} > ,{"start tx tone", "Send a tone with > 5043", toneTx} > ,{"stop tx tone", "Stop sending the > tone",noToneTx} > ----> ,{"raise tx freq","Raise the telem > frequency by n Hz",RaiseTxFreq} > ,{"lower tx freq","Lower the telem > frequency by n Hz",LowerTxFreq} > ,{"raise rx freq","Raise the command > frequency by n Hz",RaiseRxFreq} > The text in the middle is printed when you say help. > > Then finally, there is a switch statement that takes up most of the > module. You want to add a new case with the label you created above. > For example > > case RaiseTxFreq:{ > int number = parseNumber(afterCommand); > DCTTxFreq += number; > printf("TxFreq=%d\n",DCTTxFreq); > quick_setfreq(AX5043Dev1, DCTTxFreq); > break; > } > > Notice that you can also use get a number that has been typed after > the command (i.e. raise tx freq 20). Also, this one just adds to the > static variable DCTTxFreq. Static meaning that it only exists within > the ConsoleTask.c module, but it does not get changed unless you > change it, or the next time the processor reboots. This also just > calls an AX5043 routine to change frequency. > > =============================== > I know Bob wants to be able to change the power. Do NOT look at > "GetRfPower", SelectRFPowerLevels, SetDCTDrivePower, etc. I think > Chris has 'disconnected' these, and besides they do not change the > power level immediately. They really just write into MRAM to be used > for another time. On Golf there is a routine named "ax5043_set_power" > but that has apparently been deprecated in pacsat. But I would > recommend some similar routine in one of the AX5043 modules under > device support rather than writing directly into the register in the > ConsoleTask.c module. We've tried to keep device-specific routines > together. > > I hope this is useful. > > 73, > > Burns Fisher, WB1FJ > /AMSAT(R) Engineering -- Flight Software/ > > ----------------------------------------------------------- > > pacsat-dev mailing list --pacsat-dev(a)amsat.org > View archives of this mailing list athttps://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email topacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences athttps://mailman.amsat.org

1 0

Quick tutorial on adding a console command to PacSat sw
by Burns Fisher (AMSAT) 24 May '24

24 May '24

This is just how to add a command. I'll give an example that could easily be used for temporarily raising the power. Adding it to the MRAM requires additional work. This is all in the module ConsoleTask.c. I'll use the existing command "raise tx freq" as an example. You need both the command itself (raise tx freq) which can be any lower case string, and a label (RaiseTxFreq) which has to be name that will work for a C variable. I'll use 'raise tx power' as an example to add, but you can look at "raise tx freq" as an existing example. First create the label by adding it to the list of enums around line 85. It does not matter where it goes in that list of enums. enum { nada=0 ,getTemp ,reset ,resetBoth ,startWD ,preflight ,raiseTxFreq <---- etc etc } The commands are in three groups: Setup Commands, Debug Commands, and Common Commands. Which one you choose only matters insofar as it determines which help command they show up on. (helpall, helpdevo, helpsetup, help). Anyway, chose one and add the new command. Example: commandPairs setupCommands[] = { {"init new proc","Init DCT stuff that will be set once for each unit",initSaved} ,{"start tx tone", "Send a tone with 5043", toneTx} ,{"stop tx tone", "Stop sending the tone",noToneTx} ----> ,{"raise tx freq","Raise the telem frequency by n Hz",RaiseTxFreq} ,{"lower tx freq","Lower the telem frequency by n Hz",LowerTxFreq} ,{"raise rx freq","Raise the command frequency by n Hz",RaiseRxFreq} The text in the middle is printed when you say help. Then finally, there is a switch statement that takes up most of the module. You want to add a new case with the label you created above. For example case RaiseTxFreq:{ int number = parseNumber(afterCommand); DCTTxFreq += number; printf("TxFreq=%d\n",DCTTxFreq); quick_setfreq(AX5043Dev1, DCTTxFreq); break; } Notice that you can also use get a number that has been typed after the command (i.e. raise tx freq 20). Also, this one just adds to the static variable DCTTxFreq. Static meaning that it only exists within the ConsoleTask.c module, but it does not get changed unless you change it, or the next time the processor reboots. This also just calls an AX5043 routine to change frequency. =============================== I know Bob wants to be able to change the power. Do NOT look at "GetRfPower", SelectRFPowerLevels, SetDCTDrivePower, etc. I think Chris has 'disconnected' these, and besides they do not change the power level immediately. They really just write into MRAM to be used for another time. On Golf there is a routine named "ax5043_set_power" but that has apparently been deprecated in pacsat. But I would recommend some similar routine in one of the AX5043 modules under device support rather than writing directly into the register in the ConsoleTask.c module. We've tried to keep device-specific routines together. I hope this is useful. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Pacsat dev mtg 5/23/2024
by Bill 23 May '24

23 May '24

Pacsat dev mtg 5/23/2024 Thu, May 23, 2024 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/861448069 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-3212 - One-touch: tel:+18722403212,,861448069# Access Code: 861-448-069 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 861 448 069 Or dial directly: 861448069(a)67.217.95.2 or 67.217.95.2##861448069 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: AX5043 Info
by Jim McCullers 23 May '24

23 May '24

Sorry, I thought I had mentioned Not Black Magic before. Excellent information except he did get the power setting incorrect which has been done by many as the documentation is incorrect. Probably the best write up I have seen and makes one wonder if he had inside information or played with it as a job. There are other code listings but BM is good. He also has a good one on FSK. I thought you were getting output from the AX5043 or I was confused about the 2 watt PA output post. Jim McCullers WA4CWI Here is a very nice posting by a 3rd party on setup of the AX5043. Everything is explained well. Some discussion on an analog mode near the bottom. https://www.notblackmagic.com/bitsnpieces/ax5043/ I still only see 0 dBm out of the AX5043. I do not have power register turned up all the way so I will try that next. I tried to post a software issue on get hub which included may code routine but this did not post properly. I am going to try again with a simpler issue. Still having some problem uploading things with going through a big ordeal here. I have corrections to code i will be trying to post later today. Bob

1 0

Re: AX5043 Info
by Chris Thompson 23 May '24

23 May '24

Hi Bob, We are aware of the not black magic post. I think Jonathan used it for his original prototype. I referred to it a lot. But his code does not work as written. It is a good starting point though. 73 Chris On Thu, May 23, 2024, 12:20 Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Here is a very nice posting by a 3rd party on setup of the AX5043. > Everything is explained well. Some discussion on an analog mode near the > bottom. > https://www.notblackmagic.com/bitsnpieces/ax5043/ > > > I still only see 0 dBm out of the AX5043. I do not have power register > turned up all the way so I will try that next. > > I tried to post a software issue on get hub which included may code > routine but this did not post properly. I am going to try again with a > simpler issue. Still having some problem uploading things with going > through a big ordeal here. I have corrections to code i will be trying to > post later today. > > > 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

AX5043 Info
by Bob Stricklin 23 May '24

23 May '24

Here is a very nice posting by a 3rd party on setup of the AX5043. Everything is explained well. Some discussion on an analog mode near the bottom. https://www.notblackmagic.com/bitsnpieces/ax5043/ I still only see 0 dBm out of the AX5043. I do not have power register turned up all the way so I will try that next. I tried to post a software issue on get hub which included may code routine but this did not post properly. I am going to try again with a simpler issue. Still having some problem uploading things with going through a big ordeal here. I have corrections to code i will be trying to post later today. Bob

1 0

I'm back from Dayton
by Bill Reed 22 May '24

22 May '24

Meeting this Thursday. Bill

1 0

RevD Schematic
by Bob Stricklin 21 May '24

21 May '24

I pushed up a copy of the RevD schematic under PacSatDocs->Hardware. This is not complete or finished but does have the changes I have been working with here relating to the PA and other fixes. I am currently biasing the gate of the PA with an external voltage supply set to 2.7 volts and 100 mA. This can be done with a voltage divider and a voltage reference later. Tenths of a volt mater here so best to have a good reference in the long run. This node pulls almost no current. The drain supply and current are setup by using a 50 ohm resistor in series with the 5V regulator. I see the voltage has dropped to about 4.9 volts due to series inductor and trace resistance. This can be improved on the next PCB layout. There is about 3 volts on the drain with this combination and the resulting overall current low enough so the current monitor MAX4995 does not shut things down when set to its max of 600 mA. This may need to be eliminated when we push for more power and get the drain bias up to 5V. More testing is needed. The gate is being driven with about 0 dB or RF and the AX5043 is capable of 16dBm according to the data sheet. There is currently a filter in this circuit to reduce harmonics which may need to be eliminated or optimized to get the power level up on the gate of the PA. The final output filter is doing a good job of stopping harmonics. However feeding harmonics into the PA can cause some heating and power loss. Having the TMS570 switch the PA power on only when transmitting will result in some power savings. When on the PA will have a substantial bias current. Some delay for power to settle may be needed. My goal here was to document my thought and work. Bob

1 0

PacSatSW
by Bob Stricklin 21 May '24

21 May '24

I just did a manual update from my MAC which has a key file for GitHub login. Should be fine with updated files. I need to add a keyhole to the linux computer I am using to see if thet allow CCS to work. Bob

1 0

Code is working
by Bob Stricklin 21 May '24

21 May '24

I now have the code turning the Rx and Tx LEDs on and off. Rx is always on now. Also should have PA power working but need to add the blue wires to this PCB. I will work on pushing code up to GitHub. Bob

1 0

Coding issue
by Bob Stricklin 20 May '24

20 May '24

I am having trouble getting the PA power and LEDs to switch the way I want. The most important code to me is in the tasked.c routine. This is were I am trying to do the power control and LED1 switching. I tried to PUSH my project into pacsatSW but apparently do not have permission to do so. Can this be changed? I raised an issue in issues and pasted my code in the issue. I would appreciate it if one of you can have a look and tell me what may fix the problem. My code is flagged with date 240519 N5BRG I have similar code blinking the LED3 for a heartbeat in interfaces->MET.c and this is working fine. Bob

1 0

Re: Progress
by Chris Thompson 18 May '24

18 May '24

Very good Bob, sounds great. 73 Chris On Sat, May 18, 2024, 10:43 Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I have the ability to make the power out of the AX5043 what I want it to > be thanks to the good suggestions. > > When I turn it up to max power I am seeing 0 dBm into the PA. At this > point the PA has 5 dBm out. To get to 2W we need 33 dBm to be at 2W however > we the amp would need to be higher by about 1 or 2 dBm to overcome the loss > of the final filter. I do have the PA held back by limiting its current and > only applying 5V and this time. I want to see the input side working > properly > before turning this up. I also want to change the code to allow the 5V be > turned on only when there is a need to send packets. Otherwise, the PA > continues to draw idle current and even though > the voltage drop is low there can be some heating. Eventually we will need > to look at the duty cycle of the PA and may need to plan on some sort of > heat sink/spreader which gets complicated > on a satellite. > > I am changing the LEDs to have one LED blink with a heart beat and one > each for TX and RX activity. > > There is no oscillations on PA at this point and the second harmonic is > not showing up past the filter at all. This is good news. > > Supply current goes up from 260 mA to about 360 mA when PA is active. This > will increase when we get more PA power output. > > I am working on the code to do power control and operate the LED. I have > one LED operating now and I see where to turn on TX LED. Bot TX and RX LEDs > can be controlled as part of the > interrupt routines coming from the AX5043 I believe. > > 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

Progress
by Bob Stricklin 18 May '24

18 May '24

I have the ability to make the power out of the AX5043 what I want it to be thanks to the good suggestions. When I turn it up to max power I am seeing 0 dBm into the PA. At this point the PA has 5 dBm out. To get to 2W we need 33 dBm to be at 2W however we the amp would need to be higher by about 1 or 2 dBm to overcome the loss of the final filter. I do have the PA held back by limiting its current and only applying 5V and this time. I want to see the input side working properly before turning this up. I also want to change the code to allow the 5V be turned on only when there is a need to send packets. Otherwise, the PA continues to draw idle current and even though the voltage drop is low there can be some heating. Eventually we will need to look at the duty cycle of the PA and may need to plan on some sort of heat sink/spreader which gets complicated on a satellite. I am changing the LEDs to have one LED blink with a heart beat and one each for TX and RX activity. There is no oscillations on PA at this point and the second harmonic is not showing up past the filter at all. This is good news. Supply current goes up from 260 mA to about 360 mA when PA is active. This will increase when we get more PA power output. I am working on the code to do power control and operate the LED. I have one LED operating now and I see where to turn on TX LED. Bot TX and RX LEDs can be controlled as part of the interrupt routines coming from the AX5043 I believe. Bob

1 0

Not there tonight
by Corey Minyard 16 May '24

16 May '24

This is the Thursday I can't make it. -corey

1 0

Re: PA Working!
by Chris Thompson 14 May '24

14 May '24

The power was set very low for bench testing. I put an extra hard coded call to set the register in the TxTask: radio_set_power(0x020); // minimum power to test You can change that line to update the tx power for testing. As Burns said, this all needs to be connected back to commands from the ground, stored in the telemetry etc. 73 Chris On Mon, May 13, 2024, 21:34 Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Thanks Jim. > > Bob > > > On May 13, 2024, at 7:39 PM, Jim McCullers via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > The power level is set by registers TXPWRCOEFFE0 and TXPWRCOEFFE1 (0x171 > and 0x170). > The range is 0 to 4095 (0x0fff) with 4095 representing maximum power. > > The documentation leads one to believe the relationship is linear but that > is not the case. > The power level follows a curve best described in the attached document. > See figure 1. > There is no way that I know to write an equation to set a desired level > and a table lookup is required. > The only given is 4095 (0xfff) represents max power, about +17dbm. The > low range is about -10dbm if I recall. > > Jim McCullers > WA4CWI > > > > > DCT is "Digital Command Transponder" which makes about as much sense as > IHU, but it's the Gofl name for the chip. That command can set two levels, > I think, and each pair can be set for either safe mode or non-safe. In > other words, you can set it so if golf is in safe mode, it will be either > high or low, and also if it not in safe mode, it will be high or low. I > don't remember what I did with the command on Pacsat. But look where in > MRAM that command puts a value, and then search for the MRAM name in other > places, and you can probably see what it does to change the power. > > 73, > > Burns Fisher, WB1FJ > *AMSAT**(R) **Engineering -- Flight Software* > > > On Mon, May 13, 2024 at 11:58 AM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > We have a functioning PA. The final level is low at this point but that > should be a matter of running things. > > The input drive level is also very low. Is there a provision in the code > to turn adjust the drive level? > I see a command "Set dct drive power” but what is dct? I hope it the name > of the AX5043 register. > Also see “SELECT DCT POWER”. What does this do? > > I hope one of your knows the combination otherwise I can start looking at > the data sheet and manual for AX5043? > > The magic here has to do with the Vbias level on the LDMOS. I just copied > the example in the data sheet and they never talk about what the Vbias > level should be. > The level also sets up the quiescent current in the LDMOS and critically > biases the device. I took out the filtering and matching and just > capacitively coupled the input and output then tuned the > Vbias. The operate point is going to be about 2.9 volts to 3.4 Volts. at > 2.8 volts the Ids through the device is 100 ma and it goes up fast from > there. We will need a Ids of about 300 to get 2W operation. > > WE need to be thinking about turning on and off the supply voltage to the > PA when we transmit. This will save a lot of battery power and a heat > reduction. > > Currently when I turn the Vbias up to about 2.9 volts I get extra > oscillation. This should be eliminated by adding matching components back > in. I have included two images of the signals with and without the > oscillation. The level of output is about -40dBm with the current setup > and it is sending packets to the ground station fine. > > Photo of my setup for spectrum analyzer testing included. Using a stack of > attenuators on transmitter. The Rx antenna is two of the clip leads > together and clipped on Rx antenna. > > One thing to look for at Hamvention would be a low cost rubber ducky > antenna for 2M and 70cm. Either dual band or two singles. If we want to > keep spending money on this we could probably use 8 of these antennas. > > Bob N5BRG > > > > > > > > > > > > <image001.jpg> > > > > <image002.jpg> > > > > <image003.jpg> > > > > > ----------------------------------------------------------- > > 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 > > <AX5043_AND9314-D_Power Analysis.PDF> > ----------------------------------------------------------- > > 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: PA Working!
by Bob Stricklin 13 May '24

13 May '24

Thanks Jim. Bob On May 13, 2024, at 7:39 PM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: The power level is set by registers TXPWRCOEFFE0 and TXPWRCOEFFE1 (0x171 and 0x170). The range is 0 to 4095 (0x0fff) with 4095 representing maximum power. The documentation leads one to believe the relationship is linear but that is not the case. The power level follows a curve best described in the attached document. See figure 1. There is no way that I know to write an equation to set a desired level and a table lookup is required. The only given is 4095 (0xfff) represents max power, about +17dbm. The low range is about -10dbm if I recall. Jim McCullers WA4CWI DCT is "Digital Command Transponder" which makes about as much sense as IHU, but it's the Gofl name for the chip. That command can set two levels, I think, and each pair can be set for either safe mode or non-safe. In other words, you can set it so if golf is in safe mode, it will be either high or low, and also if it not in safe mode, it will be high or low. I don't remember what I did with the command on Pacsat. But look where in MRAM that command puts a value, and then search for the MRAM name in other places, and you can probably see what it does to change the power. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, May 13, 2024 at 11:58 AM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: We have a functioning PA. The final level is low at this point but that should be a matter of running things. The input drive level is also very low. Is there a provision in the code to turn adjust the drive level? I see a command "Set dct drive power” but what is dct? I hope it the name of the AX5043 register. Also see “SELECT DCT POWER”. What does this do? I hope one of your knows the combination otherwise I can start looking at the data sheet and manual for AX5043? The magic here has to do with the Vbias level on the LDMOS. I just copied the example in the data sheet and they never talk about what the Vbias level should be. The level also sets up the quiescent current in the LDMOS and critically biases the device. I took out the filtering and matching and just capacitively coupled the input and output then tuned the Vbias. The operate point is going to be about 2.9 volts to 3.4 Volts. at 2.8 volts the Ids through the device is 100 ma and it goes up fast from there. We will need a Ids of about 300 to get 2W operation. WE need to be thinking about turning on and off the supply voltage to the PA when we transmit. This will save a lot of battery power and a heat reduction. Currently when I turn the Vbias up to about 2.9 volts I get extra oscillation. This should be eliminated by adding matching components back in. I have included two images of the signals with and without the oscillation. The level of output is about -40dBm with the current setup and it is sending packets to the ground station fine. Photo of my setup for spectrum analyzer testing included. Using a stack of attenuators on transmitter. The Rx antenna is two of the clip leads together and clipped on Rx antenna. One thing to look for at Hamvention would be a low cost rubber ducky antenna for 2M and 70cm. Either dual band or two singles. If we want to keep spending money on this we could probably use 8 of these antennas. Bob N5BRG <image001.jpg> <image002.jpg> <image003.jpg> ----------------------------------------------------------- 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/> <AX5043_AND9314-D_Power Analysis.PDF> ----------------------------------------------------------- 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: PA Working!
by Jim McCullers 13 May '24

13 May '24

The power level is set by registers TXPWRCOEFFE0 and TXPWRCOEFFE1 (0x171 and 0x170). The range is 0 to 4095 (0x0fff) with 4095 representing maximum power. The documentation leads one to believe the relationship is linear but that is not the case. The power level follows a curve best described in the attached document. See figure 1. There is no way that I know to write an equation to set a desired level and a table lookup is required. The only given is 4095 (0xfff) represents max power, about +17dbm. The low range is about -10dbm if I recall. Jim McCullers WA4CWI DCT is "Digital Command Transponder" which makes about as much sense as IHU, but it's the Gofl name for the chip. That command can set two levels, I think, and each pair can be set for either safe mode or non-safe. In other words, you can set it so if golf is in safe mode, it will be either high or low, and also if it not in safe mode, it will be high or low. I don't remember what I did with the command on Pacsat. But look where in MRAM that command puts a value, and then search for the MRAM name in other places, and you can probably see what it does to change the power. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, May 13, 2024 at 11:58 AM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > wrote: We have a functioning PA. The final level is low at this point but that should be a matter of running things. The input drive level is also very low. Is there a provision in the code to turn adjust the drive level? I see a command "Set dct drive power” but what is dct? I hope it the name of the AX5043 register. Also see “SELECT DCT POWER”. What does this do? I hope one of your knows the combination otherwise I can start looking at the data sheet and manual for AX5043? The magic here has to do with the Vbias level on the LDMOS. I just copied the example in the data sheet and they never talk about what the Vbias level should be. The level also sets up the quiescent current in the LDMOS and critically biases the device. I took out the filtering and matching and just capacitively coupled the input and output then tuned the Vbias. The operate point is going to be about 2.9 volts to 3.4 Volts. at 2.8 volts the Ids through the device is 100 ma and it goes up fast from there. We will need a Ids of about 300 to get 2W operation. WE need to be thinking about turning on and off the supply voltage to the PA when we transmit. This will save a lot of battery power and a heat reduction. Currently when I turn the Vbias up to about 2.9 volts I get extra oscillation. This should be eliminated by adding matching components back in. I have included two images of the signals with and without the oscillation. The level of output is about -40dBm with the current setup and it is sending packets to the ground station fine. Photo of my setup for spectrum analyzer testing included. Using a stack of attenuators on transmitter. The Rx antenna is two of the clip leads together and clipped on Rx antenna. One thing to look for at Hamvention would be a low cost rubber ducky antenna for 2M and 70cm. Either dual band or two singles. If we want to keep spending money on this we could probably use 8 of these antennas. Bob N5BRG ----------------------------------------------------------- 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: PA Working!
by Burns Fisher (AMSAT) 13 May '24

13 May '24

DCT is "Digital Command Transponder" which makes about as much sense as IHU, but it's the Gofl name for the chip. That command can set two levels, I think, and each pair can be set for either safe mode or non-safe. In other words, you can set it so if golf is in safe mode, it will be either high or low, and also if it not in safe mode, it will be high or low. I don't remember what I did with the command on Pacsat. But look where in MRAM that command puts a value, and then search for the MRAM name in other places, and you can probably see what it does to change the power. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, May 13, 2024 at 11:58 AM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > We have a functioning PA. The final level is low at this point but that > should be a matter of running things. > > The input drive level is also very low. Is there a provision in the code > to turn adjust the drive level? > I see a command "Set dct drive power” but what is dct? I hope it the name > of the AX5043 register. > Also see “SELECT DCT POWER”. What does this do? > > I hope one of your knows the combination otherwise I can start looking at > the data sheet and manual for AX5043? > > The magic here has to do with the Vbias level on the LDMOS. I just copied > the example in the data sheet and they never talk about what the Vbias > level should be. > The level also sets up the quiescent current in the LDMOS and critically > biases the device. I took out the filtering and matching and just > capacitively coupled the input and output then tuned the > Vbias. The operate point is going to be about 2.9 volts to 3.4 Volts. at > 2.8 volts the Ids through the device is 100 ma and it goes up fast from > there. We will need a Ids of about 300 to get 2W operation. > > WE need to be thinking about turning on and off the supply voltage to the > PA when we transmit. This will save a lot of battery power and a heat > reduction. > > Currently when I turn the Vbias up to about 2.9 volts I get extra > oscillation. This should be eliminated by adding matching components back > in. I have included two images of the signals with and without the > oscillation. The level of output is about -40dBm with the current setup > and it is sending packets to the ground station fine. > > Photo of my setup for spectrum analyzer testing included. Using a stack of > attenuators on transmitter. The Rx antenna is two of the clip leads > together and clipped on Rx antenna. > > One thing to look for at Hamvention would be a low cost rubber ducky > antenna for 2M and 70cm. Either dual band or two singles. If we want to > keep spending money on this we could probably use 8 of these antennas. > > Bob N5BRG > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > 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

PA Working!
by Bob Stricklin 13 May '24

13 May '24

We have a functioning PA. The final level is low at this point but that should be a matter of running things. The input drive level is also very low. Is there a provision in the code to turn adjust the drive level? I see a command "Set dct drive power” but what is dct? I hope it the name of the AX5043 register. Also see “SELECT DCT POWER”. What does this do? I hope one of your knows the combination otherwise I can start looking at the data sheet and manual for AX5043? The magic here has to do with the Vbias level on the LDMOS. I just copied the example in the data sheet and they never talk about what the Vbias level should be. The level also sets up the quiescent current in the LDMOS and critically biases the device. I took out the filtering and matching and just capacitively coupled the input and output then tuned the Vbias. The operate point is going to be about 2.9 volts to 3.4 Volts. at 2.8 volts the Ids through the device is 100 ma and it goes up fast from there. We will need a Ids of about 300 to get 2W operation. WE need to be thinking about turning on and off the supply voltage to the PA when we transmit. This will save a lot of battery power and a heat reduction. Currently when I turn the Vbias up to about 2.9 volts I get extra oscillation. This should be eliminated by adding matching components back in. I have included two images of the signals with and without the oscillation. The level of output is about -40dBm with the current setup and it is sending packets to the ground station fine. Photo of my setup for spectrum analyzer testing included. Using a stack of attenuators on transmitter. The Rx antenna is two of the clip leads together and clipped on Rx antenna. One thing to look for at Hamvention would be a low cost rubber ducky antenna for 2M and 70cm. Either dual band or two singles. If we want to keep spending money on this we could probably use 8 of these antennas. Bob N5BRG [cid:711e5b75-5bc9-45a2-a24e-ba27a4f018af@namprd13.prod.outlook.com] [cid:bd342ec3-5a50-418d-82fa-46e51662ee43@namprd13.prod.outlook.com] [cid:95b5235b-9731-4568-8ea4-a6ae8af5c968@namprd13.prod.outlook.com]

1 0

Re: Inductor Insertion
by Jim McCullers 12 May '24

12 May '24

Chis, Since you have Bob’s transformer mods you are good to go. Bob did a nice job on this mod, much better than what I did. Good luck, Jim McCullers WA4CWI Tha is for the pictures Bob. Do we need to make other changes as well? Is this in addition to the changes you made to the balun, or instead of them? Can you provide an updated schematic with the changes? Thanks 73 Chris On Sat, May 11, 2024, 13:20 Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsatorg> > wrote: 2 standing on there ends and on top of the capacitors. All 100 uh Bob ----------------------------------------------------------- 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: Inductor Insertion
by Chris Thompson 12 May '24

12 May '24

Tha is for the pictures Bob. Do we need to make other changes as well? Is this in addition to the changes you made to the balun, or instead of them? Can you provide an updated schematic with the changes? Thanks 73 Chris On Sat, May 11, 2024, 13:20 Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > 2 standing on there ends and on top of the capacitors. > All 100 uh > > 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

Inductor Insertion
by Bob Stricklin 11 May '24

11 May '24

2 standing on there ends and on top of the capacitors. All 100 uh Bob

1 0

Log with RSSI readings
by Bob Stricklin 09 May '24

09 May '24

Log captured with all four receivers set for 145.840 to get common RSSI data. On the ground station log and the satellite log you can see for different transmission responding to a dir request. Bob

1 0

Pacsat dev mtg 5/9/2024
by Bill 09 May '24

09 May '24

Pacsat dev mtg 5/9/2024 Thu, May 9, 2024 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/910630661 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,,910630661# Access Code: 910-630-661 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 910 630 661 Or dial directly: 910630661(a)67.217.95.2 or 67.217.95.2##910630661 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: 4 RX devices now working!
by Jim McCullers 07 May '24

07 May '24

CONGRATS! There is some code in the receiver task RxTask that can be uncommented and will report all four RSSIs on each received packet. A bit of overkill but I used it to notice the two non-working AX5043s were essentially dead. I'll repeat your success when the regulator chip arrives. Jim WA4CWI All, I now have all four of the receivers working! The two in the center of the board did not have their inputs referenced to ground. Jim point this out and said he read that they needed to be ground referenced. So I placed a 100 nH inductor on all four of these input and connected it to Ground. I was carefully trying to keep the line length all balanced. When I tested the board all four were working. I have been moving the frequency around on each receiver. I found when two or more receivers are on the same frequency the satellite will respond to a request 2 or more times. When on individual frequencies then only one reply. I currently have the four at 145.840 .850 .860 .870 and they are all working indipendently. If I move the one at .870 up to .875 it stopes working. I tried to look at RSSI but i think I need to have data coming in when reading the RSSI value. I am going to look at this more later and capture all the register values. 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

4 RX devices now working!
by Bob Stricklin 07 May '24

07 May '24

All, I now have all four of the receivers working! The two in the center of the board did not have their inputs referenced to ground. Jim point this out and said he read that they needed to be ground referenced. So I placed a 100 nH inductor on all four of these input and connected it to Ground. I was carefully trying to keep the line length all balanced. When I tested the board all four were working. I have been moving the frequency around on each receiver. I found when two or more receivers are on the same frequency the satellite will respond to a request 2 or more times. When on individual frequencies then only one reply. I currently have the four at 145.840 .850 .860 .870 and they are all working indipendently. If I move the one at .870 up to .875 it stopes working. I tried to look at RSSI but i think I need to have data coming in when reading the RSSI value. I am going to look at this more later and capture all the register values. Bob

1 0

Re: Test Results after changing frequency
by Jim McCullers 07 May '24

07 May '24

Two out of two isn’t bad. The front end, especially for receiving, is open to interpretation. I’m not convinced the differential input has much impact on the noise immunity and SNR but that would be an interesting study. The differential is more for transmitter PA matching than high performance receiving. Hopefully the regulator will be in tomorrow and I can resume testing of the modified circuit. Jim McCullers WA4CWI All, Reviewing the boards this morning all four of the receivers have the same inductor. There could be a difference in tolerance creating different values in the registers. This could be checked by swapping the inductors. The traces on the board are similar in two cases and slightly different in two others. I now feel the issue with the two receivers that are not working is the matching circuit. I essentially had four different matching circuits on the board for testing. Two of the circuits are working and two are not. May be able to get the two non-working units up by changing the components or restructuring the interface. This would allow testing with all four Rx devices. My original idea was to experiment with differential inputs to try and improve noise immunity and increase SNR. Bob From: Burns Fisher (AMSAT) <wb1fj(a)fisher.cc <mailto:wb1fj@fisher.cc> > Sent: Tuesday, May 7, 2024 6:49 AM To: Bob Stricklin <bstrick(a)n5brg.com <mailto:bstrick@n5brg.com> > Cc: Jim McCullers <wa4cwi(a)bellsouth.net <mailto:wa4cwi@bellsouth.net> >; Pacsat Dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > Subject: Re: [pacsat-dev] Re: Test Results after changing frequency Oops. Well I got 91 and nano right. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, May 6, 2024 at 11:12 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > wrote: Jim, This could be an issue. I will look at it more. Sorry you having trouble with the voltage regulator. Hope you get it fixed without much trouble. I am keeping the PCB in the 3D printed case with the covers off for probing here and have not had any issues here so far. I take the board out to solder if needed. Bob On May 6, 2024, at 9:36 PM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > wrote: Not capacitor. Inductor. L301 on receiver 2, L201 on receiver 1. I was half paying attention this afternoon, read the 91 and kept going. It’s 91nf and something is required there for VHF, the actual value will determine the range which I believe to be the weakest idea on the chip. I assume they had reason. For higher frequencies like 70cm the inductor can be shorted. My belief is the problem is in the front end circuit and I had completed modifying receiver 2 and headed for the test bench when I bonked the regulator. Should be in Wednesday as I bought it a higher class ticket. Jim From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > Sent: Monday, May 6, 2024 9:26 PM To: Bob Stricklin <bstrick(a)n5brg.com <mailto:bstrick@n5brg.com> > Cc: Pacsat Dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > Subject: [pacsat-dev] Re: Test Results after changing frequency I thought it would not range at 2m without the capacitor. But I'm far from an expert! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, May 6, 2024 at 10:16 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > wrote: Burns, I do not have a 91nF cap around the Rx devices. Perhaps this is used on another project? I will look at the clock input on each of the Rx devices with a scope to see if there is any issue with clocking inputs. The clocks are all being feed from a buffer driver with a 16 MHz clock with Clock 1 signal being feed to two Rx devices one of which is working and one not. Bob On May 6, 2024, at 2:11 PM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > wrote: I’m not certain how the ranging process works as to what it leaves in the PLL values but it is affected by the range capacitor (91nF or whatever) as well as board and circuit stray capacitance so that is a possibility. The purpose of ranging is to align the PLL correctly. I spent time this weekend doing what Bob did, taking measurements and reviewing the circuits. Part of the time was using a $29 eBay phase detector I purchased to measure the actual phase out of the transformers. At the moment no ready to give it a 5 out of 5 and am struggling for a 1. It uses a Analog Devices chip that apparently goes to 2.8g but the device appeared to struggle at 146mhz and no phase change from input to no input. I find it difficult to think it is in the code as it’s all load and go but …. And in the process of moving the board between the work bench and the test stand I banged the LM1117 regulator and broke a lead at the body. Digi-Key has one on the way. I do solemnly swear to never work on this board on a Saturday night. That’s two for two power supply problems and I know the source for at least one if not the other. I’ve done my verification work and have a couple ideas to try when the chip arrives (I bought two to quell the demons). Jim Is it possible that this relates to differences in the 91nF capacitors? E.g. that either the caps differ or there is some different capacitance in in the area on the board or something? I just remember that the ranging seemed to differ some from board to board. Maybe from chip to chip too? 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, May 6, 2024 at 2:44 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > wrote: I went through a series of test using the instructions provided by Bruns for hanging the frequency. When i placed 3 of the four AX5043 devices on 145.840 MHz I could mostly only copy signals on Device 2. Occasionally Device 3 would come through also but it is supposed to be set on 145.870 MHz. Then I placed all four devices on 145.840 and again mostly only Device 2 is copied but occasionally Device 3 would be copied. Then I moved the frequency setting on device 2 and 3 off of 145.840 to 145.890. At that point occasionally Device 3 would copy the signals. Using a spectrum analyzer I checked the signal coming into each one of the AX5043 inputs and found the levels to be about the same on all devices. May need to do more testing by forcing interrupt on the parts not responding if possible. I think I recall Chris indicating he did see interrupts coming back from all four devices. With the AX5043 devices all set at 145.840 I see different values in the PLL registers. This seems odd to me. I am attaching logs for my testing this morning. I plan to spend some time looking over the layout for each AX5043 to make sure they all match except for Device 2. When I first started this morning the frequency for one of the devices was 145.860 MHz. I did change the values in config.h file and I had issues an "init new proc" and a "pre flight init" yesterday trying to get the config.h frequencies in place. There are some minor issues which may be addressed later but not a problem on debug. There may be a bug in the AX5043 code however. Bob ----------------------------------------------------------- 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 -- <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 ----------------------------------------------------------- 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 -- <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 ----------------------------------------------------------- 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: Test Results after changing frequency
by Burns Fisher (AMSAT) 07 May '24

07 May '24

Oops. Well I got 91 and nano right. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, May 6, 2024 at 11:12 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Jim, > > This could be an issue. I will look at it more. > > Sorry you having trouble with the voltage regulator. Hope you get it fixed > without much trouble. > > I am keeping the PCB in the 3D printed case with the covers off for > probing here and have not had any issues here so far. I take the board out > to solder if needed. > > Bob > > > On May 6, 2024, at 9:36 PM, Jim McCullers via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > Not capacitor. Inductor. > > L301 on receiver 2, L201 on receiver 1. > > I was half paying attention this afternoon, read the 91 and kept going. > It’s 91nf and something is required there for VHF, the actual value will > determine the range which I believe to be the weakest idea on the chip. I > assume they had reason. For higher frequencies like 70cm the inductor can > be shorted. > > My belief is the problem is in the front end circuit and I had completed > modifying receiver 2 and headed for the test bench when I bonked the > regulator. > Should be in Wednesday as I bought it a higher class ticket. > > Jim > > > > *From:* Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> > *Sent:* Monday, May 6, 2024 9:26 PM > *To:* Bob Stricklin <bstrick(a)n5brg.com> > *Cc:* Pacsat Dev <pacsat-dev(a)amsat.org> > *Subject:* [pacsat-dev] Re: Test Results after changing frequency > > I thought it would not range at 2m without the capacitor. But I'm far > from an expert! > > 73, > > Burns Fisher, WB1FJ > *AMSAT**(R) **Engineering -- Flight Software* > > > On Mon, May 6, 2024 at 10:16 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > Burns, > > I do not have a 91nF cap around the Rx devices. Perhaps this is used on > another project? > > I will look at the clock input on each of the Rx devices with a scope to > see if there is any issue with clocking inputs. > > The clocks are all being feed from a buffer driver with a 16 MHz clock > with Clock 1 signal being feed to two Rx devices one of which is working > and one not. > > Bob > > > > On May 6, 2024, at 2:11 PM, Jim McCullers via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > I’m not certain how the ranging process works as to what it leaves in the > PLL values but it is affected by the range capacitor (91nF or whatever) as > well as board and circuit stray capacitance so that is a possibility. > The purpose of ranging is to align the PLL correctly. > > I spent time this weekend doing what Bob did, taking measurements and > reviewing the circuits. > Part of the time was using a $29 eBay phase detector I purchased to > measure the actual phase out of the transformers. > At the moment no ready to give it a 5 out of 5 and am struggling for a 1. > It uses a Analog Devices chip that apparently goes to 2.8g but the device > appeared to struggle at 146mhz and no phase change from input to no input. > > I find it difficult to think it is in the code as it’s all load and go but > …. > > And in the process of moving the board between the work bench and the test > stand I banged the LM1117 regulator and broke a lead at the body. > Digi-Key has one on the way. > I do solemnly swear to never work on this board on a Saturday night. > That’s two for two power supply problems and I know the source for at least > one if not the other. > > I’ve done my verification work and have a couple ideas to try when the > chip arrives (I bought two to quell the demons). > > Jim > > > > Is it possible that this relates to differences in the 91nF capacitors? > E.g. that either the caps differ or there is some different capacitance in > in the area on the board or something? I just remember that the ranging > seemed to differ some from board to board. Maybe from chip to chip too? > 73, > > Burns Fisher, WB1FJ > *AMSAT**(R) **Engineering -- Flight Software* > > > On Mon, May 6, 2024 at 2:44 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > I went through a series of test using the instructions provided by Bruns > for hanging the frequency. > > When i placed 3 of the four AX5043 devices on 145.840 MHz I could mostly > only copy signals on Device 2. Occasionally Device 3 would come through > also but it is supposed to be set on 145.870 MHz. > > Then I placed all four devices on 145.840 and again mostly only Device 2 > is copied but occasionally Device 3 would be copied. > > Then I moved the frequency setting on device 2 and 3 off of 145.840 to > 145.890. At that point occasionally Device 3 would copy the signals. > > Using a spectrum analyzer I checked the signal coming into each one of the > AX5043 inputs and found the levels to be about the same on all devices. > > May need to do more testing by forcing interrupt on the parts not > responding if possible. I think I recall Chris indicating he did see > interrupts coming back from all four devices. > > With the AX5043 devices all set at 145.840 I see different values in the > PLL registers. This seems odd to me. > > I am attaching logs for my testing this morning. > > I plan to spend some time looking over the layout for each AX5043 to make > sure they all match except for Device 2. > > When I first started this morning the frequency for one of the devices was > 145.860 MHz. I did change the values in config.h file and I had issues an > "init new proc" and a "pre flight init" yesterday trying to get the > config.h frequencies in place. > > There are some minor issues which may be addressed later but not a problem > on debug. There may be a bug in the AX5043 code however. > > 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 > > > ----------------------------------------------------------- > > 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 >

2 1

Re: Test Results after changing frequency
by Bob Stricklin 06 May '24

06 May '24

Jim, This could be an issue. I will look at it more. Sorry you having trouble with the voltage regulator. Hope you get it fixed without much trouble. I am keeping the PCB in the 3D printed case with the covers off for probing here and have not had any issues here so far. I take the board out to solder if needed. Bob On May 6, 2024, at 9:36 PM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Not capacitor. Inductor. L301 on receiver 2, L201 on receiver 1. I was half paying attention this afternoon, read the 91 and kept going. It’s 91nf and something is required there for VHF, the actual value will determine the range which I believe to be the weakest idea on the chip. I assume they had reason. For higher frequencies like 70cm the inductor can be shorted. My belief is the problem is in the front end circuit and I had completed modifying receiver 2 and headed for the test bench when I bonked the regulator. Should be in Wednesday as I bought it a higher class ticket. Jim From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Sent: Monday, May 6, 2024 9:26 PM To: Bob Stricklin <bstrick(a)n5brg.com<mailto:bstrick@n5brg.com>> Cc: Pacsat Dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Subject: [pacsat-dev] Re: Test Results after changing frequency I thought it would not range at 2m without the capacitor. But I'm far from an expert! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, May 6, 2024 at 10:16 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Burns, I do not have a 91nF cap around the Rx devices. Perhaps this is used on another project? I will look at the clock input on each of the Rx devices with a scope to see if there is any issue with clocking inputs. The clocks are all being feed from a buffer driver with a 16 MHz clock with Clock 1 signal being feed to two Rx devices one of which is working and one not. Bob On May 6, 2024, at 2:11 PM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I’m not certain how the ranging process works as to what it leaves in the PLL values but it is affected by the range capacitor (91nF or whatever) as well as board and circuit stray capacitance so that is a possibility. The purpose of ranging is to align the PLL correctly. I spent time this weekend doing what Bob did, taking measurements and reviewing the circuits. Part of the time was using a $29 eBay phase detector I purchased to measure the actual phase out of the transformers. At the moment no ready to give it a 5 out of 5 and am struggling for a 1. It uses a Analog Devices chip that apparently goes to 2.8g but the device appeared to struggle at 146mhz and no phase change from input to no input. I find it difficult to think it is in the code as it’s all load and go but …. And in the process of moving the board between the work bench and the test stand I banged the LM1117 regulator and broke a lead at the body. Digi-Key has one on the way. I do solemnly swear to never work on this board on a Saturday night. That’s two for two power supply problems and I know the source for at least one if not the other. I’ve done my verification work and have a couple ideas to try when the chip arrives (I bought two to quell the demons). Jim Is it possible that this relates to differences in the 91nF capacitors? E.g. that either the caps differ or there is some different capacitance in in the area on the board or something? I just remember that the ranging seemed to differ some from board to board. Maybe from chip to chip too? 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, May 6, 2024 at 2:44 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I went through a series of test using the instructions provided by Bruns for hanging the frequency. When i placed 3 of the four AX5043 devices on 145.840 MHz I could mostly only copy signals on Device 2. Occasionally Device 3 would come through also but it is supposed to be set on 145.870 MHz. Then I placed all four devices on 145.840 and again mostly only Device 2 is copied but occasionally Device 3 would be copied. Then I moved the frequency setting on device 2 and 3 off of 145.840 to 145.890. At that point occasionally Device 3 would copy the signals. Using a spectrum analyzer I checked the signal coming into each one of the AX5043 inputs and found the levels to be about the same on all devices. May need to do more testing by forcing interrupt on the parts not responding if possible. I think I recall Chris indicating he did see interrupts coming back from all four devices. With the AX5043 devices all set at 145.840 I see different values in the PLL registers. This seems odd to me. I am attaching logs for my testing this morning. I plan to spend some time looking over the layout for each AX5043 to make sure they all match except for Device 2. When I first started this morning the frequency for one of the devices was 145.860 MHz. I did change the values in config.h file and I had issues an "init new proc" and a "pre flight init" yesterday trying to get the config.h frequencies in place. There are some minor issues which may be addressed later but not a problem on debug. There may be a bug in the AX5043 code however. Bob ----------------------------------------------------------- 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<https://mailman.amsat.org/>

1 0

Re: Test Results after changing frequency
by Jim McCullers 06 May '24

06 May '24

Not capacitor. Inductor. L301 on receiver 2, L201 on receiver 1. I was half paying attention this afternoon, read the 91 and kept going. It’s 91nf and something is required there for VHF, the actual value will determine the range which I believe to be the weakest idea on the chip. I assume they had reason. For higher frequencies like 70cm the inductor can be shorted. My belief is the problem is in the front end circuit and I had completed modifying receiver 2 and headed for the test bench when I bonked the regulator. Should be in Wednesday as I bought it a higher class ticket. Jim From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Monday, May 6, 2024 9:26 PM To: Bob Stricklin <bstrick(a)n5brg.com> Cc: Pacsat Dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: Test Results after changing frequency I thought it would not range at 2m without the capacitor. But I'm far from an expert! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, May 6, 2024 at 10:16 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > wrote: Burns, I do not have a 91nF cap around the Rx devices. Perhaps this is used on another project? I will look at the clock input on each of the Rx devices with a scope to see if there is any issue with clocking inputs. The clocks are all being feed from a buffer driver with a 16 MHz clock with Clock 1 signal being feed to two Rx devices one of which is working and one not. Bob On May 6, 2024, at 2:11 PM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > wrote: I’m not certain how the ranging process works as to what it leaves in the PLL values but it is affected by the range capacitor (91nF or whatever) as well as board and circuit stray capacitance so that is a possibility. The purpose of ranging is to align the PLL correctly. I spent time this weekend doing what Bob did, taking measurements and reviewing the circuits. Part of the time was using a $29 eBay phase detector I purchased to measure the actual phase out of the transformers. At the moment no ready to give it a 5 out of 5 and am struggling for a 1. It uses a Analog Devices chip that apparently goes to 2.8g but the device appeared to struggle at 146mhz and no phase change from input to no input. I find it difficult to think it is in the code as it’s all load and go but …. And in the process of moving the board between the work bench and the test stand I banged the LM1117 regulator and broke a lead at the body. Digi-Key has one on the way. I do solemnly swear to never work on this board on a Saturday night. That’s two for two power supply problems and I know the source for at least one if not the other. I’ve done my verification work and have a couple ideas to try when the chip arrives (I bought two to quell the demons). Jim Is it possible that this relates to differences in the 91nF capacitors? E.g. that either the caps differ or there is some different capacitance in in the area on the board or something? I just remember that the ranging seemed to differ some from board to board. Maybe from chip to chip too? 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, May 6, 2024 at 2:44 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > wrote: I went through a series of test using the instructions provided by Bruns for hanging the frequency. When i placed 3 of the four AX5043 devices on 145.840 MHz I could mostly only copy signals on Device 2. Occasionally Device 3 would come through also but it is supposed to be set on 145.870 MHz. Then I placed all four devices on 145.840 and again mostly only Device 2 is copied but occasionally Device 3 would be copied. Then I moved the frequency setting on device 2 and 3 off of 145.840 to 145.890. At that point occasionally Device 3 would copy the signals. Using a spectrum analyzer I checked the signal coming into each one of the AX5043 inputs and found the levels to be about the same on all devices. May need to do more testing by forcing interrupt on the parts not responding if possible. I think I recall Chris indicating he did see interrupts coming back from all four devices. With the AX5043 devices all set at 145.840 I see different values in the PLL registers. This seems odd to me. I am attaching logs for my testing this morning. I plan to spend some time looking over the layout for each AX5043 to make sure they all match except for Device 2. When I first started this morning the frequency for one of the devices was 145.860 MHz. I did change the values in config.h file and I had issues an "init new proc" and a "pre flight init" yesterday trying to get the config.h frequencies in place. There are some minor issues which may be addressed later but not a problem on debug. There may be a bug in the AX5043 code however. Bob ----------------------------------------------------------- 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 -- <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 ----------------------------------------------------------- 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: Test Results after changing frequency
by Burns Fisher (AMSAT) 06 May '24

06 May '24

I thought it would not range at 2m without the capacitor. But I'm far from an expert! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, May 6, 2024 at 10:16 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Burns, > > I do not have a 91nF cap around the Rx devices. Perhaps this is used on > another project? > > I will look at the clock input on each of the Rx devices with a scope to > see if there is any issue with clocking inputs. > > The clocks are all being feed from a buffer driver with a 16 MHz clock > with Clock 1 signal being feed to two Rx devices one of which is working > and one not. > > Bob > > > On May 6, 2024, at 2:11 PM, Jim McCullers via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > I’m not certain how the ranging process works as to what it leaves in the > PLL values but it is affected by the range capacitor (91nF or whatever) as > well as board and circuit stray capacitance so that is a possibility. > The purpose of ranging is to align the PLL correctly. > > I spent time this weekend doing what Bob did, taking measurements and > reviewing the circuits. > Part of the time was using a $29 eBay phase detector I purchased to > measure the actual phase out of the transformers. > At the moment no ready to give it a 5 out of 5 and am struggling for a 1. > It uses a Analog Devices chip that apparently goes to 2.8g but the device > appeared to struggle at 146mhz and no phase change from input to no input. > > I find it difficult to think it is in the code as it’s all load and go but > …. > > And in the process of moving the board between the work bench and the test > stand I banged the LM1117 regulator and broke a lead at the body. > Digi-Key has one on the way. > I do solemnly swear to never work on this board on a Saturday night. > That’s two for two power supply problems and I know the source for at least > one if not the other. > > I’ve done my verification work and have a couple ideas to try when the > chip arrives (I bought two to quell the demons). > > Jim > > > > Is it possible that this relates to differences in the 91nF capacitors? > E.g. that either the caps differ or there is some different capacitance in > in the area on the board or something? I just remember that the ranging > seemed to differ some from board to board. Maybe from chip to chip too? > 73, > > Burns Fisher, WB1FJ > *AMSAT**(R) **Engineering -- Flight Software* > > > On Mon, May 6, 2024 at 2:44 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > I went through a series of test using the instructions provided by Bruns > for hanging the frequency. > > When i placed 3 of the four AX5043 devices on 145.840 MHz I could mostly > only copy signals on Device 2. Occasionally Device 3 would come through > also but it is supposed to be set on 145.870 MHz. > > Then I placed all four devices on 145.840 and again mostly only Device 2 > is copied but occasionally Device 3 would be copied. > > Then I moved the frequency setting on device 2 and 3 off of 145.840 to > 145.890. At that point occasionally Device 3 would copy the signals. > > Using a spectrum analyzer I checked the signal coming into each one of the > AX5043 inputs and found the levels to be about the same on all devices. > > May need to do more testing by forcing interrupt on the parts not > responding if possible. I think I recall Chris indicating he did see > interrupts coming back from all four devices. > > With the AX5043 devices all set at 145.840 I see different values in the > PLL registers. This seems odd to me. > > I am attaching logs for my testing this morning. > > I plan to spend some time looking over the layout for each AX5043 to make > sure they all match except for Device 2. > > When I first started this morning the frequency for one of the devices was > 145.860 MHz. I did change the values in config.h file and I had issues an > "init new proc" and a "pre flight init" yesterday trying to get the > config.h frequencies in place. > > There are some minor issues which may be addressed later but not a problem > on debug. There may be a bug in the AX5043 code however. > > 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 > > > ----------------------------------------------------------- > > 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: Test Results after changing frequency
by Bob Stricklin 06 May '24

06 May '24

Burns, I do not have a 91nF cap around the Rx devices. Perhaps this is used on another project? I will look at the clock input on each of the Rx devices with a scope to see if there is any issue with clocking inputs. The clocks are all being feed from a buffer driver with a 16 MHz clock with Clock 1 signal being feed to two Rx devices one of which is working and one not. Bob On May 6, 2024, at 2:11 PM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I’m not certain how the ranging process works as to what it leaves in the PLL values but it is affected by the range capacitor (91nF or whatever) as well as board and circuit stray capacitance so that is a possibility. The purpose of ranging is to align the PLL correctly. I spent time this weekend doing what Bob did, taking measurements and reviewing the circuits. Part of the time was using a $29 eBay phase detector I purchased to measure the actual phase out of the transformers. At the moment no ready to give it a 5 out of 5 and am struggling for a 1. It uses a Analog Devices chip that apparently goes to 2.8g but the device appeared to struggle at 146mhz and no phase change from input to no input. I find it difficult to think it is in the code as it’s all load and go but …. And in the process of moving the board between the work bench and the test stand I banged the LM1117 regulator and broke a lead at the body. Digi-Key has one on the way. I do solemnly swear to never work on this board on a Saturday night. That’s two for two power supply problems and I know the source for at least one if not the other. I’ve done my verification work and have a couple ideas to try when the chip arrives (I bought two to quell the demons). Jim Is it possible that this relates to differences in the 91nF capacitors? E.g. that either the caps differ or there is some different capacitance in in the area on the board or something? I just remember that the ranging seemed to differ some from board to board. Maybe from chip to chip too? 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, May 6, 2024 at 2:44 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I went through a series of test using the instructions provided by Bruns for hanging the frequency. When i placed 3 of the four AX5043 devices on 145.840 MHz I could mostly only copy signals on Device 2. Occasionally Device 3 would come through also but it is supposed to be set on 145.870 MHz. Then I placed all four devices on 145.840 and again mostly only Device 2 is copied but occasionally Device 3 would be copied. Then I moved the frequency setting on device 2 and 3 off of 145.840 to 145.890. At that point occasionally Device 3 would copy the signals. Using a spectrum analyzer I checked the signal coming into each one of the AX5043 inputs and found the levels to be about the same on all devices. May need to do more testing by forcing interrupt on the parts not responding if possible. I think I recall Chris indicating he did see interrupts coming back from all four devices. With the AX5043 devices all set at 145.840 I see different values in the PLL registers. This seems odd to me. I am attaching logs for my testing this morning. I plan to spend some time looking over the layout for each AX5043 to make sure they all match except for Device 2. When I first started this morning the frequency for one of the devices was 145.860 MHz. I did change the values in config.h file and I had issues an "init new proc" and a "pre flight init" yesterday trying to get the config.h frequencies in place. There are some minor issues which may be addressed later but not a problem on debug. There may be a bug in the AX5043 code however. Bob ----------------------------------------------------------- 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/>

1 0

Re: Test Results after changing frequency
by Jim McCullers 06 May '24

06 May '24

I’m not certain how the ranging process works as to what it leaves in the PLL values but it is affected by the range capacitor (91nF or whatever) as well as board and circuit stray capacitance so that is a possibility. The purpose of ranging is to align the PLL correctly. I spent time this weekend doing what Bob did, taking measurements and reviewing the circuits. Part of the time was using a $29 eBay phase detector I purchased to measure the actual phase out of the transformers. At the moment no ready to give it a 5 out of 5 and am struggling for a 1. It uses a Analog Devices chip that apparently goes to 2.8g but the device appeared to struggle at 146mhz and no phase change from input to no input. I find it difficult to think it is in the code as it’s all load and go but …. And in the process of moving the board between the work bench and the test stand I banged the LM1117 regulator and broke a lead at the body. Digi-Key has one on the way. I do solemnly swear to never work on this board on a Saturday night. That’s two for two power supply problems and I know the source for at least one if not the other. I’ve done my verification work and have a couple ideas to try when the chip arrives (I bought two to quell the demons). Jim Is it possible that this relates to differences in the 91nF capacitors? E.g. that either the caps differ or there is some different capacitance in in the area on the board or something? I just remember that the ranging seemed to differ some from board to board. Maybe from chip to chip too? 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, May 6, 2024 at 2:44 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org <mailto:pacsat-dev@amsat.org> > wrote: I went through a series of test using the instructions provided by Bruns for hanging the frequency. When i placed 3 of the four AX5043 devices on 145.840 MHz I could mostly only copy signals on Device 2. Occasionally Device 3 would come through also but it is supposed to be set on 145.870 MHz. Then I placed all four devices on 145.840 and again mostly only Device 2 is copied but occasionally Device 3 would be copied. Then I moved the frequency setting on device 2 and 3 off of 145.840 to 145.890. At that point occasionally Device 3 would copy the signals. Using a spectrum analyzer I checked the signal coming into each one of the AX5043 inputs and found the levels to be about the same on all devices. May need to do more testing by forcing interrupt on the parts not responding if possible. I think I recall Chris indicating he did see interrupts coming back from all four devices. With the AX5043 devices all set at 145.840 I see different values in the PLL registers. This seems odd to me. I am attaching logs for my testing this morning. I plan to spend some time looking over the layout for each AX5043 to make sure they all match except for Device 2. When I first started this morning the frequency for one of the devices was 145.860 MHz. I did change the values in config.h file and I had issues an "init new proc" and a "pre flight init" yesterday trying to get the config.h frequencies in place. There are some minor issues which may be addressed later but not a problem on debug. There may be a bug in the AX5043 code however. Bob ----------------------------------------------------------- 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: Test Results after changing frequency
by Burns Fisher (AMSAT) 06 May '24

06 May '24

Is it possible that this relates to differences in the 91nF capacitors? E.g. that either the caps differ or there is some different capacitance in in the area on the board or something? I just remember that the ranging seemed to differ some from board to board. Maybe from chip to chip too? 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, May 6, 2024 at 2:44 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I went through a series of test using the instructions provided by Bruns > for hanging the frequency. > > When i placed 3 of the four AX5043 devices on 145.840 MHz I could mostly > only copy signals on Device 2. Occasionally Device 3 would come through > also but it is supposed to be set on 145.870 MHz. > > Then I placed all four devices on 145.840 and again mostly only Device 2 > is copied but occasionally Device 3 would be copied. > > Then I moved the frequency setting on device 2 and 3 off of 145.840 to > 145.890. At that point occasionally Device 3 would copy the signals. > > Using a spectrum analyzer I checked the signal coming into each one of the > AX5043 inputs and found the levels to be about the same on all devices. > > May need to do more testing by forcing interrupt on the parts not > responding if possible. I think I recall Chris indicating he did see > interrupts coming back from all four devices. > > With the AX5043 devices all set at 145.840 I see different values in the > PLL registers. This seems odd to me. > > I am attaching logs for my testing this morning. > > I plan to spend some time looking over the layout for each AX5043 to make > sure they all match except for Device 2. > > When I first started this morning the frequency for one of the devices was > 145.860 MHz. I did change the values in config.h file and I had issues an > "init new proc" and a "pre flight init" yesterday trying to get the > config.h frequencies in place. > > There are some minor issues which may be addressed later but not a problem > on debug. There may be a bug in the AX5043 code however. > > 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

Test Results after changing frequency
by Bob Stricklin 06 May '24

06 May '24

I went through a series of test using the instructions provided by Bruns for hanging the frequency. When i placed 3 of the four AX5043 devices on 145.840 MHz I could mostly only copy signals on Device 2. Occasionally Device 3 would come through also but it is supposed to be set on 145.870 MHz. Then I placed all four devices on 145.840 and again mostly only Device 2 is copied but occasionally Device 3 would be copied. Then I moved the frequency setting on device 2 and 3 off of 145.840 to 145.890. At that point occasionally Device 3 would copy the signals. Using a spectrum analyzer I checked the signal coming into each one of the AX5043 inputs and found the levels to be about the same on all devices. May need to do more testing by forcing interrupt on the parts not responding if possible. I think I recall Chris indicating he did see interrupts coming back from all four devices. With the AX5043 devices all set at 145.840 I see different values in the PLL registers. This seems odd to me. I am attaching logs for my testing this morning. I plan to spend some time looking over the layout for each AX5043 to make sure they all match except for Device 2. When I first started this morning the frequency for one of the devices was 145.860 MHz. I did change the values in config.h file and I had issues an "init new proc" and a "pre flight init" yesterday trying to get the config.h frequencies in place. There are some minor issues which may be addressed later but not a problem on debug. There may be a bug in the AX5043 code however. Bob

1 0

Changing Frequencies
by Bob Stricklin 05 May '24

05 May '24

Burns, I want to change the default frequencies for test and I am not finding the code to make this work. I see frequencies in config.h which I have changed. I see this description in your 3/1/24 email: 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 check value 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 default frequency for the specified receiver on error rather than the generic frequency. I found a header for function ax...setfreq in a .h file but not seeing the function definition or use of this so maybe this was taken out. I want to set the frequencies to 145.840, 145.850, 145.860, 145.870 so the register values will match. The PLL calibration routines in the code are calculating different values for the PLL based on the default frequencies. If I set the frequency with less change and keep it between the 840 and 870 values the register values should all remain the same. Can you tell me how to go about making the frequency changes? Other comments: There is some code that works through these register values at startup and possible while operating. It seems to me the values calculated should always be the same for a given frequency and the calibration code is not needed. Since it is a satellite and on assigned frequencies fixing these values for registers would be less risk for any AX5043 application.

1 0

Re: Board Testing
by Chris Thompson 05 May '24

05 May '24

I logged this issue here, assuming that is the issue: https://github.com/AMSAT-NA/PacSatSW/issues/37 Feel free to add comments to it as you test it or if you think it should be solved in a different way. I think we need to ignore the RTC if it comes back with an error code. We should then wait for a time command from the ground. But we should actually block uploads while we are waiting. Let me know what you think. 73 Chris On Sun, May 5, 2024 at 9:39 AM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Hi Bob, > > Well done uploading a file! > > For some reason on your board the software is not able to talk to the RTC > correctly. In the startup routine I see: > Error clearing reset of RTC > > *** NO RTC: SET THE UNIX TIME BEFORE UPLOADING ANY TEST FILES *** > > That means the RTC init routine did not work and it did not set the Unix > time on the system. > > I see that you can type get rtc and it does return the correct time. So > we may need to revisit the code and see what actually happens when that rtc > init routine fails. We have not really discussed what to do if the RTC > fails other than to fall back on Uptime. > > I can't see from the ground station log what the commands were that you > sent. Did you send set time? I think that would have set the unix time to > the rtc time, but perhaps it uses the same init routine and also fails. > > Anyway, you are correct in assuming that having the time wrong will make > it almost impossible to get the directory. The file was indeed uploaded, > but it will have the 1970 date and you won't be requesting files in that > period. > > 73 > Chris > > 73 > Chris > > > > On Sat, May 4, 2024 at 10:25 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Chris, >> >> I am testing my setup here using the PacSat board that Burns worked with >> and returned. I have made all the necessary changes and now trying to be >> sure things are working and I know what to expect before trying make >> changes to the AX5043 on device 0 and 1. >> >> I am attaching two text log files with my output while testing tonight. I >> am working with Dev 2 only at this point. >> >> Would you look over these files and make comments about what you see >> there when you have some time? >> >> One question in particular is how to set the time on the Groundstation >> software. Should it be getting the time from my Windows 10 system and not >> working. I read over the docs and looked at setup options on the screen but >> I am not seeing how to do this. The time issue may be causing me an issue? >> >> I left the board powered off for over two days and the RTC on the >> satellite side still has correct UTC time. I plan to do this more extending >> the off time trying to see how long it will maintain time with current >> capacitors charged. >> >> It looks like I successfully uploaded a file to satellite board but not >> able to get a DIR back? I would like to get DIR to read back repeatable on >> demand as a method to check each AX5043. >> >> >> 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 >> > > > -- > 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 > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: Board Testing
by Chris Thompson 05 May '24

05 May '24

Hi Bob, Well done uploading a file! For some reason on your board the software is not able to talk to the RTC correctly. In the startup routine I see: Error clearing reset of RTC *** NO RTC: SET THE UNIX TIME BEFORE UPLOADING ANY TEST FILES *** That means the RTC init routine did not work and it did not set the Unix time on the system. I see that you can type get rtc and it does return the correct time. So we may need to revisit the code and see what actually happens when that rtc init routine fails. We have not really discussed what to do if the RTC fails other than to fall back on Uptime. I can't see from the ground station log what the commands were that you sent. Did you send set time? I think that would have set the unix time to the rtc time, but perhaps it uses the same init routine and also fails. Anyway, you are correct in assuming that having the time wrong will make it almost impossible to get the directory. The file was indeed uploaded, but it will have the 1970 date and you won't be requesting files in that period. 73 Chris 73 Chris On Sat, May 4, 2024 at 10:25 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Chris, > > I am testing my setup here using the PacSat board that Burns worked with > and returned. I have made all the necessary changes and now trying to be > sure things are working and I know what to expect before trying make > changes to the AX5043 on device 0 and 1. > > I am attaching two text log files with my output while testing tonight. I > am working with Dev 2 only at this point. > > Would you look over these files and make comments about what you see there > when you have some time? > > One question in particular is how to set the time on the Groundstation > software. Should it be getting the time from my Windows 10 system and not > working. I read over the docs and looked at setup options on the screen but > I am not seeing how to do this. The time issue may be causing me an issue? > > I left the board powered off for over two days and the RTC on the > satellite side still has correct UTC time. I plan to do this more extending > the off time trying to see how long it will maintain time with current > capacitors charged. > > It looks like I successfully uploaded a file to satellite board but not > able to get a DIR back? I would like to get DIR to read back repeatable on > demand as a method to check each AX5043. > > > 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 > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0