Flight Recorder Software

Abstract

This paper describes the hardware and software developed to implement an on-board computer for the JACEE-11 and JACEE-12 long duration balloon flights. The primary goals of this computer were to activate a motor when crossing atmospheric pressure thresholds, and to monitor the status of a set of temperature sensors. In addition, this computer interfaced to NASA's Scientific Information Package (SIP), providing additional flight data and two way communication with the ground.

Hardware

The heart of the flight computer is a Toshiba 68301 single chip microprocessor. Included are 768K dynamic memory, 256K for static programs, three serial ports, and 16 digital inputs and outputs. The CPU was connected to an analog board consisting of a high speed analog to digital converter multiplexed to sixteen inputs.

The analog inputs were used to sample our pressure sensor and ten temperature sensors. The digital output drove the shifter motor, and digital inputs read the status of limit switches, providing feedback for the motor. One serial port was used as a software development aid, while the other two provided the link to the SIP.

SIP

The SIP is NASA's collection of flight computers. It controls ballasting, valving, and terminate operations, obtains position and altitude fixes though the Global Positioning System (GPS), reads atmospheric pressure, and transmits telemetry to the ground. The SIP has two sides: the HF/PTT side, and the INMARSAT side. Each side performs the same function, but uses different communication links. The HF/PTT side receives data through a high frequency radio link, and transmits data to the ARGOS satellite system. The INMARSAT side uses INMARSAT satellites for both transmission and receipt of data. Both sides include a serial interface which may be used by the scientific payload.

Flight Recorder Software

Blackbox is the name given to the flight recorder software. It was written in C and cross compiled from an IBM PC using the OS9 C compiler.

The overall structure of Blackbox is similar to that of event-driven programs. A main loop continuously calls subroutines, each of which returns as soon as possible. For instance, when a character is received over one of the serial lines, a subroutine adds this character to a buffer, then checks to see if a complete command has been formed. If not, it returns to the main loop rather than waiting for the remaining characters of the command. This structure allows Blackbox to handle its separate tasks concurrently.

A special feature of Blackbox is that it will restart after a power interruption or program crash with no loss of data. The flight logs and program data are stored in battery-backed RAM. Upon a reboot, Blackbox will recover itself gracefully using these records. To prevent unexpected lockups, a "watchdog timer" is integrated into the system-level code. Blackbox continually resets a countdown timer to three minutes. During normal operation, this timer will never expire. Should the software become stuck in an unexpected loop, the timer runs out, triggering a reboot. Blackbox then restarts itself as if from a power interruption.

The major subroutines of Blackbox are UpdateSensors(), UpdateLog(), MaintainShifter(), ServiceComm(), and ServiceTTY(). Each is briefly discussed in the following sections.

UpdateSensors()

UpdateSensors() periodically reads the values of the various sensors available and stores their values in a temporary buffer. When another routine accesses the value of a sensor, it actually reads the value from this buffer. This was done to save time in other routines, since reading sensors is typically a slow process. UpdateSensors() keeps close track of the pressure sensor and limit switches, since these are critical to the motor's operation. Temperature sensors are read every minute, and requests for the SIP's data are sent on the same interval. The SIP's responses are handled by ServiceComm(). UpdateSensors() alternates sending queries to each side of the SIP. Both sides should respond with the same data. If one side should fail, the data from the other is still present as a backup.

UpdateLog()

New data is periodically added to the flight logs by UpdateLog(). Blackbox maintains two types of logs: a data log, and an event log. Both occupy the memory area which is preserved by an internal battery. 192K is reserved for the data log, and roughly 64K for the event log.

The data log is a sampling of the various sensors and program status recorded at regular intervals. Data is packed into a binary format for maximum efficiency, each entry occupying 46 bytes. By default the data log is written every twelve minutes, allowing a total record in excess of 800 hours. To guard against the possibility of single event upsets, a checksum is calculated as part of each entry. In addition, if the memory pointers used to access the log are discovered to be corrupt, the log would be turned off to avoid the possibly disastrous effects of referencing an invalid pointer.

The event log compliments the data log by recording the exact time of a specific action taken by the program, such as activating the motor, or handling a command from the ground. It is not written at regular intervals like the data log. Instead, it may be written by any subroutine when a noteworthy condition is encountered.

A description of the contents of the data log, and possible entries in the event log may be found in Appendix I.

MaintainShifter()

The responsibility for holding the shifter in a desired state falls to MaintainShifter(). A desired state for the shifter is determined based upon the pressure sensors, then this state is compared to the actual state reported by the limit switches. If these states are unequal, the MaintainShifter() activates the motor. Should the shifter tray be bumped during launch, this logic ensures that it will be returned to the appropriate condition. If the desired state is not reached in fifteen seconds, the motor is turned off, and another attempt made. The motor is disabled if the desired state is not achieved in four attempts.

MaintainShifter() is the only exception to the rule that all subroutines exit quickly. While the motor is on, MaintainShifter holds the attention of the CPU until the motor is again turned off. This was done to prevent another subroutine from interfering with the timing of the shift. It is probably unnecessary since all others are comparatively fast, but is done to be on the safe side. A typical shift takes roughly ten seconds. The CPU's serial buffers would be sufficient to handle most incoming messages during this time.

ServiceComm()

Messages from the SIP are handled through ServiceComm(). Since the two SIP interfaces are nearly identical, they are handled by the same routine. If a new character is available from the SIP, it is added to the end of an input buffer. If the buffer forms a complete message, that message is decoded and appropriate actions taken.

Most of the messages from the SIP appear in response to data requests sent by UpdateSensors(). These include GPS position reports and readings of the SIP's pressure sensors. When these are encountered, values in a global data buffer are updated, to be used by other routines.

Another SIP message is a request for data. When this message appears, the SIP is ready to receive data from Blackbox to be downlinked to the ground station. Unfortunately, this message is not a guarantee that the data will be downlinked. Two different data blocks are defined by Blackbox for these transmission opportunities, each matched to the capability of the SIP's communication link. The SIP can downlink 28 byte packets on the ARGOS satellite system, and up to 256 bytes on the INMARSAT system. Accordingly, the packets sent over ARGOS contain the maximum amount of critical data which will fit into the small packet, including the current values of all sensors, and some useful indications of Blackbox's status. INMARSAT packets add values from the SIP, more indicators of program status, recent records from the event log, and up to two entries read from the data log. By default, these entries will be data which is 18 and 36 hours old. The old data is included to make up for the possibility of gaps in INMARSAT coverage.

The final message which might be received from the SIP is a command relayed from the ground station. These commands can alter many of the parameters used by Blackbox during flight. Commands are checked to ensure that no transmission errors occurred, then executed.

Descriptions of the SIP messages, data packets, and ground commands may be found in Appendix II.

ServiceTTY()

ServiceTTY() is very similar to ServiceComm(), except that the input is read from the single serial port not connected to the SIP. In flight there is no connection to this port; this port exists only as a diagnostic tool. The commands expected are in human-readable text to facilitate debugging.

Appendix I: Internal Log Format

Data Log

The data log is made up of fixed length records written at regular intervals. Each record is 46 bytes long, and is called a packed node. The purpose of the data log is to store the values of the various sensors.

	Name		Type	Description
	CPU_timeL	word	bits 0-15 of the internal CPU time,
				measured in seconds
	SIP_baratron_L	 "	ADC counts of SIP low altitude pressure sensor
        SIP_baratron_M	 "	 " middle altitude "
        SIP_baratron_H	 "	 " high altitude "
        GPS_time	float	GPS time of week, in seconds since
				midnight, Sunday, GMT
        GPS_long	 "	GPS longitude
	GPS_lat		 "	GPS latitude
	GPS_alt		 "	GPS latitude, in meters
        temperature[16]	byte	bit-packed values of 12 temperature
				sensors.  temperature[15] holds
				CPU_Time bits 16-23
        gps_status[2]	 "	describe the validity of GPS readings
	baraShift[2] 	 "	ADC counts for internal pressure, and
				shifter state flags.  ADC bits 0-7 are
				in baraShift[0].  Bits 8-11 are the
				the lower nibble of baraShift[1].
				Shifter sensor flags are bits 4-5 of 
				baraShift[1]
	checksum	word	byte-wise checksum of this data packet

Event Log

The event log may be written to at any time, and contains records of varying length. The different Blackbox functions write to this log to report on the program status.

	Byte	Name		Description	
	0	ID		Upper nibble is major event number
				Lower nibble is minor event number
	1-3	CPUTime		Internal CPU time when event was recorded
				Byte 1 is the MSB, byte 3 is the LSB
	4...	varies

Major Event Types

	ID	Name		Length	Description
	0	TEMP_EV_MAJ	6	Temperature sensor value
	1	BARA_EV_MAJ	6	Internal pressure sensor value
	2	SIP_POS_EV_MAJ		GPS position
	3	SIP_TIME_EV_MAJ		GPS time
	4	SHIFT_EV_MAJ	5	Shifter-related action
	8	PROG_EV_MAJ	4	Misc. Program event
	9	RCPT_EV_MAJ	6	Receipt of command from ground
	A	MOTOR_EV_MAJ	4	Motor-related action
	B	PROGINFO_EV_MAJ		Recording of program status
	F	DATA_EV_MAJ	47	Recording of data

Minor Event Types - Baratron

	ID	Name
	0	BARA_INT_EV_MIN
	1	BARA_SIP_L_EV_MIN
	2	BARA_SIP_M_EV_MIN
	3	BARA_SIP_H_EV_MIN
	4	BARA_SHIFT_EV_MIN

Bytes 4 and 5 contain the value of the given pressure sensor. Byte 4 is the MSB, 5 is the LSB.

Minor Event Types - Shift

	ID	Name
	0	SHIFT_DATA_EV_MIN	Recording of shifter states
	1	AUTOSHIFT_ON_EV_MIN	Automatic shifts activated
	2	AUTOSHIFT_OFF_EV_MIN	Automatic shifts deactivated

Byte 4 contains shifter data. Bit 0 is the reading of the reverse (low altitude) limit switch; bit 1, the forward limit switch.

Minor Event Types - PROG

	ID	Name
	0	STARTUP_EV_MIN		Program startup
	1	LOWBATT_EV_MIN		Low battery warning
	2	PROGEND_EV_MIN		Program termination	
	3	SETIME_EV_MIN		Internal clock changed
	4	CLEARLOG_EV_MIN		Data and event logs cleared
	5	CLEARGLO_EV_MIN		Global variables cleared
	6	COLDSTART_EV_MIN	Program startup- static memory lost
	FF	ERROR_EV_MIN		Misc. error

Minor Event Types - RCPT

	ID	Name
	0	RCPT_OK_EV_MIN		Command received from ground
	1	RCPT_NAK_EV_MIN		Garbled information received

Bytes 4 and 5 contain the two-byte code message received from the SIP. See Appendix II for the format of these bytes.

Minor Event Types - MOTOR

	ID	Name
	0	MOTOR_LOW_EV_MIN	Successful shift to low position
	1	MOTOR_HI_EV_MIN		Successful shift to high position
	2	MOTOR_FAIL_EV_MIN	Failure trying to shift
	3	MOTOR_DISABLE_EV_MIN	Motor disabled
	4	MOTOR_ENABLE_EV_MIN	Motor enabled
	5	ATTEMPT_FOR_EV_MIN	Attempt to shift forward (high)
	6	ATTEMPT_REV_EV_MIN	Attempt to shift reverse (low)

Minor Event Types - INFO

	ID	Name
	0	RAMINFO_EV_MIN		
	1	VARINFO_EV_MIN

Minor Event Types - DATA

	ID	Name
	0	CURDATA_EV_MIN		Data packet is current
	1	BACKDATA_EV_MIN		Data packet is old
    

Bytes 1-46 are a packed node, as written to the data log. See the section above titled "Data Log" for a description.

Appendix II

APPENDIX II-- Communication Formats

ARGOS Packet
ARGOS Packets are sent through the ARGOS communication satellites.
When in satellite coverage, packets are received roughly every ten
minutes, with coverage being lost for several hours at a time.  ARGOS
packets must fit into 29 bytes.

	Name		Type	Description
	packetNum	Word	nth packet sent to SIP
	CPUTimeL	 "	bits 0-15 of cpu time when this packet was sent
	shiftHighThresh	 "	pressure threshold for a shift to high
				altitude position
	shiftLowThresh	 "	same for low altitude
	baratron	 "	pressure sensor value
	temperature[16] char	packed temperature sensor values
				temperature[15] holds CPUTime bits 16-23
	progStat[2]	 "	Program status indicators
				Byte 0
				bits 0-2	servo error count
				bits 3-5	position error count
				bit 6		motor enabled flag
				bit 7		autoshift enabled flag

				Byte 1
				bits 0-3	Log interval code
				bits 4-5	Autoshift pressure sensor
						00 - Internal
						01 - SIP L
						02 - SIP M
						03 - SIP H
				bit 6		Forward limit switch value
				bit 7		Reverse limit switch value


INMARSAT Packet 

INMARSAT packets are sent and received through
INMARSAT satellites.  Antarctic coverage by this network is poor, so
the balloon may be out of coverage for days at a time.  These packets
may be up to 256 bytes long.  Blackbox writes variable length packets,
depending upon the content of its logs.

	Name		Length		Description
	current data	47 bytes	Current data event
	program info	?		Program Info event
	events		<= 83 bytes	Most recent events recorded
	(old data)	47 bytes	Old data event - optional
	(old data)	47 bytes	Old data event - optional

The INMARSAT packet is a block of events.  For the description of
these event packets, see Appendix I.  A current data and program info
event are always written.  Next are events taken from the top of the
event log; as many as fit into 83 bytes.  Finally, if the data log is
sufficently long, a record from the data log 18 hours old is written,
followed by one 36 hours old.  These old packets are to help make up
for sparse INMARSAT coverage.


Command Packet

Commands may be sent to the flight recorder through either INMARSAT
satellites or an HF radio link.  The command format through either
link is the same, and fits into two bytes.  There are two types of
command.  The first allows the shifting thresholds to be modified.
The remaining commands are broken down into major and minor numbers.

	Byte 0

	Bit	Value/Name
	7	0
	6	1
	5	0
	4-3	ck
	2	th
	1	l/h
	0	b

	Byte 1 - th = 0
	Bit	Name/value
	7	1
	6	0
	5-3	major
	2-0	minor

ck is a 3 bit checksum of these two bytes, exclusive of the ck bits.

If th is 1, byte 1 is an eight bit value to be written to one of the
16 bit shift thresholds.  l/h specifies which threshold to be
written to: 0 indicates the low threshold, 1 indicates high.  b
specifies which byte of the threshold to write: 0 indicates the low
byte, 1 indicates high.

If th is 0, l/h and b are unused.  major and minor are the major and
minor numbers of a command as specified below:

Science Commands:

	Major	Description	Minor	Description
	0	Auto shift	0	off
				1	on

	1	Shift Now	0	shift to low / reverse
				1	shift to high / forward

	2	Motor Control	0	disable motor
				1	enable motor

	3	Select Shift	0	internal
		Baratron	1	SIP L
				2	SIP M
				3	SIP H

	4	Data Log	0	30 seconds
		Interval	1	1 minute
				2	2 minutes
				3	5 minutes
				4	10 minutes
				5	12 minutes
				6	15 minutes
				7	30 minutes

	5	unimplemented	-	-

	6	Reset		2	Reset global variables
				5	Reset permanent log

	7	Inquire		0	RAM Usage
Eric Zager