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

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