- pacsat-dev - mailman.amsat.org

New update to main
by Chris Thompson 24 May '23

24 May '23

I just pushed my latest code to main. This has a working version of the AX25 Data Link State Machine. You can see the code in AX25Task.c. If you try to upload a file it will appear to work, with the ground station saying it was uploaded correctly. All of the packets are received and Ack'd by PACSAT, but the Uplink state machine is not yet storing them in a file. I still need to write that part. To trigger the ground station you need to transmit the status of the uplink by typing: send uplink status This is also using 2m as the receive frequency. Thanks to work by Jim, I have set this to use GFSK with BT=0.3. BT is the shape of the bit shaping filter. The filter may not be applied on receive, but setting it to GFSK vs GMSK makes a big difference. It now receives well on 2m at 9600bps. There is an errata from ON SEMI that says to use BT=0.3 vs BT=0.5 for transmit. I have also implemented a mode change command. You can type these commands in the console: set rate 1200 set rate 9600 These will set the radios to the specified data rate. You need to restart the processor to apply it. We can probably just restart the radios, but that was a quick way to implement this for testing. 73 Chris -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: RF Components / Power Requirements
by Jonathan Brandenburg 22 May '23

22 May '23

Thank you, Bob! I could have known / should have known you're already on top of the single event upsets and the latchup aspects of the board. Thank you for confirming all the considerations already present in the layout! There are still some details to be worked out, some of which depend on the characterization of the initial boards. That makes sense. I'll call out your last point in particular: "I am sure we have a power issue as I stated earlier. I have been moving ahead to test things with the idea we will have to cut some things back when/if the design moves forward." Since PACSAT is not yet targeting a specific satellite or launch but is instead looking to build a payload that can be made available for a number of satellites and launches, there won't be a single power budget available. Instead it seems like PACSAT will have a specified power requirement (perhaps a range that can be adjusted by turn on or off features like the number of uplinks). In defining that range it might be helpful to consider the target "customer". If targeting the minimum capabilities of 1U CubeSat, I happen to know the average orbit power with fixed cells on all faces is considered 5W with a worst case orbit of 2W. How much of that would a customer be willing to allocate to this subsystem? Perhaps a fair amount if PACSAT is also their primary command and telemetry system (recognizing there will be loss in the electrical power system and other systems are equally important including the command & data handling system and the primary payload) Or, is a 3U CubeSat a more appropriate target because it will have more power with fixed cells? I don't have the answer to this question but it's good to be thinking about power as you're already doing, Jonathan On 5/20/2023 9:48 PM, Bob Stricklin via pacsat-dev wrote: > Jonathan, > > Just looking back through some PacSat-Dev emails and realized I missed > this one from you…. > > > > >> On May 5, 2023, at 11:55 AM, Jonathan Brandenburg via pacsat-dev >> <pacsat-dev(a)amsat.org> wrote: >> >> As discussed last night, I've completed some preliminary work on the >> radiation tolerant circuitry. That does bring up one question... >> >> Bob, do you already have circuitry for watchdog protection and >> current limiting in the schematic / on the board? Or does that still >> have to be shoehorned into the board? > >> Yes, There is a Hardware Watchdog in the schematic and on the PCB - >> STWD100NYWY3F > > Yes, There are several current limit ICs, MAX4495_1 on the bard. The > current limit is set by a resistor and is set at 600 mA on each chip. > Will need to be tuned to the real value needed after prototyping. > >> >> To refine the design I've prototyped, I need to know the >> anticipated/budgeted power requirements. The part I'm looking at for >> current limiting, MAX4995AAUT+T, can handle 600mA. If we derate that >> a bit (are we using 50%?) we can handle 300mA. That's quite a lot so >> I don't expect an issue with hitting max current except possibly the >> power amplifier and it's not clear to me if the power amplifier needs >> to be protected against latchup anyway. In our previous designs, we >> have a separate current limiter for each AX5043, the power amplifier, >> and the TMS570. (I think the LNAs are bundled with the AX5043 for the >> purposes of power limits and peripheral power requirements for TXCOs >> and such ). I don't think we'll need that many here but we'll >> probably need one for each voltage rail. >> >> >> Do we have answers to some of the following questions or is some of >> still being determined: >> >> 1. What power output level are we using on the AX5043? Max current at >> 16dbm TX is 48 mA plus 6.5 mA for VHF receiver or 9.5 mA for UHF receive. > > This is programable in the AX5043 and not currently fix/defined. The > AX5043 TX chip is driving a Linear Power section in the design I have > because the desire was to have 2 Watts of RF power. PA chip is > MMZ09312BT1. We have a Class E output driving a linear power Amp. >> >> 2. What LNAs are we using? Does each AX5043 have its own LNA? (I >> haven't looked for a schematic so tell me to go find it myself if >> it's in Github.) > > LNA is currently a SAV-331+ which should provide about 15 dB of gain. > The signal is then filtered and then power converted to a differential > signal and split four ways to feed the four AX5043s. > > One Receive Antenna is used which feeds the LNA. Then the signal is > filtered and converted to differential and power divided to drive the > four AX5043s. >> >> 3. What power amplifier are we using and what is the power output? (I >> still need to double-check a need for current limiter here.) > > Output power amp is MMZ09312BT1 (74 Ma) for a total power of about 2 > Watts. These are no current limits on the power amps now and they are > powered from the main voltage coming to us to get max power. >> >> 4. Do we have a characterization for the TMS570 configuration to know >> which subsystems will be active and thus have a power budget for the >> TMS570? > > No, The power budget I sent you earlier for all the chips assumes the > current posted in the data sheet for each including the TMS570. > Probably not going to save a lot of power in this device. You can save > power here by running with a slower clock which may support our needs. > This can be determined in prototype testing. The clocking for the > TMS570 and the AX5043 can be split apart to support rate sensitive > functions. > > > I am sure we have a power issue as I stated earlier. I have beed > moving ahead to test things with the idea we will have to cut some > things back when/if the design moves forward. > > Bob > >> >> Thanks a lot! >> >> Jonathan >> >> -- >> Jonathan Brandenburg, KF5IDY >> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aq… >> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org >> Manage all of your AMSAT-NA mailing list preferences at >> https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi… > > > ----------------------------------------------------------- > > pacsat-dev mailing list --pacsat-dev(a)amsat.org > View archives of this mailing list athttps://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email topacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences athttps://mailman.amsat.org -- jbrandenburg(a)amsat.org

1 0

Re: RF Components / Power Requirements
by Bob Stricklin 20 May '23

20 May '23

Jonathan, Just looking back through some PacSat-Dev emails and realized I missed this one from you…. On May 5, 2023, at 11:55 AM, Jonathan Brandenburg via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: As discussed last night, I've completed some preliminary work on the radiation tolerant circuitry. That does bring up one question... Bob, do you already have circuitry for watchdog protection and current limiting in the schematic / on the board? Or does that still have to be shoehorned into the board? Yes, There is a Hardware Watchdog in the schematic and on the PCB - STWD100NYWY3F Yes, There are several current limit ICs, MAX4495_1 on the bard. The current limit is set by a resistor and is set at 600 mA on each chip. Will need to be tuned to the real value needed after prototyping. To refine the design I've prototyped, I need to know the anticipated/budgeted power requirements. The part I'm looking at for current limiting, MAX4995AAUT+T, can handle 600mA. If we derate that a bit (are we using 50%?) we can handle 300mA. That's quite a lot so I don't expect an issue with hitting max current except possibly the power amplifier and it's not clear to me if the power amplifier needs to be protected against latchup anyway. In our previous designs, we have a separate current limiter for each AX5043, the power amplifier, and the TMS570. (I think the LNAs are bundled with the AX5043 for the purposes of power limits and peripheral power requirements for TXCOs and such ). I don't think we'll need that many here but we'll probably need one for each voltage rail. Do we have answers to some of the following questions or is some of still being determined: 1. What power output level are we using on the AX5043? Max current at 16dbm TX is 48 mA plus 6.5 mA for VHF receiver or 9.5 mA for UHF receive. This is programable in the AX5043 and not currently fix/defined. The AX5043 TX chip is driving a Linear Power section in the design I have because the desire was to have 2 Watts of RF power. PA chip is MMZ09312BT1. We have a Class E output driving a linear power Amp. 2. What LNAs are we using? Does each AX5043 have its own LNA? (I haven't looked for a schematic so tell me to go find it myself if it's in Github.) LNA is currently a SAV-331+ which should provide about 15 dB of gain. The signal is then filtered and then power converted to a differential signal and split four ways to feed the four AX5043s. One Receive Antenna is used which feeds the LNA. Then the signal is filtered and converted to differential and power divided to drive the four AX5043s. 3. What power amplifier are we using and what is the power output? (I still need to double-check a need for current limiter here.) Output power amp is MMZ09312BT1 (74 Ma) for a total power of about 2 Watts. These are no current limits on the power amps now and they are powered from the main voltage coming to us to get max power. 4. Do we have a characterization for the TMS570 configuration to know which subsystems will be active and thus have a power budget for the TMS570? No, The power budget I sent you earlier for all the chips assumes the current posted in the data sheet for each including the TMS570. Probably not going to save a lot of power in this device. You can save power here by running with a slower clock which may support our needs. This can be determined in prototype testing. The clocking for the TMS570 and the AX5043 can be split apart to support rate sensitive functions. I am sure we have a power issue as I stated earlier. I have beed moving ahead to test things with the idea we will have to cut some things back when/if the design moves forward. Bob Thanks a lot! Jonathan -- Jonathan Brandenburg, KF5IDY ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aq… 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://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi…

1 0

Re: AX25 code
by Chris Thompson 12 May '23

12 May '23

ok, thanks. I will have a look. 73 Chris On Fri, May 12, 2023 at 8:51 AM Corey Minyard via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > On Thu, May 11, 2023 at 8:01 PM Corey Minyard via pacsat-dev > <pacsat-dev(a)amsat.org> wrote: > > > > For Chris, mostly, > > > > In my AX25 code, the two queues are named read_data and write_data, > > you can search for those values. The length, position, and size are > > right after it and described in the comment above. > > > > There are also some functions named "sub_seq", "add_seq" and > > "seq_in_range" that handle the wraparound. In particular, > > seq_in_range is a little tricky. And I see that I should comment > > those better. > > Just to be clear, those are used for both sequence number handling and > for circular buffer handling. I've added some comments to document > them a little better. > > > > > And if you want, I can look at splitting up my code into a library > > that has the state machine that could be re-used. It may be some > > overkill, though, it does all the extended sequencing, XID, and such > > that we don't need. > > > > -corey > > > > ----------------------------------------------------------- > > > > 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 > -- Chris E. Thompson chrisethompson(a)gmail.com g0kla(a)arrl.net

1 0

Re: AX25 code
by Corey Minyard 12 May '23

12 May '23

On Thu, May 11, 2023 at 8:01 PM Corey Minyard via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > For Chris, mostly, > > In my AX25 code, the two queues are named read_data and write_data, > you can search for those values. The length, position, and size are > right after it and described in the comment above. > > There are also some functions named "sub_seq", "add_seq" and > "seq_in_range" that handle the wraparound. In particular, > seq_in_range is a little tricky. And I see that I should comment > those better. Just to be clear, those are used for both sequence number handling and for circular buffer handling. I've added some comments to document them a little better. > > And if you want, I can look at splitting up my code into a library > that has the state machine that could be re-used. It may be some > overkill, though, it does all the extended sequencing, XID, and such > that we don't need. > > -corey > > ----------------------------------------------------------- > > 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

AX25 code
by Corey Minyard 11 May '23

11 May '23

For Chris, mostly, In my AX25 code, the two queues are named read_data and write_data, you can search for those values. The length, position, and size are right after it and described in the comment above. There are also some functions named "sub_seq", "add_seq" and "seq_in_range" that handle the wraparound. In particular, seq_in_range is a little tricky. And I see that I should comment those better. And if you want, I can look at splitting up my code into a library that has the state machine that could be re-used. It may be some overkill, though, it does all the extended sequencing, XID, and such that we don't need. -corey

1 0

Re: Pacsat dev mtg 5/11/2023
by Burns Fisher (AMSAT) 11 May '23

11 May '23

Second Thursday, so I won't be there. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Thu, May 11, 2023 at 3:48 PM Bill via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > Thu, May 11, 2023 7:00 PM - 9:00 PM (CDT) > > Please join my meeting from your computer, tablet or smartphone. > > https://meet.goto.com/961241293 > > You can also dial in using your phone. > (For supported devices, tap a one-touch number below to join instantly.) > > United States: +1 (408) 650-3123 > - One-touch: tel:+14086503123,,961241293# > > Access Code: 961-241-293 > > Join from a video-conferencing room or system. > Dial in or type: 67.217.95.2 or inroomlink.goto.com > Meeting ID: 961 241 293 > Or dial directly: 961241293(a)67.217.95.2 or 67.217.95.2##961241293 > > > Get the app now and be ready when your first meeting starts: > https://meet.goto.com/install > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Pacsat dev mtg 5/11/2023
by Bill 11 May '23

11 May '23

Thu, May 11, 2023 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/961241293 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (408) 650-3123 - One-touch: tel:+14086503123,,961241293# Access Code: 961-241-293 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 961 241 293 Or dial directly: 961241293(a)67.217.95.2 or 67.217.95.2##961241293 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Building/loading PacSat software
by Burns Fisher (AMSAT) 10 May '23

10 May '23

Chris said in a previous mail that I had sent out info about how to build PacSat. Maybe I did, but I can't find it. So for Bill and any others, here is at least a quick version. Without actually DOING it again, I may miss something. We can use this thread to clarify, and I know several other people have done it. Please do speak up if I miss something. =========================== The first thing you want to do is to download and install TI's Code Composer Studio. Look at https://www.ti.com/tool/CCSTUDIO I use the Linux version 10.2.0.00009, but there are several versions newer. I tend not to update unless I need to, but feel free to try the newer one. (We should freeze the version before we start testing for flight!) When you run CCS, go to the "File" menu and select "Import" and the Git/Projects from Git. (I don't know what smart import, another choice is, so I probably did not use it). I think it will suggest a project called "PacSat" and that is what you should choose. Let it all install/download, etc, and then push the "Hammer" key to build. Hopefully this will work. Then you can plug in your LaunchPad and hit the "bug" button to download and debug. If you are not gonig to use the debugger, just hit the red square to disconnect and it will run. Remember that you have to have a serial port connected to Jim's board (the 3 pins labelled Rx, Tx, and Gnd). Use a terminal emulator to connect to this at 38400 baud. Hopefully, this all does the trick. Have I missed anything Chris, Corey, Jim? I have not done the full download in a good long time, so there are probably additional things you have to slog through. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Code Cleanup
by Burns Fisher (AMSAT) 10 May '23

10 May '23

Folks, I have removed references to the HET (High Efficiency Timer--essentially a co-processor in the TMS570) emulation of I2c and UART. We need extra UARTs and I2c busses in Golf, and Golf is where I initially ported the PacSat code from. This is step one of cleaning out Golf stuff. I've already removed anything that might be ITAR sensitive (and I don't think there was anything). This is just removing unnecessary stuff that need not take up space in flash. I don't think this will cause anyone any serious problems merging since most of it was in drivers, but it is currently in a branch called CleanUpHET. I'll put in a pull request to merge that with main, and if I hear no comments, will do that in a few days. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0