November 2022 - pacsat-dev - mailman.amsat.org

Power fail-safe embedded file system for FreeRTOS
by Rich Gopstein 12 Dec '22

12 Dec '22

I found this while poking around. They have both GPL and commercial options. https://www.freertos.org/FreeRTOS-Plus/Fail_Safe_File_System/Reliance_Edge_…

3 6

Suggested order for Pacsat devos
by Burns Fisher (AMSAT) 29 Nov '22

29 Nov '22

Hi Jonathan, I'm thinking that if we want to write software before we are producing any boards, that a few more devices to attach to the Launchpad processor eval board would be good. We have the AX5043 boards that you designed which (at this point) I am assuming can be connected (Chris is currently attempting that). But what we don't have is an MRAM except for the one board that Zach designed and RIch has used (Chris has that now, and it works). We can get an MRAM on a DIP board for use in a solderless breadboard from Proto Advantage. This would require jumpers from the LaunchPad to the solderless breadboard and to the AX5043 board. Here is an example: *http://www.proto-advantage.com/store/shopping_cart.php?cartnum=8cc208e06c96db <http://www.proto-advantage.com/store/shopping_cart.php?cartnum=8cc208e06c96…>* Another possibility is to design a pretty simple little board that would plug onto a Launchpad and would have both an MRAM and either a soldered-on 5043 or a place pins/sockets for a Jonathan-5043-board. What do you think? Hope you had a good trip to the cape! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

2 2

Fwd: [FOXTELEM] 4th Quarter FalconSAT-3 Chicken Little Report, Thanksgiving Edition
by Chris Thompson 28 Nov '22

28 Nov '22

For anyone not on the FOX list: ---------- Forwarded message --------- From: Alan <wa4sca(a)gmail.com> Date: Sun, Nov 27, 2022 at 8:48 AM Subject: [FOXTELEM] 4th Quarter FalconSAT-3 Chicken Little Report, Thanksgiving Edition To: Fox Telemetry Analysis <foxtelem(a)amsatfox.org> As of today, 27 October 2022, this is the current predicted lifetime from the NASA DAS program: The calculated reentry date continues to move somewhat earlier, with the current expectation around 14 February, 2023. I fully expect that trend to continue. 73, Alan ----------------------------------------------- FOXTELEM mailing list -- foxtelem(a)amsatfox.org View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/foxtelem@amsatfox.org To unsubscribe send an email to foxtelem-leave(a)amsatfox.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

2 1

MRAM size
by Burns Fisher (AMSAT) 26 Nov '22

26 Nov '22

It appears that there are 8Megabyte MRAM chips available at Digikey at about $50. Everspin is the brand we have been using. I think they invented the technology. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

4 6

AX5043 Pi Boards from Alan Johnston
by Burns Fisher (AMSAT) 19 Nov '22

19 Nov '22

Just to help you all decide about how many AX5043 Pi boards need to be built: I just heard from Alan. He only had two boards in the end. He is sending one to Jim and one to me today. I already have one board, so I may try to ensure that I can run two 5043s from a single TMS570 at some point, but if someone can use a 5043 before any can be built, let me know. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Out of Office
by Jonathan Brandenburg 19 Nov '22

19 Nov '22

Just a quick notification that I'm out of the office on vacation for the next week even from my virtual and volunteer "jobs". Thus, I may not be particularly responsive. I apologize in advance for any delays! Hope everybody has a good holiday week, Jonathan -- Jonathan, KF5IDY

1 0

Pacsat memory considerations
by Jim McCullers 18 Nov '22

18 Nov '22

We need to address Pacsat memory considerations. The MR25H40 is arranged as 8 x 512k bytes and is SPI. The higher capacity models are parallel interface that would significantly complicate the design and board space. In addition, they operate at much higher power consumption than the MR25H40. With multiple MR25H40s there will de design issues with the file system when crossing memory bounds. Burns or Rich, do you know what speed you are clocking the MR25H40? There is considerable difference in power consumption between clocking speeds of 1mhz and 40mhz. Thanks Jim McCullers WA4CWI

5 8

Greencube Operation
by Bob Stricklin 18 Nov '22

18 Nov '22

Also in case you missed it this was an interesting post from AMSAT-BB: Frank, No secret, I use following: 1) SatPC32ISS for antenna tracking and doppler correction. 2) The doppler.SQF line I use: GREENCUBE,435309.05,435309.05,USB,USB,NOR,0,0, To note that the frequency above was adjusted with the Soundmodem waterfall to have the audio well centre on 1600Hz, basically it is the USB offset for my rig and may be different for others/different rig. 3) UZ7HO GreenCube Soundmodem and GUI: http://uz7.ho.ua/greentnc.zip<https://url.emailprotection.link/?bUV-xAXuZxO2TvYoGTz_FagEbSqWfM_2Fz9YgQs8X…>, Note matching the rig bandpass filter with the Soundmodem one (900-2100 Hz) helps to have a better S/N particularly if you have local QRM. 4) DK3WN GetKISS+ to forward telemetry (and the digipeater packets also) to Satnogs. 5) Rig is TS-2000 1k2 external TNC setting (menu 50F), TNC microHam DXP, 30 ele (15H/15V) circular Pol yagi, LNA and bandpass filter on the feeder. Same rig used for all LEO’s. 6) I also use the out-of-tree module (GNU radio developed by EA4GPZ for GreenCube https://github.com/daniestevez/gr-satellites/<https://url.emailprotection.link/?buEq4eyNl9NRYRhKUfm4VcAH7hYjpTyw9D9Ehl2sv…> in parallel to monitor the downlink. As regards the ACK message it is send only if you use Tx delay, however it is better to use Tx delay 0 for QSO to avoid unnecessary transmission by the bird (saving on-board power), with Tx delay 0 you will receive your own message as acknowledgement. Hope above may help all. 73 Jean Marc (3B8DU) Notice the user structuring his operation to save battery.

1 0

Github write permission
by Bill 18 Nov '22

18 Nov '22

All pacsat dev team members have write access to github /AMSAT-NA/pacsat. Let me know if you have issues. Bill

2 1

MRAM carrier and connections to Launchpad
by Rich Gopstein 18 Nov '22

18 Nov '22

https://photos.app.goo.gl/EQsRMdaacB7msysq5

2 1

Task List 11-17-2022
by Bill 18 Nov '22

18 Nov '22

1 0

Block Diagram - Pacsat Communicator
by Bob Stricklin 17 Nov '22

17 Nov '22

Attached is a first cut at a block diagram. Bob

3 3

Can I hold two Launchpads?
by Jonathan Brandenburg 17 Nov '22

17 Nov '22

Bill, If you can spare them, I'd like to keep two of the Launchpads for two Fox-Plus volunteers. But I understand if they end up all spoken for. Thanks! Jonathan -- Jonathan, KF5IDY

1 0

Pacsat Dev Meeting #4
by Bill 17 Nov '22

17 Nov '22

Pacsat Dev Meeting #4 Thu, Nov 17, 2022 7:00 PM - 8:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/976254469 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (872) 240-3212 - One-touch: tel:+18722403212,,976254469# Access Code: 976-254-469 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install Agenda: Discuss everyone's TMS570 Dev board, AX5043, and other parts needs. Set up parts shipping schedule. Review task lists. Bill

1 0

Basic software with FreeRTOS OS running on Launchpad
by Burns Fisher (AMSAT) 16 Nov '22

16 Nov '22

The "main" branch of the PacSatx repository now has code which uses FreeRTOS and runs on the LaunchPad. Rather than starting from scratch and doing a new OS port and adding some code to do a few things, I started from Golf-TEE and removed much of the stuff that relates to Golf-TEE. Even if you go back to the root of this repo, you will not find anything that is not ok to be fully open source. I left stuff in there that might be useful to PacSat. For example, there are I2c, SPI and CAN drivers, as well as device support code for a number of devices, including MRAM, temp sensors, serial port etc. You will find that there are four tasks started up in the OS: Console, CAN, Command, and Radio. Here is the general idea: 1) Console: This is the task that interacts with a user during debugging and testing phases. I've left in the entire typed command parsing but taken out a lot of commands. The serial line that is used for console is actually implemented by the N2Het. The Rx and Tx lines are on the outside row of the LaunchPad, pins 25 and 27. This is TTL levels at 38,400 baud. (Ha, don't ask which is tx and which is rx. I just reversed the lines till it worked). You need a ground, too naturally. 2) CAN: Because CAN messages can arrive asynchronously, the easiest way to implement them is with a separate task. It works together with canDriver.c to send and receive CAN messages and to dispatch the received messages. Often these received messages on Golf will be telemetry, so they are dispatched to a telemetry collection task. That is removed to simplify the PacSat code. I don't know if we will use CAN at all, but the basic code is there. 3) Radio: This task drives the AX5043 both for transmitting BPSK telemetry and receiving AFSK commands. You will also see that this task can be set up as either a receiver or a transmitter. On Golf, it depends which of the two TMS570 processors it is running on. We have to design how this works for pacsat. The tasks that generate telemetry have been removed, so you will see a few dead-end calls that are supposed to fetch telemetry data to give to the 5043 on the transmit side. On the receive side, the AFSK data received is handed off to the command task. 4) Command: This task gets a message from the Radio task when there is command data available. Its job is to decode and validate the command and then to execute it. Note that I often say "encrypt" or "decrypt" for commands. In fact, the commands themselves are not encrypted. However, they are validated by the standard method of transmitting an encrypted digest of the command and then decrypting the digest and comparing it against the digest of the received command. (This is pretty much the same way that downloading Windows upgrades works). The encryption/decryption requires a key. There is a default key that will be used normally. When we are approaching flight time, we will generate a "real" key to match the "real" command software and load it into the MRAM where the software can read it, but no human can. My proposed next plan, subject to whatever we as a group decide, is to determine how to attach the AX5043 Rasp Pi shield to the LaunchPad and try to ensure that there is code both to receive AFSK and to transmit BPSK. Eventually, we will need to change this to AX.25 or whatever we decide to use for our message protocol, but at least we will know how to hook up the 5043 electrically and have some code to do a bit of testing. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

5 13

Component Inventory
by Jonathan Brandenburg 16 Nov '22

16 Nov '22

Bill, Here is the inventory of components currently in my possession that may be relevant to your team. These admittedly may be shared with other teams (e.g., the AX5043 chips for the RT-IHU) but much of this is earmarked for you: 9 of LAUNCHXL2-TMS57012 LaunchPad development boards 9 of V1.3 AX5043 Raspberry Pi PCBs. These are the unpopulated boards that host an AX5043. The connector fits the Raspberry Pi but I've jumpered it to the LaunchPad with success. 250 of AX5043 chips 2 of solder stencils for the V1.3 AX5043 Raspberry Pi PCBs 2 of PCB "jigs" for holding a PCB when applying solder paste (these are pieces of plastic that look like a bit like a carpenter's square) I also intend to order more LaunchPads to receive them when in stock but I've been waiting for my AMSAT credit card (it's a bit delayed). Jonathan -- Jonathan Brandenburg, KF5IDY

1 0

FYI Software state:
by Burns Fisher (AMSAT) 12 Nov '22

12 Nov '22

Right now, the software in the PacSatx dev will build and load into a LaunchPad. The OS is running, as is the N2HET-based serial port. I get a lot of error messages out because of things that are NOT there (like MRAM). Over the next few days (weeks?) I'll try to get things cleared up so that it is actually usable for PacSat experiments. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

2 1

KiCAD design files for GOLF-T
by Bob Stricklin 11 Nov '22

11 Nov '22

Hello Jonathan, You have been suggested as a possible conduit to obtain some KiCAD files on the GOLF-T. I would like to obtain copies of the version 1.0 an 1.1 designs for my reference. Would you look at this and let me know the best path. You could email them to me, move the to some GitHub, or I could come meet you for lunch and get a thumb drive. I would not be posting any of these files to any public locations. I plan to use these files to get board size layouts and pull parts of the layout out of the original to start a layout/straw-man of a pacsat board. From Zach: These files are done in the same version of KiCAD as the Booster Pack, and are located in the GOLF-T Git repository. We currently have version 1.0, which is of historic interest only, and the current version 1.1 in that repo. There is an internal Git repository, which is not public. This holds all versions of the RT-IHU design. Jonathan should be able to get you access to this and handle the issues related to ITAR/EAR coverage of that design. Bob

2 1

Finally---the software repo is now non-private
by Burns Fisher (AMSAT) 10 Nov '22

10 Nov '22

I have managed (thanks to some help from a friend) to remove all the old history from the repository I was working on (which included all the Golf code if you looked correctly), so I have now created a repository on gitHub AMSAT-NA/PacSatx which is open to viewing by all. As requested, I included a Documentation directory and put Chris' doc in it. A couple things: 1) I wanted to have everyone get a chance to look and approve what I did with the repo structure, but the next step will be to delete the AMSAT-NA/pacsat repo (which has the identical documenation) and rename PacSatx to PacSat (or whatever we decide). I did not want to delete it for now. 2) I'd have preferred to have two directory trees, code and documentation instead of having docs branching off the code tree. However, I could not get TI CCS (Code Composer Studio) to be happy with that. I'm sure it is possible but it would have taken a lot of work. 3) Feel free to clone this repository to take a look. I think the syntax on your local machine would be git clone https://github.com/AMSAT-NA/PacSatx.git 4) This code does not build successfully. It mostly compiles but there are lots of undefined references, which I will fix. I just wanted to make it available ASAP. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

3 3

Filesystem for pacsat
by Corey Minyard 10 Nov '22

10 Nov '22

I've started a google doc with questions about requirements and some info. These are things to thing about. You should be able to comment on the file. https://docs.google.com/document/d/1zwUKF2Fvk-0GLdPCOtbPxN6IyA6w_4HPR1ILC6w… I'll also paste it in here, maybe that's easier to work with. Filesystem for Pacsat Does it need to be hierarchical? Robust in the event of failures and errors * Does it need data integrity (as an option?) or just metadata integrity? * File system checking? * Journaling? * Any sort of atomicity requirement? * Checksums on data/metadata? * Memory scrubbing? Performance requirements? Any security/authentication requirements? Block oriented? Are there any non-block oriented filesystems? Perhaps a database would be a better choice? Some existing filesystems: https://github.com/littlefs-project/littlefs https://github.com/joembedded/JesFs https://github.com/NVSL/linux-nova

2 1

Another AX5043 board available
by Burns Fisher (AMSAT) 09 Nov '22

09 Nov '22

I just retrieved an AX5043 board (for the Pi) from a local guy who was going to volunteer but never had time. So now I have two. If anyone wants one without have to assemble it, let me know and I'll ship it. BTW, I had forgotten this, but Alan Johnson, VPEduation, had his students at Villanova assemble some of these. If we want more of these oards, we might check with him to see if he has more or has students to assemble them. I am in contact with him regularly, so I'll ask him about the situation. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

2 4

Pacsat-dev mailing list info
by Bill Reed 08 Nov '22

08 Nov '22

Here are my thoughts about the pacsat-dev mailing list: This is a private list for members of the pacsat-dev team. I have worked on past Amsat projects where email and meeting resources were consumed by interested, sometimes helpful, but significantly time wasting discussions of various opinions. ( Remember, opinions are like assholes, everybody has one. ) These discussions were interesting but not helpful in completing our project. I encourage those discussions on the pacsat(a)amsat.org list. The pacsat(a)amsat.org mailing list is open to everyone. I encourage dev team members in participating on the pacsat list. Please do not send a single email to both lists. A reply by someone could create problems for the pacsat-dev list. Thoughts about the dev-team: Current members are "Bill Reed" <bill(a)brconnect.com> <https://mailman.amsat.org/postorius/lists/pacsat-dev.amsat.org/members/opti…> bstrick(a)n5brg.com <https://mailman.amsat.org/postorius/lists/pacsat-dev.amsat.org/members/opti…> "Burns Fisher" <wb1fj(a)fisher.cc> <https://mailman.amsat.org/postorius/lists/pacsat-dev.amsat.org/members/opti…> chrisethompson(a)gmail.com <https://mailman.amsat.org/postorius/lists/pacsat-dev.amsat.org/members/opti…> glasbrenner(a)mindspring.com <https://mailman.amsat.org/postorius/lists/pacsat-dev.amsat.org/members/opti…> "Mark Hammond" <marklhammond(a)gmail.com> <https://mailman.amsat.org/postorius/lists/pacsat-dev.amsat.org/members/opti…> "Jim" <wa4cwi(a)bellsouth.net> <https://mailman.amsat.org/postorius/lists/pacsat-dev.amsat.org/members/opti…> "Corey Minyard" <minyard(a)acm.org> <https://mailman.amsat.org/postorius/lists/pacsat-dev.amsat.org/members/opti…> "Rich Gopstein (KD2CQ)" <rich(a)ourowndomain.com> <https://mailman.amsat.org/postorius/lists/pacsat-dev.amsat.org/members/opti…> jbrandenburg(a)amsat.org <https://mailman.amsat.org/postorius/lists/pacsat-dev.amsat.org/members/opti…> Members of the pacsat dev team should attend most dev team meetings and be working on some aspect of the pacsat project. The exceptions to this rule are Glasbrenner and Hammond from Amsat operations. We need "operations feedback". They represent our "customer" We need their feedback whenever possible. Anyone can join the dev team, they just need to be doing something to help. Does this structure make sense to everyone? Comments? Bill

4 3

AX5043 build
by Bill Reed 08 Nov '22

08 Nov '22

Jim, What filter frequencies do you plan to implement? Do you need the parts for those frequencies? bill

1 0

Dev meeting #4
by Bill Reed 08 Nov '22

08 Nov '22

My next surgery has been scheduled for Thur, Nov 10. I will not schedule a meeting for that day. Next meeting will be on Nov 17. In the meantime, I encourage discussion on the pacsat-dev(a)amsat.org mail list. Bill

1 0

My thoughts about power, host satellite etc for PacSat
by Burns Fisher (AMSAT) 04 Nov '22

04 Nov '22

Last night at the pacsat developers meeting, we had a good conversation about what we were aiming for. This started out with the question "what is our power budget", and the answer seems to be pretty tightly bound to the satellite that is hosting us, and what else that satellite is carrying. It seems to me that thinking about it this way gives us a round and round series of thoughts: What is our power budget?->What satellite will we fly on->Unknown but we can guess how much power is available on a 3U or a 1U->But that depends on what else is in the satellite, is it only us?->What is our power budget :-) My (current) thought is that pacsat is in the ASCENT program, which is specifically designed for "trying things out" without necessarily having a flight in mind for them. So I would suggest that our first job is to just get SOMETHING that works with a TMS570 and 4 AX5043s. Then we will have a very good idea how much power we use under different circumstances (fewer TMS570s, slower processor, etc) and for that matter whether we would be better off with an STM32L lower power processor. In all cases, we should design for flexibility. As an example, don't do anything that absolutely REQUIRES 4 AX5043 chips and don't do anything that REQUIRES unique capabilities in a TMS570. Then we should of course be prepared to make the required modifications for a specific flight. (Example: We are Jonathan's 5043 Pi boards; the RT-IHU is the specific implementation of those and the TMS570 for Golf.) This is quite different from a typical approach where initially software is given many requirements and a date, and then (usually) the requirements turn out to be unachievable within the given time and cutbacks have to be hacked out. But I think it is appropriate for the organization and the program we are in. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

2 1

New PacSatSW Repo
by Jonathan Brandenburg 04 Nov '22

04 Nov '22

Howdy, Burns! I think I see a new PacSatSW repo. Does that need to be made "public" for the EAR publicly available carveout? Thanks! Jonathan -- Jonathan Brandenburg, KF5IDY

2 2

Temporary github repo created
by Burns Fisher (AMSAT) 04 Nov '22

04 Nov '22

Hi, I've just created a repo on gitHub where I am going to start with the Golf software and essentially create a pacsat port of the RTOS and leave in some of the AX5043 and other device support code. I know that we decided last night to use the same git repository for both documents and code. However, just to avoid complexity and screw-ups (on my part) I have temporarily created a temporary private repo called PacSatSW. There were a lot of twisty passages all alike that I had to negotiate in order to get things set up both on my own CCS IDE, my own git repos and github, this was the easiest way to be able to do multiple tries without losing the documents. I will fix it eventually, but for now I just wanted you to know why I did what we explicitly decided not to do last night. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

2 2

GreenCube
by Jim McCullers 04 Nov '22

04 Nov '22

https://www.s5lab.space/index.php/greencube-home/

2 1

Here is the TI Launchpad that Jonathan has
by Burns Fisher (AMSAT) 04 Nov '22

04 Nov '22

LAUNCHXL2-TMS57012 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Dev mtg 3 invite
by Bill 03 Nov '22

03 Nov '22

Pacsat Dev meeting #3 Thu, Nov 3, 2022 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/711190389 This meeting is locked with a password: devmtg3 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (312) 757-3121 - One-touch: tel:+13127573121,,711190389# Access Code: 711-190-389 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install Agenda: Github and amsat mail changes Customer/power design considerations

1 0