Investigation of timing problems (with Specim)

[mggr]

This ticket documents a long term issue in timing of the Specim instruments, but has been hard to pin down. The original text has been altered at Specim's request (21/Sep/2009) to remove direct quotes of emails. A summary has been put in place instead.

Following initial contacts on the issue, Specim requested a dataset with a clear example of the timing problems. A dataset was produced with a single long line including "wobbles". This dataset showed one of two alleged issues - a straight timing offset that appeared to be due to our misuse of CaliGeo.

The second issue is that of a line needing different timing corrections at different parts of the line. Andrew Wilson has previously stated that he saw several of these in 2006 data. We have not been able to replicate this.

[benj]

(Comment edited 21/Sept/2009 to remove direct quotes of Specim material. Summaries inserted instead)

Various exchanges with Jukka in mid-May (~14th), important points are:

• Better to use autosynch in CaliGeo if it works for the dataset being run
  • Jukka was able to correct all issues in the test dataset using this functionality
  • The autosync lagtime should be set to -0.055. This has to be done in the options file, you can't do it from the interface (see below for syntax)
  • critically for az* software, this grabber delay is different to previous advice (2 frames vs ~55ms for any frame rate)
  • in the options file, GRABBER_DELAY should be set to 0 and AUTOSYNCH_LAGTIME to -0.0550000 (+/- any manual tweaks)
  • activate autosynch by adding "USE_AUTOSYNCH 1" to the options file
• Focal length for the sensor should be set correctly (18.3mm)
• Detector pixel size changes with spatial binning - 12 for SB of 1, 24 for 2 (default value). Presumably increases again with higher spatial binning rates. I think this is probably what was causing the wobbles I couldn't fix.

He found the provided test sets could be rectified well with these measures. The supplied vectors did not match well but this was possibly due to a datum shift issue between BNG and WGS84.

[mggr]

In the January maintenance, the firmware on the navsync boxes has been updated. Specim say this should correct a ~8% error in the timing. Will verify over the coming months.

[mggr]

Things seem improved, but still wrong. Teleconference with Specim on 9th June to discuss.