Stubbe F. Hviid Team Meeting Sep 2007 Shutter Handling Stubbe F. Hviid Team Meeting Sep 2007

Shutter Problem Areas Shutter Error Type D Shutter Error Type A&C Shutter not moving when command to do so Shutter Error Type A&C Functional stability problems (Shutter not locking and unlocking correctly) Backtravel opening problem

Shutter Error Type D Origin of problem not understood but extensive testing in Lindau seems to indicate: Error does not occur in Shutter Test Mode Error does not occur as first shot after a reset Error does occur in normal operational mode with all encoders enabled and internal error handling enabled. Possible solution would be to implement an optional reset of the shutter before each image (with the possibility to disable for high speed imaging) Possible correlation to type A & C

Shutter Error Type A&C Problem dominantly for the NAC Problem caused by “parameter” drift or jumps Shutter is recovered by performing a shutter optimization.

Current A&C Error Handling IFSW Error Handling Single instances are recovered Three consecutive instances causes the shutter to be declared faulty. Current recovery mode Manual scheduling of shutter optimizations Problems Labor intensive Contains the risk of loosing blocks of operations Shutter optimization Operations Timeline Recovery Point Shutter optimization Operations …

Possible future handling of A&C (Solution 1 – The simple) Initial Shutter optimization Operations Change the shutter error handling to allow auto tuning of shutter in case of shutter being declared faulty. Change the image acquire functions to block any image acquire commands coming from the timeline until recovery finished. Spacecraft Timeline Shutter declared faulty Auto Shutter Optimize Timeline Block Data loss …

Solution 1 –Pro’s and Con’s Simple to implement Allows recovery of science timeline much faster the current manual solution Con’s Allows the IFSW greater autonomy thus greater risk Can still cause significant data loss Questions How do we detect high speed blade impacts? Do we limit the number of recovery events? If so how many times? Any hardware protection issues? Can we relax some of the shutter optimization convergence criteria to speed up the optimization?

Possible future handling of A&C (Solution 2 – The complex) Initial Shutter optimization Operations Tune Same Error Handling as solution #1. But with an additional background demon that tunes the shutter based on the pulse data coming from the normal exposures (if time allows) Shutter demon Tune Spacecraft Timeline Shutter declared faulty Auto Shutter Optimize Timeline Block Data loss …

Solution 2 –Pro’s and Con’s Should reduce the number of instances where the shutter is declared faulty Is conceptually close to a possible future back travel runtime tuning algorithm Allows runtime tuning with minimum impact on the science timeline Con’s Not likely to handle stochastic state changes Is complex Will require extensive testing Required one additional demon with impact on both the RSDB and DPU memory/processing requirements Can still cause significant data loss Questions Same questions as solution #1 How do we safeguard against a diverging algorithm?

Back travel opening problem (Questions) Is mechanical stability and backtravel optimization incompatible? Can the science team accept an operational mode where the top third of the CCD is photometrically uncertain? Can we implement a backpush that is both reliable and safe when using the Shutter brake on the NAC? Can the science team accept a photometrically certain operational mode that is very slow? Exposure using the Shutter brake followed by a series of shutter firings needed to ensure that the shutter is back at the correct homeposition (without the Shutter brake)

Schedule Any software change has to be finished before ~Feb 2008 to make it to the spacecraft before Steins Solution #1 is realistic for Steins Solution #2 is probably unrealistic for Steins Backtravel optimization will have to be ready for the comet.