Date: Wed, 18 Mar 1998 17:07:46 -0500 From: "Michael Juda" [ ">" = Dan Dewey ] > 1) Mike sent me the low-down on HRC STATUS bits (attached below) > and it seems reasonable (looking at events with various bits > set: generally ~100 events have a given bit set (out of 100K) > except for the PMT active (756 events) and Upper level exceeded > (33K events, mostly with PHA=255), etc.) > > 2) Is there an agreed STATUS criterion that the HRC QE applies > to? For example, nominally good events are ones with none > of bits 08-21 set, that is: ( STATUS AND '3FFF00'xL ) EQ 0 > [for you IDL types!] This is analogous to the ACIS GRADE > set question (e.g., what grade selection does the QE apply to?) > I will assume the "3FFF00" criteria until I hear otherwise... > Normally this would be a reasonable criterion to use for selecting good events. There is one additional consideration that affects how you might wish to interpret data from the XRCF, especially from the first few days. This also goes toward an eplanation of the large pulse heights and events exceeding the upper level threshold that is the subject of the following question. Early on at the XRCF data was taken at the nominal MCP HV levels that will be used in flight. It was immediately noticed that the gain was higher than expected and so that there were many pulse heights greater than 255 and many events exceeded the upper level discriminator. More disturbingly, the largest signals from the three charge amps per axis used to determine the event position were saturating the ADCs (you can see many event with tap signals of 4095). These events cannot be assigned correct positions. At some point in time, I unfortunately do not have a record of when, the MCP HV was lowered reducing the saturation problem. > 3) Using the "3FFF00" criterion, I get (for HRC-I-grating data > sets) between 60% and 95% of the events in the level 1 file are > "valid". I am surprised at how many exceed the upper level > discriminator, also that the PHA values seem to range right up > to 255 (I would have thought there would be a clearer upperlevel > value, say 150 or something.) > > 4) Just when I thought I had STATUS undercontrol... I see some > HRC files with different columns - the "normal" file is: > > TIME CRSV CRSU AMP_SF AV1 AV2 AV3 AU1 AU2 AU3 RAWX RAWY CHIPX CHIPY > TDETX TDETY DETX DETY X Y PHA SUMAMPS CHIP_ID DET_ID STATUS > > Then there are some without STATUS but with two new items: > > TIME CRSU CRSV AU1 AU2 AU3 AV1 AV2 AV3 RAWX RAWY CHIPX CHIPY > TDETX TDETY DETX DETY X Y PHA PI SUMAMPS CHIP_ID DET_ID AMP_SF VSTAT ESTAT > > Do you know what the differences are? The VSTAT and ESTAT seem to > be all 0s (but I did not check all files.) > ESTAT and VSTAT are not appropriate for flight telemetry and as such should not be filled during XRCF evet data processing (these are for a laboratory raw data - "telemetry-like" - foramt). I think that I noticed this problem while we were at the XRCF a year ago and got the eventdef changed to put STATUS in the files I looked at the file creation dates on the two examples you had listed below tribble-48: ls -l /data/prod2/pipe/970331/G-HHI-EA-6.006/i001/hrcl1/out/hrc_ghh iea6006i001n000_evt.qp -rwxr-xr-x 1 666 1818624 Apr 1 1997 /data/prod2/pipe/970331/G-HHI-EA- 6.006/i001/hrcl1/out/hrc_ghhiea6006i001n000_evt.qp* tribble-49: ls -l /data/prod2/pipe/970322/G-HHI-EA-7.048/i001/hrcl1/out/hrc_ghh iea7048i001n000_evt.qp -rwxr-xr-x 1 666 6955008 Oct 8 14:49 /data/prod2/pipe/970322/G-HHI-EA- 7.048/i001/hrcl1/out/hrc_ghhiea7048i001n000_evt.qp* The data set with ESTAT and VSTAT instead of STATUS have not been reprocessed since they were done at XRCF. All XRCF data really does need to have the reprocessing done. > These later files also seem to have a different definition of > X and Y (I use X,Y and pixel size of 6.429 um to get physical > location of events in mm.) > Processing done at the XRCF had 1/8 arcsec pixels - the conversion from microns to arcsec included the defocus distance. I tried to get this changed for the reprocessing. Just looking at the relevent KEYWORDS I see that the two examples are not the same. hrc_ghhiea6006i001n000_evt.fits TTYPE18 = 'X ' / Label for field TCDLT18 = 3.472222222222222E-5 / x degrees per pixel hrc_ghhiea7048i001n000_evt.fits TTYPE19 = 'X ' / Label for field TCDLT19 = 3.583333333333333E-5 / x degrees per pixel > > What do you think? -Dan > > ---------------------------------------------------------- > Daniel Dewey dd@space.mit.edu > MIT Center for Space Research Office:(617) 253-7244 > 70 Vassar St., NE80-6025 Fax:(617) 253-8084 > Cambridge, MA 02139 http://space.mit.edu/~dd > ---------------------------------------------------------- > > > P.S. The file with the 33K/100K is: hrc_ghhiea7048i001n000_evt.fits > (on 970322) > > An example no-STATUS file is: hrc_ghhiea6006i001n000_evt.fits > (on 970331) > - - - - - -- Subject: HRC "status" word bit assignments Date: Mon, 16 Mar 1998 17:59:03 -0500 From: "Michael Juda" I pulled the following information out of the "include" file for the event list generation software /* the following macro's define the bits used for the status mask of events * processed by evthrcdet. * * |3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|0|0|0|0|0|0|0|0|0|0| * |1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0| * * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * * | unused | E | VSTAT | Process Stats | Data Sys Stats| * * 31 - 26 - unused * 25 E status - V axis not triggered * 24 E status - U axis not triggered * 23 V status - V axis center blank event * 22 V status - U axis center blank event * 21 V status - V axis width exceeded * 20 V status - U axis width exceeded * 19 V status - shield PMT active * 18 V status - spare * 17 V status - upper level discriminator exceeded * 16 V status - lower level discriminator exceeded * 15 P status - Hot spots * 14 P status - fine pos * 13 P status - V center (bad amps) * 12 P status - U center (bad amps) * 11 P status - pha ratio * 10 P status - zero psum * 09 P status - grid ratio * 08 P status - zero sum * 07 - 00 - Data sys stats - T.B.D. * * STATUS MASK */ Bits 8-15 are set by ground software based on the quality of the event information and should all be zero for a "good" event (bit 11 - pha ratio could be set for a good event due to some peculiarities of the hardware). Bits 16-25 are derived from the hardware "event" and "veto" status telemetry bits. It is OK for bits 22 and 23 to be set as the center blank region is arbitrary. Unfortunately, according to the description bit 16 is not inverted implying that it gets set for good events - I'm not sure that that is the cas e. Dan, I think the description of bit 16 of the status word "lower level discriminator exceeded" that was in the include file is incorrect. Examining a file it appears that it is not set most of the time. it should read "lower level discriminator NOT exceeded" ======== Michael Juda mjuda@cfa.harvard.edu Harvard-Smithsonian Center for Astrophysics phone: (617)495-7062 60 Garden Street, MS 70 fax: (617)495-7356 Cambridge, MA 02138 http://hea-www.harvard.edu/~juda/HomePage.html ------------------------------------------------------------------------------ | | | "Idiocy in the modern age isn't an all-encompassing, twenty-four-hour | | situation for most people. It's a condition that everybody slips into | | many times a day. Life is just too complicated to be smart all the | | time." | | | | from "The Dilbert Principle" by Scott Adams | | | ------------------------------------------------------------------------------