NGU Proposed revision of recommendation CCSDS (401-B-20) on TC bit rate NGU WG Fall CCSDS Meeting - London UK - Oct 25, 2010

Need NGU WG resolution concerning the following 3 Proposals driven by NGU File Upload Profile Fall CCSDS Meeting - London UK - Oct 25, 2010

3 Proposed Changes as a result of the NGU File Upload Profile Add 2 Msps (2048 Ksps) to the Telecommand Rate Table (2.2.8), since it can be supported today The requirement is to be able to command up to 2 Msps (coding overhead included) with the same spectral efficiency of today’s modulation. Reduce the data rate steps from 3 dB to 1.5 dB, doubling the number of Telecommand data rates currently supported. For the existing 11 Telecommand rates (disregard the 2 nd proposal), specify each rate to 3 significant figures. In addition, provide a tolerance range for each rate. Fall CCSDS Meeting - London UK - Oct 25, 2010

Responses Received CNES NASA ESA Fall CCSDS Meeting - London UK - Oct 25, 2010

CNES Response Support adding a 2 Msps rate (2048 Ksps) Support adding more intermediate rates with a 1.5 dB progression. Prefer ESA proposal for the computation of the rates : 1000*Round(2^(n/2),1) As for the tolerance on the rates, +/-1% is too loose as it might not be compatible with a narrow rate recovery loop on-board. +/-0.1% is more the order of magnitude of precision CNES would like to keep in the spec. Fall CCSDS Meeting - London UK - Oct 25, 2010

NASA Response Support adding a 2 Msps rate (2048 Ksps) Practically speaking, the data rate is fixed to a high precision by the on- board oscillator driving the data rate. – Current divide by 2 data rates are easy to implement (results in 3 dB steps) – Divide by 1.5 dB = which isn’t easy to implement in a digital circuit. – CCSDS should not specify on-board Oscillator Clock Rate (implementation Issue) However, for all existing TC data rates defined today and the newly proposed 2048 Ksps, specify each data rate to 4 significant figures. In addition, in Section 2.2.8, state the tolerance for each defined data rate. – This allows each mission to divide their oscillator by the value that gets them the closest to the CCSDS defined TC data rates and then allow missions to use that resulting value as long as it is within tolerance. As for the tolerance on the rates, use +/-0.1% as the order of magnitude of precision in the spec. Fall CCSDS Meeting - London UK - Oct 25, 2010

How would change So for the existing 11 data rates in and the new 2048 Kbps rate, the change would be: – 1000 bps becomes data rate x 10^3 bits/sec between 0.999x10^3 bits/sec and x 10^3 bits/sec – 2000 bps becomes data rate x 10^3 bits/sec between 1.998x10^3 bits/sec and x 10^3 bits/sec – … – bps becomes data rate x 10^6 bits/sec between 2.046x10^6 bits/sec and x 10^6 bits/sec Fall CCSDS Meeting - London UK - Oct 25, 2010

ESA Response Support adding a 2 Msps rate (2048 Ksps) No requirement to add additional Telecommand data rates such as adding more intermediate rates with a 1.5 dB progression. No preference ESA proposal for the computation of the rates : 1000*Round(2^(n/2),1) Supports a tolerance specification on the rates – I am not clear how tight a tolerance is desired by ESA Fall CCSDS Meeting - London UK - Oct 25, 2010

V. Sank 10/22/10 Choosing Frequencies in a Transmitter A mission either requests a specific carrier frequency or gets one assigned by the spectrum manager. The design engineer then selects and architecture and an oscillator that can generate that carrier frequency, often by simple integer multiplication, preferable, by factors of 2. We will used the IRIS X band as an example where the carrier is 8483 MHz. The oscillator is planned to be 8483/32 = MHz. The desired coded data rate is 15 Msps. To get something around 15 MHz, divide by 16 and get … MHz or divide by 17 and get MHz. We cannot easily get 15 MHz exactly. To get exactly 15 Msps, we would have to generate a phase locked loop (PLL) of sorts in the FPGA. This is not desirable as it wastes precious gates in limited flight FPGAs. Note that this data rate is off in the third figure from the desired rate of 15 Msps. When digitally shaping bits, it is common to used 4 samples per modulation symbol which in the case of QPSK (or OQPSK) is two bits. Just think of it as 4 samples or 4 points per bit to get the shape you want. If NTIA and SFCG did not exist and we used square bits, the 4 samples would be all 1s or all -1s. But NTIA and SFCG do exist and we have to make the spectrum meet the mask. In the old days, we literally filtered the output of the modulator which is inefficient, results in a BER implementation loss, and gives only mid quality results. The mask requirements are written as if we still simply put an analog filter on the modulator or power amp output. This is rarely done during the last 10 or so years. Today we do digital signal processing (DSP) in the form of what is called baseband filtering. In the early simple minded days of digital baseband filtering, the bits were just fed to a digital process that applied a digital form of a classic analog filter, Bessel or Butterworth or … filter. This stinks because it acts like a filter with capacitors and inductors and has time constants involved. If you look at a 1 bit that follows a previous 1, you get a certain shape after the filter but if you look at a 1 bit that follows a 0 bit you get something slightly different. The voltage of the second of two 1s in a row will be higher than the voltage of a 1 that follow a 0. Today in DSP, we craft our bits. We give the bit the “exact” shape we want it to have. For SQPSK and for a given bit on the I channel, we look at the previous bit, the following bit and the two bits that it straddles on the Q channel, and vice versa. For high data rates, the “exact” shape is limited to 4 point, 4 samples. So for 7.5 Mbps on each of the I and Q channel, we need to run the bit shaping clock at 30 MHz. Using the numbers above, that would be MHz. But the symbol rate would be Msps shown above. Another example: A few years ago when we built and X band transponder at 8470 MHz, we used a MHz oscillator, We divided the 8470/down link frequency by 880, one of the numbers in the turn around ratio, and got MHz. The turnaround ratio at X band for a coherent transponder is 880/749 so the coherent up link was 749 x MHz = MHz. We had a small tune range on the oscillator and that is how we tracked the uplink. Worked just fine, we flew three of them. The data rates were not simple numbers. For 200 Kbps we divided the MHz oscillator by 48 and got …Kbps. The ground bit synchronizers have to compensate for doppler anyhow so they have a tracking loop. The 2 Kbps came out to Kbps. 9