By: Dave Hall
Sr. Engineer
ZIN Technologies, Inc
Brookpark, OH
David.Hall@zin-tech.com
ZIN Technologies, Inc., is an Aerospace contractor supporting the NASA Glenn Research Center in Cleveland, Ohio:
http://www.zin-tech.com
http://microgravity.grc.nasa.gov/
The project that is using Kermit is called CSLM-2 (Coarsening in Solid-Liquid Mixtures). This is a microgravity space experiment in the field of Material Science. Check out this web page for more details:
http://science.nasa.gov/headlines/y2003/07jul_coarsening.htm
The original CSLM experiment flew on the space shuttle in 1997. The CSLM-2 project is an upgrade and modification to the original CSLM instrument. The strategy in developing CSLM-2 was to improve the design of the mechanical and temperature sensing subsystems, but make minimal changes to the embedded microprocessor. The original STD-bus CPU and hard drive were retained, running MS-DOS. The basic requirements did not change — the system had to perform data logging and precision control of the experiment temperatures. Operating on the Space Station posed a new wrinkle in the requirement to get the data "back to the ground". For space shuttle missions, data was retained on the hard drive and downloaded after landing. The worst case was about a 10-day delay. On the station, the delay could be months, even before the Columbia accident. Plus, the data were needed to make decisions about future operations. Another challenge posed by the CSLM-2 computer hardware was the lack of an ethernet interface. It did have RS-232 serial ports, but most of the communication links available for payload data transfers on the station use ethernet protocols.
CSLM-2 was built as a payload for a Space Station "Facility" called the MSG (Microgravity Science Glovebox). Check out this web page for more info:
http://msad.msfc.nasa.gov/glovebox/
The MSG is an equipment rack with dedicated resources for power, cooling, instrumentation and data handling. Luckily, the MSG has a Windows laptop computer dedicated to it. This laptop has an excellent interface to exchange files with the ground support organization via ethernet. It also has a couple of serial ports available. So the hardware-layer was chosen: RS-232. The search commenced for a data-exchange protocol. The vendor for the CPU board in the CSLM-2 instrument provided a proprietary but inefficient communications program that was used (with pain) on the original CSLM project. It was not compatible with the Windows laptop. Luckily, the software engineers working CSLM-2 had used Kermit in the "old days", when a PC-XT was hot stuff. The more we looked into Kermit, the more we realized it would solve multiple problems. For the laptop-side of the connection, Kermit 95 was identified and several copies were purchased. MS-DOS Kermit was downloaded and installed on our development system. We got our copy of the book Using MS-DOS Kermit and learned the nuances of Kermit scripting. Things worked out great until we transitioned to our flight-like prototype. The development system had a few extras that are not needed on-orbit, like a floppy drive, keyboard and CRT interface. The flight system is not a desktop! The user display is an LCD array of 20 characters by 4 lines. The user controls consist of 3 toggle switches. Kermit would lock up the CPU when it was run with no display device. This type of system configuration wasn't exactly "typical", that's for sure! NASA and Zin Technologies are deeply indebted to the support organization for MS-DOS Kermit. Once we described the problem, they provided the "3.16 Beta 12-NASA" version just for us within a few days. That same software is operating flawlessly today on the space station. Try getting that kind of tech support from a bigger, more commercial software vendor! The MSG laptop has a copy of Kermit 95 installed via a CD-ROM which was launched with the CSLM-2 hardware in December, 2002.
In general, Kermit and Kermit 95 have been invaluable tools to improve our computing efficiency, both in development and in the final, operational system.
We have two modes in which Kermit runs:
Mode 1) For normal science runs, the flight code generates anywhere from 5 to about 100 data files. These need to be transferred to the MSG laptop. So the Kermit control file makes the ECU a client. Kermit 95 is run by an astronaut on the laptop in Server mode. The ECU Kermit script consists of the following (simplified) commands:
set printer nul set port 1 set speed 38400 set flow xon/xoff set retry 5 set display quiet ; First, send a testfile and retry until it succeeds :RESEND send c:\\testfile IF NOT FAILURE FORWARD ISOK: GOTO RESEND :ISOK remote delete testfile ; Send a file containing the list of data files to be sent send klist.txt run display 1 ; Executable display driver program on the ECU send file1.dat ; First of many files if failure run disperr 1 ; Display driver on the ECU run display 2 send file2.dat ; 2nd of many files if failure run disperr 2 . . .[Repeat for all data files] . run dispdone ; Local display driver remote host pkzipc -add NewZip file*.dat
The Display Driver programs being run under Kermit control place messages on the LCD array for the benefit of the astronauts who may be observing the process. "Display" writes the message "Sending File 1 of 21", etc. "Disperr" writes the message "Failed to Send File 3 of 33". "Dispdone" writes the message "Finished" plus some housekeeping info, such as the total number of records in all the files sent.
The last line is interesting. Kermit on the ECU is telling Kermit 95 on the laptop to execute a Zip archive tool. This tool zips up all the data files on the laptop that were sent over into a compressed archive. This archive is the file that gets sent back to the ground station from the laptop via Ethernet.
Mode 2) For maintenance and development, CSLM-2 has a mode we call "GSE" or Ground Support. In this mode, Kermit runs in server mode on the ECU. In development, this allowed us to "log on" to the ECU serial port via an external computer running Kermit 95 and swap files around, send over new versions of the flight code, test display drivers and etc. On the Space Station, we have an automated version of Ground Support mode available on the laptop to re-program the ECU, "just in case". Of course, the very first time that the ECU was used on orbit, it did not perform a science run. Instead, we used GSE mode to change a setup file that tells the flight code how long each science run should take.
On the laptop, the astronaut activates a windows desktop icon to run Kermit 95 in GSE mode. That shortcut will start up Kermit 95, specifying a text file with the following unique initialization commands:
set printer {(null)}
set carrier-watch off
set port com1
set speed 38400
enable all
robust
take GSE_LIST.TXT
The file GSE_LIST.TXT is a Kermit script on the laptop hard drive that can be modified or swapped out using remote commands issued from a ground station. This gives us enormous flexibility to do whatever we want to the files on the ECU hard drive via the Kermit/Kermit 95 command set. Almost anything is possible, either using the built in commands such as "send newfile", or by issuing MS-DOS commands such as "remote host erase oldfile".
Editor's notes:
[ Top ]