Tohban Report 2015-10-14

From RHESSI Wiki

(Difference between revisions)
Jump to: navigation, search
(Detector issues)
Line 21: Line 21:
== Detector issues ==
== Detector issues ==
-
On October 7 and 8, we raised the FRONT fast threshold on detectors 3, 5, and 6 in order to bring down fast rates and free up livetime.  Prior to these changes, D5 and D6 front livetimes were at ~30% and ~20% respectively.  For the Oct 8 (DOY 281) changes, the D5 front fast rates fell from 131k to 2100 and the D6 front fast rates fell from 100k to 9000.  The livetimes rose accordingly, so the changes were successful.  Commanding times are below.
+
On October 7 and 8, we raised the FRONT fast threshold on detectors 3, 5, and 6 in order to bring down fast rates and free up livetime.  Prior to these changes, D5 and D6 front livetimes were at ~30% and ~20% respectively.  For the Oct 8 (DOY 281) changes, the D5 front fast rates fell from 131k to 2100 and the D6 front fast rates fell from 100k to 9000.  The livetimes rose accordingly, so the changes were successful.  D3 and D5 front LT are at 82% and 93%, respectively, after this change.  D6 front LT rose to 78%, but then worsened a lot the next day, so more action was taken (see next item).
  2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC
  2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC
Line 31: Line 31:
  2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC
  2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC
  2015-281-21:49:59 /IDPLOAD VALUE=0xFF  ; was 0xE0
  2015-281-21:49:59 /IDPLOAD VALUE=0xFF  ; was 0xE0
 +
 +
 +
On October 12, the HV on detector 6 was dropped by 200V, to ~1600V.  The reasons for this:  D6 front livetime had plummeted, and the fast threshold was already maxed.  I considered raising the slow threshold but concluded that this is unlikely to help the problem -- the previous two slow threshold raises did no good at all, spectrograms have shown that the event noise is across the energy spectrum, not exclusively at low energies, and right now it's clearly the high fast rates that are eating up all the livetime, not the slows.  So something is necessary to reduce fast rates, and an HV drop is the only shot at that.  This also may help some of the other issues with D6.  A first look at the results indicates that this change was successful in reducing fast rates and raising livetime.  Hooray!  Livetime is at ~80% after the voltage drop.  Continue to watch this detector.
 +
 +
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83  ;1593 V (was 1789 V)
Line 75: Line 80:
  2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0
  2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0
-
 
-
On October 12, the HV on detector 6 was dropped by 200V, to ~1600V.  The reasons for this:  D6 front livetime had plummeted, and the fast threshold was already maxed.  I considered raising the slow threshold but concluded that this is unlikely to help the problem -- the previous two slow threshold raises did no good at all, spectrograms have shown that the event noise is across the energy spectrum, not exclusively at low energies, and right now it's clearly the high fast rates that are eating up all the livetime, not the slows.  So something is necessary to reduce fast rates, and an HV drop is the only shot at that.  This also may help some of the other issues with D6.  A first look at the results indicates that this change was successful in reducing fast rates and raising livetime.  Hooray!  Livetime is at ~80% after the voltage drop.
 
-
 
-
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83  ;1593 V (was 1789 V)
 
Outstanding is a request to turn off D9, both HV and electronics.  The ULDs went haywire again a few days ago, so I think it's best to turn it off completely.  Ops is looking into how to do this.
Outstanding is a request to turn off D9, both HV and electronics.  The ULDs went haywire again a few days ago, so I think it's best to turn it off completely.  Ops is looking into how to do this.

Revision as of 17:44, 13 October 2015


Tohban Reports
Start Date: 30 Sep 2015
End Date: 7 Oct 2015
Tohban: Lindsay Glesener
Tohban email: glesener@ssl.berkeley.edu
Next Tohban: TBD
List all reports



Contents

Solar Activity

Memory Management

Temperatures

Data Gaps

Detector issues

On October 7 and 8, we raised the FRONT fast threshold on detectors 3, 5, and 6 in order to bring down fast rates and free up livetime. Prior to these changes, D5 and D6 front livetimes were at ~30% and ~20% respectively. For the Oct 8 (DOY 281) changes, the D5 front fast rates fell from 131k to 2100 and the D6 front fast rates fell from 100k to 9000. The livetimes rose accordingly, so the changes were successful. D3 and D5 front LT are at 82% and 93%, respectively, after this change. D6 front LT rose to 78%, but then worsened a lot the next day, so more action was taken (see next item).

2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC
2015-280-22:13:38 /IDPLOAD VALUE=0xD0  ; was 0x80
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC
2015-281-21:49:37 /IDPLOAD VALUE=0x40  ; was 0x2E
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC
2015-281-21:49:59 /IDPLOAD VALUE=0xFF  ; was 0xE0


On October 12, the HV on detector 6 was dropped by 200V, to ~1600V. The reasons for this: D6 front livetime had plummeted, and the fast threshold was already maxed. I considered raising the slow threshold but concluded that this is unlikely to help the problem -- the previous two slow threshold raises did no good at all, spectrograms have shown that the event noise is across the energy spectrum, not exclusively at low energies, and right now it's clearly the high fast rates that are eating up all the livetime, not the slows. So something is necessary to reduce fast rates, and an HV drop is the only shot at that. This also may help some of the other issues with D6. A first look at the results indicates that this change was successful in reducing fast rates and raising livetime. Hooray! Livetime is at ~80% after the voltage drop. Continue to watch this detector.

2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83  ;1593 V (was 1789 V)


We also raised the FRONT fast thresholds on D1 and D7. These detectors were NOT misbehaving -- they have the highest livetime of any detectors, but since their quiescent (i.e. nonflaring) livetime has dropped slightly, causing the attenuator logic to be fragile, the threshold was raised in an attempt to recover even more livetime. The fast rates aren't terribly high in these detectors, so this might not help (in which case one could consider reversing this raise.)

2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC
2015-285-20:17:03 /IDPLOAD VALUE=0x50  ; was 0x40
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC
2015-285-21:50:56 /IDPLOAD VALUE=0x50  ; was 0x40


On October 8, 9, and 12, several detector REAR fast thresholds were raised in order to bring down fast rates and thus free up livetime. Prior to these changes, livetimes were extremely low for D1,3,7 rear.

2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC 
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0


Outstanding is a request to turn off D9, both HV and electronics. The ULDs went haywire again a few days ago, so I think it's best to turn it off completely. Ops is looking into how to do this.

Attenuator Issues

Due to the issues noted in the previous week's report, and as discussed at the last Ops meeting we increased both the thin out and in thresholds. The thin in went from 5.9% to 8.2% dead time, the thin out went from 5.5% to 7.4% dead time. We also increased the thick out threshold to be 1 count about the thin out, from 5.9% to 7.8%.

We also changed the number of allowed moves for the thin attenuator to 1 motion per orbit. The reasoning here is that after the attenuator insertion occurs, if the shutter comes out and in again it will then stay in for the entire daylight period. This gets us a frequent toggle, but only one, and then it stays in for the rest of that daylight period (thus approximating "option 1" from Martin's list, with the addition of a single toggle at the beginning). We have NOT changed the toggle logic for the thick attenuator.



Other notes

Spacecraft Management

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