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

Re: PacSatSW - Transmitter Power Level
by Jim McCullers 21 Feb '24

21 Feb '24

Bob, I'll look further. Thanks? Take all the time you need and don't want to sort out the board to the max before sending it on! Jim Jim, There is another place you may be missing and I will have to find it later and let you know. But the code does this by calling a SPI write routine to the AX device and in this routine the value is truncated down to 0xff. However when I tested other values like 0xe0 the thing just stopped transmitting. I can copy the signal in my lab with 0x0d. Maybe it is increasing power someplace else but I hope not so we can get some more bang. I plane to ship you a board tomorrow. I thought I was going to get it out today but I kept finding issues on the board I had to fix. This board still has a bit of week power source. The 5V supply is running about 4.75 and the 3.3 is a little low like 3.25. May need the additional headroom from 5V. There is a resistor string on the back of the board that programs the level. I noticed today that the board did not come up when I powered it and then I removed power and reconnected and that time it worked fine. The board needs a bit more voltage feeding the preamp on the RX input to get more gain. It is operating with 30 mA and would like to have 60 mA to have full gain. The 3.3V minder chip I thought was set for enough current to feed everything but may need to move the monitor resistor up to allow a full 600 mA. I did not see these issues on a board I just sent to Chris. I am ready to share the fun though and instead of continuing to debug and chase problems I am going to send you a setup tomorrow. I may poke at it a little in the morning but not much. At this point when the board powers up it does transmit and it will receive or at least it will get the rf to the AX5043 inputs. I can see it there. Your call is programmed into the flash so play with it until you get a programmer. I will send you a programmer later. Burns is sending me two and soon as I see them and add a connector I will push one on to you. Bob _____ From: Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org <mailto:[email protected]> > Sent: Tuesday, February 20, 2024 8:24 PM To: 'Pacsat Dev' <pacsat-dev(a)amsat.org <mailto:[email protected]> > Subject: [pacsat-dev] PacSatSW - Transmitter Power Level Bob, Looking at the lastest code I see two places, which is one to many, where the transmit power level is set. They are: ax5043-ax25.c Lines 435-436 TxTask.c Line 63 calls radio_set_power() at line 112 They both set the power level to 0x0020 which is very weak. I don't see a place that sets the transmit level to 0x0d. Let me know where you found that reference. I would suggest setting both places to 0x0FFF for maximum output (+15 dbm) Jim McCullers WA4CWI

1 0

Re: PacSatSW - Transmitter Power Level
by Bob Stricklin 21 Feb '24

21 Feb '24

Jim, There is another place you may be missing and I will have to find it later and let you know. But the code does this by calling a SPI write routine to the AX device and in this routine the value is truncated down to 0xff. However when I tested other values like 0xe0 the thing just stopped transmitting. I can copy the signal in my lab with 0x0d. Maybe it is increasing power someplace else but I hope not so we can get some more bang. I plane to ship you a board tomorrow. I thought I was going to get it out today but I kept finding issues on the board I had to fix. This board still has a bit of week power source. The 5V supply is running about 4.75 and the 3.3 is a little low like 3.25. May need the additional headroom from 5V. There is a resistor string on the back of the board that programs the level. I noticed today that the board did not come up when I powered it and then I removed power and reconnected and that time it worked fine. The board needs a bit more voltage feeding the preamp on the RX input to get more gain. It is operating with 30 mA and would like to have 60 mA to have full gain. The 3.3V minder chip I thought was set for enough current to feed everything but may need to move the monitor resistor up to allow a full 600 mA. I did not see these issues on a board I just sent to Chris. I am ready to share the fun though and instead of continuing to debug and chase problems I am going to send you a setup tomorrow. I may poke at it a little in the morning but not much. At this point when the board powers up it does transmit and it will receive or at least it will get the rf to the AX5043 inputs. I can see it there. Your call is programmed into the flash so play with it until you get a programmer. I will send you a programmer later. Burns is sending me two and soon as I see them and add a connector I will push one on to you. Bob ________________________________ From: Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Tuesday, February 20, 2024 8:24 PM To: 'Pacsat Dev' <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] PacSatSW - Transmitter Power Level Bob, Looking at the lastest code I see two places, which is one to many, where the transmit power level is set. They are: ax5043-ax25.c Lines 435-436 TxTask.c Line 63 calls radio_set_power() at line 112 They both set the power level to 0x0020 which is very weak. I don’t see a place that sets the transmit level to 0x0d. Let me know where you found that reference. I would suggest setting both places to 0x0FFF for maximum output (+15 dbm) Jim McCullers WA4CWI

1 0

PacSatSW - Transmitter Power Level
by Jim McCullers 21 Feb '24

21 Feb '24

Bob, Looking at the lastest code I see two places, which is one to many, where the transmit power level is set. They are: ax5043-ax25.c Lines 435-436 TxTask.c Line 63 calls radio_set_power() at line 112 They both set the power level to 0x0020 which is very weak. I don't see a place that sets the transmit level to 0x0d. Let me know where you found that reference. I would suggest setting both places to 0x0FFF for maximum output (+15 dbm) Jim McCullers WA4CWI

1 0

Re: Power coming out of AX5043
by Bob Stricklin 17 Feb '24

17 Feb '24

I just spent some time trying to increase power and it does not like anything but 0xd for power level. I see where this is passed to a ax5043 register write routine and the value is AND with 0xff then passed on. I am going to give up on this and move on for now. I want to work on other task to prepare for shipping. Bob On Feb 17, 2024, at 8:53 AM, Chris Thompson via pacsat-dev <pacsat-dev(a)amsat.org> wrote: Also, out issue tracker for the software is here: https://github.com/AMSAT-NA/PacSatSW/issues I just added this one, but if you see other problems then feel free to add them or as me to add. Future ideas should be logged as enhancements. We can group all of these into 'projects' if we want or as 'milestones' so it is very flexible and allows a large number of issues to be filtered to just the right ones for an objective. Note that some of the issues are actually closed and I need to do a pass through to clean them up. One other 'rule' that Burns and I have used in the past is that the person who raises the issue is the person who closes it, once they are happy. 73 Chris On Sat, Feb 17, 2024, 09:28 Chris Thompson via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Hi all, The power setting commands were never ported over from Golf. As Bob said it is currently hard coded to a minimum level for testing in the shack. We will want this to be commandable in the future, at least to a couple of levels as Burns said. 73 Chris On Sat, Feb 17, 2024, 09:18 Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: A couple thoughts (and these are based on memory, not looking at code since I am not in my shack) First, Jim, remember that any changes that I made are all on the git branch that starts WB1FJ... And that branch will not work on the launchpad. This branch came off "MAIN" so anything in any other branches is not included in WB1FJ... Second, I did not explicitly mess with anything relating to power in my last round of changes, although most of the calls into the AX5043 code I had to change to include an argument to say which chip to use. For something transmit-only, though I'm not sure. And finally, the way power works on Golf (and I probably did not change this when I originally ported it to Launchpad, although someone else may have): There is a high power and a low power. The values for high and low are either constants or in MRAM. But the commands are essentially to set it to high or low power. On Golf, there is a high/low pair for both normal mode and safe mode, but there are no such modes on Pacsat of course. Since that must have been ripped out at some point--probably that original port, or by Chris later--I'm not sure just how the power works at this point. Sorry, I'd look at more of this, but I have a busy weekend prepping for and teaching a ham radio class. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Sat, Feb 17, 2024 at 12:20 AM Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I did some housekeeping last weekend on the files and it appears I went one step to far and don't have the latest version of the software. I'll pull it down tomorrow. The version I have sets the 0x0020 which is very low. Max power is 0x0fff. Remember the range is not linear. Congrats Jim One more point… Max power 16 dB would with 5V and we are using 3.3v on the AX5043. > On Feb 16, 2024, at 9:25 PM, Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: > > I did test a board today and found it was transmitting every 30 seconds with a power level of about -28 dBm. > > I spent some time looking at the code and found where the power level is set to ox0d in a config file and get AX reports this value. > > I see in the data sheet for AX5043 where power should range from -10 dB to 16 dB and uses a 12 bit value to set the level. Possibly we are just adjusting upper 8 bits. > > We will also be losing power in the differential to single ended converter and shaping circuit. I will probe on this a little more tomorrow but likely just leave it alone and move on for now to be sure and ship boards Monday. > > I also see the 30 second interval in the code and some other comments about setting power but does not seem like this is being used. > > I could not get a continuous tone and I did not spend time setting up a tight loop to transmit. > > I did change the call sign in the configuration to mine. > > Bob > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this > mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all > of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Power coming out of AX5043
by Jim McCullers 17 Feb '24

17 Feb '24

Bob, Attached is a power analysis done by OnSemi that I discovered after doing one of my own when I discovered the power output was not linear as the programming manual implies and several project samples utilize. As is was copyrighted material I did not believe it was appropriate to put on github. My analysis was in line with the document. They also did an output to voltage analysis which leads me to believe your 3.3 volt power supply is not a factor in the low output. 0x0fff is the eleven setting. Crank it up! Jim I did test a board today and found it was transmitting every 30 seconds with a power level of about -28 dBm. I spent some time looking at the code and found where the power level is set to ox0d in a config file and get AX reports this value. I see in the data sheet for AX5043 where power should range from -10 dB to 16 dB and uses a 12 bit value to set the level. Possibly we are just adjusting upper 8 bits. We will also be losing power in the differential to single ended converter and shaping circuit. I will probe on this a little more tomorrow but likely just leave it alone and move on for now to be sure and ship boards Monday. I also see the 30 second interval in the code and some other comments about setting power but does not seem like this is being used. I could not get a continuous tone and I did not spend time setting up a tight loop to transmit. I did change the call sign in the configuration to mine. Bob ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Power coming out of AX5043
by Chris Thompson 17 Feb '24

17 Feb '24

Also, out issue tracker for the software is here: https://github.com/AMSAT-NA/PacSatSW/issues I just added this one, but if you see other problems then feel free to add them or as me to add. Future ideas should be logged as enhancements. We can group all of these into 'projects' if we want or as 'milestones' so it is very flexible and allows a large number of issues to be filtered to just the right ones for an objective. Note that some of the issues are actually closed and I need to do a pass through to clean them up. One other 'rule' that Burns and I have used in the past is that the person who raises the issue is the person who closes it, once they are happy. 73 Chris On Sat, Feb 17, 2024, 09:28 Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Hi all, > > The power setting commands were never ported over from Golf. As Bob said > it is currently hard coded to a minimum level for testing in the shack. > > We will want this to be commandable in the future, at least to a couple of > levels as Burns said. > > 73 > Chris > > On Sat, Feb 17, 2024, 09:18 Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> A couple thoughts (and these are based on memory, not looking at code >> since I am not in my shack) >> >> First, Jim, remember that any changes that I made are all on the git >> branch that starts WB1FJ... And that branch will not work on the >> launchpad. This branch came off "MAIN" so anything in any other branches >> is not included in WB1FJ... >> >> Second, I did not explicitly mess with anything relating to power in my >> last round of changes, although most of the calls into the AX5043 code I >> had to change to include an argument to say which chip to use. For >> something transmit-only, though I'm not sure. >> >> And finally, the way power works on Golf (and I probably did not change >> this when I originally ported it to Launchpad, although someone else may >> have): There is a high power and a low power. The values for high and low >> are either constants or in MRAM. But the commands are essentially to set >> it to high or low power. On Golf, there is a high/low pair for both normal >> mode and safe mode, but there are no such modes on Pacsat of course. Since >> that must have been ripped out at some point--probably that original port, >> or by Chris later--I'm not sure just how the power works at this point. >> >> Sorry, I'd look at more of this, but I have a busy weekend prepping for >> and teaching a ham radio class. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Sat, Feb 17, 2024 at 12:20 AM Jim McCullers via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> I did some housekeeping last weekend on the files and it appears I went >>> one step to far and don't have the latest version of the software. >>> I'll pull it down tomorrow. The version I have sets the 0x0020 which is >>> very low. >>> Max power is 0x0fff. >>> >>> Remember the range is not linear. >>> >>> Congrats >>> >>> Jim >>> >>> >>> One more point… >>> Max power 16 dB would with 5V and we are using 3.3v on the AX5043. >>> >>> > On Feb 16, 2024, at 9:25 PM, Bob Stricklin via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> > >>> > I did test a board today and found it was transmitting every 30 >>> seconds with a power level of about -28 dBm. >>> > >>> > I spent some time looking at the code and found where the power level >>> is set to ox0d in a config file and get AX reports this value. >>> > >>> > I see in the data sheet for AX5043 where power should range from -10 >>> dB to 16 dB and uses a 12 bit value to set the level. Possibly we are just >>> adjusting upper 8 bits. >>> > >>> > We will also be losing power in the differential to single ended >>> converter and shaping circuit. I will probe on this a little more tomorrow >>> but likely just leave it alone and move on for now to be sure and ship >>> boards Monday. >>> > >>> > I also see the 30 second interval in the code and some other comments >>> about setting power but does not seem like this is being used. >>> > >>> > I could not get a continuous tone and I did not spend time setting up >>> a tight loop to transmit. >>> > >>> > I did change the call sign in the configuration to mine. >>> > >>> > Bob >>> > >>> > ----------------------------------------------------------- >>> > >>> > pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this >>> > mailing list at >>> > https://mailman.amsat.org/hyperkitty/list/[email protected] >>> > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all >>> > of your AMSAT-NA mailing list preferences at https://mailman.amsat.org >>> >>> ----------------------------------------------------------- >>> >>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this >>> mailing list at >>> https://mailman.amsat.org/hyperkitty/list/[email protected] >>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all >>> of your AMSAT-NA mailing list preferences at https://mailman.amsat.org >>> >>> >>> ----------------------------------------------------------- >>> >>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>> View archives of this mailing list at >>> https://mailman.amsat.org/hyperkitty/list/[email protected] >>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>> Manage all of your AMSAT-NA mailing list preferences at >>> https://mailman.amsat.org >>> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Power coming out of AX5043
by Chris Thompson 17 Feb '24

17 Feb '24

Hi all, The power setting commands were never ported over from Golf. As Bob said it is currently hard coded to a minimum level for testing in the shack. We will want this to be commandable in the future, at least to a couple of levels as Burns said. 73 Chris On Sat, Feb 17, 2024, 09:18 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > A couple thoughts (and these are based on memory, not looking at code > since I am not in my shack) > > First, Jim, remember that any changes that I made are all on the git > branch that starts WB1FJ... And that branch will not work on the > launchpad. This branch came off "MAIN" so anything in any other branches > is not included in WB1FJ... > > Second, I did not explicitly mess with anything relating to power in my > last round of changes, although most of the calls into the AX5043 code I > had to change to include an argument to say which chip to use. For > something transmit-only, though I'm not sure. > > And finally, the way power works on Golf (and I probably did not change > this when I originally ported it to Launchpad, although someone else may > have): There is a high power and a low power. The values for high and low > are either constants or in MRAM. But the commands are essentially to set > it to high or low power. On Golf, there is a high/low pair for both normal > mode and safe mode, but there are no such modes on Pacsat of course. Since > that must have been ripped out at some point--probably that original port, > or by Chris later--I'm not sure just how the power works at this point. > > Sorry, I'd look at more of this, but I have a busy weekend prepping for > and teaching a ham radio class. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Sat, Feb 17, 2024 at 12:20 AM Jim McCullers via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> I did some housekeeping last weekend on the files and it appears I went >> one step to far and don't have the latest version of the software. >> I'll pull it down tomorrow. The version I have sets the 0x0020 which is >> very low. >> Max power is 0x0fff. >> >> Remember the range is not linear. >> >> Congrats >> >> Jim >> >> >> One more point… >> Max power 16 dB would with 5V and we are using 3.3v on the AX5043. >> >> > On Feb 16, 2024, at 9:25 PM, Bob Stricklin via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> > >> > I did test a board today and found it was transmitting every 30 >> seconds with a power level of about -28 dBm. >> > >> > I spent some time looking at the code and found where the power level >> is set to ox0d in a config file and get AX reports this value. >> > >> > I see in the data sheet for AX5043 where power should range from -10 dB >> to 16 dB and uses a 12 bit value to set the level. Possibly we are just >> adjusting upper 8 bits. >> > >> > We will also be losing power in the differential to single ended >> converter and shaping circuit. I will probe on this a little more tomorrow >> but likely just leave it alone and move on for now to be sure and ship >> boards Monday. >> > >> > I also see the 30 second interval in the code and some other comments >> about setting power but does not seem like this is being used. >> > >> > I could not get a continuous tone and I did not spend time setting up a >> tight loop to transmit. >> > >> > I did change the call sign in the configuration to mine. >> > >> > Bob >> > >> > ----------------------------------------------------------- >> > >> > pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this >> > mailing list at >> > https://mailman.amsat.org/hyperkitty/list/[email protected] >> > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all >> > of your AMSAT-NA mailing list preferences at https://mailman.amsat.org >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this >> mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of >> your AMSAT-NA mailing list preferences at https://mailman.amsat.org >> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Power coming out of AX5043
by Burns Fisher (AMSAT) 17 Feb '24

17 Feb '24

A couple thoughts (and these are based on memory, not looking at code since I am not in my shack) First, Jim, remember that any changes that I made are all on the git branch that starts WB1FJ... And that branch will not work on the launchpad. This branch came off "MAIN" so anything in any other branches is not included in WB1FJ... Second, I did not explicitly mess with anything relating to power in my last round of changes, although most of the calls into the AX5043 code I had to change to include an argument to say which chip to use. For something transmit-only, though I'm not sure. And finally, the way power works on Golf (and I probably did not change this when I originally ported it to Launchpad, although someone else may have): There is a high power and a low power. The values for high and low are either constants or in MRAM. But the commands are essentially to set it to high or low power. On Golf, there is a high/low pair for both normal mode and safe mode, but there are no such modes on Pacsat of course. Since that must have been ripped out at some point--probably that original port, or by Chris later--I'm not sure just how the power works at this point. Sorry, I'd look at more of this, but I have a busy weekend prepping for and teaching a ham radio class. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Sat, Feb 17, 2024 at 12:20 AM Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I did some housekeeping last weekend on the files and it appears I went > one step to far and don't have the latest version of the software. > I'll pull it down tomorrow. The version I have sets the 0x0020 which is > very low. > Max power is 0x0fff. > > Remember the range is not linear. > > Congrats > > Jim > > > One more point… > Max power 16 dB would with 5V and we are using 3.3v on the AX5043. > > > On Feb 16, 2024, at 9:25 PM, Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > > > I did test a board today and found it was transmitting every 30 seconds > with a power level of about -28 dBm. > > > > I spent some time looking at the code and found where the power level is > set to ox0d in a config file and get AX reports this value. > > > > I see in the data sheet for AX5043 where power should range from -10 dB > to 16 dB and uses a 12 bit value to set the level. Possibly we are just > adjusting upper 8 bits. > > > > We will also be losing power in the differential to single ended > converter and shaping circuit. I will probe on this a little more tomorrow > but likely just leave it alone and move on for now to be sure and ship > boards Monday. > > > > I also see the 30 second interval in the code and some other comments > about setting power but does not seem like this is being used. > > > > I could not get a continuous tone and I did not spend time setting up a > tight loop to transmit. > > > > I did change the call sign in the configuration to mine. > > > > Bob > > > > ----------------------------------------------------------- > > > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this > > mailing list at > > https://mailman.amsat.org/hyperkitty/list/[email protected] > > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all > > of your AMSAT-NA mailing list preferences at https://mailman.amsat.org > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this > mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of > your AMSAT-NA mailing list preferences at https://mailman.amsat.org > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Power coming out of AX5043
by Jim McCullers 17 Feb '24

17 Feb '24

I did some housekeeping last weekend on the files and it appears I went one step to far and don't have the latest version of the software. I'll pull it down tomorrow. The version I have sets the 0x0020 which is very low. Max power is 0x0fff. Remember the range is not linear. Congrats Jim One more point… Max power 16 dB would with 5V and we are using 3.3v on the AX5043. > On Feb 16, 2024, at 9:25 PM, Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > I did test a board today and found it was transmitting every 30 seconds with a power level of about -28 dBm. > > I spent some time looking at the code and found where the power level is set to ox0d in a config file and get AX reports this value. > > I see in the data sheet for AX5043 where power should range from -10 dB to 16 dB and uses a 12 bit value to set the level. Possibly we are just adjusting upper 8 bits. > > We will also be losing power in the differential to single ended converter and shaping circuit. I will probe on this a little more tomorrow but likely just leave it alone and move on for now to be sure and ship boards Monday. > > I also see the 30 second interval in the code and some other comments about setting power but does not seem like this is being used. > > I could not get a continuous tone and I did not spend time setting up a tight loop to transmit. > > I did change the call sign in the configuration to mine. > > Bob > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this > mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all > of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Power coming out of AX5043
by Bob Stricklin 17 Feb '24

17 Feb '24

One more point… Max power 16 dB would with 5V and we are using 3.3v on the AX5043. > On Feb 16, 2024, at 9:25 PM, Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > I did test a board today and found it was transmitting every 30 seconds with a power level of about -28 dBm. > > I spent some time looking at the code and found where the power level is set to ox0d in a config file and get AX reports this value. > > I see in the data sheet for AX5043 where power should range from -10 dB to 16 dB and uses a 12 bit value to set the level. Possibly we are just adjusting upper 8 bits. > > We will also be losing power in the differential to single ended converter and shaping circuit. I will probe on this a little more tomorrow but likely just leave it alone and move on for now to be sure and ship boards Monday. > > I also see the 30 second interval in the code and some other comments about setting power but does not seem like this is being used. > > I could not get a continuous tone and I did not spend time setting up a tight loop to transmit. > > I did change the call sign in the configuration to mine. > > Bob > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Power coming out of AX5043
by Bob Stricklin 17 Feb '24

17 Feb '24

I did test a board today and found it was transmitting every 30 seconds with a power level of about -28 dBm. I spent some time looking at the code and found where the power level is set to ox0d in a config file and get AX reports this value. I see in the data sheet for AX5043 where power should range from -10 dB to 16 dB and uses a 12 bit value to set the level. Possibly we are just adjusting upper 8 bits. We will also be losing power in the differential to single ended converter and shaping circuit. I will probe on this a little more tomorrow but likely just leave it alone and move on for now to be sure and ship boards Monday. I also see the 30 second interval in the code and some other comments about setting power but does not seem like this is being used. I could not get a continuous tone and I did not spend time setting up a tight loop to transmit. I did change the call sign in the configuration to mine. Bob

1 0

Pacsat dev mtg 2/15/2024
by Bill 15 Feb '24

15 Feb '24

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

1 0

Re: One more time to try--I think I am done :-)
by Burns Fisher (AMSAT) 12 Feb '24

12 Feb '24

Odd, I'm not sure how I got the wrong pins for the startup. But glad it was easy to fix. I think the error in start rx error 6. I think error 6 means the PLL did not lock. And that is expected on 2 meters unless that inductor gets put in. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Sun, Feb 11, 2024 at 9:38 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > The code is working to turn PA and AX on and off. The only thing that is > different is PA is on 98 and AX is on 99. I just switched the wires and > everything is working as needed. The set pa on and off and set ax on and > off also working. > > I have also seen the message TX QUEUE FULL could not add UI frame to > Packet Queue at startup. This message then keeps popping up. > > Also on startup i see > ERROR: In start RX, axradio_init return 6. > Key magic mismatch > > One possible issue is the AX5043 will have a 200 us delay to power up then > some time for its on power up. May need a small delay after turning on AX > power. > > We can work with this version of the code for now. > > Thanks, > > Bob > > > > > On Feb 11, 2024, at 4:50 PM, Chris Thompson via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > All sounds good Burns. I'm looking forward to testing this. As I told > the others last Thursday, it will be after my ARISS conference, which is > the week of Feb 19th. Bob will send the board to me in Florida and I will > hand carry it back (hopefully convincing customs that duties should be > waived, or paying the bill in person!). > > No problem on delaying the merge. We can work off a branch for now and I > can merge it later. It's good practice I think for main to be a version > that is tested and works. > > 73 > Chris > > On Sun, Feb 11, 2024, 17:21 Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Version X0.2a pushed upstrem. This is all still in the branch >> WB1FJ_Port_to_Blinky >> >> First you will note that it will frequently tell you that you have the >> wrong MRAM version. Some of these warnings were commented out. I may have >> done it in debugging, but it is important. Lots of things may not work >> right if this message appears. It gives several alternatives of commands >> that you can issue, but in this particular case, >> >> YOU MUST ISSUE THE COMMAND 'init new proc'. >> >> After that the messages will stop. The reason for all this is that I >> added 3 more receive frequency locations in MRAM, and those are only set up >> with init new proc. >> >> This new version, as I implied above, saves 4 different receive >> frequencies. "init new proc' initializes them all the same, but you can >> adjust them with "raise rx freq n m" where n is the receiver number (1-4) >> and n is the number (in Hz) to raise the frequency by. There is also >> 'lower rx freq'. The versions for tx freq do not have a chip number. The >> maximum you can change the frequency for any of these (I think) is 32767Hz >> (it is 15 bits). >> >> BTW, I think this is actually transmitting something. If I have the tx >> frequency set out of range, I get a TX queue filling up. ?????? >> >> Anyway, let me know if you have questions or if you need other stuff. >> I'm done for now. And btw, we are again expecting snow Tuesday, so my band >> rehearsal may be moved to Thursday again :-( >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: One more time to try--I think I am done :-)
by Bob Stricklin 12 Feb '24

12 Feb '24

The code is working to turn PA and AX on and off. The only thing that is different is PA is on 98 and AX is on 99. I just switched the wires and everything is working as needed. The set pa on and off and set ax on and off also working. I have also seen the message TX QUEUE FULL could not add UI frame to Packet Queue at startup. This message then keeps popping up. Also on startup i see ERROR: In start RX, axradio_init return 6. Key magic mismatch One possible issue is the AX5043 will have a 200 us delay to power up then some time for its on power up. May need a small delay after turning on AX power. We can work with this version of the code for now. Thanks, Bob On Feb 11, 2024, at 4:50 PM, Chris Thompson via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: All sounds good Burns. I'm looking forward to testing this. As I told the others last Thursday, it will be after my ARISS conference, which is the week of Feb 19th. Bob will send the board to me in Florida and I will hand carry it back (hopefully convincing customs that duties should be waived, or paying the bill in person!). No problem on delaying the merge. We can work off a branch for now and I can merge it later. It's good practice I think for main to be a version that is tested and works. 73 Chris On Sun, Feb 11, 2024, 17:21 Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Version X0.2a pushed upstrem. This is all still in the branch WB1FJ_Port_to_Blinky First you will note that it will frequently tell you that you have the wrong MRAM version. Some of these warnings were commented out. I may have done it in debugging, but it is important. Lots of things may not work right if this message appears. It gives several alternatives of commands that you can issue, but in this particular case, YOU MUST ISSUE THE COMMAND 'init new proc'. After that the messages will stop. The reason for all this is that I added 3 more receive frequency locations in MRAM, and those are only set up with init new proc. This new version, as I implied above, saves 4 different receive frequencies. "init new proc' initializes them all the same, but you can adjust them with "raise rx freq n m" where n is the receiver number (1-4) and n is the number (in Hz) to raise the frequency by. There is also 'lower rx freq'. The versions for tx freq do not have a chip number. The maximum you can change the frequency for any of these (I think) is 32767Hz (it is 15 bits). BTW, I think this is actually transmitting something. If I have the tx frequency set out of range, I get a TX queue filling up. ?????? Anyway, let me know if you have questions or if you need other stuff. I'm done for now. And btw, we are again expecting snow Tuesday, so my band rehearsal may be moved to Thursday again :-( 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> 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:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: One more time to try--I think I am done :-)
by Burns Fisher (AMSAT) 11 Feb '24

11 Feb '24

Sounds like a good plan re customs. BTW, one thing I forgot to mention: I did not mess around at all (or nearly at all) with the receive and transmit code. So there are probably some places where it reads the frequency to set itself from MRAM, and I set it to read the frequency for receiver 1. I'm sure there is a lot of stuff that needs to be done to deal with all 4 receivers, but I only changed the low level routines to accept an Rx number argument, and then whoever called them to specify one of the receivers. For the init stuff and the raise/lower stuff I called the appropriate routines for whichever one you set, but I don't know anything about how they work. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Sun, Feb 11, 2024 at 5:50 PM Chris Thompson via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > All sounds good Burns. I'm looking forward to testing this. As I told > the others last Thursday, it will be after my ARISS conference, which is > the week of Feb 19th. Bob will send the board to me in Florida and I will > hand carry it back (hopefully convincing customs that duties should be > waived, or paying the bill in person!). > > No problem on delaying the merge. We can work off a branch for now and I > can merge it later. It's good practice I think for main to be a version > that is tested and works. > > 73 > Chris > > On Sun, Feb 11, 2024, 17:21 Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Version X0.2a pushed upstrem. This is all still in the branch >> WB1FJ_Port_to_Blinky >> >> First you will note that it will frequently tell you that you have the >> wrong MRAM version. Some of these warnings were commented out. I may have >> done it in debugging, but it is important. Lots of things may not work >> right if this message appears. It gives several alternatives of commands >> that you can issue, but in this particular case, >> >> YOU MUST ISSUE THE COMMAND 'init new proc'. >> >> After that the messages will stop. The reason for all this is that I >> added 3 more receive frequency locations in MRAM, and those are only set up >> with init new proc. >> >> This new version, as I implied above, saves 4 different receive >> frequencies. "init new proc' initializes them all the same, but you can >> adjust them with "raise rx freq n m" where n is the receiver number (1-4) >> and n is the number (in Hz) to raise the frequency by. There is also >> 'lower rx freq'. The versions for tx freq do not have a chip number. The >> maximum you can change the frequency for any of these (I think) is 32767Hz >> (it is 15 bits). >> >> BTW, I think this is actually transmitting something. If I have the tx >> frequency set out of range, I get a TX queue filling up. ?????? >> >> Anyway, let me know if you have questions or if you need other stuff. >> I'm done for now. And btw, we are again expecting snow Tuesday, so my band >> rehearsal may be moved to Thursday again :-( >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: One more time to try--I think I am done :-)
by Chris Thompson 11 Feb '24

11 Feb '24

All sounds good Burns. I'm looking forward to testing this. As I told the others last Thursday, it will be after my ARISS conference, which is the week of Feb 19th. Bob will send the board to me in Florida and I will hand carry it back (hopefully convincing customs that duties should be waived, or paying the bill in person!). No problem on delaying the merge. We can work off a branch for now and I can merge it later. It's good practice I think for main to be a version that is tested and works. 73 Chris On Sun, Feb 11, 2024, 17:21 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Version X0.2a pushed upstrem. This is all still in the branch > WB1FJ_Port_to_Blinky > > First you will note that it will frequently tell you that you have the > wrong MRAM version. Some of these warnings were commented out. I may have > done it in debugging, but it is important. Lots of things may not work > right if this message appears. It gives several alternatives of commands > that you can issue, but in this particular case, > > YOU MUST ISSUE THE COMMAND 'init new proc'. > > After that the messages will stop. The reason for all this is that I > added 3 more receive frequency locations in MRAM, and those are only set up > with init new proc. > > This new version, as I implied above, saves 4 different receive > frequencies. "init new proc' initializes them all the same, but you can > adjust them with "raise rx freq n m" where n is the receiver number (1-4) > and n is the number (in Hz) to raise the frequency by. There is also > 'lower rx freq'. The versions for tx freq do not have a chip number. The > maximum you can change the frequency for any of these (I think) is 32767Hz > (it is 15 bits). > > BTW, I think this is actually transmitting something. If I have the tx > frequency set out of range, I get a TX queue filling up. ?????? > > Anyway, let me know if you have questions or if you need other stuff. I'm > done for now. And btw, we are again expecting snow Tuesday, so my band > rehearsal may be moved to Thursday again :-( > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

One more time to try--I think I am done :-)
by Burns Fisher (AMSAT) 11 Feb '24

11 Feb '24

Version X0.2a pushed upstrem. This is all still in the branch WB1FJ_Port_to_Blinky First you will note that it will frequently tell you that you have the wrong MRAM version. Some of these warnings were commented out. I may have done it in debugging, but it is important. Lots of things may not work right if this message appears. It gives several alternatives of commands that you can issue, but in this particular case, YOU MUST ISSUE THE COMMAND 'init new proc'. After that the messages will stop. The reason for all this is that I added 3 more receive frequency locations in MRAM, and those are only set up with init new proc. This new version, as I implied above, saves 4 different receive frequencies. "init new proc' initializes them all the same, but you can adjust them with "raise rx freq n m" where n is the receiver number (1-4) and n is the number (in Hz) to raise the frequency by. There is also 'lower rx freq'. The versions for tx freq do not have a chip number. The maximum you can change the frequency for any of these (I think) is 32767Hz (it is 15 bits). BTW, I think this is actually transmitting something. If I have the tx frequency set out of range, I get a TX queue filling up. ?????? Anyway, let me know if you have questions or if you need other stuff. I'm done for now. And btw, we are again expecting snow Tuesday, so my band rehearsal may be moved to Thursday again :-( 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Re: Lots of things working--I'm pretty much done for now
by Chris Thompson 10 Feb '24

10 Feb '24

Great progress Burns. All sounds good. The RX uses the interrupt, so that will need to be setup for all 4. To test it you need to send it a packet I suppose... The TX should have an interrupt configured but we don't use it so far. But we need it to support packets longer than 255 bytes. That is important if we want to add FEC bytes. On the branches we should create a launchpad one from main before we merge blinky into main. And or add a release Tag for launchpad. Then, as long as we don't change the HCG stuff in the launchpad branch (or other incompatible things), we should probably be able to merge changes from launchpad branch back into blinky. If that is ever required. 73 Chris On Fri, Feb 9, 2024, 17:31 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I just pushed branch WB1FJ_Port_to_Blinky, version X0.1r upstream. I > think that this has essentially everything that I planned to do (although > see the end). > > 1) I2c temp sensors working > 2) SPI access to AX5043 working. (Oh, I have not tested interrupts. I > don't know with the current setup how to make one. Tell me if it does not > work and how to do something that SHOULD cause it to interrupt, and I will > fix it.) > 3) SPI access to at least MRAM 1 is working. 0 and 2 do not work on my > board and it does not have 3, but they all work on Bob's so I assume that > is all ok. > 4) All tasks are started. What they do is not my baliwick! > 5) MRAM init routines are working. Depending on what you do, these will > figure out how many address bytes are required (always 3 for blinky, always > 2 for Launchpad, so that could be hard-coded). They will also figure out > the MRAM size as well as the number of MRAM chips, and set up the chips so > that the partitions do what they should. (II can't test odd configurations > but 1 MRAM works and 4 works.) > > New info: When starting on a brand new processor (and I'd recommend it on > the current ones that we have been using), I don't think it will crash > unless none of the MRAMs work. But the first thing you should do is to > issue the command "init new proc". This will init a lot of MRAM stuff, > including the default AX5043 frequencies for two of the 5043s (one Rx and > one Tx). After that you can use "raise tx freq nnnn" or "lower tx freq > nnn" to raise and lower them. Save them with "save freq". Rebooting or > "preflight init" will not change them. > > If you do "get mram sr" to look at the status registers, that is an easy > way to tell which MRAMs are present. The status register for those not > present will read 0xff. The first one present will read 0x32. Others will > just read 2. "get mram size" will also give useful info. > > Pacsat>get mram sr > MRAM0: status ff, MRAM1: status 32 > MRAM2: status ff, MRAM3: status ff > Pacsat>get mram size > MRAM Address Size=3 > Partition 0 size=1008, partition 1=523280 > MRAM0 size is 0KBytes, MRAM1 size is 512KBytes > MRAM2 size is 0KBytes, MRAM3 size is 0KBytes > > What I have left to do: > > Fix the "raise rx freq" (and lower) so it can specify all 4 receivers. > Make a place to store them in MRAM, set default values, etc. > > Check for even more stuff that can be removed. I think there are a number > of unused commands which may have no code, but will still show up in help, > for example. > > Debug 5043 interrupts if there is a problem. Actually is it the case that > only Tx uses interrupts and not Rx? If Rx, there is more to do to make all > 4 of them work. > > In the meantime, though, Chris and Jim, I think you can play with this as > soon as you get a blink. One thing to note: Be sure to keep blinky and > launchpad on separate branches. Especially the HalCoGen stuff is much > different but also anything that knows how many MRAMs and how many 5043s > there are. Those won't merge easily if at all. > > I'll try to do at least the rx freq stuff tomorrow. I totally forgot > about that until a few minutes ago. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

2 2

Lots of things working--I'm pretty much done for now
by Burns Fisher (AMSAT) 09 Feb '24

09 Feb '24

I just pushed branch WB1FJ_Port_to_Blinky, version X0.1r upstream. I think that this has essentially everything that I planned to do (although see the end). 1) I2c temp sensors working 2) SPI access to AX5043 working. (Oh, I have not tested interrupts. I don't know with the current setup how to make one. Tell me if it does not work and how to do something that SHOULD cause it to interrupt, and I will fix it.) 3) SPI access to at least MRAM 1 is working. 0 and 2 do not work on my board and it does not have 3, but they all work on Bob's so I assume that is all ok. 4) All tasks are started. What they do is not my baliwick! 5) MRAM init routines are working. Depending on what you do, these will figure out how many address bytes are required (always 3 for blinky, always 2 for Launchpad, so that could be hard-coded). They will also figure out the MRAM size as well as the number of MRAM chips, and set up the chips so that the partitions do what they should. (II can't test odd configurations but 1 MRAM works and 4 works.) New info: When starting on a brand new processor (and I'd recommend it on the current ones that we have been using), I don't think it will crash unless none of the MRAMs work. But the first thing you should do is to issue the command "init new proc". This will init a lot of MRAM stuff, including the default AX5043 frequencies for two of the 5043s (one Rx and one Tx). After that you can use "raise tx freq nnnn" or "lower tx freq nnn" to raise and lower them. Save them with "save freq". Rebooting or "preflight init" will not change them. If you do "get mram sr" to look at the status registers, that is an easy way to tell which MRAMs are present. The status register for those not present will read 0xff. The first one present will read 0x32. Others will just read 2. "get mram size" will also give useful info. Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes What I have left to do: Fix the "raise rx freq" (and lower) so it can specify all 4 receivers. Make a place to store them in MRAM, set default values, etc. Check for even more stuff that can be removed. I think there are a number of unused commands which may have no code, but will still show up in help, for example. Debug 5043 interrupts if there is a problem. Actually is it the case that only Tx uses interrupts and not Rx? If Rx, there is more to do to make all 4 of them work. In the meantime, though, Chris and Jim, I think you can play with this as soon as you get a blink. One thing to note: Be sure to keep blinky and launchpad on separate branches. Especially the HalCoGen stuff is much different but also anything that knows how many MRAMs and how many 5043s there are. Those won't merge easily if at all. I'll try to do at least the rx freq stuff tomorrow. I totally forgot about that until a few minutes ago. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Re: AX Frequencies
by Burns Fisher (AMSAT) 09 Feb '24

09 Feb '24

Great! One last thing I will do is turn on the other tasks and make sure it does not crash now that the mrams are working. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Feb 8, 2024 at 10:57 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > All the AX frequencies are being set properly. RX frequency 145835000Hz, > TX 435759999Hz. So we are writing and reading the AX devices. > > Bob > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

AX Frequencies
by Bob Stricklin 09 Feb '24

09 Feb '24

All the AX frequencies are being set properly. RX frequency 145835000Hz, TX 435759999Hz. So we are writing and reading the AX devices. Bob

1 0

Re: Quick test for AX5043
by Bob Stricklin 08 Feb '24

08 Feb '24

Get MRAM size reports 512 which is 512 x 8 so 4 meg. Test MRAM seems to be working. On Feb 8, 2024, at 4:47 PM, Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org> wrote: <IMG_0005.jpeg> Ok, I did clean project. Rebuild and load. The clear MRAM See 4 now. Bob On Feb 8, 2024, at 4:40 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: It IS seeing 4 chips. It is getting values that are not 0xff. I think this is very promising! Try get mram size too! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 5:38 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: <IMG_0004.jpeg> I see version is q so I think this is most current. Not seeing 4 chips yet. Bob On Feb 8, 2024, at 4:01 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Ok, please also get X0.1q (just pushed upstream). I may have said before that I got one MRAM to work on my board. Now I have changed a few things so that it seems to do at least some of the tests correctly. I'm not 100% sure if it will work with only 1 and 4 chips or if it will work with yours as well. But anyway, it is an improvement. Do "clear mram" first. Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>clear mram Post Launch Time Set to 2 minutesSet to start in safe mode WOD Frequency,size set to Default, and WOD Indices initialized Telemetry min/max in MRAM initialized Reset Count set to 0 Nonfatal error count zeroed (TBD) CRC calculated for init code and full code (TBD) MRAM Version Number Initialized MRAM config partition size is 1008 bytes MRAM file partition 1 size is 523280 Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes Pacsat>test mram 4 42 NOTE: This test will wipe out the file system and configuration values in MRAM. Testing with read/write size = 4 bytes, random value base is 0x1864 Write starting at 0KB Write starting at 16KB Write starting at 32KB Write starting at 48KB Write starting at 64KB Write starting at 80KB <skipping a bunch of additional writes> Read starting at 0KB Read starting at 16KB Read starting at 32KB Read starting at 48KB Read starting at 64KB Read starting at 80KB Read starting at 96KB Read starting at 112KB Read starting at 128KB <...> Read starting at 432KB Read starting at 448KB Read starting at 464KB Read starting at 480KB Read starting at 496KB Read starting at 512KB Test is ok! Time is 37 seconds 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Ok Burns. Will check soon. At the gym and will be home in about 30 minutes. Good that you fixed this. I added 20k pull-up on MOSI and security chip. Also moved the enable lines on the two supply control chips will give details on that later. Bob On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I got one MRAM working, specifically #1. I apparently fixed the chip select for that one. Please try "get mram sr" with X0.1p. If they say something other than 0xff, they are probably working. Don't mess with the other MRAM commands unless it sees all the MRAMs. I think a lot of that code assumes there are 4 good MRAMs. In the meantime, I now KNOW that most the SPI bus is ~good on my board, so I'll focus a bit more on the chip selects for 0 and 2. If I have time, I'll see if I can get some of the other tests working for only some MRAMs. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 9:20 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: Ok, Bob, glad you figured out how to get the new code. Regarding the MRAM. I at first thought that you said "okay", but now I think you said zero K. I originally set up the MRAM code to figure out the size of the MRAMs, whether they needed 2 or 3 address bytes, and how many were present. But I only had the one example of Jim's launchpad board, so I'm not surprised it is not quite right for larger MRAMs and especially if the failing MRAMs are not in order (i.e. 0 and 1 work, 2 and 3 do not). But since none work on my board, I could not do anything more. As soon as I can get a board with working MRAMs, I'll fix all that. Also with all the MRAM errors that I get I have disabled a number of the tasks because they quickly failed and reset the processor. I'll fix that when I get a working MRAM board. Regarding the 5043: Did you do "test ax"? That shows a couple registers from each of the 5043s which we know the value of. I think you can say "get ax 2" to read AX5043 #2, but I'm less sure about that. I did not display all 5 just because I did not know the correct values anyway, and it would just run off the bottom of the screen :-) More in a separate mailing. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:17 AM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I resolved the issue with GIT I had. I was setting things up initially with my GIT username and password and apparently you must in CCS. I have built and run Version ‘o’. I am seeing data back from 2 of the AX5043s. Probably need to expand code to work with all 4 devices. Later. get ax returns this …. screen capture <Screenshot from 2024-02-08 02-56-00.png> get mram size just returns two of the mram 0 and 2 and indicates their size is 0k. test mram 1 42 seems to run saying Write starting at etc and goes from 0KB to 1024KB. Then it does a Read in same area and does not report any errors but says: Test is OK! Time is 75 seconds. MRAM chips are 4 meg so maybe code only setup for 1 meg. More testing on hardware later today. Bob On Feb 7, 2024, at 10:47 AM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: Yes, the same branch. What errors are you getting? 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Wed, Feb 7, 2024 at 11:33 AM Bob Stricklin <bstrick(a)n5brg.com<mailto:[email protected]>> wrote: Burns, Confirm for me the branch you are working with is WB1FJ_Port_to_Blinky I am having an issue getting a clean build. I know you were still working CS problem but I am trying to get the GIT build process to work properly. Bob On Feb 6, 2024, at 5:34 PM, Bob Stricklin <bstrick(a)n5brg.com<mailto:[email protected]>> wrote: OK Bob On Feb 6, 2024, at 4:16 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I'm reasonably sure that I have the chip select lines screwed up in s/w. I have band rehearsal tonight, so I won't be able to do anything till tomorrow. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Feb 6, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: I added a quick test to tell if the 5043 SPI interface is working. This is in version 0.1n and has been pushed upstream. Pacsat>test ax AX5043 #0: Revision=7, scratch=7 AX5043 #1: Revision=7, scratch=7 AX5043 #2: Revision=119, scratch=119 AX5043 #3: Revision=7, scratch=7 AX5043 #4: Revision=119, scratch=119 AX5043 #5: Revision=7, scratch=7 This is what it looks like. However the numbers are all wrong. I'm not sure how they can be other than right or 0xff, but something is screwed up. The Revision should be 0x51, which would be printed in decimal as 81. The scratch register, I wrote the AX5043 number into, so each one should read the same as the first number in the line, i.e. 0, 1, 2, 3, 4, 5. You might as well try it on yours Bob. In the meantime, I'll try to see if I can tell anything on mine. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> 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:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Quick test for AX5043
by Bob Stricklin 08 Feb '24

08 Feb '24

[IMG_0005] Ok, I did clean project. Rebuild and load. The clear MRAM See 4 now. Bob On Feb 8, 2024, at 4:40 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: It IS seeing 4 chips. It is getting values that are not 0xff. I think this is very promising! Try get mram size too! 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 5:38 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: <IMG_0004.jpeg> I see version is q so I think this is most current. Not seeing 4 chips yet. Bob On Feb 8, 2024, at 4:01 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Ok, please also get X0.1q (just pushed upstream). I may have said before that I got one MRAM to work on my board. Now I have changed a few things so that it seems to do at least some of the tests correctly. I'm not 100% sure if it will work with only 1 and 4 chips or if it will work with yours as well. But anyway, it is an improvement. Do "clear mram" first. Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>clear mram Post Launch Time Set to 2 minutesSet to start in safe mode WOD Frequency,size set to Default, and WOD Indices initialized Telemetry min/max in MRAM initialized Reset Count set to 0 Nonfatal error count zeroed (TBD) CRC calculated for init code and full code (TBD) MRAM Version Number Initialized MRAM config partition size is 1008 bytes MRAM file partition 1 size is 523280 Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes Pacsat>test mram 4 42 NOTE: This test will wipe out the file system and configuration values in MRAM. Testing with read/write size = 4 bytes, random value base is 0x1864 Write starting at 0KB Write starting at 16KB Write starting at 32KB Write starting at 48KB Write starting at 64KB Write starting at 80KB <skipping a bunch of additional writes> Read starting at 0KB Read starting at 16KB Read starting at 32KB Read starting at 48KB Read starting at 64KB Read starting at 80KB Read starting at 96KB Read starting at 112KB Read starting at 128KB <...> Read starting at 432KB Read starting at 448KB Read starting at 464KB Read starting at 480KB Read starting at 496KB Read starting at 512KB Test is ok! Time is 37 seconds 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Ok Burns. Will check soon. At the gym and will be home in about 30 minutes. Good that you fixed this. I added 20k pull-up on MOSI and security chip. Also moved the enable lines on the two supply control chips will give details on that later. Bob On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I got one MRAM working, specifically #1. I apparently fixed the chip select for that one. Please try "get mram sr" with X0.1p. If they say something other than 0xff, they are probably working. Don't mess with the other MRAM commands unless it sees all the MRAMs. I think a lot of that code assumes there are 4 good MRAMs. In the meantime, I now KNOW that most the SPI bus is ~good on my board, so I'll focus a bit more on the chip selects for 0 and 2. If I have time, I'll see if I can get some of the other tests working for only some MRAMs. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 9:20 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: Ok, Bob, glad you figured out how to get the new code. Regarding the MRAM. I at first thought that you said "okay", but now I think you said zero K. I originally set up the MRAM code to figure out the size of the MRAMs, whether they needed 2 or 3 address bytes, and how many were present. But I only had the one example of Jim's launchpad board, so I'm not surprised it is not quite right for larger MRAMs and especially if the failing MRAMs are not in order (i.e. 0 and 1 work, 2 and 3 do not). But since none work on my board, I could not do anything more. As soon as I can get a board with working MRAMs, I'll fix all that. Also with all the MRAM errors that I get I have disabled a number of the tasks because they quickly failed and reset the processor. I'll fix that when I get a working MRAM board. Regarding the 5043: Did you do "test ax"? That shows a couple registers from each of the 5043s which we know the value of. I think you can say "get ax 2" to read AX5043 #2, but I'm less sure about that. I did not display all 5 just because I did not know the correct values anyway, and it would just run off the bottom of the screen :-) More in a separate mailing. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:17 AM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I resolved the issue with GIT I had. I was setting things up initially with my GIT username and password and apparently you must in CCS. I have built and run Version ‘o’. I am seeing data back from 2 of the AX5043s. Probably need to expand code to work with all 4 devices. Later. get ax returns this …. screen capture <Screenshot from 2024-02-08 02-56-00.png> get mram size just returns two of the mram 0 and 2 and indicates their size is 0k. test mram 1 42 seems to run saying Write starting at etc and goes from 0KB to 1024KB. Then it does a Read in same area and does not report any errors but says: Test is OK! Time is 75 seconds. MRAM chips are 4 meg so maybe code only setup for 1 meg. More testing on hardware later today. Bob On Feb 7, 2024, at 10:47 AM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: Yes, the same branch. What errors are you getting? 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Wed, Feb 7, 2024 at 11:33 AM Bob Stricklin <bstrick(a)n5brg.com<mailto:[email protected]>> wrote: Burns, Confirm for me the branch you are working with is WB1FJ_Port_to_Blinky I am having an issue getting a clean build. I know you were still working CS problem but I am trying to get the GIT build process to work properly. Bob On Feb 6, 2024, at 5:34 PM, Bob Stricklin <bstrick(a)n5brg.com<mailto:[email protected]>> wrote: OK Bob On Feb 6, 2024, at 4:16 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I'm reasonably sure that I have the chip select lines screwed up in s/w. I have band rehearsal tonight, so I won't be able to do anything till tomorrow. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Feb 6, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: I added a quick test to tell if the 5043 SPI interface is working. This is in version 0.1n and has been pushed upstream. Pacsat>test ax AX5043 #0: Revision=7, scratch=7 AX5043 #1: Revision=7, scratch=7 AX5043 #2: Revision=119, scratch=119 AX5043 #3: Revision=7, scratch=7 AX5043 #4: Revision=119, scratch=119 AX5043 #5: Revision=7, scratch=7 This is what it looks like. However the numbers are all wrong. I'm not sure how they can be other than right or 0xff, but something is screwed up. The Revision should be 0x51, which would be printed in decimal as 81. The scratch register, I wrote the AX5043 number into, so each one should read the same as the first number in the line, i.e. 0, 1, 2, 3, 4, 5. You might as well try it on yours Bob. In the meantime, I'll try to see if I can tell anything on mine. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> 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:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Quick test for AX5043
by Burns Fisher (AMSAT) 08 Feb '24

08 Feb '24

It IS seeing 4 chips. It is getting values that are not 0xff. I think this is very promising! Try get mram size too! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, Feb 8, 2024 at 5:38 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > [image: IMG_0004] > > > I see version is q so I think this is most current. Not seeing 4 chips > yet. > > Bob > > On Feb 8, 2024, at 4:01 PM, Burns > > > Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > > Ok, please also get X0.1q (just pushed upstream). > > I may have said before that I got one MRAM to work on my board. Now I > have changed a few things so that it seems to do at least some of the tests > correctly. I'm not 100% sure if it will work with only 1 and 4 chips or if > it will work with yours as well. But anyway, it is an improvement. Do > "clear mram" first. > > > Pacsat>get mram sr > MRAM0: status ff, MRAM1: status 32 > MRAM2: status ff, MRAM3: status ff > > Pacsat>clear mram > Post Launch Time Set to 2 minutesSet to start in safe mode > WOD Frequency,size set to Default, and WOD Indices initialized > Telemetry min/max in MRAM initialized > Reset Count set to 0 > Nonfatal error count zeroed (TBD) > CRC calculated for init code and full code (TBD) > MRAM Version Number Initialized > MRAM config partition size is 1008 bytes > MRAM file partition 1 size is 523280 > > Pacsat>get mram size > MRAM Address Size=3 > Partition 0 size=1008, partition 1=523280 > MRAM0 size is 0KBytes, MRAM1 size is 512KBytes > MRAM2 size is 0KBytes, MRAM3 size is 0KBytes > Pacsat>test mram 4 42 > NOTE: This test will wipe out the file system and configuration values in > MRAM. > > Testing with read/write size = 4 bytes, random value base is 0x1864 > Write starting at 0KB > Write starting at 16KB > Write starting at 32KB > Write starting at 48KB > Write starting at 64KB > Write starting at 80KB > <skipping a bunch of additional writes> > Read starting at 0KB > Read starting at 16KB > Read starting at 32KB > Read starting at 48KB > Read starting at 64KB > Read starting at 80KB > Read starting at 96KB > Read starting at 112KB > Read starting at 128KB > <...> > Read starting at 432KB > Read starting at 448KB > Read starting at 464KB > Read starting at 480KB > Read starting at 496KB > Read starting at 512KB > Test is ok! Time is 37 seconds > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Thu, Feb 8, 2024 at 4:30 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Ok Burns. Will check soon. At the gym and will be home in about 30 >> minutes. >> >> Good that you fixed this. >> >> I added 20k pull-up on MOSI and security chip. Also moved the enable >> lines on the two supply control chips will give details on that later. >> >> Bob >> >> On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >> >> I got one MRAM working, specifically #1. I apparently fixed the chip >> select for that one. >> >> Please try "get mram sr" with X0.1p. If they say something other than >> 0xff, they are probably working. Don't mess with the other MRAM commands >> unless it sees all the MRAMs. I think a lot of that code assumes there are >> 4 good MRAMs. >> >> In the meantime, I now KNOW that most the SPI bus is ~good on my board, >> so I'll focus a bit more on the chip selects for 0 and 2. If I have time, >> I'll see if I can get some of the other tests working for only some MRAMs. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Thu, Feb 8, 2024 at 9:20 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >> wrote: >> >>> Ok, Bob, glad you figured out how to get the new code. >>> >>> Regarding the MRAM. I at first thought that you said "okay", but now I >>> think you said zero K. I originally set up the MRAM code to figure out >>> the size of the MRAMs, whether they needed 2 or 3 address bytes, and how >>> many were present. But I only had the one example of Jim's launchpad >>> board, so I'm not surprised it is not quite right for larger MRAMs and >>> especially if the failing MRAMs are not in order (i.e. 0 and 1 work, 2 and >>> 3 do not). But since none work on my board, I could not do anything more. >>> As soon as I can get a board with working MRAMs, I'll fix all that. Also >>> with all the MRAM errors that I get I have disabled a number of the tasks >>> because they quickly failed and reset the processor. I'll fix that when I >>> get a working MRAM board. >>> >>> Regarding the 5043: Did you do "test ax"? That shows a couple >>> registers from each of the 5043s which we know the value of. I think you >>> can say "get ax 2" to read AX5043 #2, but I'm less sure about that. I did >>> not display all 5 just because I did not know the correct values anyway, >>> and it would just run off the bottom of the screen :-) >>> >>> More in a separate mailing. >>> >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >>> >>> On Thu, Feb 8, 2024 at 4:17 AM Bob Stricklin via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>>> I resolved the issue with GIT I had. >>>> >>>> I was setting things up initially with my GIT username and password and >>>> apparently you must in CCS. >>>> >>>> I have built and run Version ‘o’. >>>> >>>> I am seeing data back from 2 of the AX5043s. Probably need to expand >>>> code to work with all 4 devices. Later. >>>> >>>> get ax returns this …. screen capture >>>> >>>> <Screenshot from 2024-02-08 02-56-00.png> >>>> >>>> get mram size just returns two of the mram 0 and 2 and indicates >>>> their size is 0k. >>>> test mram 1 42 seems to run saying Write starting at etc and goes from >>>> 0KB to 1024KB. Then it does a Read in same area and does not report any >>>> errors but says: Test is OK! Time is 75 seconds. >>>> MRAM chips are 4 meg so maybe code only setup for 1 meg. >>>> >>>> >>>> More testing on hardware later today. >>>> >>>> Bob >>>> >>>> >>>> On Feb 7, 2024, at 10:47 AM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >>>> wrote: >>>> >>>> Yes, the same branch. What errors are you getting? >>>> 73, >>>> >>>> Burns Fisher, WB1FJ >>>> *AMSAT(R) Engineering -- Flight Software* >>>> >>>> >>>> On Wed, Feb 7, 2024 at 11:33 AM Bob Stricklin <bstrick(a)n5brg.com> >>>> wrote: >>>> >>>>> Burns, >>>>> >>>>> Confirm for me the branch you are working with is >>>>> WB1FJ_Port_to_Blinky >>>>> >>>>> I am having an issue getting a clean build. I know you were still >>>>> working CS problem but I am trying to get the GIT build process to work >>>>> properly. >>>>> >>>>> Bob >>>>> >>>>> On Feb 6, 2024, at 5:34 PM, Bob Stricklin <bstrick(a)n5brg.com> wrote: >>>>> >>>>> OK >>>>> >>>>> Bob >>>>> >>>>> On Feb 6, 2024, at 4:16 PM, Burns Fisher (AMSAT) via pacsat-dev < >>>>> pacsat-dev(a)amsat.org> wrote: >>>>> >>>>> I'm reasonably sure that I have the chip select lines screwed up in >>>>> s/w. I have band rehearsal tonight, so I won't be able to do anything >>>>> till tomorrow. >>>>> >>>>> 73, >>>>> >>>>> Burns Fisher, WB1FJ >>>>> *AMSAT(R) Engineering -- Flight Software* >>>>> >>>>> >>>>> On Tue, Feb 6, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> >>>>> wrote: >>>>> >>>>>> I added a quick test to tell if the 5043 SPI interface is working. >>>>>> This is in version 0.1n and has been pushed upstream. >>>>>> >>>>>> Pacsat>test ax >>>>>> AX5043 #0: Revision=7, scratch=7 >>>>>> AX5043 #1: Revision=7, scratch=7 >>>>>> AX5043 #2: Revision=119, scratch=119 >>>>>> AX5043 #3: Revision=7, scratch=7 >>>>>> AX5043 #4: Revision=119, scratch=119 >>>>>> AX5043 #5: Revision=7, scratch=7 >>>>>> >>>>>> This is what it looks like. However the numbers are all wrong. I'm >>>>>> not sure how they can be other than right or 0xff, but something is screwed >>>>>> up. The Revision should be 0x51, which would be printed in decimal as 81. >>>>>> The scratch register, I wrote the AX5043 number into, so each one should >>>>>> read the same as the first number in the line, i.e. 0, 1, 2, 3, 4, 5. >>>>>> >>>>>> You might as well try it on yours Bob. In the meantime, I'll try to >>>>>> see if I can tell anything on mine. >>>>>> >>>>>> 73, >>>>>> >>>>>> Burns Fisher, WB1FJ >>>>>> *AMSAT(R) Engineering -- Flight Software* >>>>>> >>>>> >>>>> ----------------------------------------------------------- >>>>> >>>>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>>>> View archives of this mailing list at >>>>> https://mailman.amsat.org/hyperkitty/list/[email protected] >>>>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>>>> Manage all of your AMSAT-NA mailing list preferences at >>>>> https://mailman.amsat.org >>>>> >>>>> >>>>> >>>> >>>> ----------------------------------------------------------- >>>> >>>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>>> View archives of this mailing list at >>>> https://mailman.amsat.org/hyperkitty/list/[email protected] >>>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>>> Manage all of your AMSAT-NA mailing list preferences at >>>> https://mailman.amsat.org >>>> >>> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://mailman.amsat.org >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: Quick test for AX5043
by Bob Stricklin 08 Feb '24

08 Feb '24

[IMG_0004] I see version is q so I think this is most current. Not seeing 4 chips yet. Bob On Feb 8, 2024, at 4:01 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> wrote: Ok, please also get X0.1q (just pushed upstream). I may have said before that I got one MRAM to work on my board. Now I have changed a few things so that it seems to do at least some of the tests correctly. I'm not 100% sure if it will work with only 1 and 4 chips or if it will work with yours as well. But anyway, it is an improvement. Do "clear mram" first. Pacsat>get mram sr MRAM0: status ff, MRAM1: status 32 MRAM2: status ff, MRAM3: status ff Pacsat>clear mram Post Launch Time Set to 2 minutesSet to start in safe mode WOD Frequency,size set to Default, and WOD Indices initialized Telemetry min/max in MRAM initialized Reset Count set to 0 Nonfatal error count zeroed (TBD) CRC calculated for init code and full code (TBD) MRAM Version Number Initialized MRAM config partition size is 1008 bytes MRAM file partition 1 size is 523280 Pacsat>get mram size MRAM Address Size=3 Partition 0 size=1008, partition 1=523280 MRAM0 size is 0KBytes, MRAM1 size is 512KBytes MRAM2 size is 0KBytes, MRAM3 size is 0KBytes Pacsat>test mram 4 42 NOTE: This test will wipe out the file system and configuration values in MRAM. Testing with read/write size = 4 bytes, random value base is 0x1864 Write starting at 0KB Write starting at 16KB Write starting at 32KB Write starting at 48KB Write starting at 64KB Write starting at 80KB <skipping a bunch of additional writes> Read starting at 0KB Read starting at 16KB Read starting at 32KB Read starting at 48KB Read starting at 64KB Read starting at 80KB Read starting at 96KB Read starting at 112KB Read starting at 128KB <...> Read starting at 432KB Read starting at 448KB Read starting at 464KB Read starting at 480KB Read starting at 496KB Read starting at 512KB Test is ok! Time is 37 seconds 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:30 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: Ok Burns. Will check soon. At the gym and will be home in about 30 minutes. Good that you fixed this. I added 20k pull-up on MOSI and security chip. Also moved the enable lines on the two supply control chips will give details on that later. Bob On Feb 8, 2024, at 3:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I got one MRAM working, specifically #1. I apparently fixed the chip select for that one. Please try "get mram sr" with X0.1p. If they say something other than 0xff, they are probably working. Don't mess with the other MRAM commands unless it sees all the MRAMs. I think a lot of that code assumes there are 4 good MRAMs. In the meantime, I now KNOW that most the SPI bus is ~good on my board, so I'll focus a bit more on the chip selects for 0 and 2. If I have time, I'll see if I can get some of the other tests working for only some MRAMs. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 9:20 AM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: Ok, Bob, glad you figured out how to get the new code. Regarding the MRAM. I at first thought that you said "okay", but now I think you said zero K. I originally set up the MRAM code to figure out the size of the MRAMs, whether they needed 2 or 3 address bytes, and how many were present. But I only had the one example of Jim's launchpad board, so I'm not surprised it is not quite right for larger MRAMs and especially if the failing MRAMs are not in order (i.e. 0 and 1 work, 2 and 3 do not). But since none work on my board, I could not do anything more. As soon as I can get a board with working MRAMs, I'll fix all that. Also with all the MRAM errors that I get I have disabled a number of the tasks because they quickly failed and reset the processor. I'll fix that when I get a working MRAM board. Regarding the 5043: Did you do "test ax"? That shows a couple registers from each of the 5043s which we know the value of. I think you can say "get ax 2" to read AX5043 #2, but I'm less sure about that. I did not display all 5 just because I did not know the correct values anyway, and it would just run off the bottom of the screen :-) More in a separate mailing. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Thu, Feb 8, 2024 at 4:17 AM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I resolved the issue with GIT I had. I was setting things up initially with my GIT username and password and apparently you must in CCS. I have built and run Version ‘o’. I am seeing data back from 2 of the AX5043s. Probably need to expand code to work with all 4 devices. Later. get ax returns this …. screen capture <Screenshot from 2024-02-08 02-56-00.png> get mram size just returns two of the mram 0 and 2 and indicates their size is 0k. test mram 1 42 seems to run saying Write starting at etc and goes from 0KB to 1024KB. Then it does a Read in same area and does not report any errors but says: Test is OK! Time is 75 seconds. MRAM chips are 4 meg so maybe code only setup for 1 meg. More testing on hardware later today. Bob On Feb 7, 2024, at 10:47 AM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: Yes, the same branch. What errors are you getting? 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Wed, Feb 7, 2024 at 11:33 AM Bob Stricklin <bstrick(a)n5brg.com<mailto:[email protected]>> wrote: Burns, Confirm for me the branch you are working with is WB1FJ_Port_to_Blinky I am having an issue getting a clean build. I know you were still working CS problem but I am trying to get the GIT build process to work properly. Bob On Feb 6, 2024, at 5:34 PM, Bob Stricklin <bstrick(a)n5brg.com<mailto:[email protected]>> wrote: OK Bob On Feb 6, 2024, at 4:16 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I'm reasonably sure that I have the chip select lines screwed up in s/w. I have band rehearsal tonight, so I won't be able to do anything till tomorrow. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Tue, Feb 6, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:[email protected]>> wrote: I added a quick test to tell if the 5043 SPI interface is working. This is in version 0.1n and has been pushed upstream. Pacsat>test ax AX5043 #0: Revision=7, scratch=7 AX5043 #1: Revision=7, scratch=7 AX5043 #2: Revision=119, scratch=119 AX5043 #3: Revision=7, scratch=7 AX5043 #4: Revision=119, scratch=119 AX5043 #5: Revision=7, scratch=7 This is what it looks like. However the numbers are all wrong. I'm not sure how they can be other than right or 0xff, but something is screwed up. The Revision should be 0x51, which would be printed in decimal as 81. The scratch register, I wrote the AX5043 number into, so each one should read the same as the first number in the line, i.e. 0, 1, 2, 3, 4, 5. You might as well try it on yours Bob. In the meantime, I'll try to see if I can tell anything on mine. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> 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:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0