Instruments of RT-2 Experiment onboard CORONAS-PHOTON and their test and evaluation V: Onboard software, Data Structure, Telemetry and Telecommand
S. Sreekumar, P. Vinod, Essy Samuel, J. P. Malkar, A. R. Rao, M. K. Hingar, V. P. Madhav, D. Debnath, T. B. Kotoch, Anuj Nandi, S. Shaheda Begum, Sandip K. Chakrabarti
aa r X i v : . [ a s t r o - ph . I M ] D ec Noname manuscript No. (will be inserted by the editor)
Instruments of RT-2 Experiment onboard CORONAS-PHOTON and their test and evaluation V: Onboardsoftware, Data Structure, Telemetry and Telecommand
S. Sreekumar · P. Vinod · Essy Samuel · J.P. Malkar · A. R. Rao · M. K. Hingar · V.P. Madhav · D. Debnath · T. B. Kotoch · Anuj Nandi · S. Shaheda Begum · Sandip K.Chakrabarti
Received: date / Accepted: date
Abstract
The onboard software and data communication in the RT-2 Experimentonboard the Coronas-Photon satellite is organized in a hierarchical way to effectivelyhandle and communicate asynchronous data generated by the X-ray detectors. A flex-ible data handling system is organized in the X-ray detector packages themselves andthe processing electronic device, namely RT-2/E, has the necessary intelligence to com-municate with the 3 scientific payloads by issuing commands and receiving data. It hasdirect interfacing with the Satellite systems and issues commands to the detectors andprocesses the detector data before sending to the satellite systems. The onboard soft-ware is configured with several novel features like a) device independent communication
This work was made possible in part from a grant from Indian Space Research Organiza-tion (ISRO). The whole-hearted support from G. Madhavan Nair, Ex-Chairman, ISRO, whoinitiated the RT-2 project, is gratefully acknowledged.S. Sreekumar, P. Vinod, Essy SamuelVikram Sarabhai Space Centre, VRC, Thiruvananthapuram 695022E-mail: sreekumar [email protected]. P. Malkar, A. R. Rao, M. K. Hingar, V. P. MadhavTata Institute of Fundamental Research, Homi Bhabha Road, Colaba, Mumbai 400005D. Debnath, T. B. Kotoch, A. Nandi + Indian Centre for Space Physics, 43 Chalantika, Garia Station Rd., Kolkata 700084Tel.: +91-33-24366003Fax: +91-33-24622153 Ext. 28E-mail: [email protected]; [email protected]; [email protected] (+: Posted at ICSP by Space Sci-ence Division, ISRO Head Quarters, Bangalore)S. Shaheda BegumRadio Astronomy Centre, NCRA-TIFR, Ooty 643001Sandip K. ChakrabartiS.N. Bose National Centre for Basic Sciences, JD Block, Salt Lake, Kolkata 700097(Also at Indian Centre for Space Physics, 43 Chalantika, Garia Station Rd., Kolkata 700084)Tel.: +91-33-23355706Fax.: +91-33-23353477E-mail: [email protected] scheme, b) loss-less data compression and c) Digital Signal Processor. Functionality ofthe onboard software along with the data structure, command structure, complex pro-cessing scheme etc. are discussed in this paper.
Keywords
Satellites communication · X- and gamma-ray telescopes and instrumen-tation · Data acquisition · Telemetry
PACS · · · RT-2 Experiment onboard the Coronas-Photon satellite (Kotov et. al. 2008) consistsof 3 scientific and 1 processing electronic payloads (Nandi et al. 2009a). The processingelectronic device, namely, RT-2/E communicates with the scientific payloads and theground stations through SSRNI (System of Collection and Registration of Scientific In-formations or SCRSI in English) and the Control and Communication unit (BUS-FM)of the satellite. The three scientific payloads are RT-2/S & RT-2/G (both Phoswichscintillating detectors of NaI(Tl)/CsI(Na) crystals) and RT-2/CZT (solid-state imag-ing detector). In Debnath et al. (2009), Kotoch et al. (2009), Nandi et al. (2009),we described the technical aspects of three scientific payloads, their functionality anddifferent imaging techniques that are designed and implemented in the RT-2/CZT pay-load. In Sarkar et al. (2009), we mainly discussed the effect of the cosmic diffuse highenergy X-ray background on all the three detectors through Monte-Carlo simulationsas implemented in GEANT-4 toolkit.The RT-2 Experiment covers the energy range of 15 to 150 keV extendable up to1 MeV. All three payloads have different fields of view ranging from 4 ◦ x 4 ◦ (RT-2/S),6 ◦ x 6 ◦ (RT-2/G) and 6 ′ – 6 ◦ (RT-2/CZT). In order to view the sky (Sun) in the lowenergy γ -ray range, all the three detector systems are placed outside the hermeticallysealed module of the satellite. The three detectors are mounted with instrument axisparallel to the Sun pointing axis of the satellite. On the other hand, RT-2/E alongwith other processing systems of the satellite are placed inside the hermetically sealedchamber of the satellite.In the present paper, we will concentrate on the onboard software and the overallfunctionality of RT-2/E. The schematic diagram of RT-2 system is shown in Figure 1. RT-2/E is the main processing electronic device of the RT-2 Experiment and it acts asan interface between the detector electronics and the satellite system. The unit decodesthe telecommand appropriately and transmits the detector data to the ground throughthe satellite telemetry, which also involves the functions of compressing and makingpackets of the data from the detectors. The control logic system of the device is FPGA(Field Programmable Gate Array), which carries all the logical operations in the RT-2/E. A Digital Signal Processor ADSP2101 is used in the system for data processing.The RT-2/E electronics also consists of input and output buffers for detectors, satelliteinterface, electronics for power interface, memory interface. The schematic block dia-gram of RT-2/E device is shown in Figure 2. A continuous power supply to the RT-2system is provided by the Control and communication unit (BUS-FM) of the satellite.
Fig. 1
Schematic diagram of RT-2 system.
Power supply is provided by a DC current source with the Voltage of 27 +7 − Volt withouta midpoint. The maximum power provided for the RT-2 system is 32 Watt.RT-2/E weighs 8.56 kg and the power consumption of the device is 3.78 Watt, ≤
10 kg and ≤ ◦ C to +40 ◦ C and it is placed inside a hermetically sealedchamber of the satellite.
In the power-on mode, all detectors detect X-rays and package them in a ‘page’ in thedetector box itself, in a mode called the ‘normal’ mode, which can be changed to ‘test’mode by command. Every second, RT-2/E sends a ‘second’ signal to the detectors andthe data is sent to RT-2/E while the storing is done in a separate ‘page’ (these two pagestoggle every second). RT-2/E processes the detector data and sends to the satellite. InRT-2/E, the data is made into packets with the processing intervals known as framesin whole (a number of packets as one frame) and each frame is divided into blocks.These blocks are compressed and are written in the memory of RT-2/E, in the formof packets. This telemetry data is subsequently sent to the satellite. Telecommands,which are up-linked to the satellite, include commands to adjust high voltage (HV), lowlevel discriminator (LLD) value, Channel boundary change, ‘mode’ change and so on.All these commands are decoded within RT-2/E and are passed on to the respectivedetectors.Another important task of the RT-2/E is to execute the pulse commands (SWITCHOFF/ON) that are available form the Control and communication unit (BUS-FM) ofthe satellite. The control commands (pulse commands) of the RT-2 system are discussedlater on.
Fig. 2
Schematic block diagram of the processing electronic device RT-2/E.
The telemetry resources available for the RT-2 Experiment is 32 bits of satellite teleme-try, read every 4 seconds and transmitted semi-continuously to the ground and 10Mbytes of onboard memory, transmitted once or twice daily to the ground. The scien-tific requirement is to have coarse spectral and timing information of the X-ray dataon a continuous basis and higher time resolution information during transient events.Further, it is also desirable to have faster read out of information for ground testingas well as for trouble shooting purposes. The onboard software needs to be parame-terized so that a sufficient flexibility is available to change the working of the softwarebased on a 16-bit data command and 14 ‘pulse commands’. For time synchronization,calibration time information is also available from the satellite subsystem SSRNI. Thismultiple and complex demands are realized in the following way: • The asynchronous data from the X-ray detectors are packaged in the detector blocksthemselves. This packaging is organized in two modes: a) a time tagged event modeto get 0.3 ms time resolution (to cater to any special needs like high time resolutionstudy of some celestial objects and also for debugging the detector software) andb) a spectral and timing mode which has a time resolution better than what isscientifically required. Spectrum and image every second, and timing informationevery 10 millisecond, packaged every second are deemed to be sufficient to satisfy allthe requirements. Time-stamping is done in the detector block using a local clock,and the data is interrogated and taken precisely every second, and this precision isestablished by taking this information from SSRNI. The detector performance and software are controlled by a few data commands, designed as a subset of the 16-bitsatellite data command. • The basic detector data are packaged and kept in a memory in RT-2/E, to betransmitted to the satellite memory with its own protocol. This re-packaging isdone based on modes and while transmitting, data are compressed using a loss-lesscompression code. • The information from the detector is codified (8 bits per payload) and sent to thesatellite telemetry every 4 seconds to have a basic diagnostic of the working of theexperiment. • The modes of operation is done based on ground commands as well as onboard pro-cessing. The onboard processing caters to a) flare detection b) memory availabilityc) satellite position (high and low background regions) and solar visibility. • Facility is also kept to change the complete onboard software.The data collected from the detectors is first taken into input buffers of RT-2/Ememory and is accumulated in the accumulation buffers during a processing interval.On every processing interval boundary or on every processing mode change, the frameof data is compressed and made into packets by the onboard software. The algorithmused for loss-less compression of RT-2/E telemetry data is the CCSDS (ConsultativeCommittee for Space Data Systems) recommended Rice algorithm (Yeh et al. 1991;Rice et. al. 1993). The compressed data is then sent to the satellite and then subse-quently to the ground. Also, all the telecommands coming from the ground are decodedand appropriate commands are sent to the corresponding detectors.The onboard flare detection logic is enabled every second. Satellite telemetry datais prepared by the software every second. Also, all the required functions are carriedout on receiving the ON/OFF commands from the satellite.Memory management scheme is included in the software, which does the work ofmanaging the memory in RT-2/E. Further, CZT detectors initialization data is sent toCZT from the RT-2/E memory, on receiving CZT initialization command from ground.Watchdog timer updating logic is incorporated in the software, which will enable thehardware to reset the digital signal processor in case of software hang up.There is an additional feature of downloading the contents of the program memory(onboard software) for verification. This can be enabled based on ground command.The onboard software is developed in the assembly language of ADSP2101 processor.
Based on the diverse constraints for using the satellite memory as well as requirementof the scientific interest, various processing modes are defined for RT-2/E.5.1 Bad Mode (Mode Id = 0, 100 sec/frame)The bad mode runs when the satellite enters into high flux region (South AtlanticAnomaly - SAA, North and South polar regions), based on signals from the satellitecalled ‘GOOD’ and ‘BAD’. When RT-2/E is in this mode, the onboard software lowersthe high voltage of Photomultiplier Tubes (PMT) of the Phoswich detectors and makesthe HV of CZT detectors to zero and only the frame header data is transmitted but not the detector data. When coming out of this mode i.e., to the good state, the previousmodes are started afresh and the high voltage is set for the PMTs and CZT. The switchover to good mode from bad mode can be delayed by ground command as multiples of64 seconds. In the bad mode, the data (header data) is sent every 100 seconds.5.2 Test Mode (Mode Id = 1, 1 sec/frame)The software enters this mode, when the test mode data from the detectors are received.There will be house keeping data (VCO) and event data from the detectors, in thismode. The most significant bit of VCO data, if set, takes the software to this mode. Theraw data from the detectors is sent to the satellite as soon as they arrive to RT-2/E,i.e., every second without any compression. There are also command based facilities tosend a limited number of CZT events and also to send only the CMOS data.5.3 Debug Mode (Mode Id = 2, 1 sec/frame)In this mode, the spectral data from detector units is sent to the satellite every second assoon as they arrive to RT-2/E. The purpose of this mode is debugging during the initialverification phase as well as in the case of any later malfunctions of either packages(payloads). RT-2/E is switched to the debug mode on commands from ground.When RT-2/E is in the debug mode, there is an option to get the timing data alonefrom the detectors.5.4 Solar Quiet Mode - SQM (Mode Id = 4, 100 sec/frame)This is the primary accumulation mode since the Sun is quiet in hard X-rays mostof the time. In this mode, spectrum is obtained for every 100 second and count ratesfor every second in RT-2/S and G. Similarly, the spectra and the images in every 100second and the count rates in every second are obtained for CZT detectors while onlyimages are obtained for CMOS in every 100 second.5.5 Solar Flare Mode - SFM (Mode Id = 3, 10 sec/frame)The major science requirement for this experiment is the availability of high temporaland spectral resolution data during solar flares. Since such flares occur randomly, theonboard software has a built-in mechanism for checking the current count rate againstthe present thresholds to detect the flares. The flare search is carried out at everysecond. The logic of flare detection will be discussed later. The data packaging isunaffected for RT-2/CZT during flares.In this mode, data frame structure is identical to the solar quiet mode except thatboth the time resolutions are reduced by a factor of 10, i.e., in this mode, the countrates are stored at every 0.1 second and spectra are stored at every 10 second.Normally, the data accumulation is done in the quiet mode. However, as soon as theflare trigger occurs, the current frame of the quiet mode is filled to the next multipleof 10 s. The quiet mode data till the detection of flare is made into packets and a new frame is started in the flare mode. After trigger, the data is accumulated in this modefor next 10 second i.e., one frame. At the end of the frame, again flare threshold ischecked and if the count rate is still more than that, then this mode will continue foranother frame. Otherwise, the data accumulation will revert back to the quiet mode.Flare mode data frames are stored in the same address stream of data as the quietmode.5.6 Shadow Mode (Mode Id = 4, 100 sec/frame)Shadow mode is activated when the Sun is out of the detector field of view i.e., duringNIGHT and at the time of solar occultation. In this mode, flare detection is disabled.The processing of data in the shadow mode is similar to the solar quiet mode (SQM).The detector data are stored for every 100 seconds in blocks of 64 words. While trans-mitting, they are compressed and transmitted in packets of 60 words (59 words of dataand one packet header). Also, for each type of data a separate packet called frameheader is created.For example, in the normal mode for RT-2/S and G, after decompression at ground,one frame data consists of 57 packets data (in RT-2/CZT 218 packets). Out of these57 packets of data, first packet data is called frame header. Rest of the 56 packetscontain scientific data. First word of each data packet is called packet header, it signifiescurrent packet number out of total packets in the frame. The number of packets afterdecompression (60 words each) will be number of blocks before compression * 64/59+ 1 and these values are estimated and given in Table 1.
Table 1
Modes & packetisation of RT-2/S, RT-2/G and RT-2/CZT payload data
Processing Mode Description Compressed DecompressedS/G CZT S/G CZT
Bad Mode Frame Header, every 100 sec - - 1 1Shadow mode Spectrum every 100 sec 51 200 57 218Test mode Event data every sec 1-230 1-198 2-251 2-216Software download - 64 - 71Debug mode Spectrum every sec 51 200 57 218Timing alone 13 19 16 22Solar flare mode Spectrum every 10 sec 51 - 57 -Solar quiet mode Spectrum 100 sec 51 200 57 218
Table 2
Good data condition for RT-2 payloads
GOOD/BAD LIGHT/SHADOW Detector Mode Processor Mode Flare detected Output Mode
Bad X X X X BadGood X Test X X TestGood Shadow Normal Normal X SQMGood X Normal Debug X DebugGood Light Normal Normal No SQMGood Light Normal Normal Yes SFM
The selection logic for the Mode of operation is given in Table 2, which is valid whenthe available memory is > < . P S cut . Hence the highest timeresolution possible from the experiment is: a) 0.3 ms in the event mode and b) 10 ms for
Each detector ‘event’ is characterized by 2 words and event data structure is given inTable 3.
Table 3
Event data structure of RT-2/S & RT-2/G.
D31-D20 D19-D13 D12 D11-D0
Time Pulse Shape G1 or G2 Energy
Maximum events that can be stored in memory are 7360 events. This data blockis stored in a memory and sent to RT-2/E, whenever 1 second command is received.The channel number is incremented every second.
1. Header block (1 word): VCO data (2 bytes)2. Spectrum block (2432 words): G1 Na (PH): 1K words; + G1 Cs (PH): 1 K words;+ G2: 256 words; + width: 128 words.3. Timing blocks (800 words): 100 Timing blocks X 8 counters X 1 word (counters ineach block will count for 10 ms).4. Counter block (8 words): 8 counters (1 word each)The house-keeping data of Phoswich detectors (RT-2/S & RT-2/G) are multiplexedthrough VCO and stored in 8 channel format. The VCO data structure (2 byte) is givenin Table 4.
Table 4
VCO data structure of RT-2/S and G payloads.
D15 D14 D13-D11 D10-D0
Mode ID Corona VCO Channel No. VCO Counts
The detail descriptions of eight VCO channels (HK parameter) is given in Table5 (NC means Not Connected). One of these channel parameters is sent to RT-2/Ethrough VCO every second.Note: VCO frequency (2 kHz min. to 20 kHz max.) is corresponding to 1 to 10 Voltvariation.6.2 Data format for the RT-2/CZT detectorIn the detector block, the asynchronous data from the CZT detectors (Kotoch et al.2009) are stored in memory. This data is transmitted to RT-2/E every second, based Table 5
HK parameters of RT-2/S and G payloads.
Channel No. Description Voltage level ± ± on 1 second command from RT-2/E. Thus the asynchronous data from the detectorsare sent in a synchronized manner for further processing.The data storage occurs in two modes: i) test mode where every event is time-tagged correct to 0.3 ms and ii) normal mode, where all the spectral and image dataare accumulated and count rates are stored every 10 ms and sent in every second.Hence the highest time resolution possible from the RT-2/CZT is: a) 0.3 ms in theevent mode and b) 10 ms for 12 channel counters and c) 1 second for full spectrumand image. Apart from the detector data, the House-Keeping (HK) information of thedetectors is also sent to RT-2/E by encoding the information through an ADC.RT-2/CZT is set to command mode by ground command before issuing commandsto individual CZT modules. For CZT, the ADC value corresponding to each pixel ismultiplied by a gain factor 1.xx, where ’xx’ varies from 0 - 0.25 in steps of 0.001 (tocorrect the errors in the energy range and count ratio of pixels). Then a constant value(CZT constant can be commanded from ground) is subtracted from this. This constantis the same for all pixels. Further, an offset value is added to this. Offset is an 8 bitnumber and can be different for each pixel. • Pixel value (CZT) = (ADC O/P value) * gain - CZT constant + offsetHere, the ‘CZT constant’ is subtracted to account for the sign of the offset value.The optimum gain and offset values for each pixel is stored in the gain-offset tablewithin the CZT memory. The ADC value, after applying these operations is used forimage and spectrum computation in the normal mode. In the test mode, upper 10 bitsof the actual ADC value (12 bits) are used in the event data.For CMOS detector, 512 x 1024 pixel values are read periodically and a CMOSconstant (which can be changed by ground command) is subtracted from the ADCvalue corresponding to each pixel. • Pixel value (CMOS) = (ADC O/P value) - CMOS constantAn upper threshold value is also defined (ground command) and if the pixel valuecrosses this threshold, the value is zeroed, considering it as a bad pixel. For 1-bit image,if the value crosses a threshold (defined separately for each line), the value is 1, else 0.Bit image of the CMOS detector is made by applying logical OR to the values offour adjacent (2x2) pixels. This is done for 512 x 512 pixels, starting from a start line.Start line and line thresholds can also be changed by command. This results in a 256x 256 1-bit image. The sum of all vertical pixels and horizontal pixels are computedseparately (before ‘OR’ing) as V sum and H sum respectively.In CMOS, frames (each scanned image) are obtained depending on the frame inter-val provided. Frame interval is the time set to get a frame from the detector, which is selectable from ground. For example, if the frame interval is set for 4 seconds, a frameis obtained every 4 seconds. Frames are integrated in the detector itself during thisinterval. In the test mode, all the frames received in every 32 seconds are integratedwithin RT-2/CZT and the integrated data is sent to RT-2/E in 32 second (data of 8kpixels in each second). The possible frame intervals in normal mode and test mode aregiven in Table 6. Table 6
Frame Intervals in Normal and test modes of RT-2/CZT (CMOS detector).
Normal Mode Test Mode
CMOS Calibration :Calibration of CMOS pixels can be done in the test mode of RT-2/CZT. Dataof N consecutive image frames are averaged and these frames are taken, where N is32 divided by the frame interval, defined in the previous table. The calibration resultis written in 256 V sum locations, two values in each word. The calibration result isidentified by ‘1’ in the location 8182 of RT-2/CZT data. Addition of an offset value tothe calibrated results can also be done by command in normal or test mode.The contents of RT-2/CZT EEPROM can be sent as data to RT-2/E in test mode,on receiving the command 0x4803. The data from RT-2/CZT is sent to RT-2/E everysecond in the following format. Each CZT ‘event’ is characterized by 2 words and event data structure is given in Table7. This data is stored in the memory and sent to RT-2/E, every second. Maximumevents that can be stored in memory are 4032 events.
Table 7
Event data structure of RT-2/CZT detector
D31-D20 D19-D10 D9-D2 D1-D0
Time ADC value of Detector data Pixel ID Detector No. (0-2 for 3 CZTs)2
The normal mode data format for CZT (3 modules) and CMOS detector is given below:
Data of CZT :1. Image block (3072 words): 1 K words per CZT (4 channel X 256 pixels X 1 word).2. Spectrum block (1536 words): 512 words per CZT3. Timing blocks (1200 words): 3 CZT detector X 100 timing words X 4 channels X1 word (counters in each block will count for 10 ms).4. Counter block (24 words): 12 counters (2 words each)5. VCO block (1 word): 2 bytes of ADC data6. Special words (8 words) : Satellite telemetry word, temperature, Command sent,Data read against command, event number , CMOS line number, Calibration resultidentification word and Calibration status
Data of CMOS :1. Image block (4096 words): 256 x 256 pixels2. Sum (512 words): Vertical sum (256 words) + Horizontal sum (256 words)The house-keeping (HK) data of CZT-CMOS detector (RT-2/CZT) are multiplexedthrough an ADC and HK parameters are stored in 8 channel format. The ADC datastructure is given in Table 8.
Table 8
ADC data structure of CZT-CMOS detector
D15 D14 D13-D11 D10-D0
Mode ID (0: Normal, 1: Test) 1: EEPROM, 0: Detector ADC Channel No. ADC Counts
The detail description of eight ADC channels (HK parameter) is given in Table 9.One of these channel parameters is sent to RT-2/E through ADC in every second.
Table 9
HK Parameters of RT-2/CZT payload
Channel No. Description Voltage level ± Note: In ‘command’ mode of CZT, Data read against CZT detector commandscomes in the special words. Data from the detectors are first fed to the input buffers, where the spectral data / eventdata of the detectors are buffered. There are two separate buffers for each detector.Data is written alternately into each buffer. FPGA writes the detector data to one ofthe buffers and the processor reads the data from the other buffer. The allocation ofall three detector data in normal mode is discussed in the following sections.7.1 Input buffer of RT-2/S & RT-2/G:A total of 3328 words of memory space are allocated for the RT-2/S and RT-2/Gdetectors data in the input buffers. Data structure in the input buffer is given in Table10.
Table 10
Data structure of the input buffers of RT-2/S & RT-2/G:
Address Data Type Data (words)
Table 11
Data structure of the accumulation buffer of RT-2/S and RT-2/G
Address Data Type Data (words)
The 8 extra words in the accumulation buffer are to accommodate deeper (2 wordseach) accumulation of counters. Table 12
Data structure of CZT in RT-2/CZT payload.
Address Data Type Data (words)
In the input buffer, 8 words are assigned for ’some’ special informations (see Table12) for RT-2/CZT. Description of special words are given below:Temperature word:Bits 7-0 : Temperature, Bits 9-8 : CZT number, Bits 13-10 : 0xF valid data, Bits15-14 : base address of RT-2/CZT EEPROMEvent number:Bit 15 : CZT3 ON, Bit 14 : CZT2 ON, Bit 13 : CZT1 ON, Bits 12-0 : (number ofevents)/64Line number:Bits 7-0 : CMOS line number, Bits 15-8 : frame intervalCMOS detector has only image information. A total of 4608 words of memory spaceare allocated for CMOS detector data in the input buffers. The image data allocationof CMOS detector in input buffer is given in Table 13.
Table 13
Data structure of CMOS detector data
Address Data Type Data (words)
Table 14
Data structure in accumulation buffer for CZT of the RT-2/CZT detector.
Address Data Type Data (words)
Data allocation of CMOS detector in accumulation buffer is identical as of inputbuffer and data structure is given in Table 15.
Table 15
Data structure of CMOS of RT-2/CMOS
Address Data Type Data (words)
During test mode, data in input buffer of RT-2/CZT is read by RT-2/E for teleme-try and in normal mode, data in accumulation buffer for telemetry. The allocation ofRT-2/CZT data in RT-2/E input buffer in test mode is given in Table 16.
Table 16
Structure of the allocation of RT-2/CZT data in RT-2/E.
Address Data Type Data (words)
RT-2 telemetry data is subjected to loss-less data compression, for effective bandwidthas well as memory utilization. Each frame of data is divided into different blocks, eachblock of size 64 words. Each block is compressed, made into packets and then writtento RT-2/E memory. CCSDS recommended Rice Algorithm (Yeh et al. 1991; Rice et. al.1993) is used for compression. There are various compression options in the algorithm, the best-suited option for each block is decided onboard and the selected option is usedfor compressing the block of data. If compression is not achieved for the data block,actual data will be sent. The compressed data is made into packets and is written inthe memory. Total data size in each frame, number of compressed block and block sizeis summarized below: • Number of telemetry data per frame: 3248 words for RT-2/S & RT-2/G, 12800words (including 7760 words for CZT, and 4608 for CMOS) for RT-2/CZT, 4096 Pro-gram memory words. • Number of blocks to be compressed: 51 for RT-2/S & RT-2/G data, 200 for CZTdata, 64 for Program memory data. • Block size: 64Each block data contains a block header of one word followed by the compresseddata and is written in the packet. Flow chart to compress data is given below: • Get blocks of data • Set first sample as the reference sample • Check the difference between successive samples • Select the best compression option for the block • Compress the differences using the best option • Packet the compressed data8.1 Compression Options:The block header word (16 bits) of each block has the following information:Bits 15-8: Compression option, Bits 7-0: Block number.The difference of adjacent samples in each block is computed and the differencevalues are coded using the best option given in Table 17.
Table 17
Compression options of RT-2/E telemetry data.
Option No. Option
No compression option
When this option is chosen, the data consists of block header followed by 64 datasamples of the block.
Zero block
When all the samples in the block are the same, all the difference values will bezeroes. In this case, this option is chosen. Here, for each block, compressed data consistsof one block header followed by the first sample of the block. Here, difference value as such will be coded using Rice code.
In this option, each difference value/2 is encoded using Rice code. The LSB of thedifference is appended as such. Thus, for a block, compressed data consists of threeparts - block header, Rice codes of all the differences and followed by the LSBs (LeastSignificant Bit) of all differences. The LSBs are packed into words and written, startingfrom a fresh word. In this option, there will be 4 LSB words, following the encodeddata.
In this option, each difference value/4 is encoded using Rice code. The two LSBs ofthe difference is appended as such. In this option, there will be 8 LSB words, followingthe block header and encoded data.
In this option, each difference value/16 is encoded using Rice code. The four LSBsof the difference is appended as such. In this option, there will be 16 LSB words,following the block header and encoded data.The fundamental sequence of Rice code is given in Table 18.
Table 18
The fundamental sequence in the Rice code.
Value Code
The detector data, after compression, is written in RT-2/E memory in the form ofpackets. Each frame data results a number of packets, having 60 words (960 bits) each.Out of these packets, first packet is frame header and the remaining packets are datapackets. Frame header is written into memory as such without compression. All datapackets (from second packet) consist of compressed data. First word of each data packetis the packet header.The packet header (Table 19) will have the packet number and the location wherethe next block of compressed data starts in the packet. If there is no new block datain the packet, this number will be zero. The packet header location in the first packet(frame header) will always be 0x0101.The description of the 60 words (1 packet) in the frame header is given in the Table20, 21 and 22. Table 19
Packet header in RT-2/E memory.
Bit No. Description
15 - 8 Packet number7 - 0 Starting location of first block of compressed data
10 Satellite Interface
A sophisticated interface scheme is provided for RT-2/E with the Coronas-Photonsatellite. Satellite interface scheme includes pulse commands and power ON/OFF forRT-2 payloads, telecommand interface line, scientific telemetry for down link detectordata and ‘real-time’ satellite telemetry to have instruments health informations inevery 4 seconds. Details of satellite interface with RT-2/E and specific requirementsare discussed bellow:1. Power and Pulse Commands (PC) for ON/OFF (14 contact commands):These commands are required for power ON/OFF of the instruments and selectionof GOOD/BAD operating region in the satellite orbit. All command informations aresummarized in the Table 23.2. Data commands (16 bits):To have the redundancy in telecommand, two separate telemetry interfaces 19 and20 are provided for each telecommand chain i.e. 5 lines X 2 parallel (‘AND’ed). Theseare the five parallel lines, which are named as ‘one second command’, ‘time sync’,‘command sync’, ‘clock’, ‘serial data’ for telecommands transmitted in two independentchannels.3. Scientific telemetry:Scientific telemetry is the transmission of the scientific (spectral/event) data fromthe detectors. Detector data are packetized in RT-2/E depending on the processingmode. This scientific telemetry is done in two separate telemetry channels TM1 (forRT-2/S and RT-2/G) and TM2 (for RT-2/CZT).4. Satellite telemetry (32 bits):Satellite telemetry is a ‘real-time’ telemetry scheme, which sends the data (healthparameters) in each 4 second. Satellite telemetry is done in 32 bits (total) - 8 bits forthree detectors (S, G and CZT) and for the electronics device (RT-2/E), which are sentevery 4 second. In these 32 bits, 15 bits are allotted for the three 5 bit counters (S, Gand CZT), 3 bits for 3 VCO bytes converted into bits and 8 bits for the parameters(status of memory, orbit etc.) in RT-2/E. Four digital channels, each of 8-bit wide areused to sent the informations to the satellite telemetry by RT-2/E. In Table 24, allinformations are summarized.
11 Ground Commands
There will be certain situations to adjust some parameters like the high voltage to thePMT, the LLD value and channel boundary value. These can be done from groundby sending commands to the satellite. Also, the data transfer and mode selection aredone by the ground commands. All detector commands are passed through the RT-2/Eprocessing device. Details of detector commands are summarized in respective papers(Debnath et al. 2009; Kotoch et al. 2009). RT-2/E commands are summarized in Table
25. These commands include processor mode selection (SFM, SQM, Debug, Test etc.)with different condition, Flare selection logic for S and G, reseting the RAM, BAD toGOOD time set duration etc.
12 Flare Detection
RT-2/E has onboard flare detection logic, which is executed every second. RT-2/Esoftware switches to Solar Flare Mode (SFM) or back to Solar Quiet Mode (SQM)based on the solar mode detected on every 10 second boundary. The solar mode isdecided based on the data from RT-2/S and RT-2/G. There are two options by whichthe solar mode is decided:1. When RT-2/S or RT-2/G, any of them gives flare data.2. When RT-2/S and RT-2/G, both give flare data.Either of these two options can be chosen by ground command. The commands0xE000 and 0xE001 choose ‘or’ logic and ‘and’ logic respectively. Once the solar modeis decided based on the logic, both RT-2/S and RT-2/G data is processed in the samemode, Solar Flare Mode (SFM, processing every 10 second) or Solar Quiet Mode (SQM,processing every 100 second).Flare detection every second is done based on the accumulated values of C1, C2and C5 counts (Scientific data are accumulated in 8 counters, for details, see Debnathet al. 2009) during the last three 100 ms intervals within the second. If the sum of theaccumulated C1, C2 and C5 counts exceeds a set threshold value ( F th ) in all thesethree intervals, then a flare is identified. These threshold values can be changed bycommand. Else, if the counts have not even exceeded the threshold at least once, thenthe data are assumed to be solar quiet data. Independent threshold values can be givenfor RT-2/S and RT-2/G. The commands for default threshold are 80FF and A0FF (seeTable 25). The default value of both these thresholds is 0xFF, which means that thecount rate should be ≥ F th x 32 i.e. 255 x 32 = 8160. Flare detection logic applies toRT-2/S and RT-2/G data only.
13 Discussions and Concluding Remarks
In a series of papers on RT-2 Experiment onboard the Coronas-Photon satellite, wehave described the technical details as well as the test and evaluation methods. In thepresent paper, we have discussed the processing electronic device (RT-2/E) of RT-2.On 30th of January, 2009, the CORONAS-PHOTON was launched successfully and allthe RT-2 payload components including RT-2/E are working to our satisfaction. TheData Structure and Data Management softwares are working as per plan as verified bythe onboard Data status.The onboard performance of the software was found to be very satisfactory. Sincemost of the data are slowly varying, a factor of 3 compression could be obtained, mostlywith 15:1 or 14:2 options. In the initial days of operation, the detectors were operatedwithout applying the High Voltages to verify the satisfactory response to the BADsignals from the satellite. Once these aspects are correctly established, the detectorswere operated in the SQM (by deliberately keeping the flare threshold high and notallowing any flare detection). It was found that the onboard memory was adequate.The ‘Test Modes’ were operated to calibrate the CMOS detectors as well as to make high time resolution observations of the Crab Nebula. In this mode, however, memoryfull signal was noticed and the system was going to the ‘BAD’ mode. In the subsequentoperations of the ‘Test modes’, duration of these modes are restricted by time-taggedcommands to avoid memory overflow. Once full confidence in the overall working ofthe instrument was established, the flare detection logic was enabled with appropriateflare threshold commands (Instruments were operated with 0x8002 command for flarethreshold value F th = 2 with count rate 64). The system was going to SFM duringabout 30% of time, mostly due to the flare triggers encountered during high backgroundregions. The details of the on board data calibration would be discussed elsewhere. Acknowledgements
DD and TBK thank CSIR/NET scholarships and RT-2/SRF fellowship(ISRO) which supported their research work. The authors are thankful to scientists, engineersand technical staffs from TIFR/ICSP/VSSC/ISRO-HQ for various supports during RT-2 re-lated experiments.
References
1. Debnath, D., Nandi, A., Rao, A. R., Malkar, J. P., Hingar, M. K., Kotoch, T. B., Sreekumar,S., Madhav, V. P., Chakrabarti, S. K.: Instruments of RT-2 Experiment onboard CORONAS-PHOTON and their test and evaluation I: RT-2/S and RT-2/G Payloads, Exp. Astron. (2010,in press).2. Kotoch, T. B., Nandi, A., Debnath, D., Malkar, J. P., Rao, A. R., Hingar, M. K., Madhav, V.P., Sreekumar, S., Chakrabarti, S. K.: Instruments of RT-2 Experiment onboard CORONAS-PHOTON and their test and evaluation II: RT-2/CZT Payload, Exp. Astron. (2010, in press).3. Kotov, Yu., Kochemasov, A., Kuzin, S., Kuznetsov, V., Sylwester, J., Yurov, V.,: Set ofinstruments for solar EUV and soft X-ray monitoring onboard satellite Coronas-Photon. In37th COSPAR Scientific Assembly, in Montral, Canada., p.1596 (2008)4. Nandi, A., Palit, S., Debnath, D., Chakrabarti, S. K., Kotoch, T. B., Sarkar, R., Yadav,V. K., Girish, V., Rao, A. R., Bhattacharya, D.: Instruments of RT-2 Experiment onboardCORONAS-PHOTON and their test and evaluation III: Coded Aperture Mask and FresnelZone Plates in RT-2/CZT Payload Exp. Astron. (2010, in press).5. Nandi, A., Rao, A. R., Chakrabarti, S. K. et. al.: Indian Payloads (RT-2 Experiment) on-board CORONAS-PHOTON Mission. In Proc. of International Conference on Space Tech-nology, Greece, G. Lampropoulos and M. Petrou (Eds.) (2009a) (arXiv:0912.4126)6. Rice, R. F., Yeh, Pen-Shu and Miller, W. H.: Algorithms for high speed universal noiselesscoding module. In Proc. of the AIAA Computing in Aerospace Conference, San Diego, CA,(1993)7. Sarkar, R., Mandal, S., Debnath, D., Kotoch, T. B., Nandi, A., Rao, A. R., Chakrabarti,S. K.: Instruments of RT-2 Experiment onboard CORONAS-PHOTON and their test andevaluation IV: Background Simulations using GEANT-4 Toolkit, Exp. Astron. (2010, inpress).8. Yeh, Pen-Shu, Rice, R. F. and Miller, W. H.: On the optimally of code options for a universalnoiseless coder. NASA JPL Publication, 91-2, (1991)1
Table 20
Description of the frame header in RT-2/E memory.
Word No. Description Remarks ≥ Fth, then flare flag set19 High Voltage command Current command given for HV20-27 VCO data (8 words) VCO channels of the detectors28 Memory availability** **See Table 2229 Ground command Last ground command given30 Bit15 (CZT and CMOS data flag) 1: CMOS data alone in CZT test mode0: CZT+CMOS data in CZT test modeBit14 (Timing flag) 1: timing alone in debug mode, 0: all data in debug modeBit13-0 (Number of event data) Valid only in test mode
RT-2/S & RT-2/G
RT-2/CZT
Table 21 *Status Port1
Bit No. Description Remarks
Table 22 **Memory availability
Bit No. Availability Processing modes supported ≥
50% All modes1 50% All except SFM2 25% Bad mode3 Nil No data
Table 23
Power and Pulse commands of RT-2 operation
Contact Identification Contact Contact type
PC124 Power ON (RT-2) Executed in BUS-FMPC125 Power OFF (RT-2) Executed in BUS-FMPC130 Switch ON (RT-2/S) Pulse dry contactPC131 Switch OFF (RT-2/S) Pulse dry contactPC132 Switch ON (RT-2/G) Pulse dry contactPC133 Switch OFF (RT-2/G) Pulse dry contactPC134 Switch ON (RT-2/CZT) Pulse dry contactPC135 Switch OFF (RT-2/CZT) Pulse dry contactPC136 Change Operational Mode Pulse dry contactPC137 RESET RT-2 Pulse dry contactPC147 LIGHT Continuous dry contactPC148 SHADOW Continuous dry contactPC149 BAD Continuous dry contactPC150 GOOD Continuous dry contact3
Table 24
Description of Satellite Telemetry bits (32 bits)
Bit No. Description RemarksRT-2/S
RT-2/G
RT-2/CZT
16 +5 V 1 = +5V, 0 = 0V17 Command mode: CZT status 1 = Command sent to Detector, 0 = Command not sentEvent mode: Sum of Vsum 1 = sum of Vsum > threshold, 0 = sum of Vsum < thresholdEEPROM data read mode Bit 1 of data in address 8176 of EEPROM*18 HV Feedback 1 = HV ON, 0 = HV OFF19 - 23 5 bit counter (Channel2 count of CZT1)/32In EEPROM read mode bits 3-7 of data in address 8176 of EEPROM* RT-2/E
24 LIGHT/SHADOW 1 = SHADOW, 0 = LIGHT25 GOOD/BAD 1 = BAD, 0 = GOOD26 Flare 1 = ON, 0 = OFF27 +5 V 1 = +5V, 0 = 0V28 - 29 Memory availability (TM1) 0 = > > Table 25
Ground commands of RT-2/E