Changes between Version 11 and Version 12 of Processing/KnownProblems


Ignore:
Timestamp:
Jan 23, 2009, 12:39:21 PM (15 years ago)
Author:
benj
Comment:

Added more detail to the Eagle/Hawk sync section

Legend:

Unmodified
Added
Removed
Modified
  • Processing/KnownProblems

    v11 v12  
    22
    33== CASI data missing GPS sync ==
     4
     5(Note... same problem for Eagle/Hawk further down)
    46
    57If you're seeing azgcorr failing with `** read error on SCO input` and, earlier in the output, azcaschk2 is reporting:
     
    9193---------------------
    9294
    93 == Failed to find GPS sync ==
     95== Failed to find Eagle/Hawk GPS sync ==
    9496
    9597(level 1 processing only - will not apply to external ARSF users if only processing level 1 data to level 3)
    9698
    97 If azimport fails to find a GPS sync you must use the -sYS option to azimport to use a manual sync:
     99Firstly, 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).
     100
     101Failing that, the option we usually use to manually set sync that's been irretrievably lost is the -sSE option to azspec:
     102
    98103{{{
    99 azimport ... -sYS 0 0 0 0 ...
     104azspec ... -sSE ...
    100105}}}
    101106
    102 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:
     107Once 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.
     108
     109Once 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:
     110
    103111{{{
    104 aznav ... -so <sctoff> ...
     112aznav ... -so <sct_offset>
    105113}}}
    106 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?).
     114
     115This 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).
     116
     117Finally, 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).