Tohban Report 2015-10-07
From RHESSI Wiki
(Created page with " {{Infobox Tohban Report| |start_date = 30 Sep 2015 |end_date = 7 Oct 2015 |tohban_name = Juan Carlos Martinez Oliveros and Hazel Bain |tohban_email = hbain@ssl.berkeley.edu |ne...") |
|||
| Line 83: | Line 83: | ||
15-279-00:40:58 /IDPUTABLE6 OFFSET=FRONTSLOWDAC | 15-279-00:40:58 /IDPUTABLE6 OFFSET=FRONTSLOWDAC | ||
15-279-00:41:08 /IDPLOAD VALUE=0x50 | 15-279-00:41:08 /IDPLOAD VALUE=0x50 | ||
| + | |||
| + | In order to deal with the high SSR fill level we halted collection of detector 4 events. We also loaded a modified version of RTS 26 so that G4 events would stay off, when the other detector events were turned back on, after each eclipse exit. We noted an immediate decrease in the SSR write rate, as soon as G4 events were turned off. This SSR fill level has since begun to decrease. | ||
| + | |||
| + | ; Turn off G4 events | ||
| + | 15-279-02:16:10 /itmoff value=dib4 | ||
| + | |||
| + | ; Load modified RTS 26 so the G4 events stay off | ||
| + | 15-279-02:17:05 start sc_tbl_loadpkt("T15271SLTN61_No_G4_G9.00") | ||
| + | |||
| + | * 6th of October 2015: The thin attenuator was stuck IN again during the Berkeley passes. No changed were made to the threshold values but the thin attenuator was commanded out. It remained out at the final pass of the evening. | ||
== Attenuator Issues == | == Attenuator Issues == | ||
Revision as of 18:00, 7 October 2015
| Tohban Reports | |
|---|---|
| Start Date: | 30 Sep 2015 |
| End Date: | 7 Oct 2015 |
| Tohban: | Juan Carlos Martinez Oliveros and Hazel Bain |
| Tohban email: | hbain@ssl.berkeley.edu |
| Next Tohban: | |
| List all reports | |
Contents |
Solar Activity
In the first half of the week solar activity was moderate with 7 M class flares, mostly originating in active region NOAA 12422. AR 12422 rotated over the limb on the 4th of October, after which the Sun became very quiet with a background solar flux at the low B class level. There are currently only 2 active regions on the disk, one of which will rotate over the limb within the next 24 hours. Quiet Sun conditions are expected to continue for the next few days.
How many GOES flares occurred?
Flares above B, C, M, X class were 4 38 7 0
And how many of these are listed in the RHESSI flare list?
Flares above B, C, M, X class were 0 14 5 0
And how many had EXCELLENT coverage?
Flares above B, C, M, X class were 0 4 3 0
There were RHESSI flares/GOES flares 43 / 49 over the time range 30-Sep-15 07-Oct-15
Memory Management
The SSR is a bit high due to high solar activity, with a max of 48% and at 28% after the last pass set today.
The SSR started the week almost emptying. However, after the HV drop on D4, slow events from D4 and D6 were high enough to keep steadily increasing the SSR fill. This was even BEFORE solar activity picked up. Because of this, I proposed that it might be a good idea to disable events on D4, with the reasoning that those events aren't giving us good data and are just eating up the SSR. Because things didn't quite get bad enough that we were really in trouble, I did not implement this suggestion. Future tohbans should keep it in mind as a last resort.
Temperatures
The cold plate temps have come down a bit, consistent with solar fraction. CP1 = 134.7K, CP2 = 133.1K.
Data Gaps
GAP START TIME GAP END TIME GAP (SEC) 2015-10-02T04:05:00.000 -- 2015-10-02T04:10:00.000 300.00000 NO GAPS IN APP_ID = 154 (VC1-PMTRAS) NO GAPS IN APP_ID = 102 (VC3-MONITOR RATES)
Detector issues
- 2nd October 2015: We returned detector G3 Front Slow threshold to the nominal value of 0x0C (was 0x1C). When we did this, the front slow valids jumped from ~1680 cps to ~3800 cps. We left it this way, over the weekend, but keept a close eye on it.
15-276-01:48:22 start idib_chg_thrshld(3, FRONT, SLOW, 0x0C) ; was 0x1C 15-276-01:48:26 /IDPUDUMPTABL TABLE=DIBTBL3 15-276-01:48:26 /IDPUTABLE3 OFFSET=FRONTSLOWDAC 15-276-01:48:37 /IDPLOAD VALUE=0x0C
- 5th October 2015: We increased the front slow thresholds, on detectors G3 and G6.
15-278-21:28:34 /iattmove move=out2
15-278-21:28:51 start idib_chg_thrshld(3, FRONT, SLOW, 0x15) ; was 0x0C 15-278-21:28:55 /IDPUDUMPTABL TABLE=DIBTBL3 15-278-21:28:55 /IDPUTABLE3 OFFSET=FRONTSLOWDAC 15-278-21:29:13 /IDPLOAD VALUE=0x15
15-278-21:29:49 start idib_chg_thrshld(6, FRONT, SLOW, 0x40) ; was 0x30 15-278-21:29:53 /IDPUDUMPTABL TABLE=DIBTBL6 15-278-21:29:53 /IDPUTABLE6 OFFSET=FRONTSLOWDAC 15-278-21:30:03 /IDPLOAD VALUE=0x40
Furthermore G4 was primarily responsible was the increasing SSR fill level (max ~68%). Over the weekend the behavior of D4 changed causing very high fast valids and live time at or near 0%. This low live time has prevented G4 from putting a lot of noise into the SSR. However over the previous few days, the fast valids declined and the livetime rose to around 74%. This has allowed G4 to begin putting more than 9k events per second. Because of this, we further increased the G4 front slow valid, in steps up to max threshold 0xFF. This had no effect whatsoever (slow valid counts appear to be stuck on just one value). This is similar to some of the strange behavior was previously saw in G9.
15-279-00:37:28 start idib_chg_thrshld (4, FRONT, SLOW, 0xE0) ; was 0xD0 15-279-00:37:32 /IDPUDUMPTABL TABLE=DIBTBL4 15-279-00:37:32 /IDPUTABLE4 OFFSET=FRONTSLOWDAC 15-279-00:37:42 /IDPLOAD VALUE=0xE0
15-279-00:38:20 start idib_chg_thrshld (4, FRONT, SLOW, 0xF0) ; was 0xE0 15-279-00:38:24 /IDPUDUMPTABL TABLE=DIBTBL4 15-279-00:38:24 /IDPUTABLE4 OFFSET=FRONTSLOWDAC 15-279-00:38:29 /IDPLOAD VALUE=0xF0
15-279-00:39:19 start idib_chg_thrshld (4, FRONT, SLOW, 0xFF) ; was 0xF0 15-279-00:39:23 /IDPUDUMPTABL TABLE=DIBTBL4 15-279-00:39:23 /IDPUTABLE4 OFFSET=FRONTSLOWDAC 15-279-00:39:30 /IDPLOAD VALUE=0xFF
15-279-00:40:54 start idib_chg_thrshld (6, FRONT, SLOW, 0x50) ; was 0x40 15-279-00:40:58 /IDPUDUMPTABL TABLE=DIBTBL6 15-279-00:40:58 /IDPUTABLE6 OFFSET=FRONTSLOWDAC 15-279-00:41:08 /IDPLOAD VALUE=0x50
In order to deal with the high SSR fill level we halted collection of detector 4 events. We also loaded a modified version of RTS 26 so that G4 events would stay off, when the other detector events were turned back on, after each eclipse exit. We noted an immediate decrease in the SSR write rate, as soon as G4 events were turned off. This SSR fill level has since begun to decrease.
- Turn off G4 events
15-279-02:16:10 /itmoff value=dib4
- Load modified RTS 26 so the G4 events stay off
15-279-02:17:05 start sc_tbl_loadpkt("T15271SLTN61_No_G4_G9.00")
- 6th of October 2015: The thin attenuator was stuck IN again during the Berkeley passes. No changed were made to the threshold values but the thin attenuator was commanded out. It remained out at the final pass of the evening.
Attenuator Issues
- 2nd October 2015: The thin attenuator got stuck IN 3 times. We adjusted the threshold to pull out the thin attenuator, by one count. Thresholds were adjusted to thin: 4.31% and thick 4.71%. After the change was made, the thin attenuator moved out, in an automated fashion.
15-276-01:49:28 start attenuator013_2015_276
- 5th October 2015: The thin attenuator was stuck IN so it was commanded out. Unfortunately, the attenuator went right back in again, because the deadtime is rising. To avoid raising the thresholds on the detectors 1 and 7 which are used to trigger the attenuator motions, we had adjust the attenuator Thin In threshold, as well as the Thin Out and Thick Out thresholds fairly aggressively, to get back to normal shutter operations
Thin In: 15 (was 13) -> 5.89% Thin Out: 14 (was 11) -> 5.5% Thick Out: 15 (was 12) -> 5.89%
15-278-23:07:35 start attenuator013_2015_278
This resulted in the thin attenuator moving out, as expected.
Other notes
Spacecraft Management
It's about time for a spinup.
| Decimation | Active/Vigorous |
| HLAT Decimation | Rear decimation weight 6, no front decimation |
| Night time data (fronts) | +/- 4 minutes |
| Night time data (rears) | +/- 4 minutes |
| Require extra passes? | No |
| Requirement for moving pointer? | No |
| Attenuator operation | Looks ok. |
| Detector problems? | See notes above. |
