Internet based Real-Time Telemetry System for the micro-satellite in Low Earth Orbit C. W. Park 1,.G Réhel 1, P. Olivier 2, J. Cimon 2, B. Piyau 1,and L. Dion 2. 1 Université du Québec à Rimouski, Rimouski, Québec, G5L 3A1, Canada. 2 Cégep à Rimouski, Rimouski, Québec, G5L 3A1, Canada. 1 Introduction The telemetry system is one of the key systems in satellite that verify the state of satellite during the life of time of the satellite in orbit. Especially it is very important during the stage of initial operation phase when satellite is launched and until the attitude of the satellite is stabilized on the planed position. Specially the satellite in LEO (Low Earth Orbit) in 800 to 1300 Km for the Earth the duration of time of communication between satellite and ground control station is only 10 20 minutes each time. After the satellite goes to the other part of the Earth the satellite control base station can not receive the telemetry signal for the satellite. Thus the most of organisations have two or more satellite control base station in Earth in the other part of the Earth with cooperation other countries. The received satellite telemetry signal in the second or third base station is through communication network sent to the main control base station centre to verify all the parameter of satellite with delay. But during the initial operation period after launch satellite it is needed to verify the telemetry data in satellite continuously in real-time such as attitude of satellite, power generation of the satellite etc. Also some satellite project engaging by many organizations it is necessity of verifying the each module of Bus system or each payload status of the satellite by each group who is in charge of each module. In the case of international cooperation program we have difficulty to send each telemetry data in real-time to the each organization because of geographical location. In this paper we propose internet based real time telemetry distribution system to broadcast the telemetry data from any control base station in the world through telemetry web site. Any control station or other related person can access the telemetry web site to verify their interesting telemetry data in real-time with permission. This kind of real time telemetry broadcasting system is cost-effective solution for small organization that has a limit to access the large private communication network infrastructure to send and receive the data in real time. Currently many universities in the world participates nano-satellite, microsatellite, or small satellite program. This proposed internet based real-time telemetry system will be very useful for the above organizations to reduce the cost of operation owing to the current stable internet infrastructure in the world. This system consists of ground base station to receive the telemetry signal from satellite including antennas, satellite tracking system, receiver, transmitter, modulator, and
demodulator sub-system, with interface board to give all the telemetry information to the telemetry PC. The received telemetry data will be extracted, archived, displayed and published across web in real time. In this paper we will demonstrate the hardware structure of this system, related software requirement. 2 Overview of a OSCAR Ground Station In our project we concentrate the digital satellite systems used by the PACSAT- style satellite originated by AMSAT and the many universities, such as University of Surrey and KAIST (Korean Institute of Science Technology). 2.1 Ground Station Configuration The hardware configuration of the ground station is illustrated in Figure1. Polarisation switch Amplifier motor unit Radio Radio controller Antenna direction & Polarisation controller Modem Figure 1: An overview of the Ground Station Hardware Configuration The computer and radio work together, with the computer directing station activities and the radio providing communication. The hardware consists of the following components: Transmit Antenna Receiving Antenna Antenna Rotator Rotator Controllers Low Noise Amplifier Transceiver Personal Computer Satellite Tracking Software Terminal Node Controller
2.2 Oscar Communication System The communication system is organized in layers, with each layer providing services to the layer above and using the services of the layer below. Thus, while the net result is communication between the ground station computer and its counterpart on board the spacecraft, information must traverse a protocol stack (Figure2) from the application down to the radio link, travel between two systems on the radio link, then traverse a second protocol stack from the lowest level back to the highest level before arriving at its destination. Ground Station Spacecraft WisP PB/FTL0 AX.25 AX.25 HDLC HDLC Modem Modem Radio Radio Figure 2: The Layers of a satellite Communication System AX.25: Amateur satellite Communications use the AX.25 protocol. This is a derivative of standard X.25 protocol, with enhancements and adaptations for amateur radio use.[1] HDLC: Like AX.25, HDLC (High-Level Datalink Control) defines an elaborate protocol. For satellite AX.25 purposes HDLC merely defines a line code [2]. A line code alters the data stream in order to better adapt it to the transmission medium. In the present case HDLC provides three functions: Bit stuffing NRZI (Non Return to Zero Inverted) differential encoding Frame delimiting KISS: KISS (Keep in Simple, Stupid) is means of encapsulating AX.25 datagram for transmission over serial lines [3]. A frame transmitted by KISS is a complete AX.25 frame without the checksum or HDLC encoding. On transmission the TNC (Terminal Node Controller) will compute the CRC (Cyclic Redundancy Check) and perform HDLC encoding. On reception it is the task of the TNC to remove the HDLC encoding and validate the checksum before making the frame available to the host. Frame CMD AX.25 datagram Frame Figure 3: The layout of KISS frame Modem: MSK (Minimum Shift Keying) is presently in use on OSCAR (Orbiting Satellite Carrying Amateur Radio) satellites such as UO-22, KO-21, KO-25 and TO-31. PB: PB (PACSAT Broadcast Protocol) is the protocol used for downloaded on current satellites [4]. PB protocol is the protocol currently in use for file transfer on the amateur satellite Listed in Tables 1. UO-22 KO-23 KO-25 TO-31 UO-36 Satellite Downlink 9600 baud MSK 9600 baud MSK 9600 baud MSK 9600 baud MSK 9600 baud MSK 38400baud MSK Table 1: Amateur Satellite using PB
FTL0 (File Transfer Level 0) is used for uploads. 2.3 Oscar Telemetry System 2.3.1 Telemetry Beacon Format Almost of all OSCAR satellites transmit a telemetries beacon. In addition to basic states of health announcement ( Here I am ), such beacons provide a real time state of the spacecraft. Most of recent micro-satellite such as UO-22 and TO-31 use encoded beacon. Each beacon transmission is contained in an AX.25 UI frame. Under this format beacon transmission consist of following items: Time stamp (32 bit Unix Time, the number of seconds since 0000 UTC 1 January 1970) List of telemetry observation values (16 bits quantities, where 12 bits are devoted to the observation and the remaining four bits are control information). Encoding (binary) Meaning 0000 Telemetry value is the sample for the current channel. Move to next channel 0001 Telemetry value is the sample for the current channel. Stay on this channel 0010 Telemetry value is the channel number for the next observation Checksum 2.3.2 Whole Orbit Data format Figure 4: Control Information of UO-3 format telemetry beacon The whole-orbit data format used by many micro-satellites today originated with UO-14. The system gathered telemetry observations and saved them in files for later downloaded. The format of the files consists of three parts: File header, including start and end times and sample period. List of telemetry channels The telemetry observations themselves. The file consists of the items in Table 2. 32 bit time is the number of seconds since 0000 UTC 1 January 1970. The data samples follow the header information. Each is stored an unsigned 16-bit integer. The underlying data type is actually an unsigned 12-bit quantity; the remaining four bits are used for control functions in the telemetry beacon, but are unused in whole orbit data. The values are recorded in the same order that was stated in the file header. Item Length Interpretations Raw value Engineering Units Start Time 4 bytes 32 bit Unix Time 0x383dcd85 000005 UTC 26 November 1999 End Time 4 bytes 32 bit Unix Time 0x383e7622 115930 UTC 26 November 1999 Sample Period 2 bytes Sample period in seconds 0x001e 30 seconds Number of Channels 1 byte 0 to 255 0x13 19channels Table 2: Whole-Orbit Data Format Header Items
Header information in sample whole-orbit data file Channel list in a sample whole-orbit data file First telemetry sample in the file 85 cd 3d 38 22 76 3e 38 1e 00 13 00 08 10 1a 01 0b 03 06 21 31 11 3c 27 2f 37 15 22 2a 2b 04 00 07 07 05 00 05 00 ad 0b 92 06 aa 02 B8 02 98 03 80 00 a2 0c C4 04 7b 06 0c 09 C0 06 D7 02 75 06 Table 3: Sample whole orbit data file Channel Description Raw Value Engineering Unit Array current +X 0x0004 7.630487 ma Array current -X 0x0707 532.8304 ma Array current +Y 0x0005 0.5139264 ma Array current -Y 0x0005 7.293801 ma Array voltage 0x0bad 40.62266 V Battery Current 0x0692 682.3492 ma 14 volt bus current 0x02aa 558.8579 Battery Temperature 0x02b8 45.61132 C Transmitter 0 forward power 0x0398 1.899261 W Transmitter 0 reverse power 0x0080 0.15648 W Battery voltage 0x0ca2 13.60162 V OBC186 CPU current 0x04c4 117.6798 ma Magnetometer 1X value 0x067b 2.028127 V Magnetometer 1Y value 0x090c 2.83131 V Magnetometer 1Z value 0x06c0 2.11248 V Transmitter 1 Temperature 0x02d7 43.37684 C Receiver 0 received signal strength 0x0675 2.020792 V Receiver 1 received signal strength 0x0750 2./28852 V Receiver 1 discriminator voltage 0x0990 2.99268 V Table 4: Decoded telemetry observation in whole-orbit-data 2.3.2.1 Whole Orbit Data for TO-31 micro-satellite Figure 5 shows the thermal environment of the spacecraft. The alternation of the sun and eclipse is clearly visible in the temperature variation of the solar panels which varies from 25 C in the sun and cool down to -35 C during the eclipses. This cycle is occurs every orbit, approximately every 100 minutes for TO-31. Inside the spacecraft of the batteries and electronics experience a comfortable room-temperature environment with modest temperature variations. Figure 6 shows the derivation its electrical power from solar cells which charge the on-board batteries. It shows a alternation of charge and discharge cycles, charging when the spacecraft is in the sun and discharging during eclipses. On exit from eclipse the priority of the power system is to recharge the
batteries, according to for the initial surge over 2 [Ampere]. Once the batteries are recharged the current falls to a 0.2 [A] maintenance level. Figure 5: TO-31 Temperature Telemetry Figure 6: TO-31 Battery Current Telemetry Figure 7: TO-31 Voltages Telemetry Figure 8: TO-31 Magnetometers Telemetry
Figure 7 shows the generation electricity by solar cells when spacecraft is in the sun, and cease to do so during eclipses. It shows that the voltage from the solar arrays rises to over 40 [volt] in the sun, but drops to the battery voltage, normally 12 [volt] during eclipse. Figure 8 present the spacecraft magnetometers. Most of micro-satellite use gravity gradient boom to stabilize. The boom defines the spacecraft Z axis, and is axis of the spacecraft spin. This is clear from the readings of the spacecraft magnetometers data that shows rapid variation on the X and Y magnetometer due to the spacecraft spinning every 10 minutes. The slow variation on the z magnetometer is caused by the orbit of the spacecraft altering the spacecraft s orientation to the Earth s axial spin altering the relationship of the North and South Magnetic Poles with the spacecraft orbit. (Circular sun synchronous orbit, altitude 821Km, inclination 98.6 degrees, and period 101 minutes.) 3 Overview of a Ground Station Network This target of this project is to develop the cost effective telemetry infrastructure for the small organization like university especially during the launch operation and launch commission period. These days many universities in the world participate the micro-satellite and nano- satellite project with limited man power and with limited infrastructure for the satellite operation. The Internet was the obvious technology to use for a distributed telemetry capability because: It is free and available 24 hours per day, 365 days per year It provides almost unlimited connectivity (i.e., no limit on number of parties involved in access), All involved parties were already connected. 3.1 Technologies and selection criteria To overcome the limited human resource in the university organization compare to the big satellite organization like NASA, CSA, CNES, and ESA we develop the internet based telemetry system. Many organizations are developing their own ground station network by investing large amount of budget and engineers. To reduce the SW development time and to reduce the human resource involved in this project the solution to us is to adopting low cost and commercial off-the-shelf software that has capability to: Develop rapidly the application software Measure telemetry in Real Time Acquire any type of telemetry signal such as analogue, digital, or even through GPIB connection Access by many users in the world on the same time in real time for our case maximum 50 users. Connect easily to the integrate Ethernet and to other ground station Share the telemetry data that are received any one of the ground station in the world Implant easily the developed application software to the other ground base station
Communicate each other ground station (received telemetry data in the other ground station can be sent to the main ground station and update the telemetry data in main Web site) Analyze the received telemetry by using built-in analysis tools Reuse the same application SW for the other space mission for multi-satellite operation Have reliable technology for satellite industries Work in simple Pentium PC with Windows environments In considering the above requirement we find the low cost and reliable solution. That is Labview of the National Instrument. It satisfies almost of the above requirements. By using chosen technology we have developed the application software to publish telemetry data in real time on built-in Web site. The maximum 50 persons can access on the same time the telemetry data in real time. 3.2 Functions of Telemetry Management Software Our telemetry management system capabilities: Telemetry Displays (real-time and historical) Telemetry Storage Data Access (Read/Write) log files by web browser Data Analysis and Archiving by using built-in analysis tool Shared directories on web server for documents No software installations required on client ( just access the internet service) 3.3 Required Hardware and software To provide standard interfaces such as analogue, digital and GPIB connection for tool development by operators and subsystem engineers our developed system use the following hardware and software: Labview software Acquisition card (National Instrument PCI-6024E) : To access analogue signal With telemetry acquisition card we can deal with the 16 analog inputs, 12 or 16 bits, 200 ks/s, 2 analog outputs, 12 or 16 bits, 10 ks/s and 8 digital I/O. Although there are outputs on the D/A Converter, we only use it to read signals. GPIB card (National Instrument GPIB-USB-B): Controls up to 14 GPIB instruments remotely, USB 2.0, full speed 12 Mb/s, 880 kbytes/s minimum transfer rate. In our prototype, we use the GPIB to read and control test measurement instruments. In the control section, we can really set the range, function, delay of the instrument from the web remotely. We can see and analyze the remotely measured waveforms in a remote station. RS-232 connector to access directly RS-232 signal PC
Remote Panels in LabView software: Using the remote panel feature in LabView, we can remotely control the LabView application over the Web without any additional programming. The remote panel option is already included and ready to work in LabView. Then, the remote user can access the front panel via his web browser. The only thing needed is the LabView run-time engine and browser plug-in. It works under all operating systems on which LabView runs. Procedure to use Remote Panel: Activating Remote Panel: Once we obtain the permission, we can activate the remote panel by selecting Enable Web Server. Configuring Remote Panels: Specify a list of client IP addresses that are allowed to access the web server and if they can control or only view the front panel. Specify a list of Vis (Virtual Instruments) that can be accessed remotely. Last step, publish the web page to be accessible through the web server: saving will automatically create the html file. The database All the information read by the VI is saved in real time into a database. The name of the file to be saved begins by a time stamp with telemetry data name that consist of: Year Month Day followed by Hour: Minute: Second, Millisecond. Retrieving data We can precisely retrieve all the information from the database with graph or test format remotely. Validation of the proposed Telemetry System Demonstrated the possibility to receive the telemetry data in real time from other computers 3.4 Future Work to be continued This system will be used with UQAR-SAT to be built in University of Quebec in Rimouski in three years. We consider extending our concept to control the micro-satellite (TT&C) remotely. 4 Conclusions We developed the cost effective real time telemetry system that is very useful during launch commission period to monitor the nano-satellite or micro-satellite in LEO. We can share telemetry data more accessible via internet and it is suitable for university satellite mission such as OSCAR type of nanosatellite and micro-satellite project. We demonstrate the telemetry access through internet remotely.
Reference [1] AX.25 Link access Protocol for Amateur Packet Radio, V2.2. Newington: ARRL and Tucson, TAPR, 1997 [2] T. McDermott, Wireless Digital Communications: Design and Theory, Tucson, TAPR, 1996 [3] M. Chepponis and P. Kam, The KISS TNC: a Simple Host to TNC Communications Protocol, ARRL 6 th Computer Networking Conference, 1987. [4] J. Ward and H. Price, PACSAT File Header Definition, ARRL 9 th Computer Networking Conference, 1990. Main Ground station Command Operator, Operation Engineer Telemetry WEB site Internal Users Launch Site Public IP Networks Foreign Agent Ground station Project Partner General Public