Runtime Console Commands

BTConsole (libSensorModules/BTConsole.cs) implements a small command interpreter that is active at all times the mission is running — unlike Factory Mode, which is a separate interactive session (FactoryConsole) that must be explicitly entered with $$$ and takes over the Bluetooth port while active. Runtime commands require no session setup: they are single-line messages that can arrive at any time from either of two sources:

  • Bluetooth console (COM4) — sent directly over the same physical serial link used for Factory Mode, whenever a Factory Mode session isn't in progress.
  • Iridium MT-SBD downlink — NAL_A3LAR.processMessage() (libSensorModules/IModem.cs) forwards any inbound Iridium message whose first byte is $ straight to BTConsole.processConsoleCommand(). This is the mechanism shore operators use to send commands to a deployed float — see Iridium Communications.

Both paths call the same method, so the command set and syntax below apply identically to either transport.

Message Format

$COMMAND<CR>
$COMMAND,value<CR>
  • Every message starts with $ and ends with a carriage return (<CR>, byte 13). On the Bluetooth UART this $ also serves as the hardware framing byte (STX); on Iridium it's just the first character of the MT message text.
  • Command names are case-insensitive (processConsoleCommand upper-cases before matching).
  • A command may take at most one numeric argument, separated from the command name by a comma. Arguments are parsed with double.Parse, then cast to int or used as-is depending on the command.
  • Only one command per message is processed — text after the first <CR> is ignored. (A semicolon-separated multi-command form, e.g. $PARKTIME,5;$PARKPRESSURE,30;, appears in a canned test message in IModem.cs but is not actually supported by the current parser.)
  • Unrecognized no-argument commands get Invalid command, try again echoed back over the Bluetooth line. Unrecognized commands with an argument are silently dropped — there's no default case in that branch of the switch.

Commands With an Argument

$SIMP,<pressure>

Sets an internal simulated pressure value used for bench testing. Not currently read by any other module — setting it has no observable effect on mission behavior in the current build.

$SIMP,10.5<CR>

$UPENGR,<file number>

Flags an engineering log file for upload by setting SV.UploadEngrFile = true and recording the requested file number. As with SIMP, nothing in the current codebase reads SV.UploadEngrFile back out, so this currently has no downstream effect.

$UPENGR,3<CR>

$MAXPROFILES,<n>

Sets the maximum number of profiles for the mission. Valid range: 1–200. Out-of-range values are rejected with a logged message and no state change.

Fires the UpdateMissionMaxProfiles event, which is wired (in CPF/Program.cs) to both Mission.updateMissionMaxProfiles and SystemConfigManager.UpdateMissionMaxProfiles — so this also persists to config.xml.

$MAXPROFILES,50<CR>

$MISSIONTIMEOUT,<hours>

Sets the mission timeout, in hours. Valid range: 1–1440 (60 days). Updates Mission and SystemConfigManager via the UpdateMissionTimeoutHours event.

$MISSIONTIMEOUT,720<CR>

$PARKTIME,<seconds>

Sets the park (bottom/anchor) time, in seconds. Valid range: 1–172799 (just under 2 days). Updates via the UpdateParkTime event.

$PARKTIME,7200<CR>

$PARKPRESSURE,<dbar>

Sets the target park pressure/depth, in dbar. Valid range: >4 and <300. Updates via the UpdateParkPressure event.

$PARKPRESSURE,150<CR>

$PARKSAMPLE,<seconds>

Sets the park sampling period, in seconds. Valid range: 1–172799. Fires the UpdateParkSamplePeriod event and directly assigns SystemConfigManager.MissionParkSamplePeriodMinutes to the raw argument value — note the field name says "minutes" but the command's own range check and argument name treat it as seconds.

$PARKSAMPLE,300<CR>

Commands Without an Argument

Command Effect
$GETDIR Calls EngrLogger.getDirectory() to print the SD card data directory listing, and sets DirectoryValid = true.
$GO Sets SV.SurfaceOpsGo = true, signaling the state machine to proceed/depart from the current surface-ops wait.
$RECOVERYTRUE Sets SV.ForceRecoveryState = true, forcing the float into recovery mode. Logs the reason as "[ERROR] RECOVERYTRUE cmd from console".
$RECOVERYFALSE Clears SV.ForceRecoveryState, taking the float out of forced recovery mode.
$STARTDOG Starts the hardware watchdog timer (WatchDog.startWatchdog()).
$FAKEMTSBD Calls NAL_A3LAR.fakeMTSBD() to inject a simulated Iridium MT-SBD message for testing. In the current build this method's body is commented out, so the command is a no-op.
$SURFACEOPS Forces the state machine into the surfaceOps state (SV.CurrentState = surfaceOps, SV.DoStateEntry = true).
$EXIT Requests a halt: sets SV.DoStateEntry = true and SV.CurrentState = exit.

Examples:

$GO<CR>
$RECOVERYTRUE<CR>
$EXIT<CR>

Notes

  • BTConsole is a singleton (BTConsole.Instance) that owns the Bluetooth UART (COM4, 115200 8N1, power channel 3 / BluetoothChannel). powerUp() / powerDown() gate the channel and attach/detach EngrLogger.SendConsoleLine so engineering log lines are echoed to the console while it's powered.
  • This command set is distinct from, and does not overlap with, the Factory Mode command set (help, dir, pow, pump, etc.), which is implemented in a separate class, FactoryConsole, and temporarily takes exclusive control of the same UART.
  • Several $GO / $RECOVERYTRUE / $RECOVERYFALSE / $STARTDOG / $FAKEMTSBD / $EXIT actions are also exposed as cpf <action> inside Factory Mode — those call into the same underlying SV flags and static methods, just through a different entry point.
  • Every message that starts with a value other than $ from the Iridium path is ignored by NAL_A3LAR.processMessage() before it ever reaches BTConsole — only true command downlinks are routed here.