Changes between Version 11 and Version 12 of Processing/KnownProblems

Timestamp:

Jan 23, 2009, 12:39:21 PM (16 years ago)

Author:

benj

Comment:

Added more detail to the Eagle/Hawk sync section

Processing/KnownProblems

@@ -2 +2 @@
 
 == CASI data missing GPS sync ==
+
+(Note... same problem for Eagle/Hawk further down)
 
 If you're seeing azgcorr failing with `** read error on SCO input` and, earlier in the output, azcaschk2 is reporting:
@@ -91 +93 @@
 ---------------------
 
-== Failed to find GPS sync ==
+== Failed to find Eagle/Hawk GPS sync ==
 
 (level 1 processing only - will not apply to external ARSF users if only processing level 1 data to level 3)
 
-If azimport fails to find a GPS sync you must use the -sYS option to azimport to use a manual sync:
+Firstly, check the header file for the affected flightline. Sync problems are sometimes caused by the start time for the line being recorded incorrectly. If it's obviously wrong, copy the start time from the other sensor (or estimate from the logsheet if both are affected - if you do this you will have to fiddle with it later to get it right).
+
+Failing that, the option we usually use to manually set sync that's been irretrievably lost is the -sSE option to azspec:
+
 {{{
-azimport ... -sYS 0 0 0 0 ...
+azspec ... -sSE ...
 }}}
 
-This 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:
+Once you've done that then you need to not call azimport to import the sync (won't work), though you still do need to call it to import the applanix navigation.
+
+Once that's run through, because it won't have sync it will be in the wrong place. Use the -so <offset> option to aznav to move it along the line to the right place:
+
 {{{
-aznav ... -so <sctoff> ...
+aznav ... -so <sct_offset>
 }}}
-Trial 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?).
+
+This is trial and error, takes a while sometimes (align the final results with either vectors for the target area or one of the other known good sensors for the same line). The offset is in seconds, it's usually in the 14-15 second range if we've had to use -sSE, but will probably go up to 15-16 seconds from 2009 (presumably it's the sync offset to the nearest second plus the GPS-UTC adjustment of 14 seconds... it's 15 now, but for all the data we've got from 2008 and earlier it will be 14).
+
+Finally, doing that will shift a little bit of the data off the end of the flightline and you'll lose it. To recover this, take the offset you found in the previous step and add it on to the start time in the header file (we also add it to the end time, but actually I'm not sure that's necessary). You may want to back the header up first, or at least make a note of the old value. Once you've done that, re-run the processing with the -sSE option to azspec but with the -so option to aznav set to 0 (or omitted).