- pacsat-dev - mailman.amsat.org

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