Release RC6 · PlanetaryRobotics/IrisRoverPackage

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:

whether the Radio's basic comms worked,
whether the Radio's power amplifier worked,
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 with an RSSI of -16dBm to -30dBm. During this time, Peregrine operators also confirmed receipt of packets from the Rover over the WiFi interface, though there was not time for us to inspect these packets for correctness (this was already performed in Iris-FlatSat testing).
- NOTE: as aforementioned, this occurred during a subsequent test; so, the logs containing these results can be found here: packet prints and transceiver logs.
- NOTE: the RPI hotspot was only turned off DURING the above test and the Rover's connection to Peregrine wasn't completed until the RADIO-DM at 11-14 06:47:21 in that log. Any prior WiFi logs are referring to FM1-RPI connection. Any subsequent logs are referring to the FM1-Peregrine connection.

NOTE: Passthrough Programming is unable to change the Rover's MAC address, so, during this stage we also read out and determined that the Rover's current MAC address is: 84:71:27:98:f1:93.

(3.3) Watchdog Update

After the above successes, remaining time was used to make the change found in 638e3b7 (Issue #181) and the Watchdog was reprogrammed with these changes in the flight-appropriate Debug_with_flag mode.
After this reprogramming, the following was observed:

Hercules comms come up in SERVICE now (immediately) but even with this, messages from Hercules were not observed until the Rover entered MISSION mode.
- SERVICE mode comms testing was performed by booting the Rover into KEEP_ALIVE mode and then running the following command aliases:
  - setup
  - power-on-system-vsa
  - 3v3-on
  - power-on-herc
Upon returning to SERVICE mode from MISSION, Hercules comms persisted.
Links to: RS422 monitoring packet prints and transceiver logs.

The new comms issue discovered here is tracked in Issue #182 .

(3.4) Portable Rover Integration Checkout Kit Connector Removal

Following all software activities, the PRICK harness connector (white cable) was removed, a new battery jumper with a RBF tag was installed, and the flight MLI was sealed.

4. Final Release Status

(4.1) Completed Issues

(4.2) Fixes and Features that didn’t make it into this release (RC6)

(4.2.1) Known Bugs

(4.2.1.a) bug-impactful: could potentially degrade mission objectives

(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

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

(4.2.2) Known Important Missing Features

_CRITICAL: Features that have the potential to expand mission success

(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.

(4.2.4) Known Missing Retests

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

#165
#178

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

#157
#160

What's Changed (Overview)

FM1 + Peregrine Payload Functional Test (PFT) Complete. by @zCoCo in #174
Bidirectional Asynchronous BGAPI Passthrough added to Hercules. by @zCoCo in #175
Bidirectional Asynchronous BGAPI Passthrough added to Hercules (again) by @zCoCo in #176
Pull latest RC changes into 152. by @zCoCo in #177
Also (PR happened immediately after RC6 release b/c it was into release-candidate): BGAPI PASSTHROUGH PROGRAMMING WORKS (+RC6 Complete) by @zCoCo in #192