Hej Daniel: Jeg har nu fundet nogle referencer og materialer dig. Foerst referencerne: **** 1) B. E. Stern, Ya. Tikhomirova et al., astro-ph/0009447. Denne bliver nok det vigtigste grundlag for dit arbejde. Hvis du paa din web-browser kalder abstract frem ser du en henvisning til en datafil, etable2.txt, som du kan hente og som indeholder alt hvad vi skal bruge. Filen indeholder samtlige events som Tikhomirova (det er hende der har gjort fodarbejdet) har gravet frem, baade dem der har en BATSE trigger, og de nye som russerne har fundet. Tabellen bruger "Truncated Julian Day", TJD, som indgang, du bliver noedt til at lave dig en lille rutine der regner om fra TJD til almindelige datoer (jeg har fundet at en af de foerste BATSE- triggere, #143, fandt sted 1991-05-03, den har TJD 08379 ifoelge Stern & Tikhomirova. Det burde i princippet give dig noeglen til omsaetningen, du skal dog lige sikre dig hvornaar TJD skifter - om det f.eks. sker kl 12 GMT eller noget andet lusket. Jeg tror TJD er rimeligt standardiseret, saa du kan sikkert finde en definition i en astronomisk database paa webbet. Det ser ud til at de foerste BATSE data stammer fra 23. april 1991. De sidste WATCH data p CD'erne stammer fra 26. september 1992, saa det er den periode du skal arbejde paa. Det svarer til data paa de to direktorier "watch_c" og "watch_d" paa CD'erne. **** 2) Stern et al., ApJ 540, L21, 2000 Dette er den officielle publikation som opsummerer resultaterne fra ref. 1. **** 3) Kommers et al., ApJ 491, 704, 1997 Denne artikel redegoer for et arbejde som svarer til Stern og Tikhomirovas. Artiklen indeholder en tilsvarende tabel, som den i ref 1., men Kommers tabel daekker desvaerre kun 1993. Det er meget muligt, hvis du henvender dig direkte til Kommers, at du kan faa en tabel, der svarer til perioden april 1991 til september 1992. Det var vaerd at proeve - husk at de fleste mennesker kun bliver glade for at faa en henvendelse om et arbejde, de har lavet. (Kommers bruger i oevrigt ogsaa TJD som indgang, med decimaler oven i koebet, saa der maa du kunne checke skiftet fra en Julian Day til den naeste) ********************** Mht. vejledning i brugen af programmerne paa CD #2, den med WATCH_D direktoriet, saa har jeg fundet en beskrivelse jeg lavede i 1994, den haefter jeg efter brevet her. Lige her indsaetter jeg filen "ABOUT.CD", som ligger i rod-direktoriet paa CD #2. ********************** ABOUT THE DATA ON THIS CD This CD contains WATCH-GRANAT data from January 8 until October 1 1992. The data are stored in the directory WATCH_D. Additionally the CD contains some data analysis software and auxiliary data. The executable files can be found in the directory BEXE. Copy the programs to your harddisk and use "path=c:\bexe" to make the programs accessible. The auxiliary data in the directory BDATA. Copy the content of BDATA to your harddisk and use "append c:\bdata" to make the data accessible. The WATCH data are examined with the program QLNUT.EXE. This program is set up to write intermediate data files and output data into the same directory from where the input data are read. Therefore you must copy the relevant -.mem files to a working directory on your harddisk (or onto your ram-disk) befor you can run QLNUT. The C-source files for QLNUT are in directory SOURCE\QLNUT. The WATCH data are not public, you can only use them according to agreement with the WATCH-GRANAT collaboration (Niels Lund, Danish Space Research Institute, Lyngby, Denmark or Rashid Sunyaev, IKI, Moscow, Russia) 18. May 1994 Niels Lund ********************* Hvis du arbejder paa en Microsoft Windows-baseret PC er det maaske bedre at kopiere indholdet af saavel BDATA og BEXE direktorierne til dit arbejdsdirektorie da Windows ikke er for glad for "path"- og "append"-kommandoerne. I Windows-98 og senere versioner er du nok noedt til at starte PC'en i "DOS"-mode for at faa QLNUT-programmet til at koere, da QLNUT vil overtage kontrollen over det grafiske output til skaermen og det tillader de nyere Windows versioner ikke. P min Window-98 installation kommer jeg til DOS-mode ved at starte Windows og saa i menuen "Stop the computer" under "Start"-knappen (af alle steder!) at vaelge "Restart in DOS-mode". (Mine tekster er paa dansk, saa jeg ved ikke praecis hvordan dine vil se ud). I foerste omgang vil jeg foreslaa at sammenholder Stern og Tikhomirovas liste med nogle datoer du kan finde i "WTCAL0.TID" filen i BDATA direktoriet. HER er et eksempel fra WTCAL0.TID filen: linie# dato Granat tidcalib. Session 531 16/05/91 23:42:22.4414 331 532 17/05/91 23:42:16.9105 332 533 18/05/91 23:42:11.3795 0 534 19/05/91 23:42:05.8467 333 535 20/05/91 23:42:00.3166 334 536 21/05/91 23:41:54.7859 335 537 22/05/91 23:41:49.2549 0 538 23/05/91 23:41:43.7226 336 539 24/05/91 23:41:38.1908 337 Den sidste soejle "Session" er vigtig. Den skal du bruge til at finde hvilke Watch datafiler der svarer til datoerne i soejle 2. Her er et par linier fra Stern og Tikhomirova: TJD 08393g 86135 206 0.513 358.1 22.1 12.7 2 1 0 0 08394c 22451 1 0.381 218.4 33.0 5.7 254 29 0 0 08394e 53724 211 0.647 253.1 -11.4 4.4 296 8 0 0 08395a 9976 1 0.159 292.0 -2.4 52.7 97 3 0 0 08397a 18868 214 0.594 108.4 -28.4 15.4 36 5 0 0 Jeg har (uden garanti!) beregnet at TJD 08393 svarer til 17. maj 1991 og TJD 08397 svarer til 21. maj 1991. Saa tidspunktet for de 5 triggere fra S&T burde ligge imellem Granat session 331 og 335. (Desvaerre er tidsstemplingen af Granat og WATCH data en speget affaere, saa du kan godt komme til at lede lidt). Normalt er tidsstemplingen mest paalidelig paa WATCH#1 saa start med den. Jeg proevede lige selv at kigge efter WATCH#1 data fra den periode og de illustrerer meget godt de frustrationer vi vil komme ud for. (Husk at WATCH datafilerne normalt er navngivet saaledes: W3311.MEM hvor de foerste tre cifre efter "W" er sessionsnummeret og det sidste ciffer angiver WATCH nummeret (0, 1 eller 3). Session: 331 Watch#1 datafil: W3311.MEM, data OK, 15/5 16:35 til 16/5 17:08 Kommentar: Data ligger tidligere end den periode, der interesserer os. (vi burde dog ogsaa kontrollere WATCH #0 og #3 da tidsperioderne ikke noedvendigvis er sammenfaldende, - kig altsaa ogsaa paa W3310.MEM og W3313.MEM). Session: 332 Watch#1 datafil: W3321.MEM, data mangler Kommentar: Det er ikke alle Granat sessioner hvor data fra WATCH blev transmitteret Session: 333 Watch#1 datafil: W3331.MEM, data eksisterer, men Granat var i spin-mode (count-rate data i DID 42 boelger op og ned paa en regulaer maade) - dette er en sjaeldent forekommende problem, men det rammer altsaa her. Kommentar: Data er ubrugelige. Session: 334 Watch#1 datafil: W3341.MEM, data eksisterer, men Granat var i spin-mode. Kommentar: Data er ubrugelige. Session: 335 Watch#1 datafil: W3351.MEM, data mangler. Kommentar: Det er ikke alle Granat sessioner hvor data fra WATCH blev transmitteret **** Som du ser kan det til tider vaere lidt af en oerkenvandring, men der er oaser i oerkenen! Jeg ville gerne have fundet et lidt mere opmuntrende eksempel, men jeg er noedt til at slutte her. de bedste hilsner niels PS: herefter foelger et par filer med beskrivelse af WATCH data: **************************************************************** file: watdata.txt **************************************************************** ACCESSING THE WATCH-GRANAT DATA Niels Lund, May 1994 1) The WATCH data The WATCH-GRANAT data are available on two CD-ROM disks in the form of "mem-files". The mem files are raw images of the on-board processor memories at the times of the telemetry dumps. Most mem-files have lengths of 512 kbytes. On the CD_ROM's the mem-files are located in four subdirectories: WATCH_A, WATCH_B, WATCH_C and WATCH_D. Each subdirectory contains the mem-files from all the three operating WATCH-units from a particular period: WATCH_A: December 12, 1989 to July 23, 1990. Dumps 18 to 159. CD #1. WATCH_B: July 24, 1990 to April 16, 1991. Dumps 160 to 319. CD #1. WATCH_C: April 16, 1991 to January 7, 1992. Dumps 320 to 479. CD #1. WATCH_D: January 9, 1992 to September 26, 1992. Dumps 480 to 631. CD #2. The indidual mem-files are designated by: XYYYZ.MEM, where X is a letter (nomally "W"), YYY is a three digit number indicating the GRANAT telemetry session number and Z is a digit indicating the WATCH unit number, 0, 1 or 3. (The data from WATCH #2 are not included on the CD_ROM as they have been unuseable due to a failure during launch). The initial letter is a "W" unless more than one telemetry dump occurred during a particular telemetry session. In such cases, usually, the first dump is given the letter "W", and the second dump are designated by "B". Be aware that the time of the telemetry session is not nescessarily also the time of the most recent data contained in the memory. Frequently the WATCH data memory is filled well before the telemetry dump, and in such cases further data storage is blocked, and the instrument idles while waiting for the telemetry dump command from the ground. The termination of data storage is only taking effect for the compressed science data, the housekeeping data are written into a circular memory, so the housekeeping data will normally cover the full interval between two telemetry dumps. The capacity of the housekeeping memory allows more than 48 hours of data to be stored before overwriting of the first written data occurs. In certain cases the memory content can be even older than corresponding to the time of the previous dump. This happens when the instrument experiences multiple CPU failures in rapid succession (this is usually correlated with intense solar flares or passages through the radiation belts). In such cases the CPU automatically restarts but switches to the socalled "MONITOR MODE" rather than the nominal "RUN MODE". In MONITOR MODE all data collection (also of housekeeping data) is suspended, however the instrument still responds to the requests for telemetry dumps, but the same data are transmitted again and again with each request. A command from the ground is required to bring the instrument from the MONITOR to the RUN MODE. Only when the problem has been recognized on the ground, will the switch be executed. Due to the very limited communication possibilities between the ground station in Evpatoria and Moscow, recovery in some cases has been delayed by several weeks. 2) WATCH analysis software In addition to the mem-files both CD-ROMS contains auxiliary data files (in the subdirectory BDATA) and analysis software (in executable form in the subdirectory BEXE and in source form under subdirectory SOURCE). The software versions on CD #2 are the most recent and should be used preferentially. For working with the WATCH data it is recommended that you create the BDATA and BEXE directories on your harddisk and copy the content from the CD to the harddisk. The BEXE directory should be in your AUTOEXEC PATH statement, and you should make the data-files in the BDATA directory accessible by adding a statement: APPEND C:\BDATA to your AUTOEXEC.BAT file. 3) Accessing the WATCH data. Most of the data in the mem-files are stored in compressed form and must be unpacked before further analysis. The programs GETHKN and QLNUT are available for this purpose. GETHKN can display and output the housekeeping data whereas QLNUT is a very powerfull, interactive quick look program with many facilities for science data display, manipulation and output. Both of these programs creates, during execution, a number of auxiliary files, these will be placed in the directory where the mem-file is located. Therefore, the mem-files cannot be analyzed while reciding on a read-only device like the CD-ROM, they must be copied to the hard disk (or a RAM-disk) before use. 4) WATCH data types. The WATCH data can be divided into several types. The most frequenly used types are: 1) the count rate data, 2) the modulation patterns, 3) the burst data and 4) the energy spectra. A complete list of all WATCH data types can be found in appendix A and in chapter 3 of the WATCH User Manual. The text of the User Manual are included on the CD-ROM #1, in directory \MANUAL\ASCII. 5) Primary and Secondary memory. When the software for GRANAT-WATCH was developed it was a requirement to limit the number of commands to be uplinked per day to a minimum. And it was made clear that the normal operation schedule would be to have three dumps per orbit, thus there would typically be two 24 hour and one 48 hour observation periods per four day orbit. To achieve a full exploitation of the available memory regardless of the duration of the observation period the concept of primary and secondary memory was introduced. Data with nominal time resolution is initially stored in the primary memory. The primary memory starts at the top end of the free memory area and the filling progresses downward. Data with twice finer time resolution is initially stored in the secondary memory. The secondary memory starts about midway down in the free memory area, and also here the filling progresses downward. Ideally, after 24 hours both the primary and the secondary memory should have grown to fill their allotted space. If the data are dumped at this moment, we will get a full memory with fine time resolution. If no data dump occurs, further data stored in the the primary memory will begin to overwrite the secondary memory and we will gradually loose the fine time resolution. When the primary memory begins to overwrite the secondary memory the time resolution of all normal count rate and modulation pattern data will be made coarser by a factor two in order to extend the memory survival time. 6) Invoking the QLNUT quick look program. Example: QLNUT [[DRIVE:PATH\]W2813[.MEM]] [/S] The QLNUT takes as its first parameter the name of the mem-file. The default name is WATCH.MEM. The extension ".MEM" need not be given. Normally QLNUT is invoked without any switch options "/S", but for special cases a number of options are available. These are described in appendix B. The first time QLNUT is processing a given mem-file it scans through the compressed data packets and establishes a list of packet pointers and another list containing the packet time stamps. This process takes some tens of seconds, dependent on the CPU speed of the PC used. The two lists are stored as files in the same directory from where the QLNUT is reading the mem-file, the names of the files are the same as the name of the mem-file, and they are given extensions .AD# and .PA# respectively, where # stands for the WATCH unit number. During subsequent analyses of the same mem-file the QLNUT will not need to perform this initial slow scanning process, but are ready to display the desired data packets immediately. While QLNUT is scanning through the packet list it displays the total number of packets found, and the number of unpacking errors encountered. Occasionally it will stop and display a message indicating a problem in establishing the time calibration for a certain packet, usually these messages can be ignored. Hit any key to proceed. The packet lists are limited to a maximum of 3500 packets. This is sufficient for almost all dumps. In some exceptional cases where more than 3500 packets are found during memory analysis, a switch option may be required to analyze the memory fully. Refer to Appendix B. 7) The menu system of the QLNUT program. When the analysis of the data packets is completed, QLNUT will pause, displaying some statistics on the unpacking process. Press "ENTER", and the program will switch to the "Data ID Selection Menu". The Data ID's (DID's) are the WATCH Data IDentification numbers. They range between 0 and 127. A complete list of all DID numbers and the corresponding data types is given in appendix A. The selected DID number is highlighted in the menu. The default DID is 42 - this is the DID for the low energy count rate data which is frequently the first thing to look at when working with a new mem-file. An short text explaining the content of the selected DID appears near the top of the screen. A "(P)" at the end of these text indicates data from the primary and an "(S)" data from the secondary memory. "CP" indicates data combined from several DID types, an example is DID 92. To exit from QLNUT press F1 (or F2) from the "Data ID Selection Menu". To proceed to the next menu level, press ENTER. The next menu level is the "Packet Selection Menu". Here you will see a list of available packets with the chosen DID-value. Again, the selected packet is highlighted. In a small window in the top right corner the time stamp for the selected packet is displayed. (Regarding the interpretation of the time stamps see section 12 below). In another window at the bottom right corner the memory address of the selected packet is indicated. To return to the "Data ID Selection Menu" from a deeper level in the menu system, press F2. (After certain operations you may need to press F2 twice to get back to the "Data ID Selection Menu"). The unfinished data packets which are in preparation at the time of the telemetry dump can also be inspected, they are designated "next" in the "Packet Selection Menus". You may use all the four Arrow Keys plus PgUp, PgDn, Home and End for moving around on the text menus. In cases where there are more packets of a given type than will fit on a single screen (Example: DID 93 in file W4680.MEM) you can scroll the "Packet Selection Menu" sideways by attempting to move the highlighted block right or left beyond the borders of the menu window. You can also use a tagging facility to select packets for display or output, this facility will be described in section 13, first we will discuss some further details of the graphics displays. 7) The graphics display To display the data in the selected packet press ENTER. When inspecting graphics data you have a number of options some of which are indicated in the bottom menu bar. Additionally a HELP SCREEN can be called up by pressing "h". Since some options distinguishes between upper and lower case characters be careful not to have the CAPS LOCK function activated when executing QLNUT. The graphic displays are auto scaled on the ordinate axis to bring out the maximum amount of detail in the plots. By pressing "R", you may request a rescaling of the ordinate axis. Near the top of the ordinate axis you will see the text: "Scale Factor: 1.0". This scale factor always have the value 1.0 when displaying any individual packet. But in cases where you add many packets together (using the "overlook"-facility) or you perform calculations on the data using the "Pocket Calculator" functions, the result may exceed the capacity of the 16-bit unsigned integers on which the whole QLNUT graphics package is build, and the data will automatically be rescaled suitably to fit within the range 0 to 65535. The most commonly used display modifying options are listed below: "o" Generate OVERLOOK of several packets. The packet numbers must be entered as requested. The overlook function works differently with count rate data and modulation data. This is explained in the corresponding sections. "r" RESCALE the Y-axis (vertical count scale). "R" RESCALE the X-axis (horizontal channel scale). "F7" Display previous packet. "F8" Display next packet. "PgUp" Display corresponding data in next higher energy band. "PgDn" Display corresponding data in next lower energy band. Output functions "F3" OUTPUT the current display buffer in ASCII form to the det-file. "F4" OUTPUT the current display as a graphics buffer to a print buffer. If this printer buffer contains images when QLNUT is requested to terminate (after pressing F1) you will be prompted for print options. This buffer is intended for printing on line on a matrix printer. "F10" OUTPUT the current display as a graphics buffer to the file QLASER.PIX. This file can be printed on a HP-compatible laser printer by simply copying the file in binary to the printer: "COPY /B QLASER.PIX LPT1" To return to the "PACKET Selection Menu" from a graphics display press ENTER; to return to the "Data ID Selection Menu", press F2. 8) Working with count rate data. The normal count rate data are stored 256 channels per packet, in primary memory with DID = 42 (low energy counts in the NaI-scintillator), DID = 45 (medium energy counts in NaI) and DID = 48 (medium energy counts in CsI). In the secondary memory the corresponding DID-values are: 41, 44 and 47. The initial integration time per channel is 8 motor rotations for the primary memory and 4 motor rotations per channel in the secondary memory. If the primary memory reaches the secondary memory and begins to overwrite it, then both these integration times are doubled; we then have 16 motor rotations in the primary and 8 rotations in the secondary memory. The duration of a motor rotation can vary between 0.8 and 1.0 s, WATCH #0 runs somewhat faster than WATCH #1 or #3. We may, therefore, in a given data dump find data with three different time resolutions: fine (in the remaining secondary memory), nominal (in the first part of the primary memory) and coarse (in that part of the primary memory written on top of the secondary memory. QLNUT is usually capable of identifying correctly which packets are written with which resolution, but occasionally the time resolution of a packet is not assigned correctly, and this may cause apparent jumps by a factor two in the count rates when displaying several adjacent count rate packets. The fine time resolution available in the secondary memory is not displayed automatically, it must be requested by typing "e" (expand), when displaying a count rate packet from primary memory. If the corresponding packet exists in the secondary memory, the display will change from 256 to 512 channels with finer resolution. If no data are available in secondary memory, typing "e" has no effect. In addition to the normal count rate data in DID 42, 45 and 48, there may also be "Burst Count Rate Packets" with DID 43, 46 and 49. These packets are only collected following the occurrence of "Burst Triggers". Usually two to four packets, each with 64 channels, are collected following each burst trigger. The "overlook" facility (obtained by typing "o") works differently on count rate packets and modulation packets. With count rate packets you will obtain a continous count rate display covering the total observation time of all the packets selected for the overlook. 9) Cursor functions In addition to the graphics, the count rate display provides a number of additional informations. The text line below the graphics window contains two "Cursor Blocks". In each is given the channel number in which the corresponding cursor presently is located, and the UT-time corresponding to this channel. The last information given in the two Cursor Blocks is the DID type and the packet number for the modulation packet containing data corresponding to the cursor time. In the space between the Cursor Blocks id printed the total number of counts between the two cursors, including the counts in the channels of the cursors. The cursors are moved with the right and left arrow keys. Initially the upper (right) cursor is selected, and only that cursor will react on the arrow keys. When it is desired to move the lower cursor, press "Arrow Down", and the lower (left) cursor will be selected. Pressing "Arrow Up" will select the upper cursor again. Pressing the "CTRL" key while using the right or left arrow keys will make the cursors move in steps of 16 channels. "F9" switches between count rate data and modulation pattern data. This is a very useful possibility when searching for transients and bursts. First the count rate packets are inspected for signs of interesting events. Once an event is identified, the two cursors are positioned so they bracket the event. Pressing F9 now allows you to inspect the modulation pattern corresponding to the region of the cursors. NOTE: You cannot display a part of a modulation pattern packet. The modulation pattern shown after pressing F9, will show the sum of all the packets between and including the cursor channels. So, if at all possible, move the cursors so far into the event that you can be sure not to include data from times much prior to or much after the interesting event. You can use the PgUp and PgDn keys after having used F9, to inspect the modulation in different energy bands. Pressing F9 a second time will bring you back to the count rate display. 10) Working with modulation patterns The search for persistent sources is usually carried out by combining all the modulation patterns from a given day, and outputting the resulting sum-pattern by the F3-function. The sum-pattern can then be analyzed using one of the programs in the "SVD"-family. These programs sequentially identifies the brightest source, subtract its contribution to the modulation pattern, and continuing the search for the next source. The "overlook" function in QLNUT provides a fast and simple way to combine any stretch of consecutive packets of a given type. This may suffice for many purposes. However, there are several situations where the simple overlook will not work well: a) In WATCH #0 you will frequently have a number of very strong solar flare events, which will make the search for underlying persistent sources very difficult or even impossible. b) In all units very strong, unmodulated noise events appears, which seems to be related to low-energy charged particle streams. These events only introduces unnesecessary noise in the "overlook" patterns. c) Particularly during disturbed periods (with many solar flares and particle events) the WATCH "Transient Event Logic" is frequently triggered. When this happens, the data collection into the normal modulation patterns (DID 33, 36 and 39) will be interrupted, and the modulation data will be stored as "Transient Modulation Patterns" in DID 93, 96 and 99. During disturbed conditions more than half of the total modulation data may be stored in the transient patterns, and the number of transient patterns may run in the hundreds. The integration time of a transient pattern is 16 motor rotations rather than the 512 motor rotations of the DID 33, 36 and 39. It is an unpleasant complication of the WATCH data logic that a DID 33 (36, 39) pattern which is being interrupted by a transient trigger is stored as the first DID 93 (96, 99) packet in the sequence of packets associated by the trigger. Normally this first packet contain very little data belonging to the triggering event, and it should therefore rather have been stored in the DID 33 (36, 39) stream - at least that is where we would like to use it in a search for weak, persistent sources. So, in extracting the best overall modulation pattern we have two problems: we want to exclude packets containing strong solar flares and noise spikes, and we may want to include the initial packet in each sequence of transient modulation patterns. To facilitate this selection process two functions are available in QLNUT: 1) It is possible to select the packets of DID's 33, 36, 39, 93, 96 and 99 by "tagging" the packet numbers in the "Packet Selection Menu". Typing "t" when inspecting the "Packet Selection Menu" will "tag" the highlighted packet and the cursor will move to the next packet. (Typing "u" will "untag" an already "tagged" packet). CTRL-t will tag all packets, CTRL-u will untag all packets. Typing "o" while in the "Packet Selection Menu" will then produce an "overlook" of only the tagged packets. So, once you have decided which packets of a given DID to use in the analysis, it is therefore straightforward to produce the desired overlook. 2) In the case of the "transient" packets (DID 93, 96 and 99) the total number of packets may be so high (hundreds) that a manual inspection of each packet becomes extremely time consuming and boring. Nevertheless the total integration time hidded in these packets, particularly in the "first"-packets of each sequence may be an important fraction of the total observation time. Typing "f" ("find") while in the "Packet Selection Menu" of DID 93, 96 or 99 will "tag" all the "first"-packets automatically. The procedure is not 100% safe, so it is a good idea to verify the selection manually (by checking that the selected packets contain many counts). However, going through, maybe 25, tagged packets manually, is a lot easier than scanning all of the available packets. Once the selection is verified, typing "o" while in the "Packet Selection Menu" will produce the desired overlook. The two overlook-patterns (from DID 33 and from DID 93) can be added using the "Pocket Calculator" functions described in section 11. There are two more complications in the WATCH modulation patterns which must be mentioned. One is the uneven motor rotation rate and its influence on the patterns, the other is the (small) errors in the tachometer marks, producing a constant noise pattern on top of the modulation patterns. The last effect have been mapped for each of the WATCH units and the three tachometer patterns are stored in the files W#MOT.TAC (# = WATCH unit number) stored in the directory BDATA on the CD-ROMS. The uneven motor rotation is not completely constant from one observation session to the next, so the mapping must be done for each session separately. The recommended procedure is to add together the overlook patterns from DID's 96 and 99 and using this sum pattern to derive the motor rotation pattern. This sum will only contain a low level of source modulation, because the modulation in DID 99 is in antiphase with the modulation in DID 96. The program MODCMP.EXE (in directory BEXE on the CD-ROM's) will take as input a *.DET file generated by QLNUT and will automatically perform the compensation, both for tachometer errors and for uneven motor rotation. MODCMP assumes that the first modulation pattern in the *.DET file is the pattern to be corrected, and the second pattern is the pattern from which the motor correction can be derived. MODCMP also assumes that the naming convention for the *.DET file is the usual one, i.e. that the WATCH unit number is the last digit in the file name. The output file name is the same as that of the *.DET file, hovever the extension name is ".CMP". The MODCMP program derives the motor compensation pattern from the DID 96 + DID 99 sum pattern by making a sliding mean over 33 phase bins. In this way high frequency signals which are unlikely to originate in the motor is damped out, and the loss of statistical significance in the corrected pattern is reduced. 11) The Pocket Calculator Functions. The build-in "Pocket Calculator" allows you to manipulate the data buffers displayed on the screen. The pocket calculator uses a stack consisting of two buffers X and Y, each with a maximum of 512 channels. Reverse polish logic is used for the arithmetic operations, so you must enter both X and Y onto the stack before addition or subtraction operations has meaning. All the available functions are listed in the "Help"-screen which can be called up from any graphics screen by typing "h". The functions are explained below: "ALT e" Move X into Y. Enter the current display buffer into X. "Alt p" Add Y to X. Put result into X. "ALT m" Subtract X from Y. Put result into X "ALT d" Display X. "ALT k nnnnn" Move X into Y. Enter an (integer) constant into all channels of X. NOTE: The numerical value entered appears in the upper left corner of the graphics screen. Use ENTER ("Carriage Return") to terminate the numerical input. Use ALT-p or ALT-m to add or subtract after entering the constant. Use ALT-d to display the modified buffer. "ALT f +/-nnnnnn.nnnnnn" Multiply all channels of X with a (floating point) constant. NOTE: The numerical value entered appears in the upper left corner of the graphics screen. Use ENTER ("Carriage Return") to terminate the numerical input. Use ALT-d to display the modified buffer. "ALT w" Write X to the *.DET-file. NOTE: F3 does not work here! 12) Time Stamping and Time Calibration. Each packet of WATCH data carries a time stamp which is giving the time when the processing of the packet by the data compression routine was completed. This information is only accurate to within a few seconds. Higher precision can be obtained from packets having "special time words". The information in the special time words refer to the exact time the data collection for a given set of packets were terminated. The following sets are relevant: Modulation Patterns: DID 33, 36, 39. Special t-word in DID 36. Count Rates: DID 42, 45, 48. Special t-word in DID 45. Burst Count Rates: DID 43, 46, 49, 52, 55. Special t-word in DID 46. Transient Modulation P: DID 93, 96, 99. Special t-word in DID 96. The times shown on a graphics display refers to the time stamp of the packet being displayed. Therefore the times for f.i. a DID 42 packet may be slightly inaccurate, while the times given for the corresponding DID 45 packet is more precise, and this time is the best one to use also for the DID 42 and 48 packets completed simultaneously with the DID 45 packet. The most precise UT time values are those output with the DID 45 and DID 46 count rate packets using the F3-key. Below are shown, with C-style comments the output of two such packets from the mem-file: W4680.MEM: WATCH : 0 DID : 45 nr: 1 /* Normal count rate packet. 8 rots/channel */ CLOCK $8fbad d2c0 /* actual packet time stamp, CLOCK1 and 0 */ UT end time: ' 1991 12 9 15 19 34.152 /* UT time derived from CLOCK */ End time (elapsed): 63818376.151676 /* secs since 1989:12:01:00:00:00 */ Local ROTTIME: 0.81751 /* Motor rot. period based on this packet */ Estimated, corrected UT start/end time: _14:51:39.073 15:19:33.331 /* The start and end time given in this line is corrected for a bug in the on-board software discovered only after the launch: The time stamps associated with the count rate packets are delayed with respect to the true termination time of data collection by 257/256 of a motor rotation period. Note that the "Estimated, corrected end time" is early with respect to the "UT time derived from CLOCK" by about one "Local ROTTIME". This is why the "local" motor rotation time is of interest. As shown in the next example, for some packets, the locally derived rotation time is grossly in error (for reasons which are uninteresting here). In such cases a globally derived rotation period (averaged over the whole observation session) is used instead */ Total counts: 77919 # 0 ? 1.000000 ^ 281 306 295 308 287 266 283 316 320 339 302 315 321 317 279 305 302 284 293 306 319 302 297 312 295 289 292 301 283 291 320 316 306 302 305 277 297 319 301 281 291 304 314 290 319 282 279 326 288 308 326 302 323 293 306 283 289 305 321 302 299 318 309 290 329 292 323 265 309 311 295 308 313 289 318 308 310 295 290 297 304 301 323 282 275 318 320 300 311 299 302 302 325 337 312 254 311 282 304 302 301 323 275 353 303 315 309 310 309 281 316 334 300 319 288 322 277 292 320 306 325 305 320 304 333 292 333 286 304 291 310 308 283 304 299 299 321 302 316 320 315 324 324 313 298 311 304 327 285 286 330 266 284 320 304 309 308 299 314 326 310 290 310 306 332 320 283 338 326 292 285 307 316 326 301 286 304 334 313 321 283 298 295 309 286 299 276 285 294 306 297 322 326 316 313 305 290 301 292 315 283 264 295 308 293 313 266 290 297 297 325 327 291 322 283 311 299 336 298 315 303 285 298 343 288 322 301 287 326 329 322 305 288 315 307 317 307 297 286 317 329 346 306 332 290 304 279 314 292 277 284 320 309 317 272 316 /* See comments on DID 45 above */ WATCH : 0 DID : 46 nr: 1 /* Burst count rate packet, 1 rot/channel */ CLOCK $944f5 5cd0 UT end time: ' 1991 12 9 17 32 58.145 End time (elapsed): 63826380.145185 Global ROTTIME: 0.81667 (Bad local value: 59.666953) /* Motor rot. period based on this packet is wrong; use Global value. Note that the difference with respect to the "Local ROTTIME" derived from the DID 45 packet shown above is only about 1 ms */ Estimated, corrected UT start/end time: _ 17:32:05.059 17:32:57.325 Total counts: 2486 # 0 ? 1.000000 ^ 31 39 39 47 40 35 30 30 43 49 44 40 43 39 32 47 38 36 32 42 40 42 40 33 37 51 36 37 37 41 42 35 39 35 38 36 43 38 45 33 38 37 36 43 37 29 32 37 46 43 40 51 39 36 36 35 42 39 49 35 42 37 41 32 The "UT-time" shown in the QLNUT count rate graphics displays (in the "Cursor Blocks") is giving the approximate start time of the channel in which the cursor is positioned. The UT-time shown in the bottom line of the display is the "Packet time", i.e. the time corresponding to the packet end time. The times shown in the graphics are only given to the nearest second. The Cursor Times have had 1 s subtracted to correct (approximately) for the on-board error mentioned above. This correction have not been applied to the "Packet times". **************************************************************** file: watdata.app **************************************************************** Appendix B. WATCH Data IDentifications DID chan mem rots usage 0 256 S 4096 9 color Modulation pattern. NaI band 0 1 256 S 4096 9 color Modulation pattern. NaI band 1 2 256 S 4096 9 color Modulation pattern. NaI band 2 3 256 S 4096 9 color Modulation pattern. NaI band 3 4 256 S 4096 9 color Modulation pattern. NaI band 4 5 256 S 4096 9 color Modulation pattern. NaI band 5 6 256 S 4096 9 color Modulation pattern. NaI band 6 7 256 S 4096 9 color Modulation pattern. NaI band 7 8 256 S 4096 9 color Modulation pattern. NaI band 8 9 256 S 4096 9 color Modulation pattern. CsI band 2 10 256 S 4096 9 color Modulation pattern. CsI band 3 11 256 S 4096 9 color Modulation pattern. CsI band 4 12 256 S 4096 9 color Modulation pattern. CsI band 5 13 256 S 4096 9 color Modulation pattern. CsI band 6 14 256 S 4096 9 color Modulation pattern. CsI band 7 15 256 S 4096 9 color Modulation pattern. CsI band 8 16 256 P 8192 9 color Modulation pattern. NaI band 0 17 256 P 8192 9 color Modulation pattern. NaI band 1 18 256 P 8192 9 color Modulation pattern. NaI band 2 19 256 P 8192 9 color Modulation pattern. NaI band 3 20 256 P 8192 9 color Modulation pattern. NaI band 4 21 256 P 8192 9 color Modulation pattern. NaI band 5 22 256 P 8192 9 color Modulation pattern. NaI band 6 23 256 P 8192 9 color Modulation pattern. NaI band 7 24 256 P 8192 9 color Modulation pattern. NaI band 8 25 256 P 8192 9 color Modulation pattern. CsI band 2 26 256 P 8192 9 color Modulation pattern. CsI band 3 27 256 P 8192 9 color Modulation pattern. CsI band 4 28 256 P 8192 9 color Modulation pattern. CsI band 5 29 256 P 8192 9 color Modulation pattern. CsI band 6 30 256 P 8192 9 color Modulation pattern. CsI band 7 31 256 P 8192 9 color Modulation pattern. CsI band 8 32 256 S 512 Low energy NaI modulation pattern 33 256 P 1024 Low energy NaI modulation pattern 34 256 P variable Low energy NaI modulation pattern during burst 35 256 S 512 Med.E NaI modulation pattern Special time words 1) 36 256 P 1024 Med.E NaI modulation pattern Special time words 1) 37 256 P variable Med.E NaI modulation pattern during burst 38 256 S 512 Medium energy CsI modulation pattern 39 256 P 1024 Medium energy CsI modulation pattern 40 256 P variable Medium energy CsI modulation pattern during burst 41 256 S 4 Low energy NaI count rate 42 256 P 8 Low energy NaI count rate 43 64 P 1 Low energy NaI count rate during burst 44 256 S 4 Medium energy NaI count rate Special time words 1) 45 256 P 8 Medium energy NaI count rate Special time words 1) 46 64 P 1 Medium E NaI count rate burst Special time words 1) 47 256 S 4 Medium energy CsI count rate 48 256 P 8 Medium energy CsI count rate 49 64 P 1 Medium energy CsI count rate during burst 50 256 S 32 High energy NaI+CsI count rate 51 256 P 64 High energy NaI+CsI count rate 52 64 P 1 High energy NaI+CsI count rate during burst Appendix A. WATCH Data IDentifications (continued) DID chan mem rots usage 53 256 S 32 Overflow (particle) counts 54 256 P 64 Overflow (particle) counts 55 64 P 1 Overflow (particle) counts during burst 56 65 S 2048 Source energy spectrum no. 0 57 65 S 2048 Source energy spectrum no. 1 58 65 S 2048 Source energy spectrum no. 2 59 65 S 2048 Source energy spectrum no. 3 60 65 S 2048 Source energy spectrum no. 4 61 65 S 2048 Source energy spectrum no. 5 May be reserved for burst 62 65 S 2048 Source energy spectrum no. 6 together with spectrum 7 63 65 S 2048 Spectrum 7. Reserved for follow-up on burst source 64 65 P 4096 Source energy spectrum 0 65 65 P 4096 Source energy spectrum 1 66 65 P 4096 Source energy spectrum 2 67 65 P 4096 Source energy spectrum 3 68 65 P 4096 Source energy spectrum 4 69 65 P 4096 Source energy spectrum 5 May be reserved for burst 70 65 P 4096 Source energy spectrum 6 together with spectrum 7 71 65 P 4096 Reserved for follow-up on burst source 72 1025 S 2048 Period fold spectrum no. 0 73 1025 S 2048 Period fold spectrum no. 1 74 1025 S 2048 Period fold spectrum no. 2 75 1025 P 4096 Period fold spectrum no. 0 Special time words 2) 76 1025 P 4096 Period fold spectrum no. 1 Special time words 2) 77 1025 P 4096 Period fold spectrum no. 2 Special time words 2) 79 256 P 1800s Global energy spectra 80 64 P N/A Energy spectra (bursts and transients) Sp. time wd 1) 84 512 P 3600s Bi-dimensional, energy versus risetime 93 256 P 16 Low E NaI mod. pattern after transient 96 256 P 16 Med.E NaI mod. pattern after transient Sp. time wd 1) 99 256 P 16 Med.E CsI mod. pattern after transient 100 20 P N/A Source spectra and period fold assign. + Att. matrix. 101 11 P N/A Numerical command data. 102 2 P N/A Software events and errors 126 29 P N/A Burst summary data. Special time words3) 127 256 P N/A Raw detector data after burst. Sp. time words4) 1) The time words associated with these packets contains 20 bits of timing information corresponding to the moment where the data collection for the buffer in question is terminated. Figure A3.6-1 in the WATCH manual shows the relation between the bits selected for the normal packets and for the special packets. 2) The time given with these packets is the time where the last phase change in the corresponding period-fold procedure was executed. This information is not sufficient to determine completely the relation between the phase value and the CLOCK and CLOCK1 reading - this information may be obtained by comparing the phase value at the time of the telemetry dump and the CLOCK and CLOCK1 values as transmitted during the dump. Note also that in these packets the time word A contains the least significant 4 bits of CLOCK1 and time word B contains all bits of CLOCK. 3) Time word A = . Time word B = CLOCK1 at the time of the burst trigger. 4) The time given in all these packets is the burst trigger time according to the format illustrated in the WATCH manual, figure A3.6-1a. *) The length in this column is the length of raw buffer before packing and it does not include the 3 header words. APPENDIX B. QLNUT SWITCH OPTIONS /m Manually set the WATCH unit number /r Reanalyze this file, allow manual parameter control /x Update *.smy-file. Auto-exit if operator intervention reqd. /X Update *.smy-file. Allow operator intervention /U Output list of UT-times for DID 42 packets to file UTIME.DAT **************************************************************** file: timecal.txt **************************************************************** The GRANAT-WATCH UT-time calibration proceed in the following steps: 1) The QLX.EXE program was run on all *.mem-files producing WATCx.SMY-files. The WATCx.SMY-files contains all time calibration data from the dump. A *.SMY file is produced for each WATCH unit, containing all the time data from all the dumps of that instrument. The final *.SMY files have been renamed to *.SM5. 2) The TIMWR.EXE (with WATCH NO = 4 !) is run using as input the file TIME0.DAT. TIME0.DAT is a slightly edited (for easier reading) version of the original TIME.DAT file supplied from IKI. Output from this program is the file TIME1.DAT which contains among other things the RUNSEC parameter, a continous time parameter beginning 1989 Dec. 1.st 00:00:00 UT. 3) The WATIME.EXE is taking as input the TIME1.DAT and all three of the *.SM5-files. The program will produce a binary output file FUTURE.TID containing everything about time and WATCH. 4) The WATIM3.EXE will produce three files: WTCALx.TID, which are the almost final product of the time calibration. These are ASCII-files containing one or two lines of time calibration data for each dump. At the beginning of each line are information relating a CLOCK2,-1,-0 reading to a RUNSEC-value. At the end of each line are memory pointers for the primary and the secondary memory indicating the memory area inside which this calibration is valid. For normal dumps this is just the entire primary or secondary mmemory, but in case of CPU-resets the time calibration may only be valid for a part of the memory. It is the WTCALx.TID-files which will be read by QLNUT to produce UT-times corresponding to a given CLOCK2, -1, -0 value. 5) In cases where the CPU.clock is reset during a dump, two lines of time- calibration data will be found in WTCALx.TID-files. The first of the two lines correspond to the time calibration valid prior to the reset, the second to the calibration valid after the reset. Which data in the WATCH memory corresponds to which calibration must be decided by clever judgment. As default the WATIM3.EXE takes the last calibration to be valid for the whole dump. If this is wrong, it will show up as a sudden jump (often by several days) of the UT-time associated to neighboring packets. When this happens manual editing of the WTCALx.TID file is required, adjusting the dividing line in the memory between the two time calibrations. 6) Another special case calling for editing of the *.TID files is the situation where the instrument have been left unattended for for more than 4 days. Then the onboard clocks will have wrapped around in the CLOCK-1 values and the calibration logic will be confused as to how many wraps to account for. **************************************************************** file: timcal1.ml **************************************************************** The following old letter explain some of the processing steps for the time calibration. You will not need this now, but I include it to have it available when we run into time calibration problems - which I am sure we will! *** We start from the file containing the calculated GRANAT hour pulses near midnight for every day. In fact we are a little unhappy that the file contains data which have already been interpolated and not the raw measurements, because each process is likely to introduce its own errors. We calculate the duration of the GRANAT HOUR for each day, and we delete those entries from the file which produces obviously wrong values. This happens every time a "leap second" is introduced in the UT time (the Moscow time follows UT in this respect). The leap seconds of interest for GRANAT have been introduced at 891231, 901231 and 920630. Another one is coming up for 930630. A few more apparently erroneous entries have also been deleted. On the basis of the cleaned file we generate a new file containing "elapsed time measured in seconds since dec 1.st 1989 UT 00:00:00.000" as a floating point number (double precision) for each remaining entry in the cleaned file. This elapsed time is running smoothly counting elapsed seconds including the effects of the leap seconds. For each operating WATCH unit (0, 1 and 3) we have generated a file containing one line for every session available. The data written in these files are among other things: a) The session number b) The reading of the WATCH onboard UR (UR means "clock" in danish!) giving year, month, date, hour, minute and second corresponding to the last GRANAT hour pulse received by WATCH prior to the data dump. Note, that the time data are stored onboard in "wrap around memories", so they never fill up. For this reason it will almost always be true that these data refer to the same GRANAT pulse for all the three WATCH units. This is quite important for establishing the time calibration as you will see later. c) The reading of the clock-2-1-0 counters exactly at the time of the GRANAT 1 second pulse coming together with the hour pulse. (This is one of the critical points - which of the GRANAT 1 second pulses really marks the hour ???). The problem of course is compounded by the nasty 2/3 GRANAT hour of delay between the pulses actually calibra- ted to Moscow Time and the "hour pulse" seen by the WATCH units. I have tried to discuss this problem with Volodja Evgenov who constructed the BUNA, but we never came to a conclusion. However I understood from him that the time calibration in principle is more accurate on the MBM, i.e. on the PHEBUS and SIGMA data, but take care ! The calibration of clock-2-1-0 is important because these are the counter values associated with each WATCH data packet (only clock-1 and the four most significant bits of clock-0 are included with the normal packets). d) Status and quality information containing flags to warn us if the time data are unreliable for this dump. I have then made a (nasty) program which takes as input the four files described above (The elapsed time file and the three data files for the WATCH units) and builds one file containing all the information required for the time calibration. The logic of the program is that I have deter- mined the initial offset of the UR in WATCH 1; from this I calculate the approximate elapsed time for the hour data in the WATCH files; then I find which GRANAT hour pulse matches this elapsed time best - usually to within a second; then I calculate the true elapsed time for this hour pulse, and finally I determine new offsets for the URs in all three WATCH units. With these offsets I proceed to the next session. If for a given session I do not have WATCH 1 data available I try with WATCH 3, and if also not WATCH 3 is useable I finally turn to WATCH 0. I end up with a file containing for each session a value of the elapsed time, and for each WATCH unit, the values of clock-2-1-0 corresponding to this elapsed time. I also store for each WATCH the elapsed time value for the last reset of clock-2-1-0. (These counters are reset every time the instrument is switched off or is commanded into MONITOR mode). From this combination file I finally produce a time calibration file for each unit. I have now modified our data analysis program (running on PC) to give UT time for every data packet I request. The main problem remaining is to be sure that the basic zero point is correct, that is: which 1 second pulse really marks the hour, and what is actually the delay in the BUNA between the pulse calibrated on the ground and the pulse going to WATCH?