The firmware is the onboard computer system for the satellite. This system is the backbone for communication between systems, allowing for the satellite to function toward our Mission Goals.
Summer 2002:
- Aaron Hall
Michael Wood Mark Mussetter Matthew Garner
This system is centered around a Motorola MC68HC812A4 (HC12) microcontroller. This microcontroller was chosen for its speed, processing power, and build in features such as eight built in Analog to Digital converters, two sets of serial interfaces, multiple interrupts both software and hardware, but mostly because it is the micro controller used in computer engineering here at Montana State University. This chip was supplied complete on a prototype board by Kevin Ross of the Seattle Robotics Society.
We are using Integrated
Device Technology CMOS Supersync FIFO IDT72291which is 128KBytes.
This memory was chosen because of its conveinient physical and memory size
and the FIFO (First-In First-Out) eases the programming and interface significantly.
With the memory chosen the housekeeping, attitude, and payload data must
share the 150KBytes that we have available.
The system is written to use a main loop that is as small as possible, in this case the main loop consists of listening to the receiver and seeing if the state of the battery needs to be changed (i.e. start/stop charging). This loop then is interrupted to do the various other routines that need to be done. The advantage of this is the modularity of the system allows future missions to add interrupt routines (ISR's) without modification of the main loop.
The bitstream or data stream of MEROPE has been set up maximize the available stored data that will fit in the 150 KBytes of memory that we have available. The system has been broken up into three different data sets.
The telemetry set is the housekeeping information of the satellite this consists of battery temperature, battery voltage, battery charge state, processor temperature, bus voltage, and high voltage. This information is collected every 60 seconds of the mission lifetime. This data is stored in a given order for decoding on the ground. The stored information consists of all the values and the time at which the values were collected. To get this time there are "hard time stamps" which are the absolute mission elapsted time (MET) and "soft time stamps" that give the time since the last stamp. Since these occur at regular intervals we don't need to collect the soft time stamp times only that data since 60 seconds is known.
The attitude set is information on which side or sides are in the sun at any given time. This is useful information to evaluate the attitude control system and to give information that can be used for future missions to tune communications more carefully to maximize the transmission power from the satellite. This like the telemetry stores which sides are in the sun and the "hard time" and the "soft time" for each data point.
The payload set is the data collected from the Geiger tube.
The tube outputs a TTL level logic pulse for every intercepted cosmic ray.
These pulses are counted by the processor and then every N counts the
processor writes to memory a time stamp. The beauty of this system
is that since the number of counts per stamp, N, is fixed we don't need to
store that data only the time at which the data occurred.
| Name | Description | TS-bits | Data-bits | Total-bits |
| PHTS | "11111111" 8-bits | 24 | 0 | 32 |
| PSTS | "11110000" 8-bits | 16 | 0 | 24 |
| AHTS | "00001111" 8-bits | 24 | 8 | 40 |
| ASTS | "11001100" 8-bits | 0 | 8 | 16 |
| THTS | "00110011" 8-bits | 24 | 48 | 80 |
| TSTS | "11100011" 8-bits | 0 | 48 | 56 |
The bitstream was overhauled after more thought about burst errors in the communiucation system. Meaning it wasn't clear that if a hard-time stamp was lost if we still could understand the soft-time stamps that followed without numbering the soft-time stamps. Therefore it was modified to a simpilier and only slightly larger format.
| Name |
Description |
TS-bits |
Data-bits |
Total-bits |
| PHTS |
"11111111" 8-bits |
24 |
0 |
32 |
| AHTS |
"11110000" 8-bits |
18 |
6 |
32 |
| THTS |
"00110011" 8-bits |
24 |
6*8=48 |
80 |
When one calculates the time per data dump to the ground station
and the number of attitude and payload stamps that occur you can find what
the counts per stamp from the payload have to be. It is a balancing
act between the payload and other systems for memory space.
| 12 hours between data dumps | |||
| Attitude on 3 second intervals | 14400 Attitude Points |
9504 attitude points assuming no data in 33% dark cycle |
38016 bytes |
| Telemetry (housekeeping) on 60 second intervals | 720 Housekeeping Points |
7200 bytes |
|
| Payload on N count interval | |||
| That leaves 85856 Bytes for the payload | Which is 21464 stamps |
||
| So to find N you take the expected total number of counts per dump and divide by the number of payload data points per dump. |
Now this is all fine and dandy if one can transmit
the whole 124 kbytes in a comm cycle. Unfortunetly in a 10 minute window
at 1200 baud you can only transmit 90000 bytes. Which lowers the number
of payload stamps significantly. This is still being studied to determine
the best sharing of the available starage space.
Return to the top of the page
This will be added after launch and more extensive testing has been
performed .... please check back soon!
Return to the top of the page
