Frequently Asked Questions

To ease your transition to the world of Low Rate Information Transmission (LRIT), we have compiled a list of common questions; easy fixes and simple tips that will help you.

I am trying to compile the LRIT software available at LRIT Home Page. I can´t do this, can you tell me how I need to do for compile it?

To answer your question, the beta source code you downloaded from http://noaasis.noaa.gov/NOAASIS/ml/LRIT.html is 100% C++.  To generate the executables, Microsoft Visual Studio.net and Borland C++ Builder 5 are necessary.  There are several .vcproj files, which are Visual Studio project  files, and the d6.bpg file which is the Borland workspace file.  First, load the .vcproj files and compile.  Next, load the d6.bpg file and compile.  The Borland GUI source may have some non-standard syntax and is separate from the data processing logic.  If the user needs only the processing components, then the user can write their own GUI and they do not need the GUI stuff.  The Physical Layer contains proprietary code and is thus not included.  The LritPhysicalLayer.idl file, which is the interface definition file ,should be included so that users may create their own Physical Layer for other hardware.  If the user wants to use the software with a Monarch board, they may use the LritPhysicalLayer.idl directly.

Back to top

Can you give us a list of APID's against their respective GOES LRIT image/product format? 

VCIDs and APIDs are assigned based on priority not on image/product format.

Back to top

Can I assume that VCDUs will arrive in sequence?

VCDUs of the same VCID should arrive in sequence, otherwise it is a sequence error. However, each VCID has its own sequence counter. So you can have VCID-Seq stream that looks like:  0-0,0-1,4-4,0-2,4-5,61-515,0-3

Back to top

Every LRIT file has a primary header.  The last value in the primary header is the data field length in bits.   In all the files we've checked, the length of the data field is set to #image columns * #image rows.   We are pretty certain that the data field length should be equal to (or within seven bits shy of)  8*(total file size in bytes - total header size in bytes).  Why do we see this?

When lossless compression is employed in LRIT, Rice compression is used.  Rice compression is being performed at the packet level, in the Transport Layer.  At that point, the concept of the file (data field length) size doesn’t really mean much. In the Transport Layer it isn’t a file; it is a series of packets.  There are several reasons for it being done at the packet level, but a major one is robustness. Packet loss only means loss of N scanlines, where N is set in the Rice header, and is normally 1. If it was done at the file level, if you lose a packet, you’ve lost the entire file.

I have found that the APID (Application Process Identifiers) in the source packet headers are not in the range specified in the LRIT Transmitter Spec, 0 - 191 for GOES LRIT data. I am seeing APIDs in a range of approx 450 to 1350. The lrit transmitter spec says these are 'Not used'.  Should I be worried about this?

Based on the document you  read, you are correct.  Unfortunately the document you read had not been updated.  It is being updated currently and should be available soon.   Effectively, the original idea was to only use six priorities which would generate the APIDs 0-191.  Subsequently it was decided to utilize 63 priorities which would account for the APIDs 192 - 2015 designated 'Not Used'.

When I read LRIT headers on my assembled LRIT files I see some files which are indicated to be of data type 'Image' and then, Compression type 'Lossless', and NOAA specific compression type 'None'.  Is this a valid header configuratioin or am I reading the data incorrectly?

If the data type is 'Image', and the Image Compression type is 'Lossless', then the NOAA specific compression type should be 'Rice', not 'None.'  Or the Compression type should be 'None' and the NOAA specific compression type should be 'None.'

I have a number of Lrit files where the global lrit file type looks like it is -126. (instead of 0 for Image or 1 for Messages etc). Do you know why this might be or what -126 corresponds to?

The file type you are seeing as -126 is actually 130 which represents data from DCS.  You are using a signed byte to get this value when you need to use an unsigned byte.

Which  JPEG compression is to be used for the lrit transmissions. Is it standard JPEG or JPEG2000 format?

Current JPEG compression is standard JPEG.  JPEG2000 may be included in the future.

Will you supply LRIT receiver schematics like you did with WEATHERNODE decoder?

Receiver schematics and such are not being provided, however, NOAA is providing basic software source code. See
NOAA LRIT Web Page

What is your best estimate on when the WEFAX downlink will no longer be available to users?

Presently, WEFAX will be discontinued on GOES-East and GOES-West on 31 December 2005.

Back to top