The flight computer used is an SC4A Single Board Spaceflight Computer developed by Southwest Research Institute (SwRI). Instrumentation and Space Research Division. It includes a 16-bit 80C186 central processor with a clock frequency of 10 MHz. It is MS-DOS and VRTX compatible. The throughput capacity is estimated at 0.77 MIPS. On-board memory includes 512K Bytes RAM, 256K Bytes EEPROM, and 64K Bytes UVPROM all with error detection and correction. Up to 24M Bytes of mass memory is also provided. Communication capability includes 32 12-bit analog input channels, 4 12-bit analog output channels, a two channel RS-422 Serial I/O port, and 16 input/output Parallel I/O (total 32). The computer uses memory mapped I/O, providing 16 bit word reads or writes per instruction cycle. Along with interrupts, this will be the main method of interface to the computer.

SNOE uses a packetized telemetry data scheme based upon the recommendations by the Consultative Committee for Space Data Systems (CCSDS). The CCSDS is an international organization composed of representatives from the world's space agencies. Compared to a traditional time-division multiplexed telemetry system, packetized telemetry systems provide substantial design freedom: any number of different packets can be developed to hold the spacecraft's science, engineering and ancillary data. Generating packets sometimes involves complex sets of functions that are, just as all functions performed by the SNOE software, grouped into software modules. Since the SNOE software handles functions traditionally implemented in hardware, the software modules are called from a main loop that is rigorously deterministic in its timing.

Both telemetry channels utilize fixed-length transfer frames with variable-length source packets inside the frames. The transfer frame lengths on each channel are not equal, since each is derived from transmission rate and desired frame update rate. The desired real-time frame update rate is nominally 2 seconds, a value based solely on the desires of mission operators. This equates to a frame length of 1024 bits on the low-rate channel. Frame length selection on the high-rate channel, discussed below, is more involved. Simple CRC error checking is performed on a frame-by-frame basis, as neither telemetry stream is Reed-Solomon encoded. Additionally, SNOE will not utilize the optional transfer frame secondary header. The transfer frame overhead then equates to a header of 48 bits, a 32-bit trailer for a Frame Acceptance and Reporting Mechanism (FARM)2, and a 16-bit CRC code, for a total of 96 bits. This leaves a 464 bps real-time bandwidth for data on the low-rate channel.

Originally, SNOE designers intended to utilize the high-rate channel solely for playback data. The bandwidth analysis for the high-rate channel would then be identical to the low-rate. However, if the SNOE team used the low-rate channel as the only means to a real-time communication link, telemetering anything but engineering data on the low-rate channel would effectively choke the bandwidth and cause severely increased engineering data update delays for the ground crew. In other words, the operations team would have to settle for either engineering data only, science data with limited engineering data, or neither during a memory dump. Clearly, the limited bandwidth on the low-rate channel complicates the downlink. Therefore, SNOE uses part of the high-rate channel as a "virtual" low-rate channel for real-time communications.

The available bandwidth for each channel is used to hold flexible data structures called "Source Packets." The SNOE telemetry system allows for packets to overlap frame boundaries in both the low-rate and high-rate channels. This unconventional design decision maximizes the bandwidth use, eliminating the so-called "slop", or unused portion of a transfer frame. Most telemetry systems steer clear of this technique due to the fact that a loss of a single frame may affect data in adjacent frames. The SNOE team can afford this risk since loss of an occasional piece of data does not cripple the SNOE science objectives. This is a classic example of a small satellite trade-off that the SNOE engineering team has used to its advantage.

Pre-defined packet descriptions:

• Communication Status
  use: command verification and comm. link status
  update rate: 2 seconds
• Subsystem Status
  use: ADCS, instrument status, C&DH parameters
  update rate: Spin Period
• General Engineering
  use: Temperatures, Power, C&DH Parameters
  update: 60 seconds
• Critical Engineering (Contains duplicate items from main three engineering packets for low-rate channel science telemetry mode)
  use: Minimal command verification, comm. link status, power, ADCS, and C&DH parameters.
  update rate: 6 seconds

Programmable Telemetry Packets

Although it is a term typically viewed with trepidation, SNOE uses 'programmable' telemetry: items in some packets can be selected in a custom manner during flight. There are two such packets on-board the spacecraft: the Programmable Rapid Sample Packet and the Programmable Engineering Packet. Each telemetry item on-board is associated with an ID. These ID's are then used to populate the programmable packets through ground commands. Both packets limit the total number of items in each, but neither pre-define the contents of any 'slot' within a packet. The Rapid Sample Packet allows operations personnel to specify which telemetry ID's, and hence which telemetry items, to sample as fast as 10 Hz. Due to the high frequency capability, only four items are allowed at a time. When commanded, the flight software will then sample the four telemetry items and plac ten consecutive samples of each in the packet for transmission. The Programmable Engineering Packet allows for a larger set of items (up to 28) at frequency ranges much lower than the Rapid Sample Packet. These packets provide a flexible means of de-bugging problems on the spacecraft, as well as allowing for telemetry arrangements not anticipated by the pre-defined packets.