SPECIFICATION FOR A PROGRAM TO GENERATE SIMULATION OF DOWNLINK HEADERS L. D'Addario 94/06/01 This document describes a program whose job is to create a file that simulates the downlink data from an orbiting VLBI satellite. Only the header portion of each frame is simulated, and the data is written into an ASCII file as hexadecimal numbers. Any length of data can be simulated. Algorithm The program operates interactively, prompting the user for required information. Initially, it needs: output file name satellite (VSOP or Radioastron) data mode of satellite It then proceeds as follows: 0. Open the specified output file. 1. Prompt the user for the value of each parameter that is transmitted in the headers for the specified satellite and mode. These values apply at the beginning of the period of time to be simulated. A reasonable default value is provided for each. 2. Prompt the user for an interval of time to be simulated. If zero is entered, close the output file and exit. 3. Prompt the user for the value of each header parameter at the end of the interval. The default is the value at the beginning of the interval. Generally, this signifies a step change of the value at the end of the interval, so that changes are effective only if another interval will be specified. But for some parameters an option is provided to make the value during the interval vary linearly with time from the beginning to the end. 4. Calculate and write to the output file the simulated header bits for the specified time interval. One record (line) in the output file corresponds to each downlink frame (see further details of format, below). 5. Go to step 2. Record Format Each record is a hexadecimal string, with optional embedded blanks and tabs for easier reading, terminated by the newline character. The first digit in the string and the most significant bit of each digit is the one transmitted first on the satellite downlink. For VSOP, the record is 12 bytes (24 hex digits) long and represents the composite of the I and Q modulation channels. For Radioastron, the record is 60 bytes (120 digits) long, with the first 30 bytes representing the I channel data and the next 30 bytes representing the Q channel data. Notes For VSOP there are 200 frames per second, with 16 different header types. Each header type is repeated 25 times before switching to the next type, giving 400 frames or 2 sec for a complete cycle of all data. The program must take special care to get the header sequence right if the user enters intervals that are not multiples of 2 sec; it would be acceptable if the program enforces a requirement that all intervals be multiples of 2 sec. Even though the significant data is repeated for 25 frames at a time, all 25 frames must be simulated because they include a sequence number (0..24) that changes each frame. Also for VSOP, although the normal sequence is that the header types step through the cyclic series 0,1,...,15,0,... each 25 frames, timing considerations on the satellite will sometimes cause a header type to be repeated for an additional 25 frames, or for a header type to be skipped. Thus, sequences like 0,1,2,2,3,4... or 0,1,2,4,5,... are possible. These situations should be included in the simulation. For Radioastron, each byte of data in the headers is actually 9 bits long because a parity bit is added for each 8 bits of user data. In an initial version of the simulation program, the parity bits should simply be omitted; we will consider adding them in a later, more sophisticated version. Also for Radioastron, each frame's header contains 2 bytes of special "housekeeping" (HK) data from the spacecraft bus. This data forms longer records in its own format over many frames. We do not know all the internal details of these records, but the program should simulate all aspects that we currently know. Those details are given in Russian documents, available separately.