Tohban Report 2015-10-07

From RHESSI Wiki

(Difference between revisions)
Jump to: navigation, search
 
(4 intermediate revisions not shown)
Line 43: Line 43:
* 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.
* 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:22 start idib_chg_thrshld(3, FRONT, SLOW, 0x0C) ; was 0x1C
-
15-276-01:48:26 /IDPUDUMPTABL TABLE=DIBTBL3
+
15-276-01:48:26 /IDPUDUMPTABL TABLE=DIBTBL3
-
15-276-01:48:26 /IDPUTABLE3 OFFSET=FRONTSLOWDAC
+
15-276-01:48:26 /IDPUTABLE3 OFFSET=FRONTSLOWDAC
-
15-276-01:48:37 /IDPLOAD VALUE=0x0C
+
15-276-01:48:37 /IDPLOAD VALUE=0x0C
* 5th October 2015: We increased the front slow thresholds, on detectors G3 and G6.   
* 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:28:51 start idib_chg_thrshld(3, FRONT, SLOW, 0x15) ; was 0x0C
+
  15-278-21:29:49 start idib_chg_thrshld(6, FRONT, SLOW, 0x40)  ; was 0x30
-
15-278-21:28:55 /IDPUDUMPTABL TABLE=DIBTBL3
+
15-278-21:29:53 /IDPUDUMPTABL TABLE=DIBTBL6
-
15-278-21:28:55 /IDPUTABLE3 OFFSET=FRONTSLOWDAC
+
15-278-21:29:53 /IDPUTABLE6 OFFSET=FRONTSLOWDAC
-
15-278-21:29:13 /IDPLOAD VALUE=0x15
+
15-278-21:30:03 /IDPLOAD VALUE=0x40
-
 
+
-
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.
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:28 start idib_chg_thrshld (4, FRONT, SLOW, 0xE0)  ; was 0xD0
-
15-279-00:37:32 /IDPUDUMPTABL TABLE=DIBTBL4
+
15-279-00:37:32 /IDPUDUMPTABL TABLE=DIBTBL4
-
15-279-00:37:32 /IDPUTABLE4 OFFSET=FRONTSLOWDAC
+
15-279-00:37:32 /IDPUTABLE4 OFFSET=FRONTSLOWDAC
-
15-279-00:37:42 /IDPLOAD VALUE=0xE0
+
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:20 start idib_chg_thrshld (4, FRONT, SLOW, 0xF0)  ; was 0xE0
-
15-279-00:38:24 /IDPUDUMPTABL TABLE=DIBTBL4
+
15-279-00:38:24 /IDPUDUMPTABL TABLE=DIBTBL4
-
15-279-00:38:24 /IDPUTABLE4 OFFSET=FRONTSLOWDAC
+
15-279-00:38:24 /IDPUTABLE4 OFFSET=FRONTSLOWDAC
-
15-279-00:38:29 /IDPLOAD VALUE=0xF0
+
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:19 start idib_chg_thrshld (4, FRONT, SLOW, 0xFF)  ; was 0xF0
-
15-279-00:39:23 /IDPUDUMPTABL TABLE=DIBTBL4
+
15-279-00:39:23 /IDPUDUMPTABL TABLE=DIBTBL4
-
15-279-00:39:23 /IDPUTABLE4 OFFSET=FRONTSLOWDAC
+
15-279-00:39:23 /IDPUTABLE4 OFFSET=FRONTSLOWDAC
-
15-279-00:39:30 /IDPLOAD VALUE=0xFF
+
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.
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
+
Turn off G4 events
-
15-279-02:16:10 /itmoff value=dib4
+
15-279-02:16:10 /itmoff value=dib4
-
; Load modified RTS 26 so the G4 events stay off
+
Load modified RTS 26 so the G4 events stay off
-
15-279-02:17:05 start sc_tbl_loadpkt("T15271SLTN61_No_G4_G9.00")
+
15-279-02:17:05 start sc_tbl_loadpkt("T15271SLTN61_No_G4_G9.00")
-
* 6th of October 2015: The front slow threshold on detector 6 was increased to 0x50. Detector 6 is still showing flare counts at higher energies, so while the front slow rate remains high, the decision was made to leave the threshold at the current value for now.
+
The front slow threshold on detector 6 was also increased
-
15-278-21:29:49 start idib_chg_thrshld(6, FRONT, SLOW, 0x40)  ; was 0x30
+
15-279-00:40:54 start idib_chg_thrshld (6, FRONT, SLOW, 0x50)  ; was 0x40
-
15-278-21:29:53 /IDPUDUMPTABL TABLE=DIBTBL6
+
15-279-00:40:58 /IDPUDUMPTABL TABLE=DIBTBL6
-
15-278-21:29:53 /IDPUTABLE6 OFFSET=FRONTSLOWDAC
+
15-279-00:40:58 /IDPUTABLE6 OFFSET=FRONTSLOWDAC
-
15-278-21:30:03 /IDPLOAD VALUE=0x40
+
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.  
+
 
 +
* 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.
== Attenuator Issues ==
== Attenuator Issues ==
Line 105: Line 99:
* 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.
* 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
+
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
* 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
Line 113: Line 107:
Thick Out:  15 (was 12) -> 5.89%
Thick Out:  15 (was 12) -> 5.89%
-
15-278-23:07:35 start attenuator013_2015_278
+
15-278-23:07:35 start attenuator013_2015_278
This resulted in the thin attenuator moving out, as expected.
This resulted in the thin attenuator moving out, as expected.
Line 119: Line 113:
* 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.  
* 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%).  
+
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%).
-
 
+
== Other notes ==
== Other notes ==

Latest revision as of 22:30, 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: Lindsay Glesener
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 69% and is now at a minimum of 28% after the last pass yesterday due to events being turned off on D4.


Temperatures

The cold plate temps have come up a bit. CP1 = 135.9K, CP2 = 134.2K.


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

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
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


Attenuator Issues

15-276-01:49:28 start attenuator013_2015_276

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.

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%).

Other notes

Spacecraft Management

There was a spin up on DOY 273 up to ~15 rpm.


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.
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox