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

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

17 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 16 Nov '22

16 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 16 Nov '22

16 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