RC8

1. Summary

Upload of actual binaries uploaded to Iris FM1 during Release Candidate 8 (RC8) opportunity on 03/14/23. To expedite the RC8 process, EGSE setup for RC8 was performed in advance on 03/11/23. Includes both FSW and GSW (backend) since they’re now both tracked on release-candidate. Note: the GSW included here is the latest (as of RC8) IPC release which was used for PCAP parsing and image reconstruction during RC8 prep. The actual GSW used for serial monitoring used during RC8 was the GSW from RC7 (due to lack of operator training with the new GSW). At the time of upload, this was considered the final in-person upload opportunity prior to the Moon.

Note: unlike previous releases, due to extreme constraints on time, this was not done from the release-candidate branch and, instead, the rc8/camera-hail-mary branch. That said, this pointer goes to release-candidate and accurately tracks the changes that were used during this release, which were brought over in PR #212 .

GSW logs from the various interactions with the Flight Rover (FM1) during this operation can be found in transciever_logs_RC8.zip and packet_prints_RC8.zip.

2. General Release Notes

• During this opportunity, battery charging was performed then code upload.

• Unlike other recent RCs since RC4, due to electrical (grounding?) issues on the silver Lenovo µHermes laptop discussed later, the black IBM X1 Carbon µHermes laptop was used to program in the cleanroom. No workspace was archived for this release, but it should match the workspace used for this same laptop during RC7.

• NOTE: During this opportunity, the rover was demated from the lander and powered by external EGSE, occasionally with a test EGSE lander harness installed. In the end, however, the rover ended up being programmed using battery power with nothing attached to the lander connector.

• NOTE: Starting with this release, the Watchdog must be put inHercules Programming Mode (program the WD using the Debug_Radio_Herc_Flashing flag in CCS or send monitor-herc-off and then don't power-off the Watchdog). After programming Hercules, the WD must be put back into flight mode (program using the Debug_with_flag flag in CCS).

  • Prior to RC8, Hercules monitoring was not activated in the WD, so in this particular release, we just had to make sure Hercules was programmed before the Watchdog.

• REMINDER: Only CCS v9.1.0 is used for programming both the Watchdog and the Hercules at this point.

Full Changelog: rc7...rc8

3. Operations Highlights

(3.0) Battery Charging

Before Charging:

• The rover was powered and the battery switch was closed. Battery voltages were measured to be:

C1:  3.852V.  (3.852V)  ∂V=0.03V
C2:  7.71V.   (3.858V)  ∂V=0.04V
C3:  11.45V.  (3.740V)  ∂V=0.08V
C4:  15.31V.  (3.860V)  ∂V=0.04V
C5:  19.15V.  (3.840V)  ∂V=0.02V
VBS: 22.91V.  (3.760V)  ∂V=0.06V
Mean: ---      3.818V

After Charging:

C1:  4.095V.  (4.095V)  ∂V=0.02V
C2:  8.19V.   (4.095V)  ∂V=0.02V
C3:  12.25V.  (4.060V)  ∂V=0.02V
C4:  16.34V.  (4.090V)  ∂V=0.01V
C5:  20.44V.  (4.100V)  ∂V=0.02V
VBS: 24.47V.  (4.030V)  ∂V=0.05V
Mean:  ---     4.078V

(3.1) Hercules Programming

• During Hercules programming using the Portable Rover Integration Checkout Kit, the long ribbon cables caused communication issues between the programmer and the Hercules. A wide range of seemingly unrelated errors were thrown — below are some examples:

Error connecting to the target:
(Error -232 @ 0x0)
The measured length of the JTAG DR data path is invalid.
This indicates that an error exists in the link-delay or scan-path.
(Emulation package 9.3.0.00042)

Error connecting to the target:
(Error -283 @ 0x0)
The measured TCLK frequency value is out of the supported range.
The utility or debugger has requested the JTAG clock frequency to be measured.
This failed because the actual value was too high or too low for the hardware
...

• Something similar occurred in a much earlier RC and was resolved by swapping the USB cables used for the programmer. That alone did not resolve the issue.
• We found that swapping to a shielded USB cable and unplugging the laptop from the grounded power strip allowed for programming to start, however it errored out part of the way through several times and was inconsistent.
• In the end, to successfully complete Hercules programming we needed to:
  • Power the rover over battery power.
  • Demate the EGSE lander harness and forgo monitoring RS422 telemetry.
  • Apply pressure to the rover EGSE port connectors and the Portable Rover Integration Checkout Kit "PCB" connectors.
  • Try a variety of shielded USB cables.
  • Try several times.
  • Trying with both the laptop's USB port shield and the operator's ESD strap grounded to the spacecraft ground and floating.
• In addition to possible grounding issues, it is believed that the ~1m length of the 2x50pin unshielded ribbon cables running from the EGSE port adapter to the Portable Rover Integration Checkout Kit "PCB" was a contributing factor. Shorter 50pin IDC cables have since been procured for any subsequent programming opportunities, should they arrive.

(3.2) WD Programming

• After Hercules programming was completed, we proceeded directly into WD programming without changing the rover state. The Watchdog was programmed using the Debug_with_flag flag.

(3.3) Close-Up

Batteries After Programming:

• Programming had to be performed using battery power. So, after programming and right before close up, battery cells were quickly measured again:

C1:  4.085V.  (4.085V)  ∂V=0.01V
C2:  8.17V.   (4.085V)  ∂V=0.01V
C3:  12.21V.  (4.040V)  ∂V=0.04V
C4:  16.30V.  (4.090V)  ∂V=0.02V
C5:  Not measured (time).
VBS: Not measured (jumper was installed on "PCB").
Mean:  ---     4.075V

Safe Mode:

• The Rover was placed into a safe-mode by re-mating the test lander harness, sending a batt-off command over RS422, removing lander power, and ensuring rover telemetry had discontinued.

4. Final Release Status

Final release status remains the same as RC7, except the following:

TODO

What's Changed

• Cleaned up placement of scripts, logs, and caches in GroundSoftware. by @zCoCo in #195
• Pull thermal and GDS updates into IPC test bed. by @zCoCo in #198
• GDS: Bring latest changes from release candidate into IPC Testbed by @zCoCo in #207
• Pull in GSW Improvements for EM4 RC8 Testing by @zCoCo in #208
• Changes Uploaded during RC8 by @zCoCo in #212
• Bring in new Stable IPC GDS into RC, incl. major GDS infra. improvements. by @zCoCo in #213

Full Changelog: rc7...rc8

Integrated TVAC (iTVAC)

1. Summary

Data and processing scripts from the periods of Integrated TVAC (iTVAC) where Iris was powered on from 01/10/23 to 01/20/23 (UTC).

NOTE: All FSW that was on Iris FM1 during iTVAC was uploaded prior during RC7. This release only contains the GSW GDS scripts involved with retrieving, processing, and analyzing the GBs worth of Iris data generated during iTVAC. As such, to take advantage of the latest GSW advances, the iTVAC tag points to a commit on the GSW GDS IPC development branch (backend/cwcolomb/ipc-testbed), not release-candidate.

2. General Release Notes

For security, the full dataset and data products can be found on the Iris secure drive at 01 - Team Drive/05 Iris - Teleoperations / Ground Software/02 - Backend/Integrated TVAC Data/. Plots can be found at Integrated TVAC Data/plots. The only data shown here will be plots which only display data generated by the Iris FSW or Iris GSW.

NOTE: This data is intentionally stored on Iris' secure drive and should not be replicated elsewhere. See the README file in the secure drive for more details.

2.1 Key Data Products:

Key data products that can be found in the shared drive are:

• Reference database of Iris-available data collected in pre-iTVAC testing in PGH (_ref_iris-pgh-testing.h5).
  • Data collected via the lander during RC7.
• Database of all Iris-available data collected during iTVAC (int-tvac-data2.h5).
• Excel table of all timestamped telemetry emitted during iTVAC (int-tvac-data2_telem_export.xlsx).
  • NOTE: This contains telemetry emitted directly from the rover as well as metatelemetry created by the GSW processing direct telemetry and lander deck temperature readings that would be available to Iris during mission. This does not include any raw packets.
• Print out of all messages emitted by the rover during iTVAC and alarms generated by GSW when processing iTVAC data archives (int-tvac-data2_messages_and_alarms.ansi.pdf).

2.2 Key Plots:

Key plot data products that can be found in the shared drive are:

• All Key Temperature, Voltage, and Power Telemetry throughout iTVAC

  • plots/int-tvac-data2_01GQ8FMVAMXJT6TT6PJWX6SW0J.png

• Rate of Change of Battery Temperature throughout iTVAC

  • plots/int-tvac-data2_TDOT_01GQ8FMVAMXJT6TT6PJWX6SW0J.png

• All Key Temperature, Voltage, and Power Telemetry when Iris had its Heater ON

  • plots/__HEATER_ON_TIME.png

• Rate of Change of Battery Temperature when Iris had its Heater ON

  • plots/__HEATER_ON_TIME__TDOT.png

• Close-up of All Key Temperature, Voltage, and Power Telemetry when Iris had its Heater ON

  • plots/__HEATER_ON_TIME__CLOSE_UP.png

• FM1 Battery Temperature Rate vs Nearest Deck Temperature Rate during Early Hot and Cold Ramps

  • plots/__DECK_TO_ROVER_TDOT.png

• Floating Battery Diode Voltage vs Battery Temperature

  • plots/__DIODE_LEAKAGE_PLOT_2.png

3. Results and Observations

4. Concluding Actions / Issues

Results, observations, and concluding actions will be written up and added to this release after RC8 closes imminently. If you need to discuss certain aspects of this data sooner, please contact Connor Colombo.

RC7

1. Summary

Upload of actual binaries uploaded to Iris FM1 during Release Candidate 7 (RC7) opportunity on 01/01/23-01/02/23. Includes both FSW and GSW (backend) used during RC7 since they’re now both tracked on release-candidate. This was the final in-person upload opportunity prior to integrated TVAC testing, and possibly prior to the Moon.

Note: unlike previous releases, due to extreme constraints on time, this was not done from the release-candidate branch and, instead, the cwcolomb/196-wd-thermal-control-patch branch. That said, this pointer goes to release-candidate and accurately tracks the changes that were used during this release, which were brought over in PR #197 .

GSW logs from the various interactions with the Flight Rover (FM1) during this operation can be found in transciever_logs_RC7.zip and packet_prints_RC7.zip.

NOTE: This operation was only concerned with updating the heater control scheme on the WD, so only the WD was programmed during this opportunity. Hercules and Radio were left as they were at the end of RC6 and untouched.

2. General Release Notes

• Notes from testing that went into #197 and #196 can be found in #196 . Note, these notes are chronological.

• Unlike other recent RCs since RC4, due to workspace issues on the silver Lenovo µHermes laptop,,the black IBM X1 Carbon µHermes laptop was used to program in the cleanroom, and the v9_workspace_watchdog.zip archive included here is pulled from ~/mschnur/v9_workspace_watchdog on that machine. Workspaces are also archived in the Bins of this release but should be copied out to a non-git-managed directory before use.

• NOTE: During this opportunity, the rover was not allowed to be demated from the lander in order to preserve integrity of testing that has already occurred. Similarly, the ensure no undue risks were taken, the rover was only powered using the lander as the power source.

• REMINDER: Only CCS v9.1.0 is used for programming both the Watchdog and the Hercules at this point.

Full Changelog: rc6...rc7

3. Operations Highlights

(3.0) Battery Voltage Checking

• All battery cell voltages except the top were checked during first power-up.
• Battery voltages were measured to be:
  • C1: 3.914V (3.914V)
  • C2: 7.835V (3.921V)
  • C3: 11.67V (3.835V)
  • C4: 15.58V (3.910V)
  • C5: 19.49V (3.910V)
  • VBS: Not measured (kept VBS off)

(3.1) WD Programming

• During pinout checkout a spark occurred through shorted pins, which we believe were C3 and either C0 or C5. Note: C3 appears slightly low which would corroborate this finding. Battery charging should be attempted during the next RC.
• WD programming failed a number of times (unrecognized device error and interface comms error). Upon inspection (and correction), it appears this was likely due to either a speck of glue found in the socket or a poorly mated rover A-B connector (couldn’t go in all the way due to interference with the chassis wall unless finessed).
  • Note: even after this fix, WD programming was observed to not work when lander power was not supplied (loading failed to upload first block error). Programming on battery power alone was not tested since we’d need lander power to activate the batteries.

(3.2) Heater Control Testing

• Readings were successfully taken from the BattRT thermistor, confirming that the battery thermistor's wiring is intact.

  • BattRT thermistor reading was observed to match ambient to +- 0.09degC

• Heater control was tested successfully, confirming the heater wiring is intact.

  • Several different power level duty cycles were commanded with PM1 on and PM1 telemetry confirmed that the change in current matched the expected change in the current.
  • Heater control logic was confirmed by:
    • setting the ON and OFF thresholds to just above ambient, and observing the rover start drawing the expected excess as soon as the ON threshold changed and this current continued until the battery temperature hit the OFF threshold.
  • All the necessary heater control commands were validated:
    • Power-Level: set-heater-to-power-XX
    • Enable Control: enable-heater-control
    • Disable Control: disable-heater-control
    • Set ON Threshold: set-heater-on-level
    • Set OFF Threshold: set-heater-off-level
    • Force Heater ON: heater-force-on
    • Force Heater OFF: heater-force-off
    • Stop Forcing Heater State: heater-force-nothing
  • Changing heater control temperature reading source from BattRT to ChargingThermistor was not tested on FM1 because it's potentially destructive and was not necessary since the BattRT thermistor was confirmed to work.

• NOTE: See _ref_iris-pgh-testing in the iTVAC release for Iris data collected via the lander during this portion of RC7.

  • Reference Database of Iris-Available Data Collected in pre-iTVAC Testing in PGH (_ref_iris-pgh-testing.h5).
  • Plot of Key Temperature, Voltage, and Power Telemetry Collected via Lander during RC7 (_ref_iris-pgh-testing_01GPQN73F91TG38Z4XM3TJ92HX.png).
  • NOTE: This data is intentionally stored on Iris' secure drive and should not be replicated elsewhere. See the README file in the secure drive for more details.

4. Final Release Status

Final release status remains the same as RC6, except the following:

(4.1) Completed Issues

• #196

(4.2) Issues Delta

Fixes and Features that didn’t make it into this release that have been added/changed since RC6.

(4.2.1) Known Bugs

(4.2.1.a) bug-impactful: could potentially degrade mission objectives
No changes since RC6.

(4.2.1.b)bug-small: unlikely to affect mission objectives directly, more likely to just make things difficult at worst or inhibit our ability to respond to edge cases

• #199
• #204

(4.2.1.c)bug-min: inconsequential, almost certainly won’t affect anything

• #201
• #205
• #206

(4.2.2) Known Important Missing Features

_CRITICAL: Features that have the potential to expand mission success
No changes since RC6.

(4.2.3) Known Nice-to-Haves Missing

feature-nice-to-have: Not a bug fix. Not essential to mission success but is likely to make things easier.

• #200
• #203

(4.2.4) Known Missing Retests

int-test: things we probably should (re)test

• #202

(4.2.5) Unresolved RC7 Issues that now no longer require FSW changes and can be handled entirely in GSW Post-FSW-RCs

No changes since RC6.

What's Changed

• BGAPI PASSTHROUGH PROGRAMMING WORKS (+RC6 Complete) by @zCoCo in #192
• Pull README changes from MS into RC. by @zCoCo in #194
• RC7 WD Thermal Control Patch by @zCoCo in #197

Full Changelog: rc6...rc7

RC6

1. Summary

Upload of actual binaries uploaded to Iris FM1 during Release Candidate 6 (RC6) opportunity on 11/13-14. Includes both FSW and GSW (backend) used during RC6 since they’re now both tracked on release-candidate. This was the final in-person upload opportunity prior to environmental testing, and possibly prior to the Moon.

Note: unlike previous releases, due to extreme constraints on time, this was not done from the release-candidate branch and, instead, the cwcolomb/152-radio-passthrough-programming branch.

GSW logs from the various interactions with the Flight Rover (FM1) during this operation can be found in transciever_logs_RC6.zip and packet_prints_RC6.zip.

2. General Release Notes

• The Radio was programmed successfully using BGAPI Passthrough Programming (demonstrating that it is a viable asynchronous programming method - though still inherently risky, long, and nerve-racking).

• Unlike RC3a which used the black IBM dev laptop, the workspace_archives in RC4 and beyond come from the silver Lenovo µHermes laptop used to program in the cleanroom (pulled from ~/Desktop/Workspaces on that machine). Workspaces are also archived in the Bins of this release but should be copied out to a non-git-managed directory before use.

• REMINDER: Only CCS v9.1.0 is used for programming both the Watchdog and the Hercules at this point.

Full Changelog: rc5...rc6

3. Operations Highlights

(3.0) Battery Voltage Checking

• All battery cell voltages except the top were checked during first power-up.

• Links to: RS422 monitoring packet prints and transceiver logs.

• Battery voltages were measured to be:

  • C1: 3.970V (3.970V)
  • C2: 7.95V (3.980V)
  • C3: 11.84V (3.980V)
  • C4: 15.81V (3.970V)
  • C5: 19.78V (3.970V)
  • VBS: Not measured (kept VBS off)

(3.1) Watchdog & Hercules Code Release

• WD was loaded with this release's FSW
  • Links to RS422 monitoring from this activity: packet prints and transceiver logs.
  • NOTE: Because of subsequent Radio programming activities, at this stage the WD was loaded in Debug_Radio_Flashing mode. It was restored to Debug_with_flag (and given further updates) in the Watchdog updating section below (3.3).
• Hercules was loaded with this release's FSW (v.6.1.2)
  • Links to RS422 monitoring from this activity: packet prints and transceiver logs.

(3.2) Radio Activities

• For all of the following activities, the WD was put into Radio Flashing mode (Debug_Radio_Flashing), which disables the ability for the Radio to be externally reset. The Watchdog was reprogrammed into the correct mode (Debug_with_flag at the end of these activities).

(3.2.1) Radio & Antenna Functional Check

Since the Radio was determined to be alive in RC5, prior to any other Radio activities which could brick the Radio's MCU, we checked all the following critical questions which have remained unanswered on the flight article:

1. whether the Radio's basic comms worked,
2. whether the Radio's power amplifier worked,
3. whether the antenna was physically still intact.

This was performed as follows:

• Boot Rover into RS_MISSION

• Turn on BGAPI Passthrough Mode

• Send the following BGAPI command aliases:

  • radio-bgapi-passthru-dfu-on
    • Receiving a command response here confirmed (3.2.1.1) above.
  • radio-bgapi-passthru-wifi-on
    • Subsequent BGAPI events triggered by this event showed success and suggested (3.2.1.2) above was a pass.
  • radio-bgapi-passthru-scan
    • BGAPI scanning events showed that it was able to detect our RaspberryPi (RPI) access point from over ~6ft. away, through the MLI, with an RSSI >=-48dBm. This confirmed (3.2.1.2) and (3.2.1.3) passed.

• Links to: RS422 monitoring packet prints and transceiver logs.

(3.2.2) PICKit ICSP Connection Check

In RC5, a better connector was added to the Portable Rover Integration Checkout Kit harness for the WF121 ICSP. At this stage, we powered on the Radio (with the reset line floating) to see if we'd have better success connecting to the WF121 with the PICKit 3 ICSP programmer. Unfortunately, as in RC3 and RC4, the programmer was able to detect the voltage of the Radio but unable to connect to the Radio. This further supports the previous hypothesis that there's either a connection issue with the PGD or PGC connections in this harness or there's just too much noise in the harness bundle for ICSP to work.

• Links to: RS422 monitoring packet prints and transceiver logs.

(3.2.3) Radio BGAPI Passthrough Programming

Radio was successfully programmed using BGAPI Passthrough Programming.

NOTE: This entire programming activity was performed without the Portable Rover Integration Checkout Kit installed (to avoid comms issues due to mutual capacitance). Additionally, the Battery Jumper was left uninstalled so batteries could take over if lander power were removed. Only lander power and RS422 were left connected through the Iris-Peregrine harness connector.

(3.2.3.a) Overview of the programming setup process (using Iris Console):

• Hercules was put into BGAPI Passthrough Mode
• Radio was commanded into DFU mode
• Links to RS422 monitoring during the setup process: packet prints and transceiver logs.

(3.2.3.b) Overview of the programming process:

• then small (128B) chunks of data were wrapped in BGAPI flash commands, wrapped in NetworkManager FPrime commands, wrapped in Iris Common Packets, sent to the Watchdog, passed to Hercules, and then written to the Radio
• validation and send status were archived in a retrievable record book in Hercules and downlinked to Ground along with Radio all responses
• Specialized ground software (_bgapi_passthrough_programmer.py) managed the entire process, including determining whether data chunks actually made it to the Radio or, in some cases, didn’t make it to Hercules or to the Radio (using the record book to circumvent the implicit Two Generals problem).)
• Links to GSW logs of Passthrough Programming: output from _bgapi_passthrough_programmer.py.

(3.2.3.c) Outcome after programming:
After completion of all 4000 128B chunks:

• the Radio was observed to respond to flash complete commands.
• after power-cycling just the Radio, Radio Heartbeat, State, and Activity messages were recorded in Ground (as well as BGAPI activity since passthrough mode was still on inside the Hercules).
• subsequently, the Radio was able to auto-connect to our RPI PM1LWAP hotspot with an RSSI of -47dBm to -54dBm
• Links to RS422 monitoring during the post-programming checkout process: packet prints and transceiver logs.

(3.2.3.d) Basic Iris FM1-Peregrine WiFi Checkout:

• During a later test (WD update), the RPI hotspotwas powered down, **Peregrine and its WIFI service were powered on, and we successfully connected to the PM1 network with FM1 through the MLI...

RC5

Summary

Upload of actual binaries uploaded to Iris FM1 during Release Candidate 5 (RC5) opportunity on 10/26. Includes both FSW and GSW (backend) used during RC5 since they’re now both tracked on release-candidate.

GSW logs from the various interactions with the Flight Rover (FM1) during this operation can be found in transciever_logs_RC5.zip and packet_prints_RC5.zip.

General Release Notes

• The Radio was found to be alive during RC5 via Hercules BGAPI Passthrough but it was not (yet) able to be programmed via these means. So, the Radio was not programmed during RC5. Binaries to be programmed remain unchanged from RC3a.

• Unlike RC3a which used the black IBM dev laptop, the workspace_archives in RC4 and beyond come from the silver Lenovo µHermes laptop used to program in the cleanroom (pulled from ~/Desktop/Workspaces on that machine).

• REMINDER: Only CCS v9.1.0 is used for programming both the Watchdog and the Hercules at this point.

Operations Highlights

• Watchdog Transit (RS_KEEPALIVE) bit rate was tuned so it will be <7.78bps with CCSDS headers accounting against our allowance. This leaves enough overhead before hitting our 10bps lander buffer drain rate that we can request diagnostic data without worrying about clogging our buffer.

• Battery voltages were measured to be:

  • C1: 3.991V (3.991V)
  • C2: 7.99V (3.999V)
  • C3: 11.90V (3.910V)
  • C4: 15.89V (3.990V)
  • C5: 19.88V (3.990V)
  • VBS: 23.80V (3.920V)

• Boot loop prevention when the jumper is removed without lander power (STORAGE -> FINAL_STORAGE BLiMP modes) was tested now that we seem to be sticking to the 9600baud rate with the lander. Boot loop prevention was confirmed to still work, though comms now cut out after Hello Earth! is received (likely due to the lower baud rate).

• The connector system for connecting the PICKit to the Radio via the breakout harness has been completely revamped and is now clean and well made. Was rang out but not explicitly tested for fear of corrupting Radio’s now-confirmed-to-exist bootloader.

• MCLR was confirmed to be wired from the SBC out to the correct pin on the breakout harness (for the Radio programmer).

What’s Changed

• Added BGAPI receive forwarding from Hercules -> WD -> Ground. by @zCoCo in #156

Full Changelog: rc4...rc5

RC4

Summary

Upload of actual binaries uploaded to Iris FM1 during Release Candidate 4 (RC4) opportunity on 10/19. Includes both FSW and GSW (backend) used during RC4 since they're now both tracked on release-candidate.

GSW logs from the various interactions with the Flight Rover (FM1) during this operation can be found in transciever_logs_RC4.zip and packet_prints_RC4.zip.

Notes

• The Radio was not able to be programmed during RC4 (nor RC3) and the binary to be programmed remains the same as in RC3a.

• Unlike RC3a which used the black IBM dev laptop, the workspace_archives in RC4 come from the silver Lenovo µHermes laptop used to program in the cleanroom (pulled from ~/Desktop/Workspaces on that machine).

• REMINDER: Only CCS v9.1.0 is used for programming both the Watchdog and the Hercules at this point.

What's Changed

• Import FSW F Prime XML by @zCoCo in #41
• Fprime fsw/staging by @zCoCo in #44
• Refit FSW v1.0.0 into GSW by @zCoCo in #45
• Remerge FSW v1.0.0 to GSW by @zCoCo in #46
• Pulling PIMS-2 Command Dictionaries by @zCoCo in #49
• Pull over relevant changes from backend/hermes/rev i testing by @zCoCo in #65
• 3.4.4 Update WatchDogInterface (WDI). by @zCoCo in #140
• Bringing latest FSW defs into GSW. by @zCoCo in #141
• Revert " Bringing latest FSW defs into GSW." by @zCoCo in #142
• PR latest stable & synced GSW into RC alongside FSW. by @zCoCo in #143
• Fix Critical Topology Issues - Logs (active), Command Responses, and Command Registration work now. by @zCoCo in #144
• (4.3.0) Radio UART DFU programming works on-SBC over J33 by @zCoCo in #146

Full Changelog: rc3a-fsw...rc4

Iris Terminal 0.8.2 (Calm Collins 2)

Install Instructions:

Mac:

Download the .dmg file.
Open and follow the instructions.
General Install Notes for Mac users:

• If it gives you a “developer cannot be verified issue”, open Settings then go to Security & Privacy > General, you should see Iris Terminal was blocked… at the bottom. Click the lock to make changes then say Open Anyway.
• Once open, it’ll ask you for permissions to access your files. Say yes (this is for logging to the filesystem).

Windows:

Download the .exe file.
Open and follow the instructions.

Linux:

Download the .AppImage file.
Open and follow the instructions.

---

Notes:

An incremental improvement to Calm Collins to improve data security and user experience issues in 0.8.1 paper mission.

• Switched to user-based DB log-in.
• Fixed auto-updater warning (suppressed auto-updater in production since it's not ready for prime-time yet).

Known Bugs:

• On Windows (but not Mac OS), it takes 21s after the splashscreen closes and the main window opens for the GUI to transition in (this can be shortcut by just clicking the window, and fullscreening it with ctrl-shift-m - sometimes, but not all the time, clicking it is just enough, even just clicking the splashscreen).
  • Advise, as soon as the splashscreen closes, click the main window and then do ctrl+shift+m.
• Production app doesn't automatically open into fullscreen. You’ll need to click the window then press ctrl+shift+m to maximize. Do this again to unmaximize.
  • On a Mac, this will be control+shift+m, not command.
• DB/Rover Connection Status Reports Incorrectly
• Clocks read different times on MacOS and Windows (NSIS, Windows is wrong).

Iris Terminal 0.8.1 (Calm Collins)

Install Instructions:

Mac:

Download the .dmg file.
Open and follow the instructions.
General Install Notes for Mac users:

• If it gives you a “developer cannot be verified issue”, open Settings then go to Security & Privacy > General, you should see Iris Terminal was blocked… at the bottom. Click the lock to make changes then say Open Anyway.
• Once open, it’ll ask you for permissions to access your files. Say yes (this is for logging to the filesystem).

Windows:

Download the .exe file.
Open and follow the instructions.

Linux:

Download the .AppImage file.
Open and follow the instructions.

---

Notes:

Last release using the legacy GDS and MongoDB interface. Hold-over release to allow Frontend to run with presently supported Node, Electron, and Mongo modules.

Known Bugs:

• An unhandled promise rejection may pop up on boot. This is fine, it's just because our autoupdates aren't setup yet.
• Production app doesn't automatically open into fullscreen. You’ll need to click the window then press ctrl+shift+m to maximize. Do this again to unmaximize.
  • On a Mac, this will be control+shift+m, not command.
• DB/Rover Connection Status Reports Incorrectly
• Clocks read different times on MacOS and Windows (NSIS, Windows is wrong)

RC3a-FSW

Pre-upload dry-run of Release Candidate 3. Barring any issues discovered when interacting with Iris FM1 that require a patch, this is the exact code to be uploaded in the RC3 upload opportunity (Sept. 20/2022).

What's Changed

• PR latest WD fixes into WF121 working branch. by @zCoCo in #121
• PR RC-Ready Standalone Radio FW into FSW Radio-staging branch. by @zCoCo in #122
• First version of new flight-ready radio suite along with some new convenience features in the data pipeline like improved commanding. by @zCoCo in #123

Full Changelog: fsw-rc2...rc3a-fsw

RC3-GSW

GSW to be used during the Sep. 20/2022 RC3 code upload campaign.