= Known processing problems =

== CASI data missing GPS sync ==

If you're seeing azgcorr failing with `** read error on SCO input` and, earlier in the output, azcaschk2 is reporting:
{{{
GPS message time to CASI clock time difference(s)...
  del_t : 
  freq  : 
  most frequent gap is: 0  secs

** NO (or insufficient) GPS messages or sync pulses
**    ... no sync saved
}}}

This means the CASI data files are missing the GPS sync markers (or azcaschk2 can't find them).  As a consequence, scans can't be tied to navigation and azgcorr has nothing to work with.  Typically, you'll be able to get the file to level 1 without problems, but level 3 can't be done.

To work around the lack of GPS sync, azcaschk2 allows you to use "frame headers" for sync instead.  You need to add `-FRsync` to the azcaschk2 command line.

This should then process through to level 3, though you may need to correct for navigation timing.

== Errors in aznav interpolation stage ==

These can occur (particularly with CASI) when there is a large offset between the site time limits and the ones on the file.  azimport will pull in the section of the navigation data according to the file limits and the actual required navigation may be outside this range.  A typical error looks something like:
{{{
*** DPspline2D no returned vectors  spl_err: 1  slpp 1: -2.4420659 n: 1.9638544
  in  len: 82201   time[0]: 42062.001400  [82200]: 42472.997200
  out len: 11667   time[0]: 42603.547100  [11666]: 43011.876100
  in time vector:
 42062.001400 ...

  out time vector:
 42603.547100 ...

** end of DPspline2D error print

** lat+lng interpolation, vectors incomplete
** should be from index: 0 to index: 11666
** valid data only from idex: 0 to index: 0
}}}

To fix this, forcibly specify the time range you want to insert navigation data for with `azimport -t JJJ HHMMSS HHMMSS ...` (JJJ = Julian date, then the start and end times from the logsheet, plus a few minutes), e.g. `azimport -t 261 110000 111000 ...` for day 261 11:00:00 to 11:10:00.

---------------------

== Image looks straight but vector layers are not lined up ==
(amro comment)

If the image looked okay after modifiying the GPSOFF and then the vector layers did not line up, them it is better to modify the SCTOFF instead of GPSOFF. This will bring the vector layers to their places (e.g project 2006/206 line 1 , 4 , 5 )