Tohban Report 2015-10-14
From RHESSI Wiki
|Start Date:||30 Sep 2015|
|End Date:||7 Oct 2015|
|Next Tohban:||Jim McTiernan|
|List all reports|
Solar activity was extremely quiet (low B level) for most of the week, until the 12th, when AR 12434 rotated onto the disk and started producing C flares. The level of flaring isn't terribly high, but there was an almost-M event. Conditions will probably remain like this (light flaring, small C level, maybe a few bigger ones) for the coming days.
How many GOES flares occurred?
Flares above B, C, M, X class were 13 7 0 0
And how many of these are listed in the RHESSI flare list?
Flares above B, C, M, X class were 2 1 0 0
And how many had EXCELLENT coverage?
Flares above B, C, M, X class were 0 0 0 0
There were RHESSI flares/GOES flares 7 / 20 over the time range 07-Oct-15 14-Oct-15
There was a 15 hour data gap on the 12th due to trouble with Wallops on Monday. The VC1 data was dumped, can’t recover this (that includes PMTRAS). VC3 data was replayed, so we recovered the detector data.
SSR fill level: last week we had a max of 50%; now the max is 35% (and would be even lower if not for the Wallops troubles). We ended the week with a fill of 17%, mostly due to replays. (Got as low as 9% at some point.)
Cold Plate 1 and 2 are at 137.3K and 135.9K, up a bit from last week (trending with daylight fraction). Cryocooler performance is unchanged; accelerations are still relatively low. No changes to performance or settings.
Some gaps in last couple days, probably due to Wallops issues?
GAPS IN APP_ID = 1 (VC1-SOH) WITH PACKET RATE LT 30 N_GAPS 2 GAP START TIME GAP END TIME GAP (SEC) 2015-10-13T18:20:00.000 -- 2015-10-13T18:25:00.000 300.00000 2015-10-13T23:10:00.000 -- 2015-10-13T23:20:00.000 600.00000 GAPS IN APP_ID = 154 (VC1-PMTRAS) WITH PACKET RATE LT 4 N_GAPS 2 GAP START TIME GAP END TIME GAP (SEC) 2015-10-13T18:20:00.000 -- 2015-10-13T18:25:00.000 300.00000 2015-10-13T23:10:00.000 -- 2015-10-13T23:20:00.000 600.00000 GAPS IN APP_ID = 102 (VC3-MONITOR RATES) WITH PACKET RATE LT 30 N_GAPS 4 GAP START TIME GAP END TIME GAP (SEC) 2015-10-13T07:00:00.000 -- 2015-10-13T07:05:00.000 300.00000 2015-10-13T07:10:00.000 -- 2015-10-13T07:15:00.000 300.00000 2015-10-13T07:25:00.000 -- 2015-10-13T07:30:00.000 300.00000
GAPS IN APP_ID = 1 (VC1-SOH) WITH PACKET RATE LT 30 N_GAPS 1 GAP START TIME GAP END TIME GAP (SEC) 2015-10-12T04:55:00.000 -- 2015-10-12T18:50:00.000 50100.000 GAPS IN APP_ID = 154 (VC1-PMTRAS) WITH PACKET RATE LT 4 N_GAPS 1 GAP START TIME GAP END TIME GAP (SEC) 2015-10-12T04:55:00.000 -- 2015-10-12T18:50:00.000 50100.000 GAPS IN APP_ID = 102 (VC3-MONITOR RATES) WITH PACKET RATE LT 30 N_GAPS 1 GAP START TIME GAP END TIME GAP (SEC) 2015-10-12T17:00:00.000 -- 2015-10-12T17:10:00.000 600.00000
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.) Update: A first glance at the VC1 data shows that this did lower the fast rates a little (more noticeable in D7), and maybe slightly boost the LT, but this should be checked thoroughly once the data are on the ground.
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 (D1, 3, 7) were raised in order to bring down fast rates and thus free up livetime. The reason so many adjustments were necessary was that fast rates had gotten quite high in these segments. This didn't happen suddenly -- it was a gradual change over weeks, but the more pressing issues (front segments, attenuators, D4, etc) had taken priority for quite awhile. Results: D3 rear fast threshold is maxed, and the LT is still ~0, so this rear segment isn't really working. D1 and D7 rear LTs are at ~62% and ~51%, respectively.
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
Note that D3 rear LT is too high to get useful data, and the front LT is only at ~83% despite the fast threshold being turned up pretty high. About a week ago, the front and rear LTs dropped over the course of a few days, almost simultaneously; that's what prompted all the threshold changes. Because the front and rear seem to be moving together, we've run out of head room on the rear fast (and don't have much on the front fast), and this detector has a reasonably high HV, I recommend an HV drop on this detector, perhaps starting with -200V and going from there.
Final detector issue for the week: D9 ULDs went haywire again, so we decided to turn off the HV and electronics for D9. On Oct 13 Jeremy removed all power from detector 9's HV and turned off DIB (Detector Interface Board) 9. This commanding was done October 13, 2015 at 18:22 UTC. It should be monitored to see if we get any noticeable changes to power or temperature diagnostics due to this.
2015-286-18:21:43 /IHVDAC DETECTOR=9, VOLTAGE=0 2015-286-18:22:48 start idib_single_off(9)
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, so this remains limited to 5 motions per orbit.
There were 14 thick attenuator motions this week.
Note that iattflux is now added to the spacecraft status page for easy reference.
Note from Albert: the detector response now includes the appropriate threshold (with some time lag after changes are made), subject to our imperfect knowledge about the calibrations of various thresholds. This will give us a far more realistic detector response for non-nominal slow threshold settings!! A side effect is that thesemi-calibrated detector count spectra on Browser look weird below the threshold.
|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.|