The third layer up in the CCSDS protocol stack is the 'network' layer. For our use in LRPT it provides a second, finer
grained addressing or description of the data source/destination. It also defines the data itself in terms of size of the data
transfer at this point. What I mean by this is the processing from here on becomes more complicated as the data fields
are no longer a fixed length that fits neatly into the 1024 byte CADU frame that we have been used to. The data structure
at this layer is called the SDU - Service Data Unit. More often, it is refered to as a 'Packet'.

Data packets finally contain the actual instrument data, be it imagery or other data from sounders and any other special
sensors the spacecraft may be carrying. The length of these packets is mostly defined by the instrument itself and what
it may be measuring. An obvious example is a scan line from the imaging camera. The number of bits per pixel, the
number of pixels per line and the number of channel bands would all contribute to a logical line length to use. The nature
of any interleaving and whether or not any data compression is used also influence how the packets are ultimately
constructed. Packets can range from a few tens or hundreds of bytes to several tens of thousands of bytes. Also, there
can be very small packets that come at the very end of a particular transfer, just to finish up. There can also be fill
packets, containing zeroes, that are used to pad out a transfer and maintain a fixed bitrate.

Something not explicitly documented in the 'official' CCSDS documentation is how the satellite providers choose to use
the protocol to best suit their needs. The protocol is simply a set of guidelines, or template, that anyone can use to frame
up their data. Of course, each satellite is very different and carry a wide variety of instruments. The format of the output
data of these instruments can set a logical place within the protocol where it is no longer appropriate to continue up the
layer stack.
Geostationary satellites, by virtue of their fixed position, tend to produce products (eg; images) that have a start and end.
A full disk scan will typically start over the north pole, scan southward some number of lines, and finish up past the south
pole. This type of data transfer needs to be flagged or 'bounded' by some mechanism. The CCSDS layer above the
packet (network) layer is called the transport layer and typically deals with the concept of discrete products that need to
be separated out.
Polar orbiting satellites, on the other hand, really don't have products that have a start and an end. The nature of their
orbits mean that the data delivery method is one of simply constantly streaming the data being observed below the
spacecraft. Acquisition on the ground is a hit and miss affair, mostly at both horizons where the signal is weakest. So there
is no concept of a 'frame' of data - an individual image or scan. Each line of data (imagery, sounder etc) scanned across
track by the onboard instruments as the spacecraft moves along track must be considered a discrete unit of data. Metop
AHRPT, FY3 CHRPT and Meteor HRPT all send a single scan line within a single packet. In contrast, geostationary
satellites use multiple packets to build a complete frame of data. In these cases they use what are called a 'start' packet,
lots of 'middle' packets and an 'end' packet to de-linearate the frame. The start packet will typically include extra
information about the frame, including some form of ID and a total file size. For polar orbiters, the packets are usually
all marked as 'self-contained', or individual packets to be collected separately, albeit sequencially, and laid down in time
order to build an image of what the satellite saw over the footprint of the reception site. Any 'missed lines' can be
replaced by a blank filler line (a process called flywheeling) to maintain image perspective, or navigation.

Meteor LRPT has a further complication to deal with. The imagery data is compressed using the JPEG standard. A
portion of the image is sectioned off, compressed according to the JPEG algorithm, and then sent in its own packet.
These packets form a sequence of image 'tiles' that can be re-assembled back on the ground to build up the complete
image from the pass. Meteor LRPT seems to have 'borrowed' the start-middle-end packet concept to group up all the
image sections associated with a single scan line block. More on this later.

Here is the full breakdown of the 6 byte source packet header from the MTSAT HRIT/LRIT specification.
Note: The 8190 byte maximum length only applies to MTSAT HRIT/LRIT. Other spacecraft have used longer packets.



The 6 byte source packet header contains quite alot of information and each detail needs to be pulled out to allow any
processing system to further proceed.
The Version and Type flags can usually be skipped. They are most often set to zero.
The secondary header flag is used when there are details about the start of a new product in the transport layer at the
start of this packet. LRIT uses this to signify the start of a new image scan. The APID number identifies the instrument
source of the data.
The APID labels the data source. The mission specific specification documentation should list all the APIDs in use by
the satellite. For Meteor LRPT, I have seen APID 67, 68, 69 and 70 used. Others have reported seeing APID 64, 65
and 66 as well. These would appear to correspond to one of the six channels of the imager plus the Metop-style channel
70 for ancilliary data. For the three APIDs that I see, I believe that 67 is the mid-wave infrared channel at 3.5um and
68 and 69 are the 'split window', long-wave or thermal infrared channels at 10.5 and 11.5um. All the packets of the
same APID must be collected together in order to build up a complete image of the pass in that particular channel.
The 2-bit sequence flag has the following meaning:
01h, 1 - This packet is the first (or 'start') packet in a transport frame or block of data, such as a full-earth scan.
00h, 0 - These packets are the 'middle' parts of a frame or block of data.
10h, 2 - This packet is the last, or 'end' packet of the frame.
11h, 3 - These packets are 'self contained' and don't belong to any larger unit of data.
An LRIT image product will start with a '1' packet, be followed by a number of '0' packets and be completed by a '2'
packet. Also, the '1', start packet will have the secondary header flag set, indicating that this packet contains further
information about this scan - usually a pruduct ID number and a file size value. For Metop LRPT, all the packets are
labelled as '3's, indicating that they can be treated as individual units of picture data. Meteor LRPT, on the other
hand, has used the sequence flag to help delinearate the 12 packets involved in making a complete block of 8 scan
lines of imagery from a single channel. This will be fleshed out in the packet details description page.
The packet sequence count is not that useful for LRIT, since the data in a packet is usually compressed and the
packet length is not related to a image scan line length. But for LRPT, the packets define a fixed portion of the image
and you can use the count as part of a flywheeling mechanism to fill in missing data with blanks in order to keep
the remaining image portions in their correct spot.
The packet length value defines not the whole packet length, but only the user data field. It is set to the length of the
user data field minus one. Handy for zero-based arrays and arithmatic, not so handy otherwise... Once you have this
packet length you can read off this many bytes (plus one) to collect all the packet data.
The 2-byte CRC field at the end should be a 16-bit CRC generated from the application data only (not the header)
I have successfully decoded several CCSDS and other datastream CRCs - a quick look at this Meteor CRC did not
manage to succeed using previously used methods... it will need more investigation.