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.
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.
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.
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() 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.
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.
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.
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() 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.
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
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
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
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.
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.
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
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.
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)
ID Name 0 RAMINFO_EV_MIN 1 VARINFO_EV_MIN
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-- 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 UsageEric Zager