Frame counters and ping packet

Overview

This release includes two major new features:

1. Frame counters in downlink packets

This enables reliable GSE frame logging in the face of packet loss, which was an issue in the FOXSI-4 flight. Both Formatter and GSE frame counter behaviors are backwards compatible, so this release can be still used with GSE v3.1.0 and earlier.

2. Ping packet transmissoin

This is a new 46 byte downlink packet that the Formatter sends on startup. The packet contains software status information, but the presence of the packet alone can be used to indicate Experiment aliveness in the GSE.

Changes

• Documentation updates by @thanasipantazides in #77
• Added some thoughts on the main README. by @KriSun95 in #78
• Documentation for systemd, systemctl, and formatter.service by @thanasipantazides in #80
• Add downlink frame counter and global health packet transmission by @thanasipantazides in #75

Full changelog

v1.2.2...v1.3.0

Fix for systems.json mcast_group value

Overview

This is a slightly more flexible version of v1.2.1. In foxsi4-commands/systems.json, in an ethernet_interface block, if mcast_group is encountered that value is used for the remote address. Otherwise this code will fall back to using address.

In all prior versions, the Formatter would transmit GSE packets to gse.ethernet_interface.address even though gse.ethernet_interface.mcast_group was present, so the Formatter's systems.json file needed to be manually edited to have the GSE multicast IP address 224.1.1.118 as the ethernet_interface.address.

This fixes that problem, you can now use fully identical systems.json files for the GSE and Formatter configuration. Or you can use an old systems.json file with hardcoded gse.ethernet_interface.address (this is backwards-compatible).

DE-corrected FOXSI-4 flight

Overview

This is just like v1.2.0 (FOXSI-4 flight version), but includes a fix to avoid repeatedly downlinking the last available DE frame. The check for the DE's write pointer to advance before reading the latest frame into the formatter now works correctly.

There are also substantial updates to the foxsimile emulator system that enable emulation of all onboard CMOS and CdTe systems simultaneously.

PRs included:

• Fix repeat readout of last DE frame; configure downlink MTU by systems.json by @thanasipantazides in #69
• Updates to foxsimile emulator by @thanasipantazides in #71
• Remove some double-added lines in foxsimile source files from last merge by @thanasipantazides in #72
• Getting Github actions to build correctly. by @thanasipantazides in #73

Changelog

Changelog

PFRR pre-sequence test (flight version)

Important

This version was FOXSI-4's flight software, flown on Apr 17 2024 from Poker Flat, AK. It did well in flight.

Summary

This version resolves the "zombie data" problem observed in March 23 2024 x-ray alignment checks of the CdTe detectors. Root cause was the CdTe DE updating the ring buffer write pointer when it starts writing a frame, rather at the end of writing a command.

The fix is for the Formatter to always decrement the CdTe ring buffer write pointer before accessing remote memory. If the ring buffer write pointer for CdTe is the first frame in the ring buffer, the decremented pointer wraps around to the last frame in the buffer. This logic is contained in an if-block that modifies write pointers only for SystemManagers whose name contains the string "cdte". So CMOS readout should be completely unaltered.

The reference commit for this release in foxsi4-commands is 9844c1d.

As of March 27 2024 this is the flight version.

Issues introduced

1. When the CdTe DE writes fewer than 1 frame per Formatter event loop (a rate of 1 frame / (approximately) 1.2 seconds), the Formatter will repeatedly read the last written frame from the DE ring buffer. This is because I mistakenly inserted src/TransportLayer.cpp lines 745-754 (the main fix in this version) after the condition checking if the prior write pointer is identical to the current write pointer. Because I decrement whatever write pointer I receive from the DE, if no new data has been written, it will always be smaller than the last write pointer I received from the DE. There is no time to resolve, but the easy fix is to move lines 745-754 to right before the condition in lines 738-741.

2. The very first frame taken from the CdTe DE after power on (and initialization, system start observation, etc) is always garbage data. This is because the Formatter will decrement the write pointer, which starts in frame position 0, around to the end of the ring buffer, which is full of uninitialized memory.

Warning

Use the version of systems.json attached in this release as the configuration file for the Formatter. If you build this release on the Formatter, copy the attached systems.json into the Formatter's folder ~/foxsi-4matter/foxsi4-commands/systems.json.

This version of Formatter code transmits telemetry to the IP address in systems.json's field gse.ethernet_interface.address, not gse.ethernet_interface.mcast_group (which is where the GSE software receives data). The flight release of the GSE (v3.0.0) contains its own version of systems.json that should be used to configure the GSE software.

This discrepancy in configuration is fixed Formatter v1.2.2.

Changes

Full Changelog: v1.1.1...v1.2.0

PFRR pre-x-ray check

Status

• Uses while-based (rather than asio timer-based) main event loop.
• Has Timepix back at 9600 baud.
• Validated with multiple turn on/background data tests with the full system.
• New CdTe canister HK frame size of 0x330, based on desire to include the counter for DE unsaved frames still in canister memory.

Full Changelog: v1.1.0...v1.1.1

Proposal: `while`-based main event loop

Note

This version was accepted in sealed source and x-ray checks.

Content changes

Modifies implementation of Circle constructor and Circle::update_state() to drive the main event loop with a while loop rather than a boost::asio::steady_timer. This is a significant change to functionality and requires testing before flight use. If there are issues, we can revert to v1.0.0.

Motivation

This is a much simpler loop driver than the timer that was in place before. My hope is that it helps with timeout/latency issues encountered late in February testing, particularly with Timepix and CMOS knock-on effects.

Testing

This version was tested Mar 21 2024 at Poker with the full system (in all runs of the day, though only 6 and 7 involve full system). Need detector teams to confirm behavior.

GSE looks as expected. Downlink data rate was identical to timer-based loop (Formatter reboot interrupts the middle of the trace):

Changes

Full Changelog: v1.0.1...v1.1.0

Update doc

In this release

Signifant documentation improvements. Nice-looking API documentation can now be built from Doxygen source with sphinx and breathe.

In terms of software functionality, this release should be completely identical to v1.0.0.

Changes

PRs

• Uart by @thanasipantazides in #64

Changelog

Compare last uart (source branch) to this one: v1.0.1...v1.0.1
Compare last main version to this one: v0.1.1...v1.0.1

v1.0.0

Nominal flight version

Prior to this version, I found an issue in which SpaceWire communications immediately following transfer of CMOS QL data (from either CMOS) would fail. This version changes the main loop order and timing (in Circle::manage_systems(), order defined in apps/main.cpp) so that SpaceWire systems all safely communicate post-CMOS.

Changelog

Full Changelog: v0.1.7...v1.0.0

v0.1.7

Overview

• Housekeeping board will now be DISCONNECTed if any read operations time out (like ABANDONment, but the Circle::manage_systems() call will still enter the housekeeping part of the function).
• Uplinked read commands will have their replies downlinked with the RING_BUFFER_TYPE_OPTIONS::REPLY data type indicator.
• CMOS and CdTe systems should have correctly-sized housekeeping data downlinked.

Changelog

Full Changelog: v0.1.5...v0.1.7

v0.1.6

Implements

• Enable/disable readout of specific Housekeeping board values.
• Slower Housekeeping data readout (once per 5 loop cycles).
• Mechanism for Formatter to intercept commands directed at a System.
• This version of Formatter runs on boot via systemd/systemctl.

Changelog

Full Changelog: v0.1.15...v0.1.6