| | 1 | = Known processing problems = |
| | 2 | |
| | 3 | == CASI data missing GPS sync == |
| | 4 | |
| | 5 | If you're seeing azgcorr failing with `** read error on SCO input` and, earlier in the output, azcaschk2 is reporting: |
| | 6 | {{{ |
| | 7 | GPS message time to CASI clock time difference(s)... |
| | 8 | del_t : |
| | 9 | freq : |
| | 10 | most frequent gap is: 0 secs |
| | 11 | |
| | 12 | ** NO (or insufficient) GPS messages or sync pulses |
| | 13 | ** ... no sync saved |
| | 14 | }}} |
| | 15 | |
| | 16 | 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. |
| | 17 | |
| | 18 | 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. In the normal batch files, amend the CSYNC line to read: `CSYNC="-FRsync"`. |
| | 19 | |
| | 20 | This should then process through to level 3, though you may need to correct for navigation timing. |