Tohban Report 2015-10-07
From RHESSI Wiki
|Start Date:||30 Sep 2015|
|End Date:||7 Oct 2015|
|Tohban:||Juan Carlos Martinez Oliveros and Hazel Bain|
|Next Tohban:||Lindsay Glesener|
|List all reports|
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
The SSR is a bit high due to high solar activity, with a max of 69% and is now at a minimum of 28% after the last pass yesterday due to events being turned off on D4.
The cold plate temps have come up a bit. CP1 = 135.9K, CP2 = 134.2K.
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)
- 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: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
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")
The front slow threshold on detector 6 was also increased
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
- 7th October 2015: The livetime of D3 is currently around 0 and D6 varying around 20%. The next tohban should investigate increasing the from fast thresholds on these detectors. Also the D1 and D7 rear livetime has dropped over the last few days.
- 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.
- 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.
The current attenuator threshold values are currently on the edge of being triggered by background noise. The next tohban might consider increasing the Thin In level for the attenuator motions (set to 7%).
There was a spin up on DOY 273 up to ~15 rpm.
|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.|