- pacsat-dev - mailman.amsat.org

Re: One board now talking
by Burns Fisher (AMSAT) 05 Feb '24

05 Feb '24

BTW, I don't if I ever said this (if so, just a remnider): Before you generate code from HalCoGen, you MUST put the code that is in CCS back in the place where HalCoGen puts its code. That is because there are a few places where I put some stuff in the "USER CODE BEGIN" section. Look in particular at sys_main.c and spi.c (in which I actually commented out a whole bunch of code and put in my own version in hcgExtras). I run CCS on Linux and HCG on Windows, and use dropbox to connect them. HalCoGen writes directly into DropBox. Then I just copy all the files on the Linux side from dropbox into CCS, and if I make any changes in the USER CODE section then I copy it from CCS back to HCG. I'm not sure what you meant about HCG a few mails back. The HalCoGen file PACSatBlinky.hcg certainly is set up for the TMS570LS0914. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Feb 5, 2024 at 4:56 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Just realized that the second temp sensor is not on this board. I took it > off to change address and have not put it back yet. Probably will work fine. > ------------------------------ > *From:* Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> > *Sent:* Monday, February 5, 2024 3:53 PM > *To:* Bob Stricklin <bstrick(a)n5brg.com> > *Cc:* Bill via pacsat-dev <pacsat-dev(a)amsat.org> > *Subject:* [pacsat-dev] Re: One board now talking > > Oh, I see. So this is saying that I2c in general is ok, but that the temp > sensor near the CPU is not working for whatever reason (bad bus connection, > bad address bit connection, or bad chip). > > And regarding the MRAM, I have the chip select wrong on at least one of > those MRAM devices. I just found that earlier and did not push it up to > the repository.. Let me check what else I have done since I pushed > upstream, and if all is ok, I'll push this change too. Looks like most > everything in the MRAM is ok otheriwise (whew! Was driving me crazy) > > I see you sent something else. Have not seen it yet but will send this. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Mon, Feb 5, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > wrote: > > Ok, looks like two of the MRAMs are ok, and two are not for whatever > reason. Oh, I bet I know...I think I got the chip select lines wrong on > one or two of them. Funny the temp actually looks ok despite the error. > In the middle of checking something else. Will get back after a bit more > testing. > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Mon, Feb 5, 2024 at 4:41 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > Pacsat> > Pacsat>get mram sr > MRAM0: status 32, MRAM1: status ff > MRAM2: status 2, MRAM3: status ff > Pacsat>get temp > CPU Temp request failed > Transmitter temp: 99 ( 29.5 degrees C) > Pacsat> > > > ------------------------------ > *From:* Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > *Sent:* Monday, February 5, 2024 3:35 PM > *To:* Bob Stricklin <bstrick(a)n5brg.com> > *Cc:* Bill via pacsat-dev <pacsat-dev(a)amsat.org> > *Subject:* Re: [pacsat-dev] One board now talking > > Oh, I just sent you a mail before seeing this. > > Wow! Looks like there may be something wrong with my board. Could you do > "get mram sr" please? You could try "get temp" also. > > I'm not sure if those are the right values for the DCT (the AX5043). I > know I had a quick way at one point that I could tell if one particular > register was correct. I'll see if I can find it. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Mon, Feb 5, 2024 at 4:24 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > After getting TX and RX connected correctly now working. Do not know what > the correct report back is but here is some checks... > > This board has four 4Mb MRAMs installed. > > > Pacsat>get version > > AMSAT-NA PacSat Console > Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) > Compiled *RELEASE* > **X, E, U, or DEBUG Version: Not configured for flight** > Watchdog NOT Enabled > Using FreeRTOS withOUT premption enabled; > Free heap size is 75504 > Flash memory size 1Mb+0Kb > MRAM config data partition size=1008, file system size=1047568 > Pacsat>>get version > > AMSAT-NA PacSat Console > Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) > Compiled *RELEASE* > **X, E, U, or DEBUG Version: Not configured for flight** > Watchdog NOT Enabled > Using FreeRTOS withOUT premption enabled; > Free heap size is 75504 > Flash memory size 1Mb+0Kb > MRAM config data partition size=1008, file system size=1047568 > Pacsat> > > Pacsat>get RSSI > RSSI is -64 dBm > Pacsat> > > Pacsat>get ax > AX5043 dev 1 TX: > FIFOSTAT: 00 > PWRMODE:: 77 > XTALCAP: 119 > PLLLOOP: 77 > PLLCPI: 77 > PLLVCOI: 77 > PLLRANGINGA: 77 > PLLVCODIV: 77 > FREQ 1911466666 Hz > MODULATION: 77 > TXPWRCOEFFB0: 77 > TXPWRCOEFFB1: 77 > > AX5043 dev 0 RX: > FIFOSTAT: 00 > PWRMODE: 67 > XTALCAP: 103 > PLLLOOP: 67 > PLLCPI: 67 > PLLVCOI: 67 > PLLRANGINGA: 67 > PLLVCODIV: 67 > FREQ 1654462744 Hz > MODULATION: 67 > TXPWRCOEFFB0: 67 > TXPWRCOEFFB1: 67 > Pacsat> > > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Re: One board now talking
by Bob Stricklin 05 Feb '24

05 Feb '24

Just realized that the second temp sensor is not on this board. I took it off to change address and have not put it back yet. Probably will work fine. ________________________________ From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Monday, February 5, 2024 3:53 PM To: Bob Stricklin <bstrick(a)n5brg.com> Cc: Bill via pacsat-dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: One board now talking Oh, I see. So this is saying that I2c in general is ok, but that the temp sensor near the CPU is not working for whatever reason (bad bus connection, bad address bit connection, or bad chip). And regarding the MRAM, I have the chip select wrong on at least one of those MRAM devices. I just found that earlier and did not push it up to the repository.. Let me check what else I have done since I pushed upstream, and if all is ok, I'll push this change too. Looks like most everything in the MRAM is ok otheriwise (whew! Was driving me crazy) I see you sent something else. Have not seen it yet but will send this. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, Feb 5, 2024 at 4:43 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: Ok, looks like two of the MRAMs are ok, and two are not for whatever reason. Oh, I bet I know...I think I got the chip select lines wrong on one or two of them. Funny the temp actually looks ok despite the error. In the middle of checking something else. Will get back after a bit more testing. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, Feb 5, 2024 at 4:41 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Pacsat> Pacsat>get mram sr MRAM0: status 32, MRAM1: status ff MRAM2: status 2, MRAM3: status ff Pacsat>get temp CPU Temp request failed Transmitter temp: 99 ( 29.5 degrees C) Pacsat> ________________________________ From: Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> Sent: Monday, February 5, 2024 3:35 PM To: Bob Stricklin <bstrick(a)n5brg.com<mailto:bstrick@n5brg.com>> Cc: Bill via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Subject: Re: [pacsat-dev] One board now talking Oh, I just sent you a mail before seeing this. Wow! Looks like there may be something wrong with my board. Could you do "get mram sr" please? You could try "get temp" also. I'm not sure if those are the right values for the DCT (the AX5043). I know I had a quick way at one point that I could tell if one particular register was correct. I'll see if I can find it. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, Feb 5, 2024 at 4:24 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: After getting TX and RX connected correctly now working. Do not know what the correct report back is but here is some checks... This board has four 4Mb MRAMs installed. Pacsat>get version AMSAT-NA PacSat Console Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) Compiled *RELEASE* **X, E, U, or DEBUG Version: Not configured for flight** Watchdog NOT Enabled Using FreeRTOS withOUT premption enabled; Free heap size is 75504 Flash memory size 1Mb+0Kb MRAM config data partition size=1008, file system size=1047568 Pacsat>>get version AMSAT-NA PacSat Console Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) Compiled *RELEASE* **X, E, U, or DEBUG Version: Not configured for flight** Watchdog NOT Enabled Using FreeRTOS withOUT premption enabled; Free heap size is 75504 Flash memory size 1Mb+0Kb MRAM config data partition size=1008, file system size=1047568 Pacsat> Pacsat>get RSSI RSSI is -64 dBm Pacsat> Pacsat>get ax AX5043 dev 1 TX: FIFOSTAT: 00 PWRMODE:: 77 XTALCAP: 119 PLLLOOP: 77 PLLCPI: 77 PLLVCOI: 77 PLLRANGINGA: 77 PLLVCODIV: 77 FREQ 1911466666 Hz MODULATION: 77 TXPWRCOEFFB0: 77 TXPWRCOEFFB1: 77 AX5043 dev 0 RX: FIFOSTAT: 00 PWRMODE: 67 XTALCAP: 103 PLLLOOP: 67 PLLCPI: 67 PLLVCOI: 67 PLLRANGINGA: 67 PLLVCODIV: 67 FREQ 1654462744 Hz MODULATION: 67 TXPWRCOEFFB0: 67 TXPWRCOEFFB1: 67 Pacsat> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: One board now talking
by Burns Fisher (AMSAT) 05 Feb '24

05 Feb '24

Ok, looks like two of the MRAMs are ok, and two are not for whatever reason. Oh, I bet I know...I think I got the chip select lines wrong on one or two of them. Funny the temp actually looks ok despite the error. In the middle of checking something else. Will get back after a bit more testing. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Feb 5, 2024 at 4:41 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Pacsat> > Pacsat>get mram sr > MRAM0: status 32, MRAM1: status ff > MRAM2: status 2, MRAM3: status ff > Pacsat>get temp > CPU Temp request failed > Transmitter temp: 99 ( 29.5 degrees C) > Pacsat> > > > ------------------------------ > *From:* Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > *Sent:* Monday, February 5, 2024 3:35 PM > *To:* Bob Stricklin <bstrick(a)n5brg.com> > *Cc:* Bill via pacsat-dev <pacsat-dev(a)amsat.org> > *Subject:* Re: [pacsat-dev] One board now talking > > Oh, I just sent you a mail before seeing this. > > Wow! Looks like there may be something wrong with my board. Could you do > "get mram sr" please? You could try "get temp" also. > > I'm not sure if those are the right values for the DCT (the AX5043). I > know I had a quick way at one point that I could tell if one particular > register was correct. I'll see if I can find it. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Mon, Feb 5, 2024 at 4:24 PM Bob Stricklin via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > After getting TX and RX connected correctly now working. Do not know what > the correct report back is but here is some checks... > > This board has four 4Mb MRAMs installed. > > > Pacsat>get version > > AMSAT-NA PacSat Console > Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) > Compiled *RELEASE* > **X, E, U, or DEBUG Version: Not configured for flight** > Watchdog NOT Enabled > Using FreeRTOS withOUT premption enabled; > Free heap size is 75504 > Flash memory size 1Mb+0Kb > MRAM config data partition size=1008, file system size=1047568 > Pacsat>>get version > > AMSAT-NA PacSat Console > Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) > Compiled *RELEASE* > **X, E, U, or DEBUG Version: Not configured for flight** > Watchdog NOT Enabled > Using FreeRTOS withOUT premption enabled; > Free heap size is 75504 > Flash memory size 1Mb+0Kb > MRAM config data partition size=1008, file system size=1047568 > Pacsat> > > Pacsat>get RSSI > RSSI is -64 dBm > Pacsat> > > Pacsat>get ax > AX5043 dev 1 TX: > FIFOSTAT: 00 > PWRMODE:: 77 > XTALCAP: 119 > PLLLOOP: 77 > PLLCPI: 77 > PLLVCOI: 77 > PLLRANGINGA: 77 > PLLVCODIV: 77 > FREQ 1911466666 Hz > MODULATION: 77 > TXPWRCOEFFB0: 77 > TXPWRCOEFFB1: 77 > > AX5043 dev 0 RX: > FIFOSTAT: 00 > PWRMODE: 67 > XTALCAP: 103 > PLLLOOP: 67 > PLLCPI: 67 > PLLVCOI: 67 > PLLRANGINGA: 67 > PLLVCODIV: 67 > FREQ 1654462744 Hz > MODULATION: 67 > TXPWRCOEFFB0: 67 > TXPWRCOEFFB1: 67 > Pacsat> > > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 1

Re: One board now talking
by Bob Stricklin 05 Feb '24

05 Feb '24

Thats good. Just need to replace MRAM on that board could be the soldering or the overvoltage they experienced early on. ________________________________ From: Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Monday, February 5, 2024 3:44 PM To: Bob Stricklin <bstrick(a)n5brg.com> Cc: Bill via pacsat-dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: One board now talking Ok, looks like two of the MRAMs are ok, and two are not for whatever reason. Oh, I bet I know...I think I got the chip select lines wrong on one or two of them. Funny the temp actually looks ok despite the error. In the middle of checking something else. Will get back after a bit more testing. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, Feb 5, 2024 at 4:41 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Pacsat> Pacsat>get mram sr MRAM0: status 32, MRAM1: status ff MRAM2: status 2, MRAM3: status ff Pacsat>get temp CPU Temp request failed Transmitter temp: 99 ( 29.5 degrees C) Pacsat> ________________________________ From: Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> Sent: Monday, February 5, 2024 3:35 PM To: Bob Stricklin <bstrick(a)n5brg.com<mailto:bstrick@n5brg.com>> Cc: Bill via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> Subject: Re: [pacsat-dev] One board now talking Oh, I just sent you a mail before seeing this. Wow! Looks like there may be something wrong with my board. Could you do "get mram sr" please? You could try "get temp" also. I'm not sure if those are the right values for the DCT (the AX5043). I know I had a quick way at one point that I could tell if one particular register was correct. I'll see if I can find it. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Mon, Feb 5, 2024 at 4:24 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: After getting TX and RX connected correctly now working. Do not know what the correct report back is but here is some checks... This board has four 4Mb MRAMs installed. Pacsat>get version AMSAT-NA PacSat Console Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) Compiled *RELEASE* **X, E, U, or DEBUG Version: Not configured for flight** Watchdog NOT Enabled Using FreeRTOS withOUT premption enabled; Free heap size is 75504 Flash memory size 1Mb+0Kb MRAM config data partition size=1008, file system size=1047568 Pacsat>>get version AMSAT-NA PacSat Console Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) Compiled *RELEASE* **X, E, U, or DEBUG Version: Not configured for flight** Watchdog NOT Enabled Using FreeRTOS withOUT premption enabled; Free heap size is 75504 Flash memory size 1Mb+0Kb MRAM config data partition size=1008, file system size=1047568 Pacsat> Pacsat>get RSSI RSSI is -64 dBm Pacsat> Pacsat>get ax AX5043 dev 1 TX: FIFOSTAT: 00 PWRMODE:: 77 XTALCAP: 119 PLLLOOP: 77 PLLCPI: 77 PLLVCOI: 77 PLLRANGINGA: 77 PLLVCODIV: 77 FREQ 1911466666 Hz MODULATION: 77 TXPWRCOEFFB0: 77 TXPWRCOEFFB1: 77 AX5043 dev 0 RX: FIFOSTAT: 00 PWRMODE: 67 XTALCAP: 103 PLLLOOP: 67 PLLCPI: 67 PLLVCOI: 67 PLLRANGINGA: 67 PLLVCODIV: 67 FREQ 1654462744 Hz MODULATION: 67 TXPWRCOEFFB0: 67 TXPWRCOEFFB1: 67 Pacsat> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: One board now talking
by Burns Fisher (AMSAT) 05 Feb '24

05 Feb '24

Oh, I just sent you a mail before seeing this. Wow! Looks like there may be something wrong with my board. Could you do "get mram sr" please? You could try "get temp" also. I'm not sure if those are the right values for the DCT (the AX5043). I know I had a quick way at one point that I could tell if one particular register was correct. I'll see if I can find it. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Feb 5, 2024 at 4:24 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > After getting TX and RX connected correctly now working. Do not know what > the correct report back is but here is some checks... > > This board has four 4Mb MRAMs installed. > > > Pacsat>get version > > AMSAT-NA PacSat Console > Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) > Compiled *RELEASE* > **X, E, U, or DEBUG Version: Not configured for flight** > Watchdog NOT Enabled > Using FreeRTOS withOUT premption enabled; > Free heap size is 75504 > Flash memory size 1Mb+0Kb > MRAM config data partition size=1008, file system size=1047568 > Pacsat>>get version > > AMSAT-NA PacSat Console > Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) > Compiled *RELEASE* > **X, E, U, or DEBUG Version: Not configured for flight** > Watchdog NOT Enabled > Using FreeRTOS withOUT premption enabled; > Free heap size is 75504 > Flash memory size 1Mb+0Kb > MRAM config data partition size=1008, file system size=1047568 > Pacsat> > > Pacsat>get RSSI > RSSI is -64 dBm > Pacsat> > > Pacsat>get ax > AX5043 dev 1 TX: > FIFOSTAT: 00 > PWRMODE:: 77 > XTALCAP: 119 > PLLLOOP: 77 > PLLCPI: 77 > PLLVCOI: 77 > PLLRANGINGA: 77 > PLLVCODIV: 77 > FREQ 1911466666 Hz > MODULATION: 77 > TXPWRCOEFFB0: 77 > TXPWRCOEFFB1: 77 > > AX5043 dev 0 RX: > FIFOSTAT: 00 > PWRMODE: 67 > XTALCAP: 103 > PLLLOOP: 67 > PLLCPI: 67 > PLLVCOI: 67 > PLLRANGINGA: 67 > PLLVCODIV: 67 > FREQ 1654462744 Hz > MODULATION: 67 > TXPWRCOEFFB0: 67 > TXPWRCOEFFB1: 67 > Pacsat> > > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

2 1

Re: Small bugs to fix (I think)
by Burns Fisher (AMSAT) 05 Feb '24

05 Feb '24

Bob, When you say "The Blinky Version" you mean the branch "WB1FJ_Port_to_Blinky"? What are you using for a serial port adapter. Mine looks like a slightly big USB-A plug with a cable that has 4 conductors: Red, Black, Green, White. I have the red one taped back since that is +5V from the computer. Black is of course ground, White is Rx relative to the adapter, but it goes to the Tx output (5th pin in), and green in Tx relative to the adapter but goes to the Rx input on the board (4th pin in from the right on the back with the PC104 facing me but at the furthest edge. I'm not going to try to figure out the pin numbers :-) At this point, I've switched the software around so all of those bus lines act as GPIOs and then just have a bit at the beginning of the program that switches them on and off one at a time. Clock and MOSI seem ok all the way up to U79 (the only place I could solder on jumpers to hook my meter/scope to). We know that SOMI was not ok at U79, but I'm not totally convinced it is ok on the others either. I tried to measure to the little via beside U78 and it did not look right. (Hard as heck to do it though so I could be wrong.). I may give up on the MRAM for the moment and look at the DCTs. At least I can easily get at those bus and NCS connections. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Mon, Feb 5, 2024 at 2:20 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I managed to get the repository into CCS and have tried the Blinky version > but still not working for me. I think the board is working but my issue is > with the serial interface cable or the terminal program. I backed away from > it for a while to work on some other things. Will sort things out later. > > Also got the Memory version but that one gives me a error message with the > programmer and I have not figured out why on this either. Proper programmer > is selected. > > Bob > > > On Feb 5, 2024, at 10:53 AM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > I finally got some wires soldered to the MRAM SPI bus (what a pain! > PLEASE put these on some pins for debugging on the next one!) One thing > that seems to be happening is that the CLK line is pulled down. I think it > should be high. There is a check box for "clock polarity" in HCG, but it > is not checked...same as Golf. I'll play more this afternoon. > > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > > On Sun, Feb 4, 2024 at 1:30 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc> > wrote: > >> Hi Bob, >> >> I don't have long today, but I with your diagram, I was able to see that >> there was apparently a via just to the left of U76 for that pin, so I was >> able to measure continuity to there from the CPU pin 94 (and just to be >> sure I had the right one I could identify the via just below the processor >> and measured to that. So what this seems to say is that there is some >> issue with the trace between U79 pin 2 and U76 pin 2. That means that the >> problem I found should not prevent the other 3 MRAMs from working (U76, 77, >> 78), so it is time to pull out the scope and see what those signals look >> like. >> >> My code is in the same git repository that Chris and Jim have been >> using. Namely https://github.com/AMSAT-NA/PacSatSW.git. I'm not sure >> what you did or how familiar you are with git, but if your IDE is pointing >> to that repository, you will probably have to go to the Team menu and then >> "Fetch from Upstream". This will ensure that you can see locally the >> branches that are upstream (that is in github). Then switch branches to >> WB1FJ_Port_to_Blinky. >> >> I did start with that code (main branch), but a created an entirely new >> HCG project for the TMS570LS0914 (rather than the LS07xxx that was on the >> launchpad. So I can't tell you that I changed exactly x and y from the >> Launchpad version. I just went through all the devices and set them >> correctly, and looked at the code in RTIHU to see which HCG-generated >> modules I had put "user code" in and copied that. I've also removed a lot >> of peripherals that we don't use like CAN. I found that, like you, I had >> to reduce the size of the heap in order to get it to link and load. >> >> I think that my main problem with the serial port was that a) I was not >> 100% sure if 38k4 was the right speed, and b) I connected the Rx and Tx >> lines on my USB-to-serial adapter to the Rx and Tx lines on Blinky. Nope. >> Rx goes to Tx and Tx goes to Rx. >> >> 73, >> >> Burns Fisher, WB1FJ >> *AMSAT(R) Engineering -- Flight Software* >> >> >> On Sun, Feb 4, 2024 at 1:03 PM Bob Stricklin via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> Burns, >>> >>> I think I have addressed all the issues you raised except pull-ups on >>> SPI. If we don’t need them I can easily remove them from the boards. >>> >>> I will order some 91 nH inductors and a few more values near by and >>> replace the zero ohm resistors. The zero ohm resistors have some inductance >>> by the way. I can measure this with limited accuracy using an inductive >>> bridge I have. I think dynamic testing is needed to prove out best value. >>> May ask Jim to help with that later. >>> >>> I thought you uploaded your code changes to a fork. Can you tell me how >>> to find that? I just looked around and it is not obvious to me. >>> >>> Would you also speak to what you feel got the serial port working? I >>> assume there is a new HCG file in your code I would like to review that. >>> >>> I have another conference call this afternoon with SARA that will go >>> till 3 or so. >>> >>> I would like to test the MRAM on one of the other boards. These chips >>> have not been removed and resoldered. >>> I want to buy four new memory chips and have the assembly house place >>> them on the board you have. >>> May put a loop in the code to test each chip and flash leds with >>> results. Then they could perform a test after soldering. >>> >>> I plane to make all the changes I know about and assemble the boards I >>> have. Hope to get this done and ship all of them out by the end of this >>> week. >>> >>> Will have done limited testing to RF but that can catchup later. >>> >>> Bob >>> >>> On Feb 3, 2024, at 7:42 PM, Bob Stricklin <bstrick(a)n5brg.com> wrote: >>> >>> >>> >>> On Feb 3, 2024, at 4:07 PM, Burns Fisher (AMSAT) via pacsat-dev < >>> pacsat-dev(a)amsat.org> wrote: >>> >>> I've found a few minor design issues which I don't think will affect us >>> in the short run, but may not be what we want: >>> >>> 1) I already told you (Bob) about the addresses for the Max temp >>> sensors. As set, they collide with two of the possible 4 addresses on an >>> ADS7828, a commonly-used and space-tested A/D converter that some satellite >>> might use. We talked about this before and it should all be straightened >>> out. >>> >>> >>> Yes, Let me add this to the schematic with the new address values to be >>> used on next board build if any. >>> >>> >>> 2) I just noticed that PWR_SW_AX5043 and PWR_SW_SSPA are connected to >>> AD1IN_8 and AD1IN_5, pins 78 and 83. They are used as input to the >>> MAX4995SAL power switch/limiter. While you could use these AD1IN pins as >>> an input GPIO (read the voltage and subject it to a threshold for high or >>> low), I don't think it is possible to use these for output. AD1EVT might >>> be usable for output but I'm not sure what effect it would have on the >>> bult-in a/d converter. I suppose you could use the nearby MIBSPI5 pins. >>> They appear to be usable as GPIO pins and are physically near the ADC pins. >>> >>> >>> Will have to move these lines over as you indicated. Will do that with >>> jumpers. >>> >>> >>> I think the current way it is will work for the moment, since if I read >>> the datasheet right, the "ON" pin or the MAX4995AL really should be ON_N. >>> That is, a low value on it turns the power on, and you have a pulldown >>> there. So I think the 5043 and the SSPA will always be on since the ADC >>> inputs should be high impedance. >>> >>> 3) This may just be a doc issue. I think that "PWR_FLAG" on the >>> schematic can't be a circuit, right? OTherwise you'd have lots of weird >>> stuff connected together. If they are actually test points, I think they >>> should be labelled as such (TP1, TP2, etc) and marked in silk screen on the >>> board. >>> >>> >>> This is no problem, an artifact of KiCAD and needed to just to indicate >>> this is a power connection so DRC handles it properly. >>> >>> >>> 4) And finally, from what I have read (and seen on other projects), I >>> don't think the SPI busses need pullup resistors EXCEPT for MISO, and that >>> one should be VERY weak. (One of our devices does not use MISO very often >>> but it appears not to be able to pull much current, thus requiring the >>> really weak pullup. But as I recall a builtin pullup either was not >>> enough, or it could not be used when the pin was used as an SPI device). I >>> can put a scope on the MISO line for the AX5043 to see if it is getting >>> pulled down enough with the 10K. Likewise, I'll see what the other pins >>> look like when connected to the push/pull output of the SPI master. >>> >>> >>> We will add a a pull up resistor for next build. Try to use internal >>> pull up now and if this want cut it we can add a pull-up to these boards. >>> >>> >>> Don't take these critiques as anything other than helpful. I'm no >>> expert here...I just found these things in the process of trying to debug >>> the software, and in a couple cases from tracking down some really PITA >>> problems on Fox and/or Golf! >>> >>> >>> No problem, you are the first person that has looked at things closely >>> and when you start solving issues you are forced to do so. We all make >>> mistakes I have have made plenty. Thanks. >>> >>> >>> 73, >>> >>> Burns Fisher, WB1FJ >>> *AMSAT(R) Engineering -- Flight Software* >>> >>> ----------------------------------------------------------- >>> >>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>> View archives of this mailing list at >>> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>> Manage all of your AMSAT-NA mailing list preferences at >>> https://mailman.amsat.org >>> >>> >>> >>> ----------------------------------------------------------- >>> >>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>> View archives of this mailing list at >>> https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org >>> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >>> Manage all of your AMSAT-NA mailing list preferences at >>> https://mailman.amsat.org >>> >> > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

One board now talking
by Bob Stricklin 05 Feb '24

05 Feb '24

After getting TX and RX connected correctly now working. Do not know what the correct report back is but here is some checks... This board has four 4Mb MRAMs installed. Pacsat>get version AMSAT-NA PacSat Console Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) Compiled *RELEASE* **X, E, U, or DEBUG Version: Not configured for flight** Watchdog NOT Enabled Using FreeRTOS withOUT premption enabled; Free heap size is 75504 Flash memory size 1Mb+0Kb MRAM config data partition size=1008, file system size=1047568 Pacsat>>get version AMSAT-NA PacSat Console Flight Software X0.1k (built on Feb 4 2024 at 21:53:10) Compiled *RELEASE* **X, E, U, or DEBUG Version: Not configured for flight** Watchdog NOT Enabled Using FreeRTOS withOUT premption enabled; Free heap size is 75504 Flash memory size 1Mb+0Kb MRAM config data partition size=1008, file system size=1047568 Pacsat> Pacsat>get RSSI RSSI is -64 dBm Pacsat> Pacsat>get ax AX5043 dev 1 TX: FIFOSTAT: 00 PWRMODE:: 77 XTALCAP: 119 PLLLOOP: 77 PLLCPI: 77 PLLVCOI: 77 PLLRANGINGA: 77 PLLVCODIV: 77 FREQ 1911466666 Hz MODULATION: 77 TXPWRCOEFFB0: 77 TXPWRCOEFFB1: 77 AX5043 dev 0 RX: FIFOSTAT: 00 PWRMODE: 67 XTALCAP: 103 PLLLOOP: 67 PLLCPI: 67 PLLVCOI: 67 PLLRANGINGA: 67 PLLVCODIV: 67 FREQ 1654462744 Hz MODULATION: 67 TXPWRCOEFFB0: 67 TXPWRCOEFFB1: 67 Pacsat>

1 0

Re: Small bugs to fix (I think)
by Bob Stricklin 05 Feb '24

05 Feb '24

I managed to get the repository into CCS and have tried the Blinky version but still not working for me. I think the board is working but my issue is with the serial interface cable or the terminal program. I backed away from it for a while to work on some other things. Will sort things out later. Also got the Memory version but that one gives me a error message with the programmer and I have not figured out why on this either. Proper programmer is selected. Bob On Feb 5, 2024, at 10:53 AM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I finally got some wires soldered to the MRAM SPI bus (what a pain! PLEASE put these on some pins for debugging on the next one!) One thing that seems to be happening is that the CLK line is pulled down. I think it should be high. There is a check box for "clock polarity" in HCG, but it is not checked...same as Golf. I'll play more this afternoon. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Sun, Feb 4, 2024 at 1:30 PM Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: Hi Bob, I don't have long today, but I with your diagram, I was able to see that there was apparently a via just to the left of U76 for that pin, so I was able to measure continuity to there from the CPU pin 94 (and just to be sure I had the right one I could identify the via just below the processor and measured to that. So what this seems to say is that there is some issue with the trace between U79 pin 2 and U76 pin 2. That means that the problem I found should not prevent the other 3 MRAMs from working (U76, 77, 78), so it is time to pull out the scope and see what those signals look like. My code is in the same git repository that Chris and Jim have been using. Namely https://github.com/AMSAT-NA/PacSatSW.git. I'm not sure what you did or how familiar you are with git, but if your IDE is pointing to that repository, you will probably have to go to the Team menu and then "Fetch from Upstream". This will ensure that you can see locally the branches that are upstream (that is in github). Then switch branches to WB1FJ_Port_to_Blinky. I did start with that code (main branch), but a created an entirely new HCG project for the TMS570LS0914 (rather than the LS07xxx that was on the launchpad. So I can't tell you that I changed exactly x and y from the Launchpad version. I just went through all the devices and set them correctly, and looked at the code in RTIHU to see which HCG-generated modules I had put "user code" in and copied that. I've also removed a lot of peripherals that we don't use like CAN. I found that, like you, I had to reduce the size of the heap in order to get it to link and load. I think that my main problem with the serial port was that a) I was not 100% sure if 38k4 was the right speed, and b) I connected the Rx and Tx lines on my USB-to-serial adapter to the Rx and Tx lines on Blinky. Nope. Rx goes to Tx and Tx goes to Rx. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software On Sun, Feb 4, 2024 at 1:03 PM Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Burns, I think I have addressed all the issues you raised except pull-ups on SPI. If we don’t need them I can easily remove them from the boards. I will order some 91 nH inductors and a few more values near by and replace the zero ohm resistors. The zero ohm resistors have some inductance by the way. I can measure this with limited accuracy using an inductive bridge I have. I think dynamic testing is needed to prove out best value. May ask Jim to help with that later. I thought you uploaded your code changes to a fork. Can you tell me how to find that? I just looked around and it is not obvious to me. Would you also speak to what you feel got the serial port working? I assume there is a new HCG file in your code I would like to review that. I have another conference call this afternoon with SARA that will go till 3 or so. I would like to test the MRAM on one of the other boards. These chips have not been removed and resoldered. I want to buy four new memory chips and have the assembly house place them on the board you have. May put a loop in the code to test each chip and flash leds with results. Then they could perform a test after soldering. I plane to make all the changes I know about and assemble the boards I have. Hope to get this done and ship all of them out by the end of this week. Will have done limited testing to RF but that can catchup later. Bob On Feb 3, 2024, at 7:42 PM, Bob Stricklin <bstrick(a)n5brg.com<mailto:bstrick@n5brg.com>> wrote: On Feb 3, 2024, at 4:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I've found a few minor design issues which I don't think will affect us in the short run, but may not be what we want: 1) I already told you (Bob) about the addresses for the Max temp sensors. As set, they collide with two of the possible 4 addresses on an ADS7828, a commonly-used and space-tested A/D converter that some satellite might use. We talked about this before and it should all be straightened out. Yes, Let me add this to the schematic with the new address values to be used on next board build if any. 2) I just noticed that PWR_SW_AX5043 and PWR_SW_SSPA are connected to AD1IN_8 and AD1IN_5, pins 78 and 83. They are used as input to the MAX4995SAL power switch/limiter. While you could use these AD1IN pins as an input GPIO (read the voltage and subject it to a threshold for high or low), I don't think it is possible to use these for output. AD1EVT might be usable for output but I'm not sure what effect it would have on the bult-in a/d converter. I suppose you could use the nearby MIBSPI5 pins. They appear to be usable as GPIO pins and are physically near the ADC pins. Will have to move these lines over as you indicated. Will do that with jumpers. I think the current way it is will work for the moment, since if I read the datasheet right, the "ON" pin or the MAX4995AL really should be ON_N. That is, a low value on it turns the power on, and you have a pulldown there. So I think the 5043 and the SSPA will always be on since the ADC inputs should be high impedance. 3) This may just be a doc issue. I think that "PWR_FLAG" on the schematic can't be a circuit, right? OTherwise you'd have lots of weird stuff connected together. If they are actually test points, I think they should be labelled as such (TP1, TP2, etc) and marked in silk screen on the board. This is no problem, an artifact of KiCAD and needed to just to indicate this is a power connection so DRC handles it properly. 4) And finally, from what I have read (and seen on other projects), I don't think the SPI busses need pullup resistors EXCEPT for MISO, and that one should be VERY weak. (One of our devices does not use MISO very often but it appears not to be able to pull much current, thus requiring the really weak pullup. But as I recall a builtin pullup either was not enough, or it could not be used when the pin was used as an SPI device). I can put a scope on the MISO line for the AX5043 to see if it is getting pulled down enough with the 10K. Likewise, I'll see what the other pins look like when connected to the push/pull output of the SPI master. We will add a a pull up resistor for next build. Try to use internal pull up now and if this want cut it we can add a pull-up to these boards. Don't take these critiques as anything other than helpful. I'm no expert here...I just found these things in the process of trying to debug the software, and in a couple cases from tracking down some really PITA problems on Fox and/or Golf! No problem, you are the first person that has looked at things closely and when you start solving issues you are forced to do so. We all make mistakes I have have made plenty. Thanks. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://mailman.amsat.org/> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://mailman.amsat.org/> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Small bugs to fix (I think)
by Burns Fisher (AMSAT) 05 Feb '24

05 Feb '24

Hi Bob, I don't have long today, but I with your diagram, I was able to see that there was apparently a via just to the left of U76 for that pin, so I was able to measure continuity to there from the CPU pin 94 (and just to be sure I had the right one I could identify the via just below the processor and measured to that. So what this seems to say is that there is some issue with the trace between U79 pin 2 and U76 pin 2. That means that the problem I found should not prevent the other 3 MRAMs from working (U76, 77, 78), so it is time to pull out the scope and see what those signals look like. My code is in the same git repository that Chris and Jim have been using. Namely https://github.com/AMSAT-NA/PacSatSW.git. I'm not sure what you did or how familiar you are with git, but if your IDE is pointing to that repository, you will probably have to go to the Team menu and then "Fetch from Upstream". This will ensure that you can see locally the branches that are upstream (that is in github). Then switch branches to WB1FJ_Port_to_Blinky. I did start with that code (main branch), but a created an entirely new HCG project for the TMS570LS0914 (rather than the LS07xxx that was on the launchpad. So I can't tell you that I changed exactly x and y from the Launchpad version. I just went through all the devices and set them correctly, and looked at the code in RTIHU to see which HCG-generated modules I had put "user code" in and copied that. I've also removed a lot of peripherals that we don't use like CAN. I found that, like you, I had to reduce the size of the heap in order to get it to link and load. I think that my main problem with the serial port was that a) I was not 100% sure if 38k4 was the right speed, and b) I connected the Rx and Tx lines on my USB-to-serial adapter to the Rx and Tx lines on Blinky. Nope. Rx goes to Tx and Tx goes to Rx. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Sun, Feb 4, 2024 at 1:03 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Burns, > > I think I have addressed all the issues you raised except pull-ups on SPI. > If we don’t need them I can easily remove them from the boards. > > I will order some 91 nH inductors and a few more values near by and > replace the zero ohm resistors. The zero ohm resistors have some inductance > by the way. I can measure this with limited accuracy using an inductive > bridge I have. I think dynamic testing is needed to prove out best value. > May ask Jim to help with that later. > > I thought you uploaded your code changes to a fork. Can you tell me how to > find that? I just looked around and it is not obvious to me. > > Would you also speak to what you feel got the serial port working? I > assume there is a new HCG file in your code I would like to review that. > > I have another conference call this afternoon with SARA that will go till > 3 or so. > > I would like to test the MRAM on one of the other boards. These chips have > not been removed and resoldered. > I want to buy four new memory chips and have the assembly house place them > on the board you have. > May put a loop in the code to test each chip and flash leds with results. > Then they could perform a test after soldering. > > I plane to make all the changes I know about and assemble the boards I > have. Hope to get this done and ship all of them out by the end of this > week. > > Will have done limited testing to RF but that can catchup later. > > Bob > > On Feb 3, 2024, at 7:42 PM, Bob Stricklin <bstrick(a)n5brg.com> wrote: > > > > On Feb 3, 2024, at 4:07 PM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > I've found a few minor design issues which I don't think will affect us in > the short run, but may not be what we want: > > 1) I already told you (Bob) about the addresses for the Max temp sensors. > As set, they collide with two of the possible 4 addresses on an ADS7828, a > commonly-used and space-tested A/D converter that some satellite might > use. We talked about this before and it should all be straightened out. > > > Yes, Let me add this to the schematic with the new address values to be > used on next board build if any. > > > 2) I just noticed that PWR_SW_AX5043 and PWR_SW_SSPA are connected to > AD1IN_8 and AD1IN_5, pins 78 and 83. They are used as input to the > MAX4995SAL power switch/limiter. While you could use these AD1IN pins as > an input GPIO (read the voltage and subject it to a threshold for high or > low), I don't think it is possible to use these for output. AD1EVT might > be usable for output but I'm not sure what effect it would have on the > bult-in a/d converter. I suppose you could use the nearby MIBSPI5 pins. > They appear to be usable as GPIO pins and are physically near the ADC pins. > > > Will have to move these lines over as you indicated. Will do that with > jumpers. > > > I think the current way it is will work for the moment, since if I read > the datasheet right, the "ON" pin or the MAX4995AL really should be ON_N. > That is, a low value on it turns the power on, and you have a pulldown > there. So I think the 5043 and the SSPA will always be on since the ADC > inputs should be high impedance. > > 3) This may just be a doc issue. I think that "PWR_FLAG" on the schematic > can't be a circuit, right? OTherwise you'd have lots of weird stuff > connected together. If they are actually test points, I think they should > be labelled as such (TP1, TP2, etc) and marked in silk screen on the board. > > > This is no problem, an artifact of KiCAD and needed to just to indicate > this is a power connection so DRC handles it properly. > > > 4) And finally, from what I have read (and seen on other projects), I > don't think the SPI busses need pullup resistors EXCEPT for MISO, and that > one should be VERY weak. (One of our devices does not use MISO very often > but it appears not to be able to pull much current, thus requiring the > really weak pullup. But as I recall a builtin pullup either was not > enough, or it could not be used when the pin was used as an SPI device). I > can put a scope on the MISO line for the AX5043 to see if it is getting > pulled down enough with the 10K. Likewise, I'll see what the other pins > look like when connected to the push/pull output of the SPI master. > > > We will add a a pull up resistor for next build. Try to use internal pull > up now and if this want cut it we can add a pull-up to these boards. > > > Don't take these critiques as anything other than helpful. I'm no expert > here...I just found these things in the process of trying to debug the > software, and in a couple cases from tracking down some really PITA > problems on Fox and/or Golf! > > > No problem, you are the first person that has looked at things closely and > when you start solving issues you are forced to do so. We all make mistakes > I have have made plenty. Thanks. > > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 1

Re: Small bugs to fix (I think)
by Bob Stricklin 04 Feb '24

04 Feb '24

On Feb 3, 2024, at 4:07 PM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: I've found a few minor design issues which I don't think will affect us in the short run, but may not be what we want: 1) I already told you (Bob) about the addresses for the Max temp sensors. As set, they collide with two of the possible 4 addresses on an ADS7828, a commonly-used and space-tested A/D converter that some satellite might use. We talked about this before and it should all be straightened out. Yes, Let me add this to the schematic with the new address values to be used on next board build if any. 2) I just noticed that PWR_SW_AX5043 and PWR_SW_SSPA are connected to AD1IN_8 and AD1IN_5, pins 78 and 83. They are used as input to the MAX4995SAL power switch/limiter. While you could use these AD1IN pins as an input GPIO (read the voltage and subject it to a threshold for high or low), I don't think it is possible to use these for output. AD1EVT might be usable for output but I'm not sure what effect it would have on the bult-in a/d converter. I suppose you could use the nearby MIBSPI5 pins. They appear to be usable as GPIO pins and are physically near the ADC pins. Will have to move these lines over as you indicated. Will do that with jumpers. I think the current way it is will work for the moment, since if I read the datasheet right, the "ON" pin or the MAX4995AL really should be ON_N. That is, a low value on it turns the power on, and you have a pulldown there. So I think the 5043 and the SSPA will always be on since the ADC inputs should be high impedance. 3) This may just be a doc issue. I think that "PWR_FLAG" on the schematic can't be a circuit, right? OTherwise you'd have lots of weird stuff connected together. If they are actually test points, I think they should be labelled as such (TP1, TP2, etc) and marked in silk screen on the board. This is no problem, an artifact of KiCAD and needed to just to indicate this is a power connection so DRC handles it properly. 4) And finally, from what I have read (and seen on other projects), I don't think the SPI busses need pullup resistors EXCEPT for MISO, and that one should be VERY weak. (One of our devices does not use MISO very often but it appears not to be able to pull much current, thus requiring the really weak pullup. But as I recall a builtin pullup either was not enough, or it could not be used when the pin was used as an SPI device). I can put a scope on the MISO line for the AX5043 to see if it is getting pulled down enough with the 10K. Likewise, I'll see what the other pins look like when connected to the push/pull output of the SPI master. We will add a a pull up resistor for next build. Try to use internal pull up now and if this want cut it we can add a pull-up to these boards. Don't take these critiques as anything other than helpful. I'm no expert here...I just found these things in the process of trying to debug the software, and in a couple cases from tracking down some really PITA problems on Fox and/or Golf! No problem, you are the first person that has looked at things closely and when you start solving issues you are forced to do so. We all make mistakes I have have made plenty. Thanks. 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 1