Task

We need to improve how IP address resolution is done for sending data to Iridium Pilot in order to make the code more maintainable and readable.

Acceptance

mcp/communications/pilot.c:71 calls initBITsender(), defined in ./common/bitserver.c. bitserver.c:340 calls gethostbyname() on strings from the array pilot_target_names, defined in blast_config/command_list.c:53. This function relies on the /etc/hosts file mapping these hostnames to IP addresses. If the /etc/hosts file is wrong, or there are no hosts on the network at those addresses (e.g. they are disconnected), mcp segfaults. The names hardcoded into the array are Lord of the Rings characters and highbay. Cool, but these names should be changed to more closely represent the intended receivers of the data.

1. Make a copy of an old flight computer's /etc/hosts file and attach it to this issue for posterity. We will use the IP addresses later to confirm for CSBF which IPs we will reserve for TIM usage, so the routing table from the balloon network to the outside world can be set up appropriately.
2. Interview Ian or a former BLAST team member to find out what the options really should be in practical terms. Ice high bay? Palestine remote operations center? What about the other two?
3. Change pilot_target_names to reflect the actual recipients.
4. Change /etc/hosts to match in your development environment and confirm that hostname resolution still works. Build and run mcp and attach relevant lines of logging output that show hostname resolution succeeding.

Describe the bug

test_EVTM_loop_body_filelinklist failing in my dev environment.

Test failure (hash serial mismatch) on dev branches seem to occur when I have something in /data/etc/linklists/. Deleting the file causes the code to have fallback behavior such that test passes.

vagrant@fc1:/media/sf_TIMflight/mcp/build$ ctest -VV -R evtm
UpdateCTestConfiguration  from :/media/sf_TIMflight/mcp/build/DartConfiguration.tcl
UpdateCTestConfiguration  from :/media/sf_TIMflight/mcp/build/DartConfiguration.tcl
Test project /media/sf_TIMflight/mcp/build
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
    Start 1: evtm

1: Test command: /media/sf_TIMflight/mcp/build/communications/tests/test_evtm "1"
1: Test timeout computed to be: 10000000
1: [==========] Running 8 test(s).
1: [ RUN      ] test_EVTM_setup_config_LOS
1: channels_tng.c:482 (channels_initialize):Allocating 1052 bytes for 367 channels at 1HZ
1: channels_tng.c:482 (channels_initialize):Allocating 855 bytes for 320 channels at 5HZ
1: channels_tng.c:482 (channels_initialize):Allocating 201 bytes for 77 channels at 100HZ
1: channels_tng.c:482 (channels_initialize):Allocating 234 bytes for 68 channels at 200HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 244HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 488HZ
1: Hash with entry "sc2_dynamic_hp". Trying key 16301
1: channels_tng.c:516 (channels_initialize):Successfully initialized Channels data structures
1: Total of 1 linklists loaded from "/data/etc/linklists/"
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:91 (EVTM_setup_config):Setting up EVTM 0, 239.255.0.1
1: [       OK ] test_EVTM_setup_config_LOS
1: [ RUN      ] test_EVTM_setup_config_TDRSS
1: channels_tng.c:482 (channels_initialize):Allocating 1052 bytes for 367 channels at 1HZ
1: channels_tng.c:482 (channels_initialize):Allocating 855 bytes for 320 channels at 5HZ
1: channels_tng.c:482 (channels_initialize):Allocating 201 bytes for 77 channels at 100HZ
1: channels_tng.c:482 (channels_initialize):Allocating 234 bytes for 68 channels at 200HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 244HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 488HZ
1: channels_tng.c:516 (channels_initialize):Successfully initialized Channels data structures
1: Total of 1 linklists loaded from "/data/etc/linklists/"
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:91 (EVTM_setup_config):Setting up EVTM 1, 239.255.0.2
1: [       OK ] test_EVTM_setup_config_TDRSS
1: [ RUN      ] test_EVTM_setup_config_fails
1: channels_tng.c:482 (channels_initialize):Allocating 1052 bytes for 367 channels at 1HZ
1: channels_tng.c:482 (channels_initialize):Allocating 855 bytes for 320 channels at 5HZ
1: channels_tng.c:482 (channels_initialize):Allocating 201 bytes for 77 channels at 100HZ
1: channels_tng.c:482 (channels_initialize):Allocating 234 bytes for 68 channels at 200HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 244HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 488HZ
1: channels_tng.c:516 (channels_initialize):Successfully initialized Channels data structures
1: Total of 1 linklists loaded from "/data/etc/linklists/"
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:87 (EVTM_setup_config):Invalid evtm type 1511
1: [       OK ] test_EVTM_setup_config_fails
1: [ RUN      ] test_EVTM_setup_config_fails_initBITSender
1: channels_tng.c:482 (channels_initialize):Allocating 1052 bytes for 367 channels at 1HZ
1: channels_tng.c:482 (channels_initialize):Allocating 855 bytes for 320 channels at 5HZ
1: channels_tng.c:482 (channels_initialize):Allocating 201 bytes for 77 channels at 100HZ
1: channels_tng.c:482 (channels_initialize):Allocating 234 bytes for 68 channels at 200HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 244HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 488HZ
1: channels_tng.c:516 (channels_initialize):Successfully initialized Channels data structures
1: Total of 1 linklists loaded from "/data/etc/linklists/"
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:91 (EVTM_setup_config):Setting up EVTM 0, 239.255.0.1
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:98 (EVTM_setup_config):initializing BITSender did not work for EVTM 239.255.0.1: check above error msg
1: [       OK ] test_EVTM_setup_config_fails_initBITSender
1: [ RUN      ] test_EVTM_loop_body_nominal
1: channels_tng.c:482 (channels_initialize):Allocating 1052 bytes for 367 channels at 1HZ
1: channels_tng.c:482 (channels_initialize):Allocating 855 bytes for 320 channels at 5HZ
1: channels_tng.c:482 (channels_initialize):Allocating 201 bytes for 77 channels at 100HZ
1: channels_tng.c:482 (channels_initialize):Allocating 234 bytes for 68 channels at 200HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 244HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 488HZ
1: channels_tng.c:516 (channels_initialize):Successfully initialized Channels data structures
1: Total of 1 linklists loaded from "/data/etc/linklists/"
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:140 (EVTM_loop_body):EVTM 0, 239.255.0.1: serial is 0x65f31048 (ensure serial hashtables match b/w FC and GS)
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:142 (EVTM_loop_body):EVTM 0, 239.255.0.1: linklist set to "all_telemetry.ll"
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:140 (EVTM_loop_body):EVTM 1, 239.255.0.2: serial is 0x65f31048 (ensure serial hashtables match b/w FC and GS)
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:142 (EVTM_loop_body):EVTM 1, 239.255.0.2: linklist set to "all_telemetry.ll"
1: [       OK ] test_EVTM_loop_body_nominal
1: [ RUN      ] test_EVTM_loop_body_allframe
1: channels_tng.c:482 (channels_initialize):Allocating 1052 bytes for 367 channels at 1HZ
1: channels_tng.c:482 (channels_initialize):Allocating 855 bytes for 320 channels at 5HZ
1: channels_tng.c:482 (channels_initialize):Allocating 201 bytes for 77 channels at 100HZ
1: channels_tng.c:482 (channels_initialize):Allocating 234 bytes for 68 channels at 200HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 244HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 488HZ
1: channels_tng.c:516 (channels_initialize):Successfully initialized Channels data structures
1: Total of 1 linklists loaded from "/data/etc/linklists/"
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:140 (EVTM_loop_body):EVTM 0, 239.255.0.1: serial is 0x65f31048 (ensure serial hashtables match b/w FC and GS)
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:142 (EVTM_loop_body):EVTM 0, 239.255.0.1: linklist set to "all_telemetry.ll"
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:140 (EVTM_loop_body):EVTM 1, 239.255.0.2: serial is 0x65f31048 (ensure serial hashtables match b/w FC and GS)
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:142 (EVTM_loop_body):EVTM 1, 239.255.0.2: linklist set to "all_telemetry.ll"
1: [       OK ] test_EVTM_loop_body_allframe
1: [ RUN      ] test_EVTM_loop_body_transmit_size_zero
1: channels_tng.c:482 (channels_initialize):Allocating 1052 bytes for 367 channels at 1HZ
1: channels_tng.c:482 (channels_initialize):Allocating 855 bytes for 320 channels at 5HZ
1: channels_tng.c:482 (channels_initialize):Allocating 201 bytes for 77 channels at 100HZ
1: channels_tng.c:482 (channels_initialize):Allocating 234 bytes for 68 channels at 200HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 244HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 488HZ
1: channels_tng.c:516 (channels_initialize):Successfully initialized Channels data structures
1: Total of 1 linklists loaded from "/data/etc/linklists/"
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:140 (EVTM_loop_body):EVTM 0, 239.255.0.1: serial is 0x65f31048 (ensure serial hashtables match b/w FC and GS)
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:142 (EVTM_loop_body):EVTM 0, 239.255.0.1: linklist set to "all_telemetry.ll"
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:140 (EVTM_loop_body):EVTM 1, 239.255.0.2: serial is 0x65f31048 (ensure serial hashtables match b/w FC and GS)
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:142 (EVTM_loop_body):EVTM 1, 239.255.0.2: linklist set to "all_telemetry.ll"
1: [       OK ] test_EVTM_loop_body_transmit_size_zero
1: [ RUN      ] test_EVTM_loop_body_filelinklist
1: [  ERROR   ] --- 0x65f31048 != 0xa235fc18
1: /media/sf_TIMflight/mcp/communications/tests/test_evtm.c:81: error: Check of parameter serial, function __wrap_setBITSenderSerial failed
1: /media/sf_TIMflight/mcp/communications/tests/test_evtm.c:244: note: Expected parameter declared here
1: [   LINE   ] --- /media/sf_TIMflight/mcp/communications/tests/test_evtm.c:81: error: Failure!
1: channels_tng.c:482 (channels_initialize):Allocating 1052 bytes for 367 channels at 1HZ
1: channels_tng.c:482 (channels_initialize):Allocating 855 bytes for 320 channels at 5HZ
1: channels_tng.c:482 (channels_initialize):Allocating 201 bytes for 77 channels at 100HZ
1: channels_tng.c:482 (channels_initialize):Allocating 234 bytes for 68 channels at 200HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 244HZ
1: channels_tng.c:482 (channels_initialize):Allocating 4 bytes for 1 channels at 488HZ
1: channels_tng.c:516 (channels_initialize):Successfully initialized Channels data structures
1: Total of 1 linklists loaded from "/data/etc/linklists/"
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:140 (EVTM_loop_body):EVTM 0, 239.255.0.1: serial is 0x65f31048 (ensure serial hashtables match b/w FC and GS)
1: /media/sf_TIMflight/mcp/communications/tests/../evtm.c:142 (EVTM_loop_body):EVTM 0, 239.255.0.1: linklist set to "z_file_dl.ll"
1: [  FAILED  ] test_EVTM_loop_body_filelinklist
1: [==========] 8 test(s) run.
1: [  PASSED  ] 7 test(s).
1: [  FAILED  ] 1 test(s), listed below:
1: [  FAILED  ] test_EVTM_loop_body_filelinklist
1: 
1:  1 FAILED TEST(S)
1/1 Test #1: evtm .............................***Failed    0.06 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.07 sec

The following tests FAILED:
	  1 - evtm (Failed)
Errors while running CTest

To Reproduce
Steps to reproduce the behavior:

1. In dev environment, sudo rm /data/etc/linklists/*
2. Build flight code with tests enabled
3. Observe passing tests
4. In TIMflight root: sudo cp blast_config/linklists/z_file_dl.ll /data/etc/linklists/
5. ctest -VV
6. Test fails

Expected behavior
Test fails if /data/etc/linklists/ doesn't exist. Test passes if z_file_dl.ll exists and is in /data/etc/linklists/.

Screenshots
N/A

Environment info (please complete the following information):

• PC hardware: TIMflight vagrant VM
• OS: Ubuntu 20.04.5 LTS
• Software version: 5392c21

Additional context
Notable: this passes GitHub Actions testing because the GitHub Actions runner doesn't have /data/etc/linklists/ dir. Maybe the fallback behavior making this pass is the right thing here? But because it doesn't exist, I don't think the behavior that the test is intended to test is being exercised.

Contents of my z_file_dl.ll file:

# This is a special linklist for downlinking files at full telemetry rate
# The rate specifies the max size before checksum

file_block B 400

Task

A few TODOs are left in mcp and groundhog from the EVTM development. Removing deprecated telemetry threads; changing the CommandData linklist names to the independent names for the links that will be used during flight. This issue is a reminder to remove or change that code pre-FTS test flight.

Task

Magic number 250 was valid for BLAST-TNG, is no longer valid for TIM.

./mcp/commanding/commands.c:

        case antisun:  // turn antisolar (az-only)
            sun_az = PointingData[i_point].sun_az + 250;  // point solar panels to sun
            NormalizeAngle(&sun_az);

            CommandData.pointing_mode.nw = CommandData.slew_veto;
            CommandData.pointing_mode.mode = P_AZEL_GOTO;
            CommandData.pointing_mode.X = sun_az;   // az
            CommandData.pointing_mode.Y = PointingData[i_point].el;   // el
            CommandData.pointing_mode.vaz = 0.0;
            CommandData.pointing_mode.del = 0.0;
            CommandData.pointing_mode.w = 0;
            CommandData.pointing_mode.h = 0;
            break;

Find the correct new value. Replace the magic number with a named (const) variable defined in a sensible place.

Acceptance

Contemplate a way to test this, showing the contents of the CommandData struct before/after calls to SingleCommand() to verify that 250 isn't being used anymore (testing by inspection being the bare minimum). Overachievers will spin up a unit test that can be later adapted to check more parts of these giant switch cases.

Details

250 deg, expressing the angular offset in azimuth of the solar panel array from boresight CCW viewed from above (i.e. heading west of boresight) is hardcoded. Replace it with a named constant that reflects the correct position of TIM's solar panels, and put the constant somewhere that makes sense.

Contact AJ Corso, James Augirre, or Justin Bracks for solar panel info.

in derived.c the current sensor channels are currently piping in raw ADC counts instead of the appropriate converted voltage channels. This is due to a typo where the "in" channels are in all lower case, rather than all capitals.

example:
LINCOM("Current_fc1", "current_fc1", 5, CURR_LOOP_OFFSET),

solution:
LINCOM("Current_fc1", "CURRENT_FC1", 5, CURR_LOOP_OFFSET),

Voltage monitoring also has the same issue:

example:
LINCOM("Outer_frame_voltage_1", "outer_frame_vm_1", 10, 0),

solution:
LINCOM("Outer_frame_voltage_1", "OUTER_FRAME_VM_1", 10, 0),

This needs to be done for all current channels and also the voltage monitoring channels.

Task

In order to speed up development and ensure telemetry configs are synced between version controlled files and files on the flight computer, we need to attempt to rsync from TIMflight/blast_config/linklists/ and TIMflight/blast_etc/ folders into the relevant directories on the flight computers.

Acceptance

CMake updated to accomplish the stated goals, but must be tolerant to no flight computers being present on the network.

Details

See CMake install tasks at bottom of mcp/CMakeLists.txt. Maybe a custom function? See various install scripts at toplevel of TIMflight repo, too.

Task

We need to update gps.c in order to give mcp accurate LAT/LON data in the absence of a CSBF GPS.

Acceptance

Follow the gpsd client architecture to connect to a running instance of gpsd, and query it for the latest info from the daemon.

When complete, the module shall continuously try to query the daemon for LAT/LON data. When the daemon responds, it shall update GPSData->latitude, GPSData->longitude, and GPSData->is_new (NOT gps_info, which is unused in mcp) with the LAT/LON in degrees.

Details

gpsd has kindly provided an example client in C: https://gpsd.gitlab.io/gpsd/gpsd-client-example-code.html
Copy as much as possible, with attribution.

In order to use the gpsd client API, which was installed when we installed gpsd from apt, you will need to link against lgps by editing the CMake.

GPSData is useful for pointing.c, in that it allows us to know our location if the SIP GPS data is not present.

Describe the bug
If we upgrade soem, many functions in ec_motors.c will break. Anything that calls

• ec_SDOwrite8()
• ec_SDOwrite16()
• ec_SDOwrite32()
  will break, because legit distributions of soem do not provide these convenience functions. It seems they were added after downloading.

To Reproduce
Steps to reproduce the behavior:

1. Go to ./external_libs/soem/soem/ethercatcoe.c
2. Scroll down to 1370
3. See functions that we have
4. Compare against contemporary version
   https://github.com/OpenEtherCATsociety/SOEM/blob/6afd2f50cc4266527fc0e0b526e57338c2129fb6/soem/ethercatcoe.c

Expected behavior
mcp either provides these convenience functions in its own code, for instance something that already needs to link against soem, like ec_motors.c, or stops using ec_SDOwrite[8,16,32]() in favor of ec_SDOwrite().

Environment info (please complete the following information):

• PC hardware: any
• OS: any
• Software version b3bbc57

Additional context
I determined that soem doesn't provide ec_SDOwrite[8,16,32]() functions by looking at the state of the repo where the file header date first matches the one we have.

https://github.com/OpenEtherCATsociety/SOEM/blob/6afd2f50cc4266527fc0e0b526e57338c2129fb6/soem/ethercatcoe.c

The newest version doesn't supply them either.

Describe the bug
mcp does not receive properly formatted gyro packets unless the flight computer has been freshly booted. Upset events (gyro power loss, stopping and restarting mcp) cause gyro data to be seen as garbage by mcp. mcp detects this and disconnects the offending gyro ad infinitum.

To Reproduce

0. Set up some means to observe gyro data, either via ground station TM, or by uncommenting dsp1760.c:309 (where it prints out raw gyro xyz, temp, status, etc. data)
1. Reboot flight computer
2. Log in
3. Run any version of mcp: sudo ./mcp -x
4. See gyro data
5. Cause an upset event (see above): halt mcp: Ctrl+C. Wait for it to stop on its own, if you're feeling nice.
6. sudo ./mcp -x
7. Observe mcp attempt to connect to gyros, warn of garbage in data stream, and repeat with longer and longer reconnect times.

Other upset events that can cause this: power cycling the gyros while mcp is running, starting mcp with gyros off, then turning them on, or stopping mcp in a debugger...seemingly anything else that vaguely has to do with the gyro serial buffer potentially filling up, or the data stream being interrupted?

Expected behavior
mcp resumes reading from gyros after interruptions as designed and written.

Screenshots
Gyro healthy:

[...]
-Sep-22-23 00:30:52.833- Schedu: dsp1760.c:309 (dsp1760_process_data):Gyro0: x_raw=857850152, y_raw=-1286864080, z_raw=-1287491338, reserved = 778c0ed0, status=7, seq=b, temp=44, crc=cb670257
-Sep-22-23 00:30:52.833- Schedu: dsp1760.c:356 (dsp1760_process_data):OK->Buffer 0 length 0, size_of(dsp1760_std_t)=36-> OK
-Sep-22-23 00:30:52.834- Schedu: dsp1760.c:309 (dsp1760_process_data):Gyro0: x_raw=866449050, y_raw=873701749, z_raw=-1278330828, reserved = 778c0ef4, status=7, seq=c, temp=44, crc=56edefc7
-Sep-22-23 00:30:52.834- Schedu: dsp1760.c:356 (dsp1760_process_data):OK->Buffer 0 length 0, size_of(dsp1760_std_t)=36-> OK
^CClosing MCP with signal 2

Gyro failure:

[... more messages showing buffer length going up ...]
-Sep-22-23 00:30:56.876- Schedu: dsp1760.c:350 (dsp1760_process_data):Buffer 0 length 73, size_of(dsp1760_std_t)=36
*Sep-22-23 00:30:56.876* Schedu: dsp1760.c:352 (dsp1760_process_data):Disconnecting Gyro Box 0 garbage in stream (multiple-access?)
-Sep-22-23 00:30:56.876- Schedu: dsp1760.c:234 (dsp1760_disconnect):Will attempt to reconnect to Gyro box 0 every 4 seconds
[...]

Environment info (please complete the following information):

• PC hardware: ARK-1551 fc2
• OS: Ubuntu 20.04.6.4 Server
• Software version: any

Additional context

Inspection of buffer memory shows that the data in the buffer is indeed "garbage", although there appears to be some structure to the garbage, as if it were gyro packets that had been shifted by a bit or several. Not obvious how, though.

What I've tried:

• Flight software fixes/workarounds
  • Uncomment activate_921k_clock(i);, no effect
  • Try ph_bufq_consume_bytes to empty the phenom async serial buffer on reconnect, even though dsp1760_disconnect destroys the buffer "object" and dsp1760_connect_gyro always creates a new one
• Kernel and /sys/ level fixes/workarounds
  • Verify baudrate was set correctly: sudo stty -F /dev/ttyGYRO0 after a run of mcp, see 921600
  • Remove and reconnect PCI device that handles serial I/O (LPC, low pin count ISA bridge): echo '1' | sudo tee /sys/bus/pci/devices/0000\:00\:1f.0/remove, then echo '3' | sudo tee /sys/bus/pci/rescan
  • Device tree ID found by lspci -vv
  • N.B.: it's unclear (read: poorly documented) which power state the device enters when this happens; is the power removed from the device? Are address/memory spaces on the device cleared? Who knows!
• Hardware-level workarounds
  • Connecting the gyros to the FC via their included RS-422 to USB adapter results in expected behavior, ruling out the gyros themselves as a problem.
  • An Arduino programmed to spew prefabbed gyro packets (with checksums!) recovers properly after hotplugging and Arduino reset button presses, and mcp restarts. This is also serial via USB, though. This rules out the flight software being intolerant of upset events, as does its use on BLAST-TNG.
  • Double-verified that the expected behavior exists when gyros are plugged into the old ARK-2150L FC and upset.

All of this points to either a kernel-level or hardware-level problem with the serial I/O card on the ARK-1551, which I have not been able to diagnose.

Task

During integration at FTS, some thermistor mappings have changed from the original spreadsheet I had made (due to discovering some routing/crimping problems and finding that some extra thermistors work). This changes some of the modifications from #115 ; this issue serves as a reminder to fix this pre-FTS test flight.

https://docs.google.com/spreadsheets/d/1KdtDNa9JTKtr3wB2hA-NPOL4V7alAPZz4IKeI48_CTc/edit?pli=1&gid=936198727#gid=936198727

Task

We need to allow CommandData.disable_az and CommandData.disable_el to be on by default before flight.

Acceptance

CommandData.disable_az = 0;
CommandData.disable_el = 0;

Details

These are overwritten if a prev_status file exists.

See title.

Task

Post test flight we need to take the commands, variables, and base code found in (not exclusive...):
inner_frame_power.c/h
outer_frame_power.c/h
motor_box_power.c/h
commands.c
command_struct.h
command_list.h
command_list.c
tx_struct_tng.c

and re-map them from the test flight configuration to the "more final" configuration once we have integrated most of the payload and assigned the outputs.

Acceptance

This is considered done once we have fully remapped the channels, data structures, and code base to the final flight configuration.

Task

We need to create and compile a unit test against a subset of mcp code to start getting some segments of it under test.

Acceptance

A tests dir is created in a module's directory, with a CMocka unit test that is conditionally compiled on the -DENABLE_TESTING=ON cmake flag. Any tests pass, it can even be one test.

Details

In order to compile and test some segment of code without compiling the entire mcp executable, we need to compile that segment as a library. In order to do that, the segment's dependencies need to be rooted out and specified to the linker. If the dependencies aren't able to be linked to, they will also need to be made libraries, or header include paths specified.

This is harder than it sounds due to the monolithic CMake structure of the mcp build target. This will be a lot of CMake work. The result may be messy, and that is ok - we need to expose dependency webs explicitly before we can begin untangling them.

Effectively, we are creating a linker seam here where there was none because of the CMake build structure. Once dependencies are resolved by the linker, a unit test can mock them out by linking to dummy versions as needed.

Task

#7 showed us that the flight computer uses a custom kernel build circa 2016. The prospects of reproducing this from scratch are grim, and the risks of being unable to do so are unknown. To mitigate, create an image of the entire filesystem (including boot partitions, etc.) of a flight computer and figure out a way to store it safely.

Acceptance

Physical media with FC image exists. Must be capable of relatively long term stable storage.

Offsite (cloud) backup exists with access given to more than one collaborator.

Document process steps used and access instructions to get at an image in case we need it.

Details

fc1 is at Penn, fc2 is at U of A. Access Penn through PennKey (see James Aguirre) or TeamViewer (see James Aguirre). Access U of A through physical access (Ian Lowe). Due diligence would have us compare the OS versions and kernel builds to see if there are any differences.

The OCC (operations control center) in Palestine/maybe Ft. sumner is where our groundstations will be plugged into the CSBF internal network to receive data. We need to understand and document how the protocol for GSE receiving through groundhog then serves the data to the ROCC (remote operations control center). Presumably this is done with some sort of combination of Guaca/Mole/Groundhog, but we need to write down the protocol we expect to follow to do this, and figure out a way to test it.

To make refactoring easier, remove code that is no longer needed.

This may include empty directories, output/ascii files that shouldn't have been committed in the first place, or an entire executable's source code, if it's been superseded by something else. To limit scope, stay at the directory level (don't go file-by-file or line-by-line yet).

To do this, you will need to sit down with or interview Ian, James, or potentially other people who worked with the code.

With the pull request, provide the following information for each unit of code removed:

path/to/code/removed

• Purpose:
• Reason for removal:
• Actions taken:

Try to group changes into commits such that restoring whole units of code may be done by cherry picking one or two commits, without too much hunting.

Task

In order to make reading and maintaining code easier, the repo structure should have some logical organization that enables users to find specific modules and functions quickly. In order to avoid relearning, this should happen relatively soon, so users don't get too used to the current structure.

Avoid moving code between files (for now), try to keep reorganization at the directory level.

Acceptance

More folders than before, with better names

Details

Suggestions:

• Ground software
  • Separate by function or layer of TM/commanding stack
• Flight software
  • Separate configuration files, hardware interfaces, and algorithm code?
  • Separate motion control, detector readout, and telemetry?

Task

We need to trial an update to SOEM in order to test a ring topology in EtherCAT.

Acceptance

Update TIMflight SOEM directory to a download of the latest (compatible) version.

Details

Evan wrote about this problem here: https://github.com/tim-balloon/tim-logs/blob/main/ecm/lab_notebook_public.md#422023-timpublic-why-doesnt-my-ethercat-redundant-cable-topology-just-work

That post has some links to soem, where you can find versions to download. The update version must have ec_init_redundant().

Do this work in a clean dedicated branch, because it's possible this opens a can of worms or a portal to dependency hell, to mix metaphors.

Task

We need to be able to run code that exercises each path through the blast_config/command_list.c & blast_config/command_list.h > mcp/commanding/commands.c chain in order to verify that the mapping of commands -> enumeration -> action taken by mcp is consistent between them.

Acceptance

A unit test pretending to be an operator attempts to send all commands listed in the command list, and some kind of check is performed to see which ones terminated in a commands.c switch case and which ones did not. Document the results of the test in this issue, and create a new issue to clean up any findings, if necessary.

Details

You will likely need to work closely with @ianlowe13 to get started.

Bonus points: report on code coverage - is there any unreachable code even when we try to run all commands?

Task

gy az vel limit from a #define to a CommandData value and add commands

Acceptance

add a new member to commandData struct
move trigger check from the #define to that struct member
add default in commands.c
add commanding in commands.c/command_list.h/command_list.c

test!

Task

Multiple parts of the old star camera code will no longer be used. Clean them up.

Acceptance

• xsc*.c, .h files
• Old commands in commanding infrastructure
• Renaming away from "xsc" to make less confusing
• Add plumbing for commanding the star camera uncertainty floor
• Remove old telemetry channels

Details

N/A

Task

The older Debian Jessie operating system image we pulled off of the old flight computer, with its Linux 4.5.0blast kernel, is incompatible with the ethernet card in the new flight computer. In order to have the new flight computer talk to devices over ethernet, the old operating system needs to have an ethernet driver that is compatible with it's hardware.

Acceptance

New flight computer recognizes and loads kernel driver for ethernet adapter, as indicated by sudo lspci -knn output. Can ping other devices on network.

Document steps in text or .md file so it can be replicated if necessary, commit to TIMflight/docs.

Alternate ending: 1 week-ish of effort spent, but not possible to get Ethernet working with this config. Suggest an alternate path that will get us a newer flight computer with working Ethernet on the ice in a few years' time.

Details

• New flight computer model: Advantech ARK-1551
• Old flight computer model: Advantech ARK-2150
• Ethernet controller: Intel i210
• Intel Linux driver source download/install: Intel site

To access new flight computer: point of contact @JuzzBracks to get remote access to a new flight computer at Penn with the old Debian Jessie image running on it. @JuzzBracks will need to plug a USB-A to Ethernet adapter into a USB port and connect it to an accessible network for you. Perform network setup in /etc/network/interfaces for DHCP according to the docs to get the computer to connect to a network using the USB adapter.

What has been tried?

But don't let this list stop you from trying again.

• Manually install driver from vendor site

  • Download/unzip driver source from Intel from link above
  • Compile with make
  • Got errors: compiler flags are -Werror, and I don't know how to change that for this build system, so can't get past some warnings about implicit defines. I don't think it would work, even if I could; these kinds of errors suggest the driver code is incompatible with the system headers they are building against!
  • Tried several different driver versions with same results: latest, oldest available, random choice of a version in the middle

• Upgrade OS from Jessie to Stretch

  • Followed basically this guide, although the exact recorded details of all the twists and turns live on @evanmayer's computer in a Markdown doc.
  • Didn't solve the issue: apt updates didn't come with any new drivers, and the kernel was not updated, so no new kernel drivers.
  • Still could not build Intel driver

• Upgrade kernel version from 4.5.0blast to a newer, stretch-compatible one

  • Following these instructions
  • Picked out a kernel using sudo apt search linux-image
  • Installed a rt-ready newer kernel: sudo apt -t stretch-backports install linux-image-rt-amd64
  • This kernel comes with newer kernel drivers compatible with the ethernet card, so everything "just works"
  • HOWEVER, this is not the route we want to go in the short term, because it introduces unknown changes away from the flight-proven custom kernel, so this option is out of the picture

What might you try?

But don't let this list stop you coming up with something else.

• Connect to Internet and check for updated development headers in jessie backports repo:
  • sudo apt update
  • sudo apt search linux-headers
    • (note that the usual trick, sudo apt install linux-headers-$(uname -r) won't work here, because our uname -r displays the custom kernel version string, which won't be found in any remote apt list)
  • try to get some new headers with sudo apt install?
  • try to build the Intel driver, if that worked?

Misc. useful commands

• Get current OS info:
  • uname -a
  • lsb_release -a
• Get current network interfaces status:
  • ip addr
• Get info on what happened with Ethernet adapter devices on startup:
  • sudo dmesg | grep -i eth

Task

In order to get the best usage out of our onboard magnetometers, we need to check whether an up-to-date World Magnetic Model (WMM) is required. To the best of our knowledge, the version in mcp is from 2015, and is valid up to 2020. Find out what needs to be done to get the most recent WMM into mcp.

Acceptance

blast_etc/WMM.COF lookup table (?) updated if needed. Source file mcp/sensors/geomag2015.c updated if needed. Any code changes needed for compatibility completed. Not expected to unit test code in geomag2015.c or its successor, if an updated source file is provided by the WMM source, but some basic unit tests that mimic how we query for model data may be appropriate.

Details

TIM uses 3-axis vector magnetometer readings, comparing them to forecasts of Earth's magnetic field at a location on (above) Earth. This is one input to the attitude solution.

Access to WMM data seems to happen in mcp/pointing/pointing.c:MagConvert().

Task

On fc1 at UPenn, uname -v does not print a string with PREEMPT RT in it, as might be expected from a Red Hat or Ubuntu OS that has had an RT patch applied. Instead, it prints something like [...] 4.5.0blast [...].

Figure out another way to check if a flight computer's kernel is capable of scheduling processes with real-time priority to determine if the kernel has had the RT patch applied.

Acceptance

Evidence of RT kernel patch or ability to schedule processes with real-time priority provided. If no RT patch, follow-on issue created to patch all flight computer OSs.

Details

Access to the flight computer(s) is required. Ask James for UPenn, ask Ian for U Arizona.

Typical patch process seems to go like this: https://unix.stackexchange.com/questions/650320/installing-preempt-rt-kernel-on-ubuntu-20-04

Not sure off the top of my head the next easiest way to check.

@mxk62 said:

It's out of the scope of this ticket, but we may want to have a dedicated place for such generic macros. Now MAX(a, b) it is being defined in multiple places:

$ grep -inr '#define MAX(.*)' .
./common/include/FIFO.h:39:#define MAX(a, b) ((a) > (b) ? (a) : (b))
./common/include/bitserver.h:55:#define MAX(a, b) ((a) > (b) ? (a) : (b))
./common/include/blast.h:173:#define max(a, b) ((a) >= (b) ? (a) : (b))
./common/logger.c:41:#define MAX(a, b) ((a) > (b) ? (a) : (b))
./external_libs/socat/mytypes.h:20:#define Max(x,y) ((x)>=(y)?(x):(y))
./groundhog/blast/groundhog.h:19:#define MAX(a, b) ((a) > (b) ? (a):(b))
./liblinklist/linklist_connect.h:71:#define MAX(a,b) ((a) > (b) ? (a) : (b))
./mcp/motors/cryovalves.c:39:#define MAX(a, b) ((a) > (b) ? (a) : (b))

Originally posted by @mxk62 in #25 (comment)

Task

Function responsible for estimating the azimuth and the elevation, PSSConvert, is fairly large and contains a few magic numbers. In order to make it easier to follow and cover with unit tests it should be refactored which may include splitting it into smaller, more manageable pieces.

Acceptance

• Magic numbers should be replaced by symbolic constants or at least well documented (if using a symbolic constants seems like an overkill).
• New function(s) must be covered by unit tests.

Details

See:

1. Gandilo, N., PROBING INTERSTELLAR GRAIN ALIGNMENT WITH BALLOON - BORNE SUBMILLIMETER OBSERVATIONS [Phd Thesis, University of Toronto, 2015]
2. Williams, P. A., MAPPING GALACTIC CLOUDS WITH THE BALLOON-BORNE LARGE APERTURE SUBMILLIMETER TELESCOPE (BLAST) [PhD Thesis, Northwestern University, 2021]

for more details regarding architecture and usage of the pihhole sun sensors.

Describe the bug
groundhog returns error about "bad serial packets" if the /dev/ writing area on groundstation is full

To Reproduce
Steps to reproduce the behavior:

1. run mcp too many times => someone is not cleaning /dev/groundhog
2. try to run groundhog again
3. enjoy confusing error message

Expected behavior
groundhog should notice and report a full writing area

Describe the bug

chrgctrl.c:
Because have_warned_connect is shared between two threads (1 for each battery charge controller), if both charge controllers are unreachable, we will only warn about one missing. The warning will only be issued from the thread that gets to the charge controller comm check first, so it's also kind of a race condition.

To Reproduce
Steps to reproduce the behavior:

1. Ensure all charge controllers are disconnected from the network
2. Start mcp: sudo ./mcp -x | grep ctrl
3. Observe only 1 warning, either for 192.168.1.253 or 192.168.1.252, and that it varies from run to run.

Expected behavior
One one-time warning for each disconnected charge controller. Potential fix: remove the static keyword from have_warned_connect and have_warned_error too.

Environment info (please complete the following information):

• PC hardware: Vagrant VM
• OS: Ubuntu 20.04
• Software version: bded235

Task

To store PDFs and other external documentation without carrying potentially multiple versions around in the git history, we need to implement git-lfs

Acceptance

./docs/pdf dir exists, with EZStepper PDF versioned inside using git-lfs. Basic config file generated.

Docs generated to guide users to git-lfs docs for GitHub.

Details

https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-git-large-file-storage

https://git-lfs.github.com/

Task

Floating point comparisons of (in)equality are used in command logic.

./mcp/commanding/commands.c:

      if ((CommandData.pointing_mode.mode != P_AZEL_GOTO) ||
          (CommandData.pointing_mode.X != rvalues[0]) ||
          (CommandData.pointing_mode.Y != rvalues[1])) {
        CommandData.pointing_mode.nw = CommandData.slew_veto;
      }

rvalues being an array of doubles.

This is bad because the result of the written code is not guaranteed to match the intent, so we should fix it wherever we see it.

Acceptance

Static analysis of commands.c proves a reduction of this type of violation, which is checked by many basic rulesets.

Details

There are so many of these (even in just this file) that it's likely to be a systemic issue throughout the code. Write a macro or function to perform a better floating point comparison and put it in a header or implementation file somewhere so it can be included and used elsewhere easily. You probably don't need to go as crazy as the author does in the link above, if you can make some reasoned assumptions about the majority of values we'll be comparing.

Task

We need to re-enable the software watchdog on both flight computers in order to trigger reboots on flight software freezes.

Acceptance

If flight software fails to tickle the watchdog within 5s (SOFTWARE_WATCHDOG_TIMEOUT), the flight computer shall reboot.

Details

NOTE: These instructions shall not be executed until motor tuning is completed and TIM is basically flight ready, since in theory flight software being run on boot could allow motors to move.

1. Enable flight software service (sudo systemctl enable flight_software.service), in order to prevent a reboot loop
2. Pop off the FC enclosure lid
3. Connect monitor to FC HDMI
4. Remove front panel hardware watchdog USB connector
5. Connect keyboard to USB
6. Reboot PC
7. Mash del key to enter BIOS
8. Refer to the disablement instructions in the new flight computer instructions, and instead enable the watchdog.
9. Close up FC and reconnect hardware watchdog USB
10. Repeat for other FC

Task

Skimming ./mcp/communications/pilot.c and ./mcp/communications/highrate.c revealed code that is similar in *_compress_and_send(), despite not being picked up by similarity analysis tools. This suggests it is a candidate for refactoring to reduce duplicate code. Determine if the similarity is sufficient to functionalize the similar parts.

Acceptance

If not similar enough to make a neat refactored function, the issue is closed. If it seems tenable, make a new follow-on issue to encompass the effort.

Details

Treat this issue as a "spike," if you know what that is. Don't spend longer than a day on it.

Describe the bug
If we fail to set baudrate for the gyro port by either the old or new method, we will stop mcp. This is less than ideal, because failing to set baudrate on ONE of two (redundant) devices can bring down a flight computer, when we may otherwise be able to operate with a single gyro.

To Reproduce
N/A, design issue

Expected behavior
mcp issues a warning for the offending serial port and continues.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment info (please complete the following information):

• PC hardware: any
• OS: Ubuntu 20
• Software version: 0e882e2

Additional context
dsp1760.c:341: blast_fatal("Gyro %d baud not set by either method! Shutting down.\n", gyrobox);

Describe the bug
mcp/communications/pilot.c:71 calls initBITsender(), defined in ./common/bitserver.c. bitserver.c:340 calls gethostbyname() on strings from the array pilot_target_names, defined in blast_config/command_list.c:53. This function relies on the /etc/hosts file mapping these hostnames to IP addresses. If the /etc/hosts file contains no entries for all hosts, mcp segfaults. It's not clear how many hosts must be in there for this to work.

To Reproduce
Steps to reproduce the behavior:

1. Comment out anything starting with 192.168.1.* from /etc/hosts on any computer or VM that can compile and run mcp.
2. Compile mcp for debug: cd TIMflight/mcp/ && mkdir build && cd build && cmake .. -DCMAKE_BUILD_TYPE=Debug && cmake --build .
3. Run mcp: sudo ./mcp -x
4. Observe segfault.

Expected behavior
mcp checks the return values for each host it tries, and fails gracefully with an error message if no hostnames are resolved. See other functions that do this with reporting that uses berror macro.

Screenshots
N/A

Environment info (please complete the following information):

• PC hardware: vagrant or FC
• OS: Debian 8 or Ubuntu 20.04
• Software version: main commit SHA: 3d9a6562d32ca0f9fa86d15743d3871b96a549cc

Additional context
N/A

Describe the bug
dsp1760.h defines the gyro variance as

/**
 * @brief Gyro noise: 7' / rt(hour)
 * 
 */
#define GYRO_VAR (0.7E-6)

This doesn't agree with the datasheet value, which is ≤0.7°/hr/(Hz^1/2) (or ≤0.012°/(hr^1/2)). The comment is very old, and totally wrong. It's possible the GYRO_VAR value is outdated.

To Reproduce
Steps to reproduce the behavior:

The DSP-1760 datasheet value yields is 0.012 deg / (hr^1/2). Multiply by an effective integration time of (1 / 100 Hz), and square it to give a variance value ~4e-10 deg^2 / sample, which is the variance used to weight each sample when gyro data is combined with data from any other sensor.

Expected behavior
Gyro variance agrees with datasheet, applying proper variance when weighted against other sensors.

Note that the impact of a large change in gyro variance weighting, making it smaller, may cause all other sensor measurements to be rejected, if their variance is much larger than the gyros. This value worked when BLAST-TNG flew with this gyro, so any changes should be carefully tested.

Screenshots
N/A

Environment info (please complete the following information):

• PC hardware: N/A
• OS: N/A
• Software version: 1639160

Additional context
This isn't the exact datasheet, it's more of a brochure, but the bias instability and random walk values agree with the datasheet I have on file: https://emcore.com/wp-content/uploads/2024/01/DS_DSP1760.pdf

Task

In order to send some telemetry (TM) data using the Columbia Scientific Ballooning Facility (CSBF) Ethernet Via Telemetry (EVTM) system, we must replace line of sight biphase and Tracking and Data Relay Satellite System (TDRSS) TM senders with universal datagram protocol (UDP) multicast senders.

Acceptance

New thread instantiated in mcp alongside pilot that sends data to a UDP multicast address in the CSBF-accepted range for LOS comms. Refer to CSBF "EVTM Details" and "EVTM Simulated Testing" PDFs. To limit scope, UDP multicast packet sending may be verified by reception via Wireshark or another computer running iperf, tcpdump, or a bespoke listener, and does not need to be ground support equipment. Do not remove the any existing senders yet - we will wait until ground support receiver functionality has been tested with EVTM.

Appropriate unit tests are mandatory for acceptance of this development work.

Details

We can begin this task by keeping existing components, creating a new TM sender that uses UDP multicast alongside the existing ones. A UDP (but not multicast) sender exists in the form of the Iridium Pilot sender (pilot in code). Extend the BitSender code to support multicast packet sending, if necessary - do not re-implement any functionality in BitSender.

EVTM Details.pdf
EVTM Simulated Testing.A.pdf

Task

Develop code and procedure for calibrating the pin hole sun sensors (PSSs).

Acceptance

Working code and detailed calibration procedure.

Details

Azimuth determination from the PSSs can be cross-checked against the azimuth from CSBF's differential GPS (DGPS) for calibration.

CSBF's DGPS az check happens in pointing.c with the call: PointingData[point_index].dgps_az_raw = CSBFGPSAz.az;

Procedure will include spinning gondola around in azimuth to fully scan the sun across the FOVs of all 4 sensors.

Task

Pick a unit test framework for the project and describe why it was chosen.

Acceptance

Comment on this issue to document process of choosing.

Provide a sample unit test project.

Details

In flight we run a blastcmd daemon which listens on port 41414 for commands, presumably formatted in a UDP packet as a message which it can decode to figure out what to send to MCP.

On the ground, we use the formalism (no COW) "./blastcmd @target_ip command_name value1 value2 ... etc" which executes the blastcmd executable telling it the target for the message is a specific IP addr, and the message should contain a command name and a series of values if the command requires them. This all makes sense on the ground, simple IP link (probably TCP/IP, see netcmd.c).

In flight, we have a single link that works like this, the iridium pilot link is basically just an internet connection. Commanding over this seems the same as before, especially given the cow source code does not specify anything special for this link AND cow on the ground runs via "pilot" which is just an ethernet cable. We also have the options to send commands over TDRSS among other links and they have a secondary target called "COMM 1" or "COMM 2". These links go through the SIP to the payload FC, which is poorly understood on our end but needs to be understood so that we can have the test flight this summer.

I request that we document and understand how the flight commanding software works through the links not used on the ground.

Describe the bug
When flight computers are configured to send star cameras lat/lon info for use in their solutions, it seems that mcp is unable to command them to do updates like exposure time, aperture, etc.

To Reproduce
Steps to reproduce the behavior:

1. Start an FC running mcp and a SCC on the same network running the star camera software
2. Start a ground station running groundhog, guaca, kst2, and cow, to send commands to the star camera computer via mcp
3. Send command to change exposure time
4. See exposure time remain the same in telemetry

Expected behavior
When commanded to change exposure time or any other parameters, SCC reports change back to FC, then to GSE via telemetry.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment info (please complete the following information):

• PC hardware: fc1 InCharge, sc1, network switch
• OS: Ubuntu 20.04
• Software version: bd28ea9

Additional context
The SCCs do and report on what they have been commanded to do based on flags they unpack from the command packet sent by mcp. Ian surmises that the packet is improperly written somehow and either stomps on the flags or clears the fields prematurely.

Start looking in mcp/sensors/star_camera_transmit.c:prepare_command_packet_*

Task

Pull Request #14 added some new functions, and they came with unit tests. Make a GitHub Action we can customize to run unit tests.

Acceptance

Nick's new unit tests are executed and output is checked using GitHub actions upon AT LEAST pull request and push to the main dev branch.

Details

https://docs.github.com/en/actions

This should be a new "Workflow" in GitHub Actions, separate from the Build-ground-software workflow. Thus, it will need a new .yml to be created in the .github/workflows/ folder.

You may cast about for a template to modify, plenty of options/a search box here.

Testing new GitHub actions without doing it in the main branch can be a bit tricky. Here's how Evan did it (IIRC):

1. Check out your feature branch
2. Create the new .yml file for the Action
3. Add the name of your feature branch to this section at the top of the .yml:

on:
  push:
    branches:
    - feature-branch-name

4. Commit and push the .yml
5. Verify that when you push a change from your local machine to the GitHub remote, the GitHub Action for that .yml kicks off.

Task

Ethercat motors provide error codes and state values that can be added to the standard MCP telemetry for remote diagnosis

Acceptance

Create telemetry channels for all states and error codes

pull state values and error codes from the motor controllers

populate data into the telemetry channels and check their downlinked values

Overview

This is an attempt to finalize a well-documented procedure for calibrating the magnetometer, detailing needs and insights discovered from testing at the UA MIL. It exists as a GitHub Issue as we need to make sure that our sensors, pointing, and commanding code are compliant with our nominal procedure. Some of the information listed in this issue is speculative and based on our best guess of what the current BLAST flight code is attempting to do.

Current mcp behavior

We use a three-axis (say, Z towards the pivot, X "towards" boresight) magnetometer that measures fields from -2 to 2 G, mounted on the outer frame's static sunshield. During the flight, the two dominant sources the magnetometer is sensitive to are the gondola and the Earth.

Calibration on the ground, close to flight at LDB, seems to involve rotating the gondola through full rotations, and extracting the constant offset in X, Y, and Z components of the gondola (say B_x, B_y, B_z), as well as the "amplitude" of the Earth's magnetic field (say, A_x, ...). These are #DEFINE#s in magnetometer.h for Z or command-able fields for X & Y.

In pointing.c:MagConvert, the WMM is used to figure out the "declination" and the "dip" of the magnetic field given our known lat, long, and altitude. To get azimuth, we compare this declination to the angle of the XY vector formed by linearly scaled versions of the magnetometer readings. We subtract the offset B and then divide by the slope A.

Suggested changes and questions

1. Subtracting the offset term B_* makes sense, getting rid of the gondola's magnetic field. The scaling term A_* does not. The best explanation could be the past magnetometer(s) used had different sensitivities along different axes. For us, the scaling does not help, atan2 is similar precise over its domain, and A_x and A_y should be the same value, unless the pivot axis precesses by a lot. remove scaling by magx_m and like in pointing.c.
2. Currently, the command-able fields for X and Y are not A_*, B_* directly. Rather, we set the maximum and minimum of the curves we obtain on the ground when performing the calibration operation, and the code calculates A_*, B_*. This makes A_*, B_* related and toughens removing the scaling. make the gondola field offset the command-able term.
3. Cannot see a reason to not have the Z axis offset also be command-able.

Acceptance

A coherent procedure that several of us agree is the right thing to do pre-flight, corresponding code changes code in magnetometer. and pointing., and changes to command-able fields to ensure the sufficient flexibility during operations.

Task

We need to modify the lock pin code and logic in order to allow the lock pin to work using limit switch feedback.

Acceptance

When the task is done, the lock pin code will look similar to a fusion of the existing lock pin code and the existing shutter code, except the lock pin code does not need the following functions:

• off
• reset
• keep open
• keep closed

Lock pin queries digital inputs on EZStepper board:

• Switch #\1 input is "tripped" (connected to GND, logical 0) when lock pin is fully retracted ("positive" motion)
• Switch #\2 input is "tripped" (connected to GND, logical 0) when lock pin is fully extended ("negative" motion)
  State machine is in commanded open state:
• Lock pin motor driver is commanded to drive "forward", "positive" infinitely unless Switch #\1 input is tripped.
  State machine is in close state:
• Lock pin motor driver is commanded to drive "backward", "negative" infinitely unless Switch #\2 input is tripped.

Unit tests updated

Details

actuators.c holds shutter and lock pin code. EZHR17EN Command Set describes the EZStepper protocol.

Task

We need to make the libphenom and cmocka repos into git submodules of the main flight code repo in order to more easily compile offline.

Acceptance

After cloning a repo, mcp and its unit tests compile fully while the machine is not connected to the Internet.

Documentation updates completed.

Details

N/A

Task

Write two small programs in C to build skills and useful code for when we have to write and test code to talk to detector control boards later on.

• Write a UDP writer program:

  • Specify a place to spew packets: a loopback IP address and port
  • Populate a struct according to UDP
  • Send some data - first try chars or ints (easy), then try sending floats (harder)

• Write a UDP listener program:

  • Receive packets on a port
  • unpack the received data
  • print or do something to show it's working (maybe even write a unit test to show this?)

• Write a .md or .txt file describing how to build and run them so anybody can see how it should work.

Acceptance

Complete when both programs compile and run and there's proof that data is communicated successfully.

Put the example code and any files you need to build in a dir called sandbox for now, to keep it separate from other code until it has a home as part of a test suite. Work in your own development branch (make a new one), make any commits there, and open a pull request to the master branch to complete this issue when done.

Context

We expect the flight computer running mcp to receive UDP packets containing detector data from the Xilinx radio frequency system-on-chip (RFSoC) boards. They get shuffled to telemetry to get them off the balloon as well as recorded locally to hard disks for recovery and post-flight reconstruction after landing.

I have found this explainer on network programming useful for understanding what UDP is all about:
Beej's Guide to Network Programming
It's good because many of the examples are written in C.

Once you know what function calls are used to get things done, you might also be able to look at code in the repo for examples, as things are already talking using UDP.

Due to pbob issues at FTS during preparations for test flight we had to swap the IP addresses of labjack1 and labjack3 from
labjack1 = 192.168.1.110
and
labjack3 = 192.168.1.112

to
labjack1 = 192.168.1.112
and
labjack3 = 192.168.1.110

fix this post test flight when we rebuild the PBOBs

Task

make sure there is a helper function that constantly updates the lat and lon in SC command packets and sends them out at a reasonable cadence - maybe 0.1 Hz?

Acceptance

write the helper function and test from MCP that the SC computer is getting updated lat and lon data, this will be visible on the command line datastream as "received an update to LAT from FCx"

Details

This function should go in the star_camera_transmit.c file and make use of the command data lat and lon fields that pointing.c updates for us