Here we attempt to pull apart some of the details inside an individual imagery packet from a single channel. The
accompanying screenshot shows a printout of one of my decoding programs. It shows the results of the stage
that has just collected all of the packets of APID 67 - the 3.5um channel.

THE PACKET HEADER:
The first seven fields before the hyphen are the values out of the 6 byte packet header.

The first value, '0' is the Version field. All documentation to date suggests this should be zero.

The second value, also '0' is the type field. This is also always zero, at this stage.

The third value, '1' is the secondary header flag. Set to one, it indicates that there is secondary header information
following the packet header. The Metop documentation states that their LRPT would use this area for date and
timestamps and such. The Meteor LRPT seems to have a similar setup, as we will see soon.

The fourth value is obviously the APID, in this example it is 67. As you can see the software has used this value
to collect together all the packets with the same APID.

The fifth value is the sequence flag. Meteor seems to use it to help group together the 16 JPEG image tiles involved
in building up one 1536x8 block of imagery from 8 consecutive raw scanlines. The operation of the flag is as
follows:- the first packet (the first 96x8 pixels on the left hand side of the image) has the flag set to '1'. The next 14
packets (the middle of the line) have the flag set to '0' and the last packet (the last 96x8 pixels on the right) has the
flag set to '2'. This value can be used as part of a scheme to help lay down the tiles in their correct positions in your
viewer software.

The sixth value is the packet sequence counter. All the packets from a single VCDU VCID stream, in this case '05'
have a sequentially incrementing count. The values on this screen show that all 16 packets for a single block and
for a single channel (APID) are sent one after the other and then there is a gap. This gap is where the same scanline
from the other channels are being sent - as well as packet APID 70. This counter can also be part of a tile placement
(image navigation) system.

The last field in the header is the packet length count. Even though the image segment is a set size - 96x8 pixels - the
JPEG compression produces a variable size result depending on the amount of detail in the original image tile. So you
can see the size of the data field stretching between the mid 200's to the mid 400's in byte size. It can even be bigger
or smaller than these values, depending on the channel and the time of day. Packet 70 can be only 40-60 bytes long.

THE "SECONDARY HEADER" AREA:
The 8 bytes immediately following the 6 byte primary packet header are refered to as the secondary header in the
Metop LRPT documentation. They reserve it for timestamp information. Below is a excerpt from their specification
describing what each byte means.

The Meteor data seems to suggest that, at this time, they only use the four middle bytes that represent the milliseconds
of the day count (from 00:00 UTC). In a previous processing step I have decoded these four bytes and they do
indeed produce a time value co-incident with the orbit time in UTC.

ANCILLIARY DATA FIELD:
The next six bytes, sometimes loosely refered to as the "ancilliary data field", contain two more useful pieces of
information. The first byte is a counter that increments by 12. It is zeroed at the start of each block of 16 packets
that make up the 1536x8 pixel block. This count represents the MCU count along the block scanline. There are 12
MCUs per image tile and 16 image tiles per block, for a total of 192 MCUs per block. The numbers work out as:
One MCU is an 8x8 pixel square of data.
Twelve MCUs in a row make a 12x(8x8) = 96x8 pixel image tile.
Sixteen tiles make a 16x(96x8) = 1536x8 pixel block of 8 consecutive scanlines from the one channel.
Obviously, this counter is very useful in putting all the JPEG tiles in order across a line.

The next two bytes appear to be always zero.

The last three bytes are very important. The 2 byte combination 'FFF0h' is a JPEG flag stating that the next byte
is a user specific, or custom value that has a special meaning for this current JPEG dataset. It turns out that
this byte (the third byte - '64h') represents the JPEG 'quality factor'. The quality factor is a number between 0
and 100 percent and is used to control the amount of compression applied in the JPEG algorithm. LRPT uses this
feature of JPEG to control and even out the bit rate. A value of 64h is 100% and means that the compression is
supposedly lossloss, but won't be as high a compression ratio. I have seen the value down as low as 50h, meaning
a quality factor of 80% and a more lossy, but higher compression ratio. This value must be passed to the JPEG
decompression decoder software for each packet/image tile.

THE JPEG DATA:
In the top screenshot you can see the 5 bytes on the extreme right are the start of the JPEG data proper. It continues
until the end of the packet as defined by the packet length field. The JPEG algorithm itself determines how much more
data it needs to complete an image de-compression. It keeps moving through the bitstream, recovering pixels until it
has enough for the completed bitmap. This leads to the situations where you can either have not enough or too much
data in a packet - at which point you know you either had a reception error or your JPEG algorithm has failed.