Changes between Version 10 and Version 11 of Processing/KnownProblems


Ignore:
Timestamp:
May 7, 2008, 11:19:28 AM (17 years ago)
Author:
benj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Processing/KnownProblems

    v10 v11  
    8888
    8989This is probably due to an incorrect central meridian specified in azgcorr.
     90
     91---------------------
     92
     93== Failed to find GPS sync ==
     94
     95(level 1 processing only - will not apply to external ARSF users if only processing level 1 data to level 3)
     96
     97If azimport fails to find a GPS sync you must use the -sYS option to azimport to use a manual sync:
     98{{{
     99azimport ... -sYS 0 0 0 0 ...
     100}}}
     101
     102This will allow processing to complete but will leave the GPS timing wrong (and will therefore put the line in the wrong place during geocorrection). To correct this, use an SCT (scan timing) offset by using the -so option to aznav:
     103{{{
     104aznav ... -so <sctoff> ...
     105}}}
     106Trial and error will need to be used to find the correct value for this (align the final results with either vectors for the target area or one of the other known good sensors for the same line), but it is suggested that you try an SCT offset of 13.9, 14.0 or 14.1 - one of these seems to be correct reasonably frequently (possible GPS delay error?).