https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INSTRM-1336 Instrument control development <p>The implementation of <a href="https://pfspipe.ipmu.jp/jira/browse/DAMD-7" title="Define format for up-the-ramp files" class="issue-link" data-issue-key="DAMD-7"><del>DAMD-7</del></a> requires that HDUs be sequenced predictably, using an absolute HDU index and not the EXTNAME.</p> <p>We almost certainly want to save the reset frame(s), so start <b>always</b> doing that. Basically, there will be <tt>W_H4NRST</tt> HDUs before the first data HDU. Named <tt>RESET_$N</tt>, but that is incidental.</p> <p>While at it, add a <tt>W_H4FFMT</tt> FITS structure version card.</p> INSTRM-1336

Always write RESET_$N HDUs.

Task Normal Done Done cloomis cloomis SPS Wed, 4 Aug 2021 21:23:26 +0000 Wed, 2 Mar 2022 14:59:34 +0000 Wed, 2 Mar 2022 14:59:34 +0000 ics_hxActor 0 2 <p>Craig will add dummy HDUs to address this.</p> <p>Two, I guess: RESET_DATA and RESET_REF. And drop the $N: I don't see us wanting to run with nreset&gt;1. Of course n4 might change that.....</p> <p>When not saving reset frames, can save a full-sized frame of 0-valued pixels (about 300kB with RICE for each) or save a 1x1 pixel array. The first seems right, if we are aiming to simplify DRP fiddling.</p> <p>It turns out that it is hard enough to figure out what the reset frame properties that making dummies is not worth the trouble. So I'm doing the work to generate real reset frames.</p> <p>Merged at 2c76f84, tagged 2.2.0</p> Relates INSTRM-980 DAMD-7 Development Rank 0|02qpuc:i6001gr068fhw9qo4o0m38k Sprint SM1PD-2021 A 14 SM1PD-2021 A 15 SM1PD-2022 B Story Points 3.0