Descriptive email from Ben to Bill (4/Mar/2009):

We were (still) trying to track down our Vocals offset problem and we think we stumbled across something else. We used CaliGeo to process a line that had had a timing error in it when we'd processed it using the az suite, and CaliGeo didn't produce a timing problem.

We noticed that in the bit where Caligeo is looking for sync the message it finds has a time delay of 548ms, which matches the 548 in the "Navsync Timing" line on the line 5 header file. The previous sync message it found (and discarded) had a time delay of 119ms, which matches the Navsync Timing for line 4. Azimport for that line found a specim sync message offset of 0.119, which suggests to me that it actually picked up the sync message for line 4 rather than 5. Can you take a look at this when you get a chance please? Let me know if I can send you any additional test data. 

Mark Danson has requested his Eagle and Hawk data from WM06/04 (Madrid, 2006 days 136 and 154) be reprocessed as previously offered.

Email from Mark:

Gary

On another point there was an offer some time ago to reprocess ARSF
Eagle and Hawk data from the Spanish Campaign in 2006. Having now looked
at these data and struggled to get sensible radiometric information it
would be useful to take up that offer - is it still open and how should
I proceed?

Thanks and hope all is well

Mark

Reply from Gary:

Hello Mark,
The offer is still open, we are very happy to re-processing of the Eagle and Hawk data from the Spanish campaign in 2006 (WM06/04; Madrid, 2006-136 & 2006-154). However, re-processing these data will be after the final block of data from the end of 2008 are processed. We will keep you informed of developments.
Best wishes
Gary 

If some of the usual entries we make in the MI data group (MIdate, MIfltno, etc) are left as blank strings, Azsite segfaults. If it's missing something critical ideally it should produce an error message and exit cleanly (since at the moment it doesn't tell you why it's segfaulted).