Introduction

The spacecraft transmits CCSDS packets from the on-board instruments through the space network, multiplexed as coded VCDU packets in CADU packets.

CADU = Channel Access Data Unit, physical packet format including sync words, 1024 bytes.

VCDU = Virtual Channel Data Unit, packet format inside CADU, 892 bytes.

CVCDU = Coded VCDU, i.e. including Reed-Solomon ECC, 1020 bytes.

M_PDU = Multiplexed Protocol Data Unit, multiplexing of CCSDS packets inside VCDU

CCSDS = Consultative Committee on Space Data Systems, standard packet format multiplexed in VCDUs, variable sizes.




MODIS CCSDS packets are either engineering, calibration or earth view. The latter is one short night packet or two long day packets per IFOV; there are 1354 IFOVs per scan line. There are differing numbers of samples per IFOV for different channels; some are single, some have two and some have four.


Packet Format

The CADU packets are transmitted with several layers of encoding. Terra and Aqua use RS (Reed-Solomon) encoding and PN (Pseudo-Noise) encoding but only Aqua abides by the CCSDS recommendations. Terra does not PN-encode the VCDU primary header, only the VCDU data, whereas Aqua does both. Terra data needs to be RS decoded before being PN decoded, whereas Aqua, which follows the CCSDS recommendations, is the reverse.

Since there can be multiple (or partial) CCSDS packets inside a CADU starting at any location, the offsets inside the CCSDS are labelled with a preceding + symbol. The offset to the start of the first packet is given by the M_PDU header.

Byte offset

Bytes

Bits

Section

Description

Value

Comment




CADU




0

4

32


Sync words

1A CF FC 1D

Not R-S coded




VCDU pri.hdr



PN on Aqua

4

2

2


Version number

01


8


Spacecraft ID

2A for Terra, 9A for Aqua


6


VC ID

Terra: 2A for MODIS, 29 for MISR, 3F for fill; Aqua: 1E for MODIS

See ICD-106 p.61; ICD-j21 B-5

6

3

24


VCDU count

0 for fill, or 1 to ...

per VCID

9

1

1


Replay flag

0


7


Spare




886


VCDU data



PN-randomized

10

2

16

VCDU insert

Encryption key

METOP only





M_PDU hdr




10 (12 on METOP)

2

5


Spare



11


Pointer to first CCSDS header

Byte offset, or 7FF if no header

Offset starts after this hdr




CCSDS pri.hdr




+0

2

3


Version

0


1


Type

0=normal, 1=test


1


Secondary hdr flag

1


11


APID

MODIS: 64 to 127


+2

2

2


Sequence flags

01=first, 10=second, 11=only packet


14


Packet count

0 to 16383

per APID

+4

2

16


Packet length

Sec.hdr+data-1

N.B. minus one




CCSDS sec.hdr




+6

2

16


Time: days

Since 01-Jan-1958 (MODIS) or 01-Jan-2000 (METOP)


+8

4

32


Time: milliseconds

ms of day


+12

2

16


Time: microseconds

of millisecond


+14 (MODIS)

1

1


Quicklook flag

1 if selected


3


Packet type

000=day, 001=night, 010=eng1, 100=eng2

Day is 2 long data packets, night is 1 short data packet.

3


Scan count

0 to 7

Relates data to a particular near-time scan

1


Mirror side

0=side 1, 1=side 2


+14 (METOP)

6 (8 for Admin, 12 for AVHRR low rate)

8 + 24 + 16


Ancillary data (time +)

0 + seconds + 2-16 seconds

Epoch changes; time rollover every ~6 months




CCSDS data







MODIS hdr



12-bit words

+15

3

1


Source identification

0=earth, 1=calib


11


Source identification

0=eng., 1 to 1354 for sample count


10


FPA/AEM config

Bit set for each detector type on


1


Sci State

0=test, 1=normal


1


Sci Abnorm

0=abnormal, 1=normal





MODIS data



12-bit words

+18

622.5 or 256.5

4980 or 2052


Day / Engineering packet

Night packet




1.5

12


Checksum

12-bit sum of data field





Coded VCDU




896

128

1024


R-S coding











MODIS Pixel Readout

There are 1354 pixels across and 10 IFOVs down per scan line. Bands with 1km resolution have 1 sample, those with 0.5km resolution have 4 samples and those with 0.25km resolution have 16 samples. During the daytime one pixel is transmitted in two packets, the first contains IFOVs 1 to 5, the second contains IFOVs 6 to 10. For each IFOV the bands are read out in order 1 to 36 (bands 13 and 14 having both a low and a high value). For each band the pixels are read out in the order show in the diagram below.



Level 0 Format

Level Zero format is the time-ordered stream of CCSDS packets relating to a particular VCDU extracted from the CADU stream, with duplicate packets removed.

PDS files (Production Data Sets) are simply level-0 data but may have other requirements such as construction records and file name conventions.

File name convention: Psssaaaasssaaaasssaaaayyjjjhhmmssicc.PDS where the tuples sssaaaa are 3-digit spacecraft id and 4-digit application process id (APID) for each APID (up to 3) in the file or "AAAAAAA" if less than three. yy is the 2-digit year, jjj the 3-digit julian day of year, hhmmss the time, i is a file id and cc is a counter 00 for construction record and 01 to 99 for each segment of the file if split due to size limits.

Construction records contain:

There are several utilities for converting from raw data to level-0. NASA Goddard supplies Sorceror, and independent versions have been developed by Dundee Satellite Receiving Station, the University of Hawaii.


EPS Level 0 format

The Eumetsat Polar System defines a different level-0 format for data from MetOp satellites. Staring with the level-0 format defined above, each CCSDS packet is encapsulated in a MDR (Measurement Data Record), which just adds a small header. The whole file of MDRs has several other header records, such as MPHR (Main Product Header Record) which is a (mainly ASCII) description of the file, some IPR records (pointers to the data records), and a record which contains the instrument time calibration parameters.


Level 1 Format

Level One format is the raw data plus sensor-calibration and geolocation information. Level-1a has the extra information appended to the data set, level-1b has it applied. MODIS Level 1b format is HDF-EOS and is supplied in several files. Note that the earth view data is stored as a non-standard data set which cannot be read with normal HDF utilities. You need to upgrade to an HDF-EOS utility to read them.

File SDS name SDS contents
250m EV_250_RefSB b1..2 = channel 1, 2 (reflective)
500m EV_500_RefSB b1..5 = channel 3..7 (reflective)
EV_250_Aggr500_RefSB b1..2 at 500m
1000m EV_1KM_RefSB b1..15 = channel 8,9,10,11,12,13lo,13hi,14lo,14hi,15,16,17,18,19,26
EV_1KM_Emissive b1..16 = channel 20,21,22,23,24,25,27,28,29,30,31,32,33,34,35,36
EV_250_Aggr1km_RefSB b1..2 = channel 1,2
EV_500_Aggr1km_RefSB b1..5 = channel 3..7
EV_Band26 b1 = channel 26

There are two utilities for converting from level-0 to level-1, both being stand-alone modifications to the software used in the DAACs. NASA Goddard supplies one which utilises a huge DEM for geolocation. The University of Wisconsin's IMAPP does not require the huge DEM. There are other differences but both should produce a result which matches the DAAC version very closely. The main difference in the DAAC is the presence, a few hours after the data has been received, of updated orbital information which aids geolocation. This is obviously not available to real-time direct broadcast sites.


References


Software

Level 0:

Level 1:


Author: Andrew Brooks. Last updated 18-April-2007.


Home Page Dundee Satellite Receiving Station Home Page      Send Us A Comment Send Us A Comment