Cost Effective Telemetry and Telecommand System for Small Satellite

DOI : 10.17577/IJERTV6IS050174

Download Full-Text PDF Cite this Publication

Text Only Version

Cost Effective Telemetry and Telecommand System for Small Satellite

Kushal M*,

*S. J. C. Institute of Technology, Chikkaballapur 562101,

Shrihari M.R***

Bhanu Prasad N**,

**S. J. C. Institute of Technology, Chikkaballapur 562101,

***S. J. C. Institute of Technology, Chikkaballapur 562101,

Abstract – At very low cost and in record time a test was completed in TEAMSAT dual spacecraft which was launched by Ariane 502. To support the final integration and testing the data handling was made ready in 6 months, it had to be designed and constructed from scratch. The availability of Telecommand (TC) and Telemetry (TM) chip set is the achievement of vital element. The spacecrafts and its mission is briefly outlined in this paper with reference to data handling system and the severe conraints under which it was developed.

Keywords: AVS, FIPEX, TEAMSAT, TELEMETRY, TELECOMMAND, TETHER, VTS.

1 INTRODUCTION

To enable young engineers and students in mid November 1996, 750 000 Euro was provided to exploit the opportunity offered by the Ariane 502 test launch to install some experiments aboard the MAQSAT instrumented test platform which would go into Geostationary Transfer Orbit (GTO). The space was made available about 94cm high and 75cm diameter weighing up to 300 kg for a cylindrical module. The TEAM /YES dual spacecraft (TEAMSAT) was ready for shipment to Kourou by the end of

June 1997. In about 6 weeks earlier to support integration and testing via the TM and TC links the data handling system and ground support equipment. The launch was delayed until 30th of October of the A-502 by the authorities. We have added information about the spacecraft and mission in general to give some idea of the scale of the challenge this project presented.

2 EXPERIMENTS AND SUB SYSTEMS REQUIRING TM/TC SUPPORT

Experiments done by candidate had to be in an advanced stage of development and suitable for the GTO provided by the launch. The experiments and subsystems established the initial requirements it had to meet are as follows.

TETHER: The in-flight deployment of a daughter spacecraft (Young Engineers Satellite YES) is involved by this, that was to be ejected as a free flyer attached by a 35 km tether to a 12 kg counter mass. The YES satellite and its support systems plus the details of the tether deployment were still being discussed.

AVS: an astronomical attitude reference is provided by Autonomous Vision System to recognize star constellations. An existing development model was available including a PC based ground support system.

FIPEX: To measure atomic oxygen the Flux Probe Experiment is used. Examples already flown on sounding rockets. Also included PC based ground support system.

VTS: Visual Telemetry System, it existing programmable digital camera system for monitoring spacecraft mechanical status, array deployment, separation etc. It is also used as engineering model. PC based ground support system existed.

GPS: to obtain position data and study reception conditions, a commercial GPS receiver was included, above the GPS satellite constellation. PC type serial output.

To monitor relay states, voltages, temperature, currents etc., Platform Analogue and digital housekeeping channels were required.

All the above required telecommand facilities to load memories, execute control commands etc.

3 CONSTRAINTS AND WAYS ROUND THEM

Until final separation TEAMSAT had to behave as an inert dummy load in MAQSAT. To make sure that there was no danger of bits falling off during the launch it had to be very robustly constructed or contained. Electrically, it means until after MAQSAT separation, no RF transmissions and no live connections outside the TEAMSAT box.

Battery powered mission was the only possibility because there was no possibility to mount solar arrays. Spare batteries from ECS II (1982!) were found to be still serviceable and provided about 3k what of capacity. With careful conservation and short hibernation periods, we estimated that a mission spanning about 4 days should be possible.

The extreme time and budget constraints obliged us to resort to some unusual and frankly dubious practices on occasions. Normal QA procedures could not be applied and such decisions were left to the judgement of the person on the spot, aided by the vast pool of expertise available in ESTEC. The imposed deadlines often forced us to start construction based on provisional assumptions before some important parameters were frozen or even identified. In effect phase A/B lasted only a week or two and merged rather than switched into phase C/D. This meant we required designs with reconfigurable capabilities that could be adjusted later rather than inflexible, case specific solutions.

When integration and testing of TEAMSAT wad already well advanced, a decision of the Space Debris Committee lead to the abandonment of the major experiment, TETHER. By that time YES and its deployment system had been fully developed and installed. It was decided that YES would be ejected, but the deployment of the tether and the counter- mass would be excluded.

  1. MECHANICAL DESIGN AND YES DEPLOYMENT SYSTEM

    The main mechanical features of TEAM and YES can be seen here, including the intended deployment of YES. Both spacecraft are in a robust octagonal box which ensures containment of everything inside. The YES spacecraft uses the octagonal lid of TEAMSAT box as a base-plate for its structure and is ejected by four springs on reception of a ground command to pyrotechnic release system system. Then the 35 km tether unwinds from a bobbin in YES while the counter mass remains in TEAM. After full tether deployment, the counter mass is released from TEAM. The TEAM spacecraft remains attached to MAQSAT throughout the mission. Deployment control placed severe requirements on the TM and TC to ensure that it took place reliably at exactly the right time and spacecraft orientation. Finally, to preserve the mandatory mechanical integrity during launch,

    the YES release system had to meet the strictest safety requirements.

  2. DATA HANDLING SYSTEMS DESIGN DECISIONS AND TRADEOFFS

    We had acquired transponders left over from the Eureka and Olympus projects. They both functioned well when tested although the Olympus transponder used on YES was an engineering model at least 16 years old. The most serious mission from the list of essential, available equipment was an on board data handling system to format the experiment data for transmission and decode and distribute commands and data received from the ground. Also still to be addressed were the issues of providing platform housekeeping data, plus power distribution, switching and conditioning.

    In general, the experiments were off the shelf and came with existing display and control systems. To be able to use these during integration and test and also I flight required a suitably transparent space link. This in turn meant that there was no possibility of imposing on users the decidedly non- transparent, traditional ESA TM system that collects fixed quantities of data at fixed intervals. The requirements to accept user data structures and I/O protocols as is meant we had to provide them with an asynchronous byte stream service rather than a packet service in both up and down links.

    However, the ESA TM/TC chipset supports all these capabilities and is fully compliant with ESA/CCSDS recommendations. Its use dramatically reduced the effort of designing a data handling system from scratch. This chipset forms the core of an on board system that genertes TM transfer frames and decodes TC frames without the involvement of a processor. Its flexibility enables details of TM bandwidth allocation amongst users to be left until later and even adjusted in flight.

    It was clear that the link budget around apogee would be marginal. Fortunately, the ESA chipset includes a Reed- Solomon and Convolutional Encoder that provides about 7dB of gain on the link. Even then, concerns about antenna pattern holes and their effect on the critical YES deployment sequence led us to provide cross coupling between the two spacecraft that enabled essential TM and TC traffic of one to be routed via the RF link of the other. To gain yet more link margin, provision was made to reduce TM bit rates by factors of 2 or 4 by telecommand. TEAM was provided with two low gain helical antennas mounted on the MAQSAT structure to provide reasonably uniform coverage in the aft direction in which the earth would lie at apogee. To provide best omnidirectional capability in free flight, YES had 2 low gain antennas. The uncertainties of the RF links imposed some sophisticated requirements on the data handling system.

  3. THE ESA TM/TC CHIP SET

Latch up free, rad-hard SOS technology, which are used by all components have a footprint of 8cm2 and weight about

15 grams. Their functionality is full complaint with ESA/CCSDS recommendations.

Telemetry

Virtual Channel Multiplexer (VCM)

Multiplexes outputs of up to 8 VCAs on to one TM link. An inflight programmable Bandwidth Allocation Table guarantees minimum portions to each VC. The VCM completes the transfer frame header. Also provides interfaces for the Command Link Control Word (CLCW) from the TC decoder chip and the Reed-Solomon/ Convolutional encoder chip. Each spacecraft used one VCM.

Virtual Channel Assembler (VCA)

Assembles bytes of data or packets into a VC on the TM link. To match the data source production rate it matches to the bandwidth available to that VC. Accepts data as CCSDS/ESA byte stream or packets. TEAM used 5 VCAs and YES used 4.

Reed-Solomon/Convolutional Encoder

Supports the on board end of a forward error detection and correction system. Provides a very cost effective means of improving link budget by about 7dB. A complete, CCSDS/ESA complaint TM frame generator comprises a single VCM plus a VCA for each VC used. The R-S/Conv encoder chip is optional, but was essential to meet minimum link budget requirements in the case of TEAMSAT.

Telecommand

Packet Telecommand Decoder

The on board end supported by protocol machine of an up link providing error-free delivery of packets or arbitrary data structures via up 62 addressable ports. An authentication check hosted by it and a Command Pulse Distribution Unit(CPDU) which decodes multiple pulse commands of individually specified length delivered in a packet.

To implement and check compliance with the fairly complex CCSDS/ESA TC protocols, the TC decoder chip eliminates the requirements. PROM contains mission dependent parameters. The PSK subcarrier is not demodulated by transponders. This was performed by a single chip device on the TC board of which we had few samples.

7 NEED FOR FPGA AND VHDL TOOLS

Maximum of the glue logic need to change the ESA TM/TC IC input/output unit to the PC type serial unit ports which was created in ACTEL 1280 FPGAs. There are at most one user on each and every TM/TC chip board. The TC FPGA used to reinforce the digital part of housekeeping system that had the control of analogue part of the device. They also backed the delay generation for time tagged commands. The design methodology produced VHDL parts of the FPGAs. Since it was already existed in the market, it allowed us to model and verify the data handling system in detail at the development stage itself. It helped in successfully generating IC design in quick and efficient manner. Socket mounting was used in FPGAs to include or adjust the circuit board in later stage. Despite all, the design process and simulation was successful with no further corrections required.

8 SELF-SUPPORTING and ASYNCHRONOUS TM SERVICE

The old, synchronous, attached method had major restriction on data retrieval and the design of UI was made more complex. The easier and modified format which is simpler known as simplified format table compares the two approaches.

Taking this example for the above, here the data points are read in fixed time interval say three frame cycles. This helps us to determine whether the data values read is useful or not (E.g.: constants and zeroes when the device is in off mode). Due to this, the instruments are forced to generate the data that maintains attached format of transfer frame.

Even though the VCM/VCA chip set have fixed size, its internal structure adopts dynamic sequences and the VC sequences, packet rate and size differs based on the users activity. Filler is automatically included to complete pre- determined transfer frame format when user outputs are inappropriate. This activates the system to accept variable sizes of user data. The bandwidth provided by TM link was 28 259 bits/sec. The system shared this with all available users to acquire guaranteed share. This guaranteed share to each VC were built by a VCA polling table hosted by VCM. It can be reloaded via the TC link through flight, on the flip

side the generator completes the frames required with the help of filler.

The AVS experiments whether the TEAM is a good example of a sporadic data producer without any flow control. That is, The VC have to be guaranteed with minimum required bandwidth in order to accept the peak rate production. In quiescent mode it had resulted in small squirts of housekeeping data from time to time. But, an image is produced that takes much prolonged squirt. The experiment doesnt contain output flow control thus allowing the TM system to take the data produced at 19.2 kBaud from an asynchronous serial interfaced PC. Even though the VC bandwidth provided is same as the peak requirement, it was taken up only on occasional. The FIPEX experiment along with TEAM was somewhat same in its data production characteristics.

The VTS unit on TEAM generates tiny amount of housekeeping as a background process but it also takes large image buffer whose output interface is flow controlled. This compliments both AVS and FIPEX cause it could take up the substantial bandwidths assigned to them but is kept idle most of the time. This results in emptying the VTS buffer as fast as total link bandwidth and the present processes of other users are allowed.

A common or single channel can be shared by multiple users via standard packet structures to bound the different data units. As we couldnt impose such structures on users, bounding was achieved by allocating them with various VCs (virtual channels) and MAPs (Multiplexer Access Points) on the TM and TC links respectively. Its not a strategy that we should advocate necessarily in different circumstances as VCs and MAPs are intended primarily to bound with various levels of service and/or address redundant paths in transport layer. Later on the achieved VC or MAP can carry packets with adaptable requirements for latency and bandwidth but with other sources and destinations as identified by the application IDs of packets. The ESA TM chip set was designed to support simultaneous bytestream and packet modes on different VCs or MAPs.

9 DATA MANUPLATING SYSTEM PERFORMANCE AND CONCLUSIONS

TEAMSAT is the first ESA spacecraft containing the TM and TC systems supporting ESA/CCSDS standards completely. It was also the first aircraft that supported to exploit the adaptive anywhere, asynchronous TM features that they were supporting. The performance and ease of use made it popular with everyone. The core functions and protocols of ESA TM/TC IC were implemented in short, relatively trouble free design and building phases. This provided a major shortcut by terminating the use of a processor and software thus providng more robust system and skipping the protocol verification tests that was required before.

The effective adaptability of the TM system to accept asynchronous input is a particular note. This is a operation mode that has complex project groups and thus it was been ignored by industry thus far. After successfully launching his type of system we have demonstrated that when using a ESA IC set, such mismatched are unfounded. Indeed this mode is easier compared to the previously available mode that is the traditionally attached format approach. The system would be possibly able to inherent differential size, rate data units ESA per CCSDS packets. This means, the comparison between event driven TMs production and user defined differential sample data techniques can be taken care by TM link that doesnt have special provisions except for a matchable minimum VC bandwidth allocation. The VC BAT (Bandwidth Allocation Table) may be assigned in the flight again.

The authentication process on TC chip didnt required any missions since it was not used. The COP-1 TC link protocol was the only ESA/CCSDS that wasnt demonstrated in the flight. As we already know TEAMSAT as first ESA spacecraft to support the above.

10 OVERVIEW OF RESULTS

VTS

AVS

FIPEX

It deliberated at an attitude of 525km-1250km of atomic oxygen. It depraved various materials along with optical surface.

GPS

It was drawed upto 26000km of GPS signals about 6000km from the GPS orbit referencing that the system survives at that particular altitude which is trusted as to be a worlds first.

11 REFERENCES

  1. www.estec.esa.nl/teamsat

  2. www.estec.esa.nl/wsmwww

  3. https://en.wikipedia.org/wiki/Telecommand

  4. https://en.wikipedia.org/wiki/Telemetry

  5. Telecommand and Telemetry Implementation of Aalto-2 CubeSat Project- Justicia Mayoral, Marc

  6. Digital communication by satellite- Spilker.J.J.Jr

  7. Satellite communications system and apparatus- Paul Baron

  8. http://www.datatel-telemetry.de/

  9. https://en.wikipedia.org/wiki/AVS

  10. https://en.wikipedia.org/wiki/Space_tether

  11. https://en.wikipedia.org/wiki/Spacecraft_design

Leave a Reply