https://sprg.ssl.berkeley.edu/~tohban/wiki/index.php?title=Special:Contributions&feed=atom&limit=250&target=Lglesener&year=&month=RHESSI Wiki - User contributions [en]2024-03-29T07:18:40ZFrom RHESSI WikiMediaWiki 1.16.0https://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-28T21:56:53Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = Jim McTiernan<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
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.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 13 7 0 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 2 1 0 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 7 / 20<br />
over the time range 07-Oct-15 14-Oct-15<br />
<br />
== Memory Management ==<br />
<br />
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.<br />
<br />
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.)<br />
<br />
<br />
== Temperatures ==<br />
<br />
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.<br />
<br />
== Data Gaps ==<br />
<br />
Some gaps in last couple days, probably due to Wallops issues?<br />
<br />
GAPS IN APP_ID = 1 (VC1-SOH) WITH PACKET RATE LT 30<br />
N_GAPS 2<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T18:20:00.000 -- 2015-10-13T18:25:00.000 300.00000<br />
2015-10-13T23:10:00.000 -- 2015-10-13T23:20:00.000 600.00000<br />
GAPS IN APP_ID = 154 (VC1-PMTRAS) WITH PACKET RATE LT 4<br />
N_GAPS 2<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T18:20:00.000 -- 2015-10-13T18:25:00.000 300.00000<br />
2015-10-13T23:10:00.000 -- 2015-10-13T23:20:00.000 600.00000<br />
GAPS IN APP_ID = 102 (VC3-MONITOR RATES) WITH PACKET RATE LT 30<br />
N_GAPS 4<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T07:00:00.000 -- 2015-10-13T07:05:00.000 300.00000<br />
2015-10-13T07:10:00.000 -- 2015-10-13T07:15:00.000 300.00000<br />
2015-10-13T07:25:00.000 -- 2015-10-13T07:30:00.000 300.00000<br />
<br />
GAPS IN APP_ID = 1 (VC1-SOH) WITH PACKET RATE LT 30<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T04:55:00.000 -- 2015-10-12T18:50:00.000 50100.000<br />
GAPS IN APP_ID = 154 (VC1-PMTRAS) WITH PACKET RATE LT 4<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T04:55:00.000 -- 2015-10-12T18:50:00.000 50100.000<br />
GAPS IN APP_ID = 102 (VC3-MONITOR RATES) WITH PACKET RATE LT 30<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T17:00:00.000 -- 2015-10-12T17:10:00.000 600.00000<br />
<br />
== Detector issues ==<br />
<br />
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).<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
<br />
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.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
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.<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
<br />
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.<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
2015-286-18:21:43 /IHVDAC DETECTOR=9, VOLTAGE=0<br />
2015-286-18:22:48 start idib_single_off(9)<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
There were 14 thick attenuator motions this week.<br />
<br />
Note that iattflux is now added to the spacecraft status page for easy reference.<br />
<br />
== Other notes ==<br />
<br />
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.<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-28T21:56:36Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
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.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 13 7 0 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 2 1 0 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 7 / 20<br />
over the time range 07-Oct-15 14-Oct-15<br />
<br />
== Memory Management ==<br />
<br />
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.<br />
<br />
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.)<br />
<br />
<br />
== Temperatures ==<br />
<br />
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.<br />
<br />
== Data Gaps ==<br />
<br />
Some gaps in last couple days, probably due to Wallops issues?<br />
<br />
GAPS IN APP_ID = 1 (VC1-SOH) WITH PACKET RATE LT 30<br />
N_GAPS 2<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T18:20:00.000 -- 2015-10-13T18:25:00.000 300.00000<br />
2015-10-13T23:10:00.000 -- 2015-10-13T23:20:00.000 600.00000<br />
GAPS IN APP_ID = 154 (VC1-PMTRAS) WITH PACKET RATE LT 4<br />
N_GAPS 2<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T18:20:00.000 -- 2015-10-13T18:25:00.000 300.00000<br />
2015-10-13T23:10:00.000 -- 2015-10-13T23:20:00.000 600.00000<br />
GAPS IN APP_ID = 102 (VC3-MONITOR RATES) WITH PACKET RATE LT 30<br />
N_GAPS 4<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T07:00:00.000 -- 2015-10-13T07:05:00.000 300.00000<br />
2015-10-13T07:10:00.000 -- 2015-10-13T07:15:00.000 300.00000<br />
2015-10-13T07:25:00.000 -- 2015-10-13T07:30:00.000 300.00000<br />
<br />
GAPS IN APP_ID = 1 (VC1-SOH) WITH PACKET RATE LT 30<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T04:55:00.000 -- 2015-10-12T18:50:00.000 50100.000<br />
GAPS IN APP_ID = 154 (VC1-PMTRAS) WITH PACKET RATE LT 4<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T04:55:00.000 -- 2015-10-12T18:50:00.000 50100.000<br />
GAPS IN APP_ID = 102 (VC3-MONITOR RATES) WITH PACKET RATE LT 30<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T17:00:00.000 -- 2015-10-12T17:10:00.000 600.00000<br />
<br />
== Detector issues ==<br />
<br />
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).<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
<br />
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.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
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.<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
<br />
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.<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
2015-286-18:21:43 /IHVDAC DETECTOR=9, VOLTAGE=0<br />
2015-286-18:22:48 start idib_single_off(9)<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
There were 14 thick attenuator motions this week.<br />
<br />
Note that iattflux is now added to the spacecraft status page for easy reference.<br />
<br />
== Other notes ==<br />
<br />
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.<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_9Detector 92015-10-14T17:59:09Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 9 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 9 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
Detector 9 is SEGMENTED after the 2014 anneal!<br />
<br />
* 2014 August 20: Due to sporadic noise in D9, the HV was dropped by 20 counts (now at 3600V). Commanding was at 20:57 UTC. This successfully quieted the noise. The noise was mainly fast counts, which cut drastically into the livetime.<br />
<br />
* 2014 October 8: This detector has started to show some periodical spikes during last couple of days. Still is not clear what is their origin. It seems to be periodic with the orbit. So far no action taken.<br />
<br />
* 2014 Oct 31: Elevated noise during the period of Oct 31 - Nov 2. The onset, as well as the abatement was sudden. No commanding was done and the noise returned to regular levels.<br />
<br />
* On 2015 Jan 8, the rear fast threshold was raised since fast counts were eating up a lot of livetime.<br />
<br />
15-008-17:45:50 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-008-17:46:04 /IDPULOAD VALUE=0x50 ;(was 0x45)<br />
<br />
* Rear fast counts are high again, so we raised the rear fast threshold by 16 steps, in two sets of 8, on the BGS pass starting at ~3:30 PST. The new value is 0x60 (was 0x50). Fast rates as eyeballed from the realtime data were approx 58,000 (pre-adjustment), 12,000 (after 8 steps up), and 1600 (after 16 steps up). Livetime percentages were approx 60%, 90%, and 98%, respectively.<br />
<br />
15-021-23:33:58 /idpudumptabl table=dibtbl9<br />
15-021-23:34:03 /idputable9 offset=rearfastdac<br />
15-021-23:34:34 /idpuload value=0x58<br />
<br />
15-021-23:36:47 /idputable9 offset=rearfastdac<br />
15-021-23:36:55 /idpuload value=0x60<br />
<br />
* The rear fast threshold was raised again for the same reasons as the last two adjustments. The threshold was raised in two jumps of hex 8 each.<br />
15-057-18:43:13 /IDPUTABLE9 OFFSET=rearfastDAC<br />
15-057-18:45:14 /IDPLOAD VALUE=0x68<br />
<br />
15-057-20:21:52 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-057-20:22:09 /IDPLOAD VALUE=0x70<br />
<br />
* Rear fast threshold changed again, usual reason.<br />
15-064-19:39:50 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-064-19:40:12 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* And again, on March 11, 2015.<br />
2015-070-22:46:04 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
2015-070-22:46:19 /IDPLOAD VALUE=0x90<br />
<br />
* On March 13, 2015 the rear fast threshold was changed again<br />
15-072-22:06:18 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-072-22:06:31 /IDPLOAD VALUE=0xA0<br />
<br />
* And then again, on March 16, 2015.<br />
15-075-19:24:13 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-075-19:24:28 /IDPLOAD VALUE=0xB0<br />
<br />
* And then again, on March 18, 2015.<br />
15-077-TBD /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-077-TBD /IDPLOAD VALUE=0xC0<br />
<br />
* And again, on March 25, 2015.<br />
15-084-21:07:00 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-084-21:07:14 /IDPLOAD VALUE=0xFF<br />
<br />
* In addition we change the HV on March 25, 2015:<br />
15-084-19:26:07 /ihvdac detector=9, voltage=176<br />
15-084-19:27:17 /ihvdac detector=9, voltage=166<br />
15-084-19:28:33 /ihvdac detector=9, voltage=156<br />
15-084-21:05:17 /ihvdac detector=9, voltage=136 (2622 V)<br />
<br />
* As of early April, detector 9 rear segment is now essentially non functional. Rear fast rates have increased to the point where livetime dropped to zero, and the fast threshold is already turned all the way up so we have no way to control those rates. The front segment appears to be operating normally, though its fast AND slow rates are high (but not worringly so).<br />
<br />
* 2015 April 7: To deal with slightly reduced livetime in the FRONT segment, we changed the front fast threshold. This does NOT seem to have had an effect!!<br />
15-097-19:58:06 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
15-097-19:58:14 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* 2015 April 14: We increase the Front Slow Threshold just to reduce the values on the front slow valid counts<br />
15-104-14:09:00 /IDPUTABLE9 OFFSET=FRONTSLOWDAC<br />
15-104-14:09:12 /IDPLOAD VALUE=0x1A<br />
<br />
* 2015 May 13: D9 front fast was increased <br />
2015-133-19:09:39 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
2015-133-19:09:52 /IDPLOAD VALUE=0x40 ; was 0x30<br />
<br />
* On June 11 2015 the front fast threshold was raised because the fast rates were high and the livetime was low. This action was DID reduce the fast rates but did NOT increase the livetime much! D9 now does not show high fast rates, slow rates, or resets, but yet the livetime is quite low.<br />
<br />
* On August 20 2015 the front fast threshold was raised in an attempt to gain livetime, which was at ~15%. This was unsuccessful.<br />
15-232-22:21:09 start idib_chg_thrshld (9, FRONT, FAST, 0x90)<br />
15-232-22:21:38 /IDPUDUMPTABL TABLE=DIBTBL9<br />
15-232-22:21:38 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
15-232-22:21:46 /IDPLOAD VALUE=0x90<br />
<br />
* On August 20 2015 the rear segment started dumping a huge number of ULD events into the SSR, filling it. Once the problem was pinpointed, D9 events were disabled entirely on the 21st. D9 HV was turned down to 1800V, then 900V, then 800V, in an attempt to bring down the resets. This brought resets down from 30k to 23k and did, indeed, quiet the ULDs. The detector remained segmented. At one point the threshold change to D9 front was reversed to see if that had caused the problem (it hadn't); the threshold change was then re-implemented. Events were turned briefly back on on Aug. 24 and then off, although no danger signs were seen. As of Aug. 25, D9 events are still off. Approximate commanding times are below:<br />
August 21:<br />
1:15 pm PDT: D9 front fast threshold to 0x60 (was 0x90).<br />
2:50 pm PDT: D9 front and rear events disabled.<br />
4:30 pm PDT: HV drop of ~400V, performed in two steps, to 1838V. No change to resets (30k). RTS load to keep D9 events from being re-enabled after eclipse. D9 fast and slow thresholds to max.<br />
6:00 pm PDT: HV drop to ~900V and then again to ~800V. Rear resets before and after are 30k then 25.7k then 23.5k. D9 front fast threshold returned to 0x90.<br />
<br />
* On August 24 2015 D9 events were enabled at 20:42:45 UTC in order to check whether we would still dump too many events into the SSR. The write pointer speed didn't seem to change with this action (although it maybe did change with other detector threshold changes). We left D9 events on, knowing that they'd be turned off again at the next dawn due to the RTS load. As of Aug. 26, D9 events are still off.<br />
2015-236-20:42:45 /itmon value=AFE8 (Detector 9 events turn on)<br />
<br />
* On Sept 9-11, 2015, the rear D9 ULD rose, finally going crazy and maxing out on Sept 11. Since events were off, this wasn't noticed until Sept. 28. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off again at eclipse entry. The ULD event rate should be checked as soon as we get the monitor rate data on it. The detector stayed segmented.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
* 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.<br />
<br />
2015-286-18:21:43 /IHVDAC DETECTOR=9, VOLTAGE=0<br />
2015-286-18:22:48 start idib_single_off(9)<br />
<br />
<br />
<br />
===D9 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C<br />
|-<br />
| 2015 Apr 14 14:09:12 || 0x1A (was 0x0C)<br />
|}<br />
<br />
===D9 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22<br />
|-<br />
| 2015-Apr-07 19:58 || 0x30 (was 0x22)<br />
|- <br />
| 2015-May-13 19:09:52 || 0x40 (was 0x30)<br />
|-<br />
| 2015-Jun-11 20:18:44 || 0x50 (was 0x40)<br />
|-<br />
| 2015-Jul-31 21:42:36 || 0x60 (was 0x50)<br />
|-<br />
| 2015-Aug-20 22:21:46 || 0x90 (was 0x60)<br />
|-<br />
| 2015-Aug-21 ~20:15 || 0x60 (was 0x90)<br />
|-<br />
| 2015-Aug-22 ~01:15 || 0x90 (was 0x60)<br />
|-<br />
|}<br />
<br />
===D9 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|- <br />
| 2015-Aug-22 ~1:15 UTC || 0xFF<br />
|- <br />
|}<br />
<br />
===D9 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|-<br />
| 2015-Jan-08 17:46:04 || 0x50 (was 0x45)<br />
|-<br />
| 2015-Jan-22 23:34:34 || 0x58 (was 0x50)<br />
|-<br />
| 2015-Jan-22 23:36:55 || 0x60 (was 0x58)<br />
|- <br />
| 2015-Feb-27 18:45:14 || 0x68 (was 0x60)<br />
|- <br />
| 2015-Feb-27 20:22:09 || 0x70 (was 0x68)<br />
|- <br />
| 2015-Mar-05 19:40:12 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Mar-11 22:46:19 || 0x90 (was 0x80)<br />
|- <br />
| 2015-Mar-13 22:06:31 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Mar-16 19:24:28 || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-Mar-18 21:52:57 || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-Mar-18 23:32:15 || 0xD0 (was 0xC0)<br />
|- <br />
| 2015-Mar-25 21:07:00 || 0xFF (was 0xD0)<br />
|- <br />
|}<br />
<br />
===D9 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 3995 V<br />
|- <br />
| 2014-Aug-20 || 3603V (was 3995V)<br />
|- <br />
| 2015-Mar-25 || 2622V (was 3603V)<br />
|- <br />
| 2015-Aug-03 || 2230V (was 2622V)<br />
|-<br />
| 2015-Aug-21 || ~2000V (was 2230V)<br />
|-<br />
| 2015-Aug-21 || ~1800V<br />
|-<br />
| 2015-Aug-21 || ~900V<br />
|-<br />
| 2015-Aug-21 || 808V<br />
|-<br />
| 2015-Sep-30 03:01:09 || 490V (was 808V)<br />
|-<br />
| 2015-Oct-13 18:22:48 || 0V<br />
|-<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-14T17:58:15Z<p>Lglesener: /* Detector issues */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
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.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 13 7 0 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 2 1 0 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 7 / 20<br />
over the time range 07-Oct-15 14-Oct-15<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
Some gaps in last couple days, probably due to Wallops issues?<br />
<br />
GAPS IN APP_ID = 1 (VC1-SOH) WITH PACKET RATE LT 30<br />
N_GAPS 2<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T18:20:00.000 -- 2015-10-13T18:25:00.000 300.00000<br />
2015-10-13T23:10:00.000 -- 2015-10-13T23:20:00.000 600.00000<br />
GAPS IN APP_ID = 154 (VC1-PMTRAS) WITH PACKET RATE LT 4<br />
N_GAPS 2<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T18:20:00.000 -- 2015-10-13T18:25:00.000 300.00000<br />
2015-10-13T23:10:00.000 -- 2015-10-13T23:20:00.000 600.00000<br />
GAPS IN APP_ID = 102 (VC3-MONITOR RATES) WITH PACKET RATE LT 30<br />
N_GAPS 4<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T07:00:00.000 -- 2015-10-13T07:05:00.000 300.00000<br />
2015-10-13T07:10:00.000 -- 2015-10-13T07:15:00.000 300.00000<br />
2015-10-13T07:25:00.000 -- 2015-10-13T07:30:00.000 300.00000<br />
<br />
GAPS IN APP_ID = 1 (VC1-SOH) WITH PACKET RATE LT 30<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T04:55:00.000 -- 2015-10-12T18:50:00.000 50100.000<br />
GAPS IN APP_ID = 154 (VC1-PMTRAS) WITH PACKET RATE LT 4<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T04:55:00.000 -- 2015-10-12T18:50:00.000 50100.000<br />
GAPS IN APP_ID = 102 (VC3-MONITOR RATES) WITH PACKET RATE LT 30<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T17:00:00.000 -- 2015-10-12T17:10:00.000 600.00000<br />
<br />
== Detector issues ==<br />
<br />
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).<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
<br />
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.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
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.<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
<br />
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.<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
2015-286-18:21:43 /IHVDAC DETECTOR=9, VOLTAGE=0<br />
2015-286-18:22:48 start idib_single_off(9)<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-14T17:55:45Z<p>Lglesener: /* Data Gaps */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
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.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 13 7 0 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 2 1 0 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 7 / 20<br />
over the time range 07-Oct-15 14-Oct-15<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
Some gaps in last couple days, probably due to Wallops issues?<br />
<br />
GAPS IN APP_ID = 1 (VC1-SOH) WITH PACKET RATE LT 30<br />
N_GAPS 2<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T18:20:00.000 -- 2015-10-13T18:25:00.000 300.00000<br />
2015-10-13T23:10:00.000 -- 2015-10-13T23:20:00.000 600.00000<br />
GAPS IN APP_ID = 154 (VC1-PMTRAS) WITH PACKET RATE LT 4<br />
N_GAPS 2<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T18:20:00.000 -- 2015-10-13T18:25:00.000 300.00000<br />
2015-10-13T23:10:00.000 -- 2015-10-13T23:20:00.000 600.00000<br />
GAPS IN APP_ID = 102 (VC3-MONITOR RATES) WITH PACKET RATE LT 30<br />
N_GAPS 4<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-13T07:00:00.000 -- 2015-10-13T07:05:00.000 300.00000<br />
2015-10-13T07:10:00.000 -- 2015-10-13T07:15:00.000 300.00000<br />
2015-10-13T07:25:00.000 -- 2015-10-13T07:30:00.000 300.00000<br />
<br />
GAPS IN APP_ID = 1 (VC1-SOH) WITH PACKET RATE LT 30<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T04:55:00.000 -- 2015-10-12T18:50:00.000 50100.000<br />
GAPS IN APP_ID = 154 (VC1-PMTRAS) WITH PACKET RATE LT 4<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T04:55:00.000 -- 2015-10-12T18:50:00.000 50100.000<br />
GAPS IN APP_ID = 102 (VC3-MONITOR RATES) WITH PACKET RATE LT 30<br />
N_GAPS 1<br />
GAP START TIME GAP END TIME GAP (SEC)<br />
2015-10-12T17:00:00.000 -- 2015-10-12T17:10:00.000 600.00000<br />
<br />
== Detector issues ==<br />
<br />
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).<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
<br />
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.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
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.<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
<br />
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.<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-14T17:52:26Z<p>Lglesener: /* Solar Activity */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
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.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 13 7 0 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 2 1 0 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 7 / 20<br />
over the time range 07-Oct-15 14-Oct-15<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
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).<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
<br />
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.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
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.<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
<br />
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.<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-13T18:15:52Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
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).<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
<br />
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.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
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.<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
<br />
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.<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
<br />
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.<br />
<br />
<br />
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.<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_3Detector 32015-10-13T18:12:54Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 3 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 3 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
Detector 3 is SEGMENTED following the 2014 anneal (yay!)<br />
<br />
* 2014-Aug-26: D3 is suffering a lot from the known light leak problem. This does not affect the quality of the data but greatly reduces livetime at times when light leaks in through the cryostat port. To alleviate this problem, the G3 rear fast threshold was raised from 0x45 to 0x50 at 2014-238-19:22:56 UTC. This didn't seem to fix the problem.<br />
<br />
* Another threshold change b/c of light leak:<br />
14-241-18:34:11 /IDPUTABLE3 REARFASTDAC ;Load address 0x25CC <br />
14-241-18:34:31 /IDPULOAD VALUE=0x60 ;Rear fast from ox50 to 0x60<br />
<br />
* Front Fast threshold increase due to light leak. This lowered fast counts and increased livetime<br />
2015-152-16:58:07 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-152-16:58:16 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* The front fast threshold was increased on July 10 2015 due to low livetime due to high fast rates. This action was effective in raising the livetime.<br />
2015-191-19:20:47 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-191-19:20:58 /IDPLOAD VALUE=0x40 ; was 0x30<br />
<br />
* On Aug 20, 2015 the front fast threshold was raised in order to lower fast rates and free up livetime. This was successful: Livetime rose from ~50% to >90%.<br />
15-232-22:16:08 start idib_chg_thrshld (3, FRONT, FAST, 0x50)<br />
15-232-22:16:30 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-232-22:16:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
15-232-22:16:41 /IDPLOAD VALUE=0x50<br />
<br />
* By Aug 24, 2015 rear livetime was so low that the detector had entered "reverse mode" where fast rates are not fully shown, and so fast threshold changes give the opposite effect to that you might expect. (Light leak shows up as livetime peaks, not valleys, in this mode.) The rear fast threshold was raised in two jumps. The first raise apparently increased fast rates and worsened livetime (due to this "reverse mode") but the second raise was successful in bringing down the fast rates and restoring livetime to ~64%.<br />
2015-236-20:45:42 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-236-20:45:54 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
2015-237-00:03:38 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-237-00:03:48 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
* The front slow count rates were elevated, to try to bring them down we raised the slow front threshold by 0x10 on August 27th. This has an immediate effect lowering the slow front counts by a factor of 2. We also raised the front and rear fast threshold to increase the livetime.<br />
<br />
2015-239-17:57:41 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-239-17:57:50 /IDPLOAD VALUE=0x1C ; was 0x0C<br />
<br />
2015-239-19:33:13 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-239-19:33:23 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-239-21:13:25 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-239-21:13:33 /IDPLOAD VALUE=0x60 ; was 0x50<br />
<br />
*On Sept 14 2015, we raised the rear fast threshold on D3 from 0xA0 to 0xB0, to arrest a live-time decrease. Live time jumped fro 10 to 70%, but was bak to 40% in two days.<br />
<br />
2015-257-17:33:14 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-257-17:33:22 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
* Some threshold changes occurred during the tohban week of Sept 15-22.<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* 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.<br />
<br />
15-276-01:48:22 start idib_chg_thrshld(3, FRONT, SLOW, 0x0C) ; was 0x1C<br />
15-276-01:48:26 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-276-01:48:26 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
15-276-01:48:37 /IDPLOAD VALUE=0x0C<br />
<br />
* 5th October 2015: We increased the front slow thresholds, on detectors G3 and G6. <br />
<br />
15-278-21:28:51 start idib_chg_thrshld(3, FRONT, SLOW, 0x15) ; was 0x0C<br />
15-278-21:28:55 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-278-21:28:55 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
15-278-21:29:13 /IDPLOAD VALUE=0x15<br />
<br />
* On October 7, Detector 3's front fast threshold was increased from 0x80 to 0xD0 at 280-22:13:38 UTC. This was due to high fast rates and low livetime in that detector. This worked, increasing D3 front LT to ~85%.<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
* On October 8 and 9, the rear fast threshold was raised to try and raise livetime. This threshold is now maxed out, but it wasn't enough to lower the fast rates enough to get appreciable LT back. The rear segment is at essentially zero livetime, so it's not really functional.<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
<br />
<br />
===D3 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C<br />
|- <br />
| 2015-08-27 17:57:50 UTC || 0x1C (was 0x0C)<br />
|- <br />
| 2015-09-17 06:35:17 UTC || 0x80 (was 0x1C)<br />
|- <br />
| 2015-09-23 19:24:12 UTC || 0x1C (was 0x80)<br />
|- <br />
| 2015-10-03 01:48:22 UTC || 0x0C (was 0x1C)<br />
|-<br />
| 2015-10-05 21:28:51 UTC || 0x15 (was 0x0C)<br />
|- <br />
|}<br />
<br />
===D3 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22<br />
|-<br />
| 2015-06-03 16:58:16 UTC || 0x30 (was 0x22)<br />
|- <br />
| 2015-07-09 19:20:58 UTC || 0x40 (was 0x30)<br />
|- <br />
| 2015-08-20 22:16:41 UTC || 0x50 (was 0x40)<br />
|- <br />
| 2015-08-27 21:13:33 UTC || 0x60 (was 0x50)<br />
|- <br />
| 2015-09-17 06:36:45 UTC || 0x70 (was 0x60)<br />
|- <br />
| 2015-09-22 19:47:12 UTC || 0x80 (was 0x70)<br />
|- <br />
| 2015-10-07 22:13:38 UTC || 0xD0 (was 0x80)<br />
|- <br />
|}<br />
<br />
===D3 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D3 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|- <br />
| 2014-08-26 19:22:56 UTC || 0x50 (was 0x45)<br />
|- <br />
| 2014-08-29 18:33:28 UTC || 0x60 (was 0x50)<br />
|- <br />
| 2015-08-24 20:45:54 UTC || 0x80 (was 0x70)<br />
|- <br />
| 2015-08-25 00:03:48 UTC || 0x90 (was 0x80)<br />
|- <br />
| 2015-08-27 19:33:23 UTC || 0xA0 (was 0x90)<br />
|- <br />
| 2015-09-14 17:33:22 UTC || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-09-17 06:37:06 UTC || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-09-21 20:09:44 UTC || 0xD0 (was 0xC0)<br />
|- <br />
| 2015-10-08 21:57:12 UTC || 0xE0 (was 0xD0)<br />
|- <br />
| 2015-10-08 19:56:18 UTC || 0xF0 (was 0xE0)<br />
|- <br />
| 2015-10-08 23:02:35 UTC || 0xFF (was 0xF0)<br />
|- <br />
|}<br />
<br />
<br />
===D3 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 3995 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_6Detector 62015-10-13T17:58:23Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 6 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 6 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
After the 2014 anneal, detector 6 began its reincarnated life as an unsegmented detector but segmented shortly after (see below).<br />
<br />
<br />
* On 2014 August 14, the HV on D6 was raised to 4926V in an attempt to segment it. This was successful, and D6 now operates as a segmented detector. Since its segmentation is borderline as of Aug/Sept 2014, it commonly unsegments during and just after the SAA.<br />
<br />
* On 2014 Jan 8, the rear fast threshold was raised since fast counts were eating up a lot of livetime.<br />
<br />
15-008-17:44:55 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
15-008-17:45:18 /IDPULOAD VALUE=0x50 ;(was 0x45)<br />
<br />
* * D6 has been showing some strange peaks in the spectrum; these are best seen as multiple lines (that drift) in spectrograms. On Monday, Jan 28 we raised the slow front threshold on D6 to ~10 keV and kept it there for a day before returning to the nominal ~3 keV. This is intended to see if the slow threshold affects the abnormal spectral lines.<br />
15-026-21:57:13 / D6 front slow threshold to 0x30 (was 0x0C).<br />
15-027-21:37:03 / D6 front slow threshold to 0x0C (was 0x30).<br />
<br />
<br />
* D6 fast rates are a bit high (have been rising slowly over the past week). It would be a good idea to raise the front fast threshold a touch. I didn't want to do this at the same time as the slow threshold experiment! <br />
<br />
*D6 front fast threshold was adjusted from default (0x22) due to increased rates, based on the above suggestion. Rates dropped from 3300 to 1250 when the change was made.<br />
15-030-00:19:54 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-030-00:20:17 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* On 2015 February 27 Front Fast threshold was raised <br />
15-058-21:41:11 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-058-21:41:44 /IDPLOAD VALUE=0x40 (was 0x30)<br />
<br />
*Another raise to D6 front fast threshold on 2015 March 9:<br />
15-068-01:26:56 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-068-01:27:07 /IDPLOAD VALUE=0x50<br />
<br />
*On 2015 March 13 another raise was made to D6 front fast threshold and a raise of the rear fast threshold was made:<br />
15-072-22:04:01 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-072-22:04:22 /IDPLOAD VALUE=0x60<br />
<br />
15-072-22:05:07 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
15-072-22:05:17 /IDPLOAD VALUE=0x60<br />
<br />
*Again 2015 March 17 D6 front fast threshold was increased:<br />
15-076-20:44:01 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-076-20:44:14 /IDPLOAD VALUE=0x70<br />
<br />
On 2015 March 20 D6 HV was dropped in two 10 step increments, twice. Also we attempted to lower the front fast threshold to 0x50, but changed this almost immediately when the live time dropped to 3%:<br />
15-079-21:10:49 /IHVDAC DETECTOR=6, VOLTAGE=243<br />
15-079-21:12:47 /IHVDAC DETECTOR=6, VOLTAGE=233<br />
<br />
15-079-22:49:23 /ihvdac detector=6, voltage=223<br />
15-079-22:50:44 /ihvdac detector=6, voltage=213<br />
<br />
15-079-22:52:39 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:52:58 /IDPLOAD VALUE=0x60<br />
<br />
15-079-22:55:07 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:55:19 /IDPLOAD VALUE=0x50<br />
<br />
15-079-22:55:53 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:56:01 /IDPLOAD VALUE=0x70<br />
<br />
On 2015 March 25 D6 HV was dropped in 20 steps. <br />
15-084-22:45:15 /ihvdac detector=6, voltage=203<br />
15-084-22:46:45 /ihvdac detector=6, voltage=193 (3750 V)<br />
<br />
* April 7 2015: the front fast threshold was raised due to high fast rates that were significantly reducing livetime. This helped, but not a lot, so the action will probably be repeated soon.<br />
15-097-19:56:35 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-097-19:56:45 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* April 9 2015: The front fast and the front slow threshold were raised up to recover the livetime and trying to reduce the noise on the slow valid counts.<br />
<br />
15-099-17:32:59 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-099-17:33:11 /IDPLOAD VALUE=0xA0<br />
<br />
15-099-21:17:16 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-099-21:17:27 /IDPLOAD VALUE=0x15<br />
<br />
* On Abril 14 starting at 14:06 UT we made the next changes for detectors 6 trying to decrease valid counts on the Slow Front segment.<br />
<br />
15-104-14:11:57 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-104-14:12:05 /IDPLOAD VALUE=0xA8<br />
15-104-15:45:14 /IDPLOAD VALUE=0xB0<br />
15-104-15:46:24 /IDPLOAD VALUE=0xB8<br />
15-104-15:47:36 /IDPLOAD VALUE=0xB0<br />
<br />
15-104-15:49:18 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-104-15:49:25 /IDPLOAD VALUE=0x1A<br />
15-104-15:50:30 /IDPLOAD VALUE=0x1F<br />
15-104-15:52:06 /IDPLOAD VALUE=0x15<br />
<br />
* On May 21 starting at 19:23 UTC we made the next changes on Front Slow threshold:<br />
<br />
15-141-19:25:36 start idib_chg_thrshld (6, FRONT, SLOW, 0x20) --> Was 0x15<br />
15-141-19:25:46 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-141-19:25:47 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-141-19:25:55 /IDPLOAD VALUE=0x20<br />
<br />
* On May 26 we lowered the HV on detector 6 by 30 counts to a value of 1984 V. This change gave detector 6 the lowest voltage of all the detectors. G6 remained segmented through the pass.<br />
<br />
2015-146-19:11:11 /IHVDAC DETECTOR=6, VOLTAGE=103 (1985 V)<br />
<br />
We also increased the rear fast threshold on detector 6 by 0x08<br />
<br />
2015-146-19:13:07 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-146-19:13:25 /IDPLOAD VALUE=0x68 ; was 0x60<br />
<br />
* On 2015 July 7, D6 rear fast threshold was raised due to decreased livetime<br />
<br />
2015-188-18:49:02 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-188-18:49:19 /IDPLOAD VALUE=0x70 ; was 0x68<br />
<br />
* The rear fast threshold was changed on July 13 2015 due to dropping livetime in the rear:<br />
2015-194-16:34:40 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-194-16:34:52 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* The rear fast threshold was changed on July 24 2015 due to low livetime. However, the change probably wasn't needed; the tohban hadn't noticed that a change had already been made a few days ago. The next tohban can reverse the change if desired.<br />
2015-205-17:19:29 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-205-17:19:45 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
* Aug. 24, 2015: Detector 6: Both front and rear fast thresholds were raised again. This successfully brought the livetime up to 75% in the front, but didn't really change anything in the rear. Another attempt was made with the rear fast threshold, but again no change. The slow threshold was also raised, which brought the slow rates down from 200k to 5k.<br />
<br />
2015-236-20:44:59 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-236-20:45:10 /IDPLOAD VALUE=0xD0 ; was 0xB0<br />
<br />
2015-237-00:02:53 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
2015-237-00:03:04 /IDPLOAD VALUE=0x25 ; was 0x20<br />
<br />
2015-236-20:47:27 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-236-20:47:36 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-237-00:04:26 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-237-00:04:34 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
* Detector 6 was showing elevated slow front rates. We made a HV change on August 28, lowering the voltage by 200V. The change made the slow front rates to decrease, but still the detector shows elevated slow front counts. On August 31, the rear fast threshold was raised to increase the detector livetime.<br />
<br />
2015-240-17:32:26 /ihvdac detector=6, voltage=93 (from 1984 to 1789 V)<br />
<br />
2015-243-18:01:47 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-243-18:01:56 /IDPLOAD VALUE=0xE0 ; was 0xD0 <br />
<br />
* The rear fast threshold was changed on Sep 9 2015 due to low livetime.<br />
<br />
2015-252-17:53:05 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-252-17:53:18 /IDPLOAD VALUE=0xF0 ; was 0xF0<br />
<br />
* On September 14 2015 we raised the rear fast threshold on D6 from 0xF0 to 0xFF and on September 15 we raised the RHESSI D6 front slow threshold from 0x25 to 0x30.<br />
<br />
2015-257-17:35:39 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-257-17:35:49 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-258-17:09:29 /IDPUTABLE6 OFFSET=frontslowDAC<br />
2015-258-17:09:38 /IDPLOAD VALUE=0x30 ; was 0x25<br />
<br />
* 2nd October 2015: We increased the front slow thresholds, on detectors G3 and G6. <br />
<br />
15-278-21:29:49 start idib_chg_thrshld(6, FRONT, SLOW, 0x40) ; was 0x30<br />
15-278-21:29:53 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-278-21:29:53 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-278-21:30:03 /IDPLOAD VALUE=0x40<br />
<br />
* 5th October 2015: We increased the front slow thresholds G6<br />
<br />
15-279-00:40:54 start idib_chg_thrshld (6, FRONT, SLOW, 0x50) ; was 0x40<br />
15-279-00:40:58 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-279-00:40:58 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-279-00:41:08 /IDPLOAD VALUE=0x50<br />
<br />
* On October 8, the front fast threshold was raised to try and raise livetime. Prior to these changes, D6 front livetime was at ~20%. As the changes were made on a BGS pass, the D6 front fast rates fell from 100k to 9000, and the front LT rose to 78%, but then worsened a lot the next day, so more action was taken (see next item).<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
* 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.<br />
<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
===D6 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C (after segmentation)<br />
|-<br />
| 2015 Jan 26 21:57:13 UTC || 0x30 (was 0x0C)<br />
|- <br />
| 2015 Jan 27 21:37:03 UTC || 0x0C (was 0x30)<br />
|- <br />
| 2015 Apr 09 21:17:27 UTC || 0x15 (was 0x0C)<br />
|-<br />
| 2015 Apr 14 15:49:25 UTC || 0x1A (was 0x15)<br />
|-<br />
| 2015 Apr 14 15:50:30 UTC || 0x1F (was 0x1A)<br />
|-<br />
| 2015 Apr 14 15:52:06 UTC || 0x15 (was 0x1F)<br />
|-<br />
| 2015 May 21 19:25:36 UTC || 0x20 (was 0x15)<br />
|-<br />
| 2015 Aug 25 00:03:04 UTC || 0x25 (was 0x20)<br />
|-<br />
| 2015 Sep 15 00:17:09 UTC || 0x30 (was 0x25)<br />
|-<br />
| 2015 Oct 02 21:29:49 UTC || 0x40 (was 0x30)<br />
|-<br />
| 2015 Oct 05 00:40:54 UTC || 0x50 (was 0x40)<br />
|-<br />
|}<br />
<br />
===D6 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22 (after segmentation)<br />
|- <br />
| 2015-Jan-30 00:20:17 || 0x30 (was 0x22)<br />
|-<br />
| 2015-Feb-27 21:41:44 || 0x40 (was 0x30)<br />
|-<br />
| 2015-Mar-09 01:27:07 || 0x50 (was 0x40)<br />
|-<br />
| 2015-Mar-13 22:04:22 || 0x60 (was 0x50)<br />
|- <br />
| 2015-Mar-17 20:44:14 || 0x70 (was 0x60)<br />
|- <br />
| 2015-Mar-20 22:52:58 || 0x60 (was 0x70)<br />
|- <br />
| 2015-Mar-20 22:55:19 || 0x50 (was 0x60)<br />
|- <br />
| 2015-Mar-20 22:56:01 || 0x70 (was 0x50)<br />
|- <br />
| 2015-Apr-07 19:57 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Apr-09 17:33 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Apr-14 14:12 || 0xA8 (was 0xA0)<br />
|- <br />
| 2015-Apr-14 15:45 || 0xB0 (was 0xA8)<br />
|- <br />
| 2015-Apr-14 15:46 || 0xB8 (was 0xB0)<br />
|- <br />
| 2015-Apr-14 15:48 || 0xB0 (was 0xB8)<br />
|- <br />
| 2015-Aug-24 20:45:10 || 0xD0 (was 0xB0)<br />
|- <br />
| 2015-Sep-21 19:47:33 || 0xE0 (was 0xD0)<br />
|- <br />
| 2015-Oct-08 21:49:59 || 0xFF (was 0xE0)<br />
|- <br />
|}<br />
<br />
<br />
===D6 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30 (after segmentation)<br />
|}<br />
<br />
===D6 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45 (after segmentation)<br />
|-<br />
| 2015-Jan-08 17:45:18 || 0x50 (was 0x45)<br />
|-<br />
| 2015-Jan-08 17:45:18 || 0x50 (was 0x45)<br />
|- <br />
| 2015-Mar-17 22:05:17 || 0x60 (was 0x50)<br />
|- <br />
| 2015-May-26 19:13:07 || 0x68 (was 0x60)<br />
|- <br />
| 2015-Jul-07 18:49:19 || 0x70 (was 0x68)<br />
|- <br />
| 2015-Jul-13 16:34:52 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Jul-29 17:19:45 || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-Aug-24 20:47:36 || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-Aug-25 00:04:34 || 0xD0 (was 0xC0)<br />
|- <br />
| 2015-Aug-31 18:01:56 || 0xE0 (was 0xD0)<br />
|- <br />
| 2015-Sep-09 17:53:18 || 0xF0 (was 0xE0)<br />
|- <br />
| 2015-Sep-14 17:35:49 || 0xFF (was 0xF0)<br />
|- <br />
|}<br />
<br />
===D6 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 4510 V (unsegmented)<br />
|- <br />
| 2014-Aug-14 03:40 UTC || 4926 V (was 4510 V) (segmented)<br />
|- <br />
| 2015-Mar-20 21:12 UTC || 4500 V (was 4926 V)<br />
|- <br />
| 2015-Mar-20 22:50 UTC || 4142 V (was 4500 V)<br />
|- <br />
| 2015-Mar-25 22:47 UTC || 3750 V (was 4142 V)<br />
|-<br />
| 2015-May-26 19:11 UTC || 1985 V (was 2573 V)<br />
|-<br />
| 2015-Aug-28 17:32 UTC || 1789 V (was 1985 V)<br />
|-<br />
| 2015-Oct-12 21:52:42 UTC || 1593 V (was 1789 V)<br />
|-<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-13T17:52:53Z<p>Lglesener: /* Detector issues */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
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).<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
<br />
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.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
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.<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
<br />
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.<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
<br />
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.<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-13T17:49:46Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
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).<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
<br />
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.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
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.<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
<br />
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. Results: D3 rear fast threshold is maxed, and the LT is still ~0. D1 and D7 rear LTs are at ~62% and ~51%, respectively.<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
<br />
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.<br />
<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-13T17:44:15Z<p>Lglesener: /* Detector issues */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
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).<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
<br />
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.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
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.)<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
<br />
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. <br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
<br />
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.<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-13T17:38:11Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
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.<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
<br />
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.)<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
<br />
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. <br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
<br />
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.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
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.<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_6Detector 62015-10-13T17:37:49Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 6 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 6 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
After the 2014 anneal, detector 6 began its reincarnated life as an unsegmented detector but segmented shortly after (see below).<br />
<br />
<br />
* On 2014 August 14, the HV on D6 was raised to 4926V in an attempt to segment it. This was successful, and D6 now operates as a segmented detector. Since its segmentation is borderline as of Aug/Sept 2014, it commonly unsegments during and just after the SAA.<br />
<br />
* On 2014 Jan 8, the rear fast threshold was raised since fast counts were eating up a lot of livetime.<br />
<br />
15-008-17:44:55 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
15-008-17:45:18 /IDPULOAD VALUE=0x50 ;(was 0x45)<br />
<br />
* * D6 has been showing some strange peaks in the spectrum; these are best seen as multiple lines (that drift) in spectrograms. On Monday, Jan 28 we raised the slow front threshold on D6 to ~10 keV and kept it there for a day before returning to the nominal ~3 keV. This is intended to see if the slow threshold affects the abnormal spectral lines.<br />
15-026-21:57:13 / D6 front slow threshold to 0x30 (was 0x0C).<br />
15-027-21:37:03 / D6 front slow threshold to 0x0C (was 0x30).<br />
<br />
<br />
* D6 fast rates are a bit high (have been rising slowly over the past week). It would be a good idea to raise the front fast threshold a touch. I didn't want to do this at the same time as the slow threshold experiment! <br />
<br />
*D6 front fast threshold was adjusted from default (0x22) due to increased rates, based on the above suggestion. Rates dropped from 3300 to 1250 when the change was made.<br />
15-030-00:19:54 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-030-00:20:17 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* On 2015 February 27 Front Fast threshold was raised <br />
15-058-21:41:11 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-058-21:41:44 /IDPLOAD VALUE=0x40 (was 0x30)<br />
<br />
*Another raise to D6 front fast threshold on 2015 March 9:<br />
15-068-01:26:56 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-068-01:27:07 /IDPLOAD VALUE=0x50<br />
<br />
*On 2015 March 13 another raise was made to D6 front fast threshold and a raise of the rear fast threshold was made:<br />
15-072-22:04:01 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-072-22:04:22 /IDPLOAD VALUE=0x60<br />
<br />
15-072-22:05:07 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
15-072-22:05:17 /IDPLOAD VALUE=0x60<br />
<br />
*Again 2015 March 17 D6 front fast threshold was increased:<br />
15-076-20:44:01 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-076-20:44:14 /IDPLOAD VALUE=0x70<br />
<br />
On 2015 March 20 D6 HV was dropped in two 10 step increments, twice. Also we attempted to lower the front fast threshold to 0x50, but changed this almost immediately when the live time dropped to 3%:<br />
15-079-21:10:49 /IHVDAC DETECTOR=6, VOLTAGE=243<br />
15-079-21:12:47 /IHVDAC DETECTOR=6, VOLTAGE=233<br />
<br />
15-079-22:49:23 /ihvdac detector=6, voltage=223<br />
15-079-22:50:44 /ihvdac detector=6, voltage=213<br />
<br />
15-079-22:52:39 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:52:58 /IDPLOAD VALUE=0x60<br />
<br />
15-079-22:55:07 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:55:19 /IDPLOAD VALUE=0x50<br />
<br />
15-079-22:55:53 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:56:01 /IDPLOAD VALUE=0x70<br />
<br />
On 2015 March 25 D6 HV was dropped in 20 steps. <br />
15-084-22:45:15 /ihvdac detector=6, voltage=203<br />
15-084-22:46:45 /ihvdac detector=6, voltage=193 (3750 V)<br />
<br />
* April 7 2015: the front fast threshold was raised due to high fast rates that were significantly reducing livetime. This helped, but not a lot, so the action will probably be repeated soon.<br />
15-097-19:56:35 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-097-19:56:45 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* April 9 2015: The front fast and the front slow threshold were raised up to recover the livetime and trying to reduce the noise on the slow valid counts.<br />
<br />
15-099-17:32:59 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-099-17:33:11 /IDPLOAD VALUE=0xA0<br />
<br />
15-099-21:17:16 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-099-21:17:27 /IDPLOAD VALUE=0x15<br />
<br />
* On Abril 14 starting at 14:06 UT we made the next changes for detectors 6 trying to decrease valid counts on the Slow Front segment.<br />
<br />
15-104-14:11:57 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-104-14:12:05 /IDPLOAD VALUE=0xA8<br />
15-104-15:45:14 /IDPLOAD VALUE=0xB0<br />
15-104-15:46:24 /IDPLOAD VALUE=0xB8<br />
15-104-15:47:36 /IDPLOAD VALUE=0xB0<br />
<br />
15-104-15:49:18 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-104-15:49:25 /IDPLOAD VALUE=0x1A<br />
15-104-15:50:30 /IDPLOAD VALUE=0x1F<br />
15-104-15:52:06 /IDPLOAD VALUE=0x15<br />
<br />
* On May 21 starting at 19:23 UTC we made the next changes on Front Slow threshold:<br />
<br />
15-141-19:25:36 start idib_chg_thrshld (6, FRONT, SLOW, 0x20) --> Was 0x15<br />
15-141-19:25:46 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-141-19:25:47 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-141-19:25:55 /IDPLOAD VALUE=0x20<br />
<br />
* On May 26 we lowered the HV on detector 6 by 30 counts to a value of 1984 V. This change gave detector 6 the lowest voltage of all the detectors. G6 remained segmented through the pass.<br />
<br />
2015-146-19:11:11 /IHVDAC DETECTOR=6, VOLTAGE=103 (1985 V)<br />
<br />
We also increased the rear fast threshold on detector 6 by 0x08<br />
<br />
2015-146-19:13:07 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-146-19:13:25 /IDPLOAD VALUE=0x68 ; was 0x60<br />
<br />
* On 2015 July 7, D6 rear fast threshold was raised due to decreased livetime<br />
<br />
2015-188-18:49:02 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-188-18:49:19 /IDPLOAD VALUE=0x70 ; was 0x68<br />
<br />
* The rear fast threshold was changed on July 13 2015 due to dropping livetime in the rear:<br />
2015-194-16:34:40 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-194-16:34:52 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* The rear fast threshold was changed on July 24 2015 due to low livetime. However, the change probably wasn't needed; the tohban hadn't noticed that a change had already been made a few days ago. The next tohban can reverse the change if desired.<br />
2015-205-17:19:29 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-205-17:19:45 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
* Aug. 24, 2015: Detector 6: Both front and rear fast thresholds were raised again. This successfully brought the livetime up to 75% in the front, but didn't really change anything in the rear. Another attempt was made with the rear fast threshold, but again no change. The slow threshold was also raised, which brought the slow rates down from 200k to 5k.<br />
<br />
2015-236-20:44:59 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-236-20:45:10 /IDPLOAD VALUE=0xD0 ; was 0xB0<br />
<br />
2015-237-00:02:53 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
2015-237-00:03:04 /IDPLOAD VALUE=0x25 ; was 0x20<br />
<br />
2015-236-20:47:27 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-236-20:47:36 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-237-00:04:26 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-237-00:04:34 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
* Detector 6 was showing elevated slow front rates. We made a HV change on August 28, lowering the voltage by 200V. The change made the slow front rates to decrease, but still the detector shows elevated slow front counts. On August 31, the rear fast threshold was raised to increase the detector livetime.<br />
<br />
2015-240-17:32:26 /ihvdac detector=6, voltage=93 (from 1984 to 1789 V)<br />
<br />
2015-243-18:01:47 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-243-18:01:56 /IDPLOAD VALUE=0xE0 ; was 0xD0 <br />
<br />
* The rear fast threshold was changed on Sep 9 2015 due to low livetime.<br />
<br />
2015-252-17:53:05 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-252-17:53:18 /IDPLOAD VALUE=0xF0 ; was 0xF0<br />
<br />
* On September 14 2015 we raised the rear fast threshold on D6 from 0xF0 to 0xFF and on September 15 we raised the RHESSI D6 front slow threshold from 0x25 to 0x30.<br />
<br />
2015-257-17:35:39 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-257-17:35:49 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-258-17:09:29 /IDPUTABLE6 OFFSET=frontslowDAC<br />
2015-258-17:09:38 /IDPLOAD VALUE=0x30 ; was 0x25<br />
<br />
* 2nd October 2015: We increased the front slow thresholds, on detectors G3 and G6. <br />
<br />
15-278-21:29:49 start idib_chg_thrshld(6, FRONT, SLOW, 0x40) ; was 0x30<br />
15-278-21:29:53 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-278-21:29:53 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-278-21:30:03 /IDPLOAD VALUE=0x40<br />
<br />
* 5th October 2015: We increased the front slow thresholds G6<br />
<br />
15-279-00:40:54 start idib_chg_thrshld (6, FRONT, SLOW, 0x50) ; was 0x40<br />
15-279-00:40:58 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-279-00:40:58 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-279-00:41:08 /IDPLOAD VALUE=0x50<br />
<br />
* On October 8, the front fast threshold was raised to try and raise livetime. Prior to these changes, D6 front livetime was at ~20%. As the changes were made on a BGS pass, the D6 front fast rates fell from 100k to 9000, and the livetimes rose accordingly, so the changes were successful. <br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
* 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.<br />
<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
===D6 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C (after segmentation)<br />
|-<br />
| 2015 Jan 26 21:57:13 UTC || 0x30 (was 0x0C)<br />
|- <br />
| 2015 Jan 27 21:37:03 UTC || 0x0C (was 0x30)<br />
|- <br />
| 2015 Apr 09 21:17:27 UTC || 0x15 (was 0x0C)<br />
|-<br />
| 2015 Apr 14 15:49:25 UTC || 0x1A (was 0x15)<br />
|-<br />
| 2015 Apr 14 15:50:30 UTC || 0x1F (was 0x1A)<br />
|-<br />
| 2015 Apr 14 15:52:06 UTC || 0x15 (was 0x1F)<br />
|-<br />
| 2015 May 21 19:25:36 UTC || 0x20 (was 0x15)<br />
|-<br />
| 2015 Aug 25 00:03:04 UTC || 0x25 (was 0x20)<br />
|-<br />
| 2015 Sep 15 00:17:09 UTC || 0x30 (was 0x25)<br />
|-<br />
| 2015 Oct 02 21:29:49 UTC || 0x40 (was 0x30)<br />
|-<br />
| 2015 Oct 05 00:40:54 UTC || 0x50 (was 0x40)<br />
|-<br />
|}<br />
<br />
===D6 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22 (after segmentation)<br />
|- <br />
| 2015-Jan-30 00:20:17 || 0x30 (was 0x22)<br />
|-<br />
| 2015-Feb-27 21:41:44 || 0x40 (was 0x30)<br />
|-<br />
| 2015-Mar-09 01:27:07 || 0x50 (was 0x40)<br />
|-<br />
| 2015-Mar-13 22:04:22 || 0x60 (was 0x50)<br />
|- <br />
| 2015-Mar-17 20:44:14 || 0x70 (was 0x60)<br />
|- <br />
| 2015-Mar-20 22:52:58 || 0x60 (was 0x70)<br />
|- <br />
| 2015-Mar-20 22:55:19 || 0x50 (was 0x60)<br />
|- <br />
| 2015-Mar-20 22:56:01 || 0x70 (was 0x50)<br />
|- <br />
| 2015-Apr-07 19:57 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Apr-09 17:33 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Apr-14 14:12 || 0xA8 (was 0xA0)<br />
|- <br />
| 2015-Apr-14 15:45 || 0xB0 (was 0xA8)<br />
|- <br />
| 2015-Apr-14 15:46 || 0xB8 (was 0xB0)<br />
|- <br />
| 2015-Apr-14 15:48 || 0xB0 (was 0xB8)<br />
|- <br />
| 2015-Aug-24 20:45:10 || 0xD0 (was 0xB0)<br />
|- <br />
| 2015-Sep-21 19:47:33 || 0xE0 (was 0xD0)<br />
|- <br />
| 2015-Oct-08 21:49:59 || 0xFF (was 0xE0)<br />
|- <br />
|}<br />
<br />
<br />
===D6 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30 (after segmentation)<br />
|}<br />
<br />
===D6 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45 (after segmentation)<br />
|-<br />
| 2015-Jan-08 17:45:18 || 0x50 (was 0x45)<br />
|-<br />
| 2015-Jan-08 17:45:18 || 0x50 (was 0x45)<br />
|- <br />
| 2015-Mar-17 22:05:17 || 0x60 (was 0x50)<br />
|- <br />
| 2015-May-26 19:13:07 || 0x68 (was 0x60)<br />
|- <br />
| 2015-Jul-07 18:49:19 || 0x70 (was 0x68)<br />
|- <br />
| 2015-Jul-13 16:34:52 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Jul-29 17:19:45 || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-Aug-24 20:47:36 || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-Aug-25 00:04:34 || 0xD0 (was 0xC0)<br />
|- <br />
| 2015-Aug-31 18:01:56 || 0xE0 (was 0xD0)<br />
|- <br />
| 2015-Sep-09 17:53:18 || 0xF0 (was 0xE0)<br />
|- <br />
| 2015-Sep-14 17:35:49 || 0xFF (was 0xF0)<br />
|- <br />
|}<br />
<br />
===D6 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 4510 V (unsegmented)<br />
|- <br />
| 2014-Aug-14 03:40 UTC || 4926 V (was 4510 V) (segmented)<br />
|- <br />
| 2015-Mar-20 21:12 UTC || 4500 V (was 4926 V)<br />
|- <br />
| 2015-Mar-20 22:50 UTC || 4142 V (was 4500 V)<br />
|- <br />
| 2015-Mar-25 22:47 UTC || 3750 V (was 4142 V)<br />
|-<br />
| 2015-May-26 19:11 UTC || 1985 V (was 2573 V)<br />
|-<br />
| 2015-Aug-28 17:32 UTC || 1789 V (was 1985 V)<br />
|-<br />
| 2015-Oct-12 21:52:42 UTC || 1593 V (was 1789 V)<br />
|-<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-13T01:05:34Z<p>Lglesener: /* Detector issues */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
On October 7, Detector 3's fast threshold was increased from 0x80 to 0xD0 at 280-22:13:38 UTC. This was due to high fast rates and low livetime in that detector. Results should be checked.<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
<br />
On October 8, 9, and 12, several detector fast thresholds were raised in order to bring down fast rates and thus free up livetime. Prior to these changes, D5 and D6 front livetimes were at ~30% and ~20% respectively, and livetimes were extremely low for D1,3,7 rear. 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. The effects of the rear threshold changes still need to be assessed. Commanding times are below.<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
Note the fast front threshold change to D1 and D7. These 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 raise 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.)<br />
<br />
On October 12, the HV on detector 6 was dropped by 200V. 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. Results should be checked.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
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.<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_7Detector 72015-10-13T01:05:30Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 7 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 7 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
After the 2014 anneal, detector 7 was unsegmented. As of 11-27-2014 it has SEGMENTED<br />
<br />
* A tweak shortly after the anneal was completed:<br />
G7 front slow to 0x80 (was 0x70) after 03:40 on 2014-Aug-14.<br />
<br />
* 11-27-2014. G7 rear slow rates rose and the detector segmented<br />
<br />
* Front Fast and Front Slow thresholds were changed on January 7, 2015 at 14:20 UTC to default values. Front slow is showing very high values on the monitor rates (~900).<br />
G7 front slow to 0x0C (was 0x10) after 14:21 on 2015-Jan-07.<br />
G7 front fast to 0x22 (was 0x2E) after 14:22 on 2015-Jan-07.<br />
<br />
* On Jan 13 2015, we reverted the front slow thresh back to its previous value, because it was suspected that low-energy D7 events were filling up the SSR.<br />
15-013-19:27:21 /IDPUTABLE7 OFFSET=FRONTSLOWDAC<br />
15-013-19:27:36 /IDPULOAD VALUE=0x10 ; increased from 0x0C<br />
15-013-19:28:17 start idpu_dec_active_vigorous<br />
<br />
* The rear fast threshold was changed on July 13 2015 due to dropping livetime in the rear:<br />
2015-194-16:35:07 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-194-16:35:15 /IDPLOAD VALUE=0x50 ; was 0x45<br />
<br />
* The rear fast threshold was changed on July 24 2015 due to low livetime. However, the change probably wasn't needed; the tohban hadn't noticed that a change had already been made a few days ago. The next tohban can reverse the change if desired.<br />
2015-205-17:19:59 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-205-17:20:08 /IDPLOAD VALUE=0x70 ; was 0x60<br />
<br />
* On August 27 D7 rear fast threshold was rasied to increase its livetime.<br />
<br />
2015-239-17:58:24 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-239-17:58:32 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* On October 8, 9, and 12, the rear fast threshold was raised three times to try and raise livetime. Results still need to be assessed.<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
* Also on October 12, the front fast threshold on D7 (and also D1) was raised. This is to try and top off the livetime used in the attenuator logic. It might not work, since the fast rates are not terribly high for this detector, in which case the change could be reversed by a future tohban. Check this and se..<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
===D7 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x70<br />
|- <br />
| 2014-Aug-14 after 03:40 UTC || 0x80 (was 0x70)<br />
|-<br />
| 2014-Dec-4 after 01:09 UTC || 0x10 (was 0x80)<br />
|- <br />
| 2015-Jan-07 after 14:09 UTC || 0x0C (was 0x10)<br />
|-<br />
| 2015-Jan-14 19:27:36 UTC || 0x10 (was 0x0C)<br />
|-<br />
|}<br />
<br />
===D7 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x2E<br />
|- <br />
| 2015-Jan-07 after 14:09 UTC || 0x22 (was 0x2E)<br />
|-<br />
| 2015-May-12 21:01:53 || 0x30 (was 0x22)<br />
|-<br />
| 2015-May-12 21:03:20 || 0x40 (was 0x30)<br />
|- <br />
| 2015-Oct-12 21:50:56 || 0x50 (was 0x40)<br />
|- <br />
|}<br />
<br />
===D7 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D7 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|- <br />
| 2015-Jul-13 16:35:15 || 0x50 (was 0x45)<br />
|- <br />
| 2015-Jul-24 17:20:08 || 0x70 (was 0x60)<br />
|- <br />
| 2015-Aug-27 17:58:32 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Sep-17 06:37:46 || 0x90 (was 0x80)<br />
|- <br />
| 2015-Sep-21 20:10:26 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Oct-08 21:57:39 || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-Oct-09 19:57:41 || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-Oct-12 21:52:03 || 0xD0 (was 0xC0)<br />
|- <br />
|}<br />
<br />
===D7 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 4510 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_1Detector 12015-10-13T01:02:18Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 1 after the 2014 anneal. Detector 1 updates from 2012-mid 2014 can be found here: [[Detector 1 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
Detector 1 is SEGMENTED following the 2014 anneal (yay!)<br />
<br />
* The rear fast threshold was changed on July 13 2015 due to dropping livetime in the rear:<br />
2015-194-16:33:58 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-194-16:34:12 /IDPLOAD VALUE=0x50 ; was 0x45<br />
<br />
* The rear fast threshold was changed on July 24 2015 due to low livetime. However, the change probably wasn't needed; the tohban hadn't noticed that a change had already been made a few days ago. The next tohban can reverse the change if desired.<br />
2015-205-17:18:59 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-205-17:19:08 /IDPLOAD VALUE=0x70 ; was 0x60<br />
<br />
* The rear fast threshold was changed on Sep 9 2015 due to low livetime.<br />
2015-252-17:51:10 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-252-17:51:17 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* On October 8, 9, and 12, the rear fast threshold was raised three times to try and raise livetime. Results still need to be assessed.<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
* Also on October 12, the front fast threshold on D1 (and also D7) was raised. This is to try and top off the livetime used in the attenuator logic. It might not work, since the fast rates are not terribly high for this detector, in which case the change could be reversed by a future tohban. Check this and se..<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
<br />
<br />
<br />
===D1 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C<br />
|}<br />
<br />
===D1 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22<br />
|-<br />
| 2015-May-12 21:01:12 || 0x30 (was 0x22)<br />
|-<br />
| 2015-May-12 21:10:35 || 0x40 (was 0x30)<br />
|- <br />
| 2015-Oct-12 20:17:03 || 0x50 (was 0x40)<br />
|- <br />
|}<br />
<br />
===D1 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D1 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|-<br />
| 2015-Jul-13 16:34:12 || 0x50 (was 0x45)<br />
|- <br />
| 2015-Jul-24 17:19:08 || 0x70 (was 0x60)<br />
|- <br />
| 2015-Sep-9 17:51:17 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Sep-17 06:36:06 || 0x90 (was 0x80)<br />
|- <br />
| 2015-Oct-08 21:50:24 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Oct-09 19:55:58 || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-Oct-12 21:51:37 || 0xC0 (was 0xB0)<br />
|- <br />
|}<br />
<br />
<br />
===D1 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 3995 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_6Detector 62015-10-13T00:58:57Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 6 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 6 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
After the 2014 anneal, detector 6 began its reincarnated life as an unsegmented detector but segmented shortly after (see below).<br />
<br />
<br />
* On 2014 August 14, the HV on D6 was raised to 4926V in an attempt to segment it. This was successful, and D6 now operates as a segmented detector. Since its segmentation is borderline as of Aug/Sept 2014, it commonly unsegments during and just after the SAA.<br />
<br />
* On 2014 Jan 8, the rear fast threshold was raised since fast counts were eating up a lot of livetime.<br />
<br />
15-008-17:44:55 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
15-008-17:45:18 /IDPULOAD VALUE=0x50 ;(was 0x45)<br />
<br />
* * D6 has been showing some strange peaks in the spectrum; these are best seen as multiple lines (that drift) in spectrograms. On Monday, Jan 28 we raised the slow front threshold on D6 to ~10 keV and kept it there for a day before returning to the nominal ~3 keV. This is intended to see if the slow threshold affects the abnormal spectral lines.<br />
15-026-21:57:13 / D6 front slow threshold to 0x30 (was 0x0C).<br />
15-027-21:37:03 / D6 front slow threshold to 0x0C (was 0x30).<br />
<br />
<br />
* D6 fast rates are a bit high (have been rising slowly over the past week). It would be a good idea to raise the front fast threshold a touch. I didn't want to do this at the same time as the slow threshold experiment! <br />
<br />
*D6 front fast threshold was adjusted from default (0x22) due to increased rates, based on the above suggestion. Rates dropped from 3300 to 1250 when the change was made.<br />
15-030-00:19:54 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-030-00:20:17 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* On 2015 February 27 Front Fast threshold was raised <br />
15-058-21:41:11 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-058-21:41:44 /IDPLOAD VALUE=0x40 (was 0x30)<br />
<br />
*Another raise to D6 front fast threshold on 2015 March 9:<br />
15-068-01:26:56 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-068-01:27:07 /IDPLOAD VALUE=0x50<br />
<br />
*On 2015 March 13 another raise was made to D6 front fast threshold and a raise of the rear fast threshold was made:<br />
15-072-22:04:01 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-072-22:04:22 /IDPLOAD VALUE=0x60<br />
<br />
15-072-22:05:07 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
15-072-22:05:17 /IDPLOAD VALUE=0x60<br />
<br />
*Again 2015 March 17 D6 front fast threshold was increased:<br />
15-076-20:44:01 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-076-20:44:14 /IDPLOAD VALUE=0x70<br />
<br />
On 2015 March 20 D6 HV was dropped in two 10 step increments, twice. Also we attempted to lower the front fast threshold to 0x50, but changed this almost immediately when the live time dropped to 3%:<br />
15-079-21:10:49 /IHVDAC DETECTOR=6, VOLTAGE=243<br />
15-079-21:12:47 /IHVDAC DETECTOR=6, VOLTAGE=233<br />
<br />
15-079-22:49:23 /ihvdac detector=6, voltage=223<br />
15-079-22:50:44 /ihvdac detector=6, voltage=213<br />
<br />
15-079-22:52:39 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:52:58 /IDPLOAD VALUE=0x60<br />
<br />
15-079-22:55:07 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:55:19 /IDPLOAD VALUE=0x50<br />
<br />
15-079-22:55:53 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:56:01 /IDPLOAD VALUE=0x70<br />
<br />
On 2015 March 25 D6 HV was dropped in 20 steps. <br />
15-084-22:45:15 /ihvdac detector=6, voltage=203<br />
15-084-22:46:45 /ihvdac detector=6, voltage=193 (3750 V)<br />
<br />
* April 7 2015: the front fast threshold was raised due to high fast rates that were significantly reducing livetime. This helped, but not a lot, so the action will probably be repeated soon.<br />
15-097-19:56:35 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-097-19:56:45 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* April 9 2015: The front fast and the front slow threshold were raised up to recover the livetime and trying to reduce the noise on the slow valid counts.<br />
<br />
15-099-17:32:59 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-099-17:33:11 /IDPLOAD VALUE=0xA0<br />
<br />
15-099-21:17:16 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-099-21:17:27 /IDPLOAD VALUE=0x15<br />
<br />
* On Abril 14 starting at 14:06 UT we made the next changes for detectors 6 trying to decrease valid counts on the Slow Front segment.<br />
<br />
15-104-14:11:57 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-104-14:12:05 /IDPLOAD VALUE=0xA8<br />
15-104-15:45:14 /IDPLOAD VALUE=0xB0<br />
15-104-15:46:24 /IDPLOAD VALUE=0xB8<br />
15-104-15:47:36 /IDPLOAD VALUE=0xB0<br />
<br />
15-104-15:49:18 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-104-15:49:25 /IDPLOAD VALUE=0x1A<br />
15-104-15:50:30 /IDPLOAD VALUE=0x1F<br />
15-104-15:52:06 /IDPLOAD VALUE=0x15<br />
<br />
* On May 21 starting at 19:23 UTC we made the next changes on Front Slow threshold:<br />
<br />
15-141-19:25:36 start idib_chg_thrshld (6, FRONT, SLOW, 0x20) --> Was 0x15<br />
15-141-19:25:46 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-141-19:25:47 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-141-19:25:55 /IDPLOAD VALUE=0x20<br />
<br />
* On May 26 we lowered the HV on detector 6 by 30 counts to a value of 1984 V. This change gave detector 6 the lowest voltage of all the detectors. G6 remained segmented through the pass.<br />
<br />
2015-146-19:11:11 /IHVDAC DETECTOR=6, VOLTAGE=103 (1985 V)<br />
<br />
We also increased the rear fast threshold on detector 6 by 0x08<br />
<br />
2015-146-19:13:07 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-146-19:13:25 /IDPLOAD VALUE=0x68 ; was 0x60<br />
<br />
* On 2015 July 7, D6 rear fast threshold was raised due to decreased livetime<br />
<br />
2015-188-18:49:02 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-188-18:49:19 /IDPLOAD VALUE=0x70 ; was 0x68<br />
<br />
* The rear fast threshold was changed on July 13 2015 due to dropping livetime in the rear:<br />
2015-194-16:34:40 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-194-16:34:52 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* The rear fast threshold was changed on July 24 2015 due to low livetime. However, the change probably wasn't needed; the tohban hadn't noticed that a change had already been made a few days ago. The next tohban can reverse the change if desired.<br />
2015-205-17:19:29 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-205-17:19:45 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
* Aug. 24, 2015: Detector 6: Both front and rear fast thresholds were raised again. This successfully brought the livetime up to 75% in the front, but didn't really change anything in the rear. Another attempt was made with the rear fast threshold, but again no change. The slow threshold was also raised, which brought the slow rates down from 200k to 5k.<br />
<br />
2015-236-20:44:59 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-236-20:45:10 /IDPLOAD VALUE=0xD0 ; was 0xB0<br />
<br />
2015-237-00:02:53 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
2015-237-00:03:04 /IDPLOAD VALUE=0x25 ; was 0x20<br />
<br />
2015-236-20:47:27 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-236-20:47:36 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-237-00:04:26 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-237-00:04:34 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
* Detector 6 was showing elevated slow front rates. We made a HV change on August 28, lowering the voltage by 200V. The change made the slow front rates to decrease, but still the detector shows elevated slow front counts. On August 31, the rear fast threshold was raised to increase the detector livetime.<br />
<br />
2015-240-17:32:26 /ihvdac detector=6, voltage=93 (from 1984 to 1789 V)<br />
<br />
2015-243-18:01:47 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-243-18:01:56 /IDPLOAD VALUE=0xE0 ; was 0xD0 <br />
<br />
* The rear fast threshold was changed on Sep 9 2015 due to low livetime.<br />
<br />
2015-252-17:53:05 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-252-17:53:18 /IDPLOAD VALUE=0xF0 ; was 0xF0<br />
<br />
* On September 14 2015 we raised the rear fast threshold on D6 from 0xF0 to 0xFF and on September 15 we raised the RHESSI D6 front slow threshold from 0x25 to 0x30.<br />
<br />
2015-257-17:35:39 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-257-17:35:49 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-258-17:09:29 /IDPUTABLE6 OFFSET=frontslowDAC<br />
2015-258-17:09:38 /IDPLOAD VALUE=0x30 ; was 0x25<br />
<br />
* 2nd October 2015: We increased the front slow thresholds, on detectors G3 and G6. <br />
<br />
15-278-21:29:49 start idib_chg_thrshld(6, FRONT, SLOW, 0x40) ; was 0x30<br />
15-278-21:29:53 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-278-21:29:53 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-278-21:30:03 /IDPLOAD VALUE=0x40<br />
<br />
* 5th October 2015: We increased the front slow thresholds G6<br />
<br />
15-279-00:40:54 start idib_chg_thrshld (6, FRONT, SLOW, 0x50) ; was 0x40<br />
15-279-00:40:58 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-279-00:40:58 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-279-00:41:08 /IDPLOAD VALUE=0x50<br />
<br />
* On October 8, the front fast threshold was raised to try and raise livetime. Prior to these changes, D6 front livetime was at ~20%. As the changes were made on a BGS pass, the D6 front fast rates fell from 100k to 9000, and the livetimes rose accordingly, so the changes were successful. <br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
* On October 12, the HV on detector 6 was dropped by 200V. 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. Results should be checked.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
<br />
===D6 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C (after segmentation)<br />
|-<br />
| 2015 Jan 26 21:57:13 UTC || 0x30 (was 0x0C)<br />
|- <br />
| 2015 Jan 27 21:37:03 UTC || 0x0C (was 0x30)<br />
|- <br />
| 2015 Apr 09 21:17:27 UTC || 0x15 (was 0x0C)<br />
|-<br />
| 2015 Apr 14 15:49:25 UTC || 0x1A (was 0x15)<br />
|-<br />
| 2015 Apr 14 15:50:30 UTC || 0x1F (was 0x1A)<br />
|-<br />
| 2015 Apr 14 15:52:06 UTC || 0x15 (was 0x1F)<br />
|-<br />
| 2015 May 21 19:25:36 UTC || 0x20 (was 0x15)<br />
|-<br />
| 2015 Aug 25 00:03:04 UTC || 0x25 (was 0x20)<br />
|-<br />
| 2015 Sep 15 00:17:09 UTC || 0x30 (was 0x25)<br />
|-<br />
| 2015 Oct 02 21:29:49 UTC || 0x40 (was 0x30)<br />
|-<br />
| 2015 Oct 05 00:40:54 UTC || 0x50 (was 0x40)<br />
|-<br />
|}<br />
<br />
===D6 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22 (after segmentation)<br />
|- <br />
| 2015-Jan-30 00:20:17 || 0x30 (was 0x22)<br />
|-<br />
| 2015-Feb-27 21:41:44 || 0x40 (was 0x30)<br />
|-<br />
| 2015-Mar-09 01:27:07 || 0x50 (was 0x40)<br />
|-<br />
| 2015-Mar-13 22:04:22 || 0x60 (was 0x50)<br />
|- <br />
| 2015-Mar-17 20:44:14 || 0x70 (was 0x60)<br />
|- <br />
| 2015-Mar-20 22:52:58 || 0x60 (was 0x70)<br />
|- <br />
| 2015-Mar-20 22:55:19 || 0x50 (was 0x60)<br />
|- <br />
| 2015-Mar-20 22:56:01 || 0x70 (was 0x50)<br />
|- <br />
| 2015-Apr-07 19:57 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Apr-09 17:33 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Apr-14 14:12 || 0xA8 (was 0xA0)<br />
|- <br />
| 2015-Apr-14 15:45 || 0xB0 (was 0xA8)<br />
|- <br />
| 2015-Apr-14 15:46 || 0xB8 (was 0xB0)<br />
|- <br />
| 2015-Apr-14 15:48 || 0xB0 (was 0xB8)<br />
|- <br />
| 2015-Aug-24 20:45:10 || 0xD0 (was 0xB0)<br />
|- <br />
| 2015-Sep-21 19:47:33 || 0xE0 (was 0xD0)<br />
|- <br />
| 2015-Oct-08 21:49:59 || 0xFF (was 0xE0)<br />
|- <br />
|}<br />
<br />
<br />
===D6 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30 (after segmentation)<br />
|}<br />
<br />
===D6 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45 (after segmentation)<br />
|-<br />
| 2015-Jan-08 17:45:18 || 0x50 (was 0x45)<br />
|-<br />
| 2015-Jan-08 17:45:18 || 0x50 (was 0x45)<br />
|- <br />
| 2015-Mar-17 22:05:17 || 0x60 (was 0x50)<br />
|- <br />
| 2015-May-26 19:13:07 || 0x68 (was 0x60)<br />
|- <br />
| 2015-Jul-07 18:49:19 || 0x70 (was 0x68)<br />
|- <br />
| 2015-Jul-13 16:34:52 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Jul-29 17:19:45 || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-Aug-24 20:47:36 || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-Aug-25 00:04:34 || 0xD0 (was 0xC0)<br />
|- <br />
| 2015-Aug-31 18:01:56 || 0xE0 (was 0xD0)<br />
|- <br />
| 2015-Sep-09 17:53:18 || 0xF0 (was 0xE0)<br />
|- <br />
| 2015-Sep-14 17:35:49 || 0xFF (was 0xF0)<br />
|- <br />
|}<br />
<br />
===D6 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 4510 V (unsegmented)<br />
|- <br />
| 2014-Aug-14 03:40 UTC || 4926 V (was 4510 V) (segmented)<br />
|- <br />
| 2015-Mar-20 21:12 UTC || 4500 V (was 4926 V)<br />
|- <br />
| 2015-Mar-20 22:50 UTC || 4142 V (was 4500 V)<br />
|- <br />
| 2015-Mar-25 22:47 UTC || 3750 V (was 4142 V)<br />
|-<br />
| 2015-May-26 19:11 UTC || 1985 V (was 2573 V)<br />
|-<br />
| 2015-Aug-28 17:32 UTC || 1789 V (was 1985 V)<br />
|-<br />
| 2015-Oct-12 21:52:42 UTC || 1593 V (was 1789 V)<br />
|-<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-13T00:56:51Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
On October 7, Detector 3's fast threshold was increased from 0x80 to 0xD0 at 280-22:13:38 UTC. This was due to high fast rates and low livetime in that detector. Results should be checked.<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
<br />
On October 8, 9, and 12, several detector fast thresholds were raised in order to bring down fast rates and thus free up livetime. Prior to these changes, D5 and D6 front livetimes were at ~30% and ~20% respectively, and livetimes were extremely low for D1,3,7 rear. 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. The effects of the rear threshold changes still need to be assessed. Commanding times are below.<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-285-20:16:55 /IDPUTABLE1 OFFSET=FRONTFASTDAC<br />
2015-285-20:17:03 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:50:47 /IDPUTABLE7 OFFSET=FRONTFASTDAC<br />
2015-285-21:50:56 /IDPLOAD VALUE=0x50 ; was 0x40<br />
<br />
2015-285-21:51:28 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-285-21:51:37 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-285-21:51:54 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-285-21:52:03 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
Note the fast front threshold change to D1 and D7. These 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 raise 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.)<br />
<br />
On October 12, the HV on detector 6 was dropped by 200V. 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. Results should be checked.<br />
<br />
2015-285-21:52:42 /IHVDAC DETECTOR=6, VOLTAGE=83 ;1593 V (was 1789 V)<br />
<br />
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.<br />
<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_7Detector 72015-10-12T18:58:31Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 7 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 7 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
After the 2014 anneal, detector 7 was unsegmented. As of 11-27-2014 it has SEGMENTED<br />
<br />
* A tweak shortly after the anneal was completed:<br />
G7 front slow to 0x80 (was 0x70) after 03:40 on 2014-Aug-14.<br />
<br />
* 11-27-2014. G7 rear slow rates rose and the detector segmented<br />
<br />
* Front Fast and Front Slow thresholds were changed on January 7, 2015 at 14:20 UTC to default values. Front slow is showing very high values on the monitor rates (~900).<br />
G7 front slow to 0x0C (was 0x10) after 14:21 on 2015-Jan-07.<br />
G7 front fast to 0x22 (was 0x2E) after 14:22 on 2015-Jan-07.<br />
<br />
* On Jan 13 2015, we reverted the front slow thresh back to its previous value, because it was suspected that low-energy D7 events were filling up the SSR.<br />
15-013-19:27:21 /IDPUTABLE7 OFFSET=FRONTSLOWDAC<br />
15-013-19:27:36 /IDPULOAD VALUE=0x10 ; increased from 0x0C<br />
15-013-19:28:17 start idpu_dec_active_vigorous<br />
<br />
* The rear fast threshold was changed on July 13 2015 due to dropping livetime in the rear:<br />
2015-194-16:35:07 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-194-16:35:15 /IDPLOAD VALUE=0x50 ; was 0x45<br />
<br />
* The rear fast threshold was changed on July 24 2015 due to low livetime. However, the change probably wasn't needed; the tohban hadn't noticed that a change had already been made a few days ago. The next tohban can reverse the change if desired.<br />
2015-205-17:19:59 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-205-17:20:08 /IDPLOAD VALUE=0x70 ; was 0x60<br />
<br />
* On August 27 D7 rear fast threshold was rasied to increase its livetime.<br />
<br />
2015-239-17:58:24 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-239-17:58:32 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* On October 8 and again on the 9th, the rear fast threshold was raised to try and raise livetime. Results still need to be assessed.<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
<br />
===D7 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x70<br />
|- <br />
| 2014-Aug-14 after 03:40 UTC || 0x80 (was 0x70)<br />
|-<br />
| 2014-Dec-4 after 01:09 UTC || 0x10 (was 0x80)<br />
|- <br />
| 2015-Jan-07 after 14:09 UTC || 0x0C (was 0x10)<br />
|-<br />
| 2015-Jan-14 19:27:36 UTC || 0x10 (was 0x0C)<br />
|-<br />
|}<br />
<br />
===D7 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x2E<br />
|- <br />
| 2015-Jan-07 after 14:09 UTC || 0x22 (was 0x2E)<br />
|-<br />
| 2015-May-12 21:01:53 || 0x30 (was 0x22)<br />
|-<br />
| 2015-May-12 21:03:20 || 0x40 (was 0x30)<br />
|- <br />
|}<br />
<br />
===D7 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D7 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|- <br />
| 2015-Jul-13 16:35:15 || 0x50 (was 0x45)<br />
|- <br />
| 2015-Jul-24 17:20:08 || 0x70 (was 0x60)<br />
|- <br />
| 2015-Aug-27 17:58:32 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Sep-17 06:37:46 || 0x90 (was 0x80)<br />
|- <br />
| 2015-Sep-21 20:10:26 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Oct-08 21:57:39 || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-Oct-09 19:57:41 || 0xC0 (was 0xB0)<br />
|- <br />
|}<br />
<br />
===D7 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 4510 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_5Detector 52015-10-12T18:57:20Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 5 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 5 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
* After the 2014 anneal, detector 5 is UNSEGMENTED.<br />
<br />
* A tweak shortly after the anneal was completed:<br />
G5 front slow to 0x80 (was 0x70) on 2014 Aug. 14 after 03:40 UTC<br />
<br />
* In late December 2014 some weak signal of segmentation were seen on G5. On January 5, 2015 at 14:57 UTC we set new values for the front fast and front slow thresholds on this detector. We need to keep an eye on its behaviour. Detector 5 is now weakly SEGMENTED.<br />
<br />
G5 front slow to 0x0C (was 0x80) on 2015 Jan. 5 after 14:57 UTC<br />
G5 front fast to 0x2E (was 0x60) on 2015 Jan. 5 after 14:57 UTC<br />
<br />
* On 2014 Jan 8, the rear fast threshold was raised since fast counts were eating up a lot of livetime.<br />
<br />
15-008-17:44:15 /IDPULOAD VALUE=0x50 ;(was 0x45)<br />
<br />
* On 2015 May 26 starting at 19:15:09 we increased the rear fast threshold by 0x08<br />
<br />
2015-146-19:15:09 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-146-19:15:21 /IDPLOAD VALUE=0x58 ; was 0x50<br />
<br />
* Aug. 24, 2015: The rear fast threshold was raised, successfully bringing the livetime up to >75%.<br />
2015-236-20:46:37 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-236-20:46:59 /IDPLOAD VALUE=0x70 ; was 0x58<br />
<br />
* On October 8, the front fast threshold was raised to try and raise livetime. Prior to these changes, D5 front livetime was at ~30%. As the changes were made on a BGS pass, the D5 front fast rates fell from 131k to 2100, and the livetimes rose accordingly, so the changes were successful. <br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
* The rear fast threshold was also raised on Oct. 9, for the usual reason. This worked, bringing the livetime up to >80%, though it's slowly dropped in the days since and might need another boost soon.<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
<br />
<br />
===D5 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x70<br />
|- <br />
| 2014-Aug-14 after 03:40 UTC || 0x80 (was 0x70)<br />
|- <br />
| 2015-Jan-5 after 14:57 UTC || 0x0C (was 0x80)<br />
|- <br />
|}<br />
<br />
===D5 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|- <br />
| 2014-Dec-8 after 20:28 UTC || 0x60 (was 0x30) <br />
|-<br />
| 2015-Jan-5 after 14:57 UTC || 0x2E (was 0x60)<br />
|- <br />
| 2015-Oct-8 21:49:37 UTC || 0x40 (was 0x2E)<br />
|- <br />
|}<br />
<br />
<br />
===D5 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D5 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|-<br />
| 2014-Jan-08 17:44:15 || 0x50 (was 0x45)<br />
|- <br />
| 2015-May-26 19:15:09 || 0x58 (was 0x50)<br />
|- <br />
| 2015-Aug-26 20:46:59 || 0x70 (was 0x58)<br />
|- <br />
| 2015-Sep-21 20:10:04 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Oct-09 23:02:58 || 0x90 (was 0x80)<br />
|- <br />
|}<br />
<br />
===D5 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 4510 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_3Detector 32015-10-12T18:52:57Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 3 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 3 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
Detector 3 is SEGMENTED following the 2014 anneal (yay!)<br />
<br />
* 2014-Aug-26: D3 is suffering a lot from the known light leak problem. This does not affect the quality of the data but greatly reduces livetime at times when light leaks in through the cryostat port. To alleviate this problem, the G3 rear fast threshold was raised from 0x45 to 0x50 at 2014-238-19:22:56 UTC. This didn't seem to fix the problem.<br />
<br />
* Another threshold change b/c of light leak:<br />
14-241-18:34:11 /IDPUTABLE3 REARFASTDAC ;Load address 0x25CC <br />
14-241-18:34:31 /IDPULOAD VALUE=0x60 ;Rear fast from ox50 to 0x60<br />
<br />
* Front Fast threshold increase due to light leak. This lowered fast counts and increased livetime<br />
2015-152-16:58:07 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-152-16:58:16 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* The front fast threshold was increased on July 10 2015 due to low livetime due to high fast rates. This action was effective in raising the livetime.<br />
2015-191-19:20:47 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-191-19:20:58 /IDPLOAD VALUE=0x40 ; was 0x30<br />
<br />
* On Aug 20, 2015 the front fast threshold was raised in order to lower fast rates and free up livetime. This was successful: Livetime rose from ~50% to >90%.<br />
15-232-22:16:08 start idib_chg_thrshld (3, FRONT, FAST, 0x50)<br />
15-232-22:16:30 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-232-22:16:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
15-232-22:16:41 /IDPLOAD VALUE=0x50<br />
<br />
* By Aug 24, 2015 rear livetime was so low that the detector had entered "reverse mode" where fast rates are not fully shown, and so fast threshold changes give the opposite effect to that you might expect. (Light leak shows up as livetime peaks, not valleys, in this mode.) The rear fast threshold was raised in two jumps. The first raise apparently increased fast rates and worsened livetime (due to this "reverse mode") but the second raise was successful in bringing down the fast rates and restoring livetime to ~64%.<br />
2015-236-20:45:42 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-236-20:45:54 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
2015-237-00:03:38 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-237-00:03:48 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
* The front slow count rates were elevated, to try to bring them down we raised the slow front threshold by 0x10 on August 27th. This has an immediate effect lowering the slow front counts by a factor of 2. We also raised the front and rear fast threshold to increase the livetime.<br />
<br />
2015-239-17:57:41 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-239-17:57:50 /IDPLOAD VALUE=0x1C ; was 0x0C<br />
<br />
2015-239-19:33:13 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-239-19:33:23 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-239-21:13:25 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-239-21:13:33 /IDPLOAD VALUE=0x60 ; was 0x50<br />
<br />
*On Sept 14 2015, we raised the rear fast threshold on D3 from 0xA0 to 0xB0, to arrest a live-time decrease. Live time jumped fro 10 to 70%, but was bak to 40% in two days.<br />
<br />
2015-257-17:33:14 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-257-17:33:22 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
* Some threshold changes occurred during the tohban week of Sept 15-22.<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* 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.<br />
<br />
15-276-01:48:22 start idib_chg_thrshld(3, FRONT, SLOW, 0x0C) ; was 0x1C<br />
15-276-01:48:26 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-276-01:48:26 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
15-276-01:48:37 /IDPLOAD VALUE=0x0C<br />
<br />
* 5th October 2015: We increased the front slow thresholds, on detectors G3 and G6. <br />
<br />
15-278-21:28:51 start idib_chg_thrshld(3, FRONT, SLOW, 0x15) ; was 0x0C<br />
15-278-21:28:55 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-278-21:28:55 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
15-278-21:29:13 /IDPLOAD VALUE=0x15<br />
<br />
* On October 7, Detector 3's fast threshold was increased from 0x80 to 0xD0 at 280-22:13:38 UTC. This was due to high fast rates and low livetime in that detector. Results should be checked, **in particular to see if this change was too drastic!**<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
* On October 8 and 9, the rear fast threshold was raised to try and raise livetime. Results still need to be assessed. This threshold is now maxed out.<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
<br />
<br />
===D3 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C<br />
|- <br />
| 2015-08-27 17:57:50 UTC || 0x1C (was 0x0C)<br />
|- <br />
| 2015-09-17 06:35:17 UTC || 0x80 (was 0x1C)<br />
|- <br />
| 2015-09-23 19:24:12 UTC || 0x1C (was 0x80)<br />
|- <br />
| 2015-10-03 01:48:22 UTC || 0x0C (was 0x1C)<br />
|-<br />
| 2015-10-05 21:28:51 UTC || 0x15 (was 0x0C)<br />
|- <br />
|}<br />
<br />
===D3 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22<br />
|-<br />
| 2015-06-03 16:58:16 UTC || 0x30 (was 0x22)<br />
|- <br />
| 2015-07-09 19:20:58 UTC || 0x40 (was 0x30)<br />
|- <br />
| 2015-08-20 22:16:41 UTC || 0x50 (was 0x40)<br />
|- <br />
| 2015-08-27 21:13:33 UTC || 0x60 (was 0x50)<br />
|- <br />
| 2015-09-17 06:36:45 UTC || 0x70 (was 0x60)<br />
|- <br />
| 2015-09-22 19:47:12 UTC || 0x80 (was 0x70)<br />
|- <br />
| 2015-10-07 22:13:38 UTC || 0xD0 (was 0x80)<br />
|- <br />
|}<br />
<br />
===D3 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D3 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|- <br />
| 2014-08-26 19:22:56 UTC || 0x50 (was 0x45)<br />
|- <br />
| 2014-08-29 18:33:28 UTC || 0x60 (was 0x50)<br />
|- <br />
| 2015-08-24 20:45:54 UTC || 0x80 (was 0x70)<br />
|- <br />
| 2015-08-25 00:03:48 UTC || 0x90 (was 0x80)<br />
|- <br />
| 2015-08-27 19:33:23 UTC || 0xA0 (was 0x90)<br />
|- <br />
| 2015-09-14 17:33:22 UTC || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-09-17 06:37:06 UTC || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-09-21 20:09:44 UTC || 0xD0 (was 0xC0)<br />
|- <br />
| 2015-10-08 21:57:12 UTC || 0xE0 (was 0xD0)<br />
|- <br />
| 2015-10-08 19:56:18 UTC || 0xF0 (was 0xE0)<br />
|- <br />
| 2015-10-08 23:02:35 UTC || 0xFF (was 0xF0)<br />
|- <br />
|}<br />
<br />
<br />
===D3 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 3995 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_1Detector 12015-10-12T18:50:19Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 1 after the 2014 anneal. Detector 1 updates from 2012-mid 2014 can be found here: [[Detector 1 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
Detector 1 is SEGMENTED following the 2014 anneal (yay!)<br />
<br />
* The rear fast threshold was changed on July 13 2015 due to dropping livetime in the rear:<br />
2015-194-16:33:58 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-194-16:34:12 /IDPLOAD VALUE=0x50 ; was 0x45<br />
<br />
* The rear fast threshold was changed on July 24 2015 due to low livetime. However, the change probably wasn't needed; the tohban hadn't noticed that a change had already been made a few days ago. The next tohban can reverse the change if desired.<br />
2015-205-17:18:59 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-205-17:19:08 /IDPLOAD VALUE=0x70 ; was 0x60<br />
<br />
* The rear fast threshold was changed on Sep 9 2015 due to low livetime.<br />
2015-252-17:51:10 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-252-17:51:17 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* On October 8, 9, and 12, the rear fast threshold was raised three times to try and raise livetime. Results still need to be assessed.<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
<br />
===D1 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C<br />
|}<br />
<br />
===D1 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22<br />
|-<br />
| 2015-May-12 21:01:12 || 0x30 (was 0x22)<br />
|-<br />
| 2015-May-12 21:10:35 || 0x40 (was 0x30)<br />
|- <br />
|}<br />
<br />
===D1 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D1 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|-<br />
| 2015-Jul-13 16:34:12 || 0x50 (was 0x45)<br />
|- <br />
| 2015-Jul-24 17:19:08 || 0x70 (was 0x60)<br />
|- <br />
| 2015-Sep-9 17:51:17 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Sep-17 06:36:06 || 0x90 (was 0x80)<br />
|- <br />
| 2015-Oct-08 21:50:24 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Oct-09 19:55:58 || 0xB0 (was 0xA0)<br />
|- <br />
|}<br />
<br />
<br />
===D1 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 3995 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-12T18:35:46Z<p>Lglesener: /* Detector issues */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
On October 7, Detector 3's fast threshold was increased from 0x80 to 0xD0 at 280-22:13:38 UTC. This was due to high fast rates and low livetime in that detector. Results should be checked.<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
<br />
On October 8 and 9, several detector fast thresholds were raised in order to bring down fast rates and thus free up livetime. Prior to these changes, D5 and D6 front livetimes were at ~30% and ~20% respectively, and livetimes were extremely low for D1,3,7 rear. 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. The effects of the rear threshold changes still need to be assessed. Commanding times are below.<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-12T18:23:48Z<p>Lglesener: /* Detector issues */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
On October 7, Detector 3's fast threshold was increased from 0x80 to 0xD0 at 280-22:13:38 UTC. This was due to high fast rates and low livetime in that detector. Results should be checked.<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
<br />
On October 8, 9, and 10, several detector fast thresholds were raised in order to bring down fast rates and thus free up livetime. Prior to these changes, D5 and D6 front livetimes were at ~30% and ~20% respectively, and livetimes were extremely low for D1,3,7 rear. 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. The effects of the rear threshold changes still need to be assessed. Commanding times are below.<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:55:48 /IDPUTABLE1 OFFSET=REARFASTDAC <br />
2015-282-19:55:58 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
2015-282-19:56:09 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-19:56:18 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-282-19:56:31 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-282-19:57:41 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-282-23:02:27 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-282-23:02:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-282-23:02:49 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-282-23:02:58 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-09T00:32:05Z<p>Lglesener: /* Detector issues */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
On October 7, Detector 3's fast threshold was increased from 0x80 to 0xD0 at 280-22:13:38 UTC. This was due to high fast rates and low livetime in that detector. Results should be checked.<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
<br />
On October 8, several detector fast thresholds were raised in order to bring down fast rates and thus free up livetime. Prior to these changes, D5 and D6 front livetimes were at ~30% and ~20% respectively, and livetimes were extremely low for D1,3,7 rear. As the changes were made on a BGS pass, 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. The effects of the rear threshold changes still need to be assessed. Commanding times are below.<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_1Detector 12015-10-09T00:32:02Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 1 after the 2014 anneal. Detector 1 updates from 2012-mid 2014 can be found here: [[Detector 1 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
Detector 1 is SEGMENTED following the 2014 anneal (yay!)<br />
<br />
* The rear fast threshold was changed on July 13 2015 due to dropping livetime in the rear:<br />
2015-194-16:33:58 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-194-16:34:12 /IDPLOAD VALUE=0x50 ; was 0x45<br />
<br />
* The rear fast threshold was changed on July 24 2015 due to low livetime. However, the change probably wasn't needed; the tohban hadn't noticed that a change had already been made a few days ago. The next tohban can reverse the change if desired.<br />
2015-205-17:18:59 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-205-17:19:08 /IDPLOAD VALUE=0x70 ; was 0x60<br />
<br />
* The rear fast threshold was changed on Sep 9 2015 due to low livetime.<br />
2015-252-17:51:10 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-252-17:51:17 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* On October 8, the rear fast threshold was raised to try and raise livetime. Results still need to be assessed.<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
<br />
<br />
===D1 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C<br />
|}<br />
<br />
===D1 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22<br />
|-<br />
| 2015-May-12 21:01:12 || 0x30 (was 0x22)<br />
|-<br />
| 2015-May-12 21:10:35 || 0x40 (was 0x30)<br />
|- <br />
|}<br />
<br />
===D1 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D1 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|-<br />
| 2015-Jul-13 16:34:12 || 0x50 (was 0x45)<br />
|- <br />
| 2015-Jul-24 17:19:08 || 0x70 (was 0x60)<br />
|- <br />
| 2015-Sep-9 17:51:17 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Sep-17 06:36:06 || 0x90 (was 0x80)<br />
|- <br />
| 2015-Oct-08 21:50:24 || 0xA0 (was 0x90)<br />
|- <br />
|}<br />
<br />
<br />
===D1 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 3995 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_3Detector 32015-10-09T00:31:11Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 3 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 3 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
Detector 3 is SEGMENTED following the 2014 anneal (yay!)<br />
<br />
* 2014-Aug-26: D3 is suffering a lot from the known light leak problem. This does not affect the quality of the data but greatly reduces livetime at times when light leaks in through the cryostat port. To alleviate this problem, the G3 rear fast threshold was raised from 0x45 to 0x50 at 2014-238-19:22:56 UTC. This didn't seem to fix the problem.<br />
<br />
* Another threshold change b/c of light leak:<br />
14-241-18:34:11 /IDPUTABLE3 REARFASTDAC ;Load address 0x25CC <br />
14-241-18:34:31 /IDPULOAD VALUE=0x60 ;Rear fast from ox50 to 0x60<br />
<br />
* Front Fast threshold increase due to light leak. This lowered fast counts and increased livetime<br />
2015-152-16:58:07 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-152-16:58:16 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* The front fast threshold was increased on July 10 2015 due to low livetime due to high fast rates. This action was effective in raising the livetime.<br />
2015-191-19:20:47 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-191-19:20:58 /IDPLOAD VALUE=0x40 ; was 0x30<br />
<br />
* On Aug 20, 2015 the front fast threshold was raised in order to lower fast rates and free up livetime. This was successful: Livetime rose from ~50% to >90%.<br />
15-232-22:16:08 start idib_chg_thrshld (3, FRONT, FAST, 0x50)<br />
15-232-22:16:30 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-232-22:16:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
15-232-22:16:41 /IDPLOAD VALUE=0x50<br />
<br />
* By Aug 24, 2015 rear livetime was so low that the detector had entered "reverse mode" where fast rates are not fully shown, and so fast threshold changes give the opposite effect to that you might expect. (Light leak shows up as livetime peaks, not valleys, in this mode.) The rear fast threshold was raised in two jumps. The first raise apparently increased fast rates and worsened livetime (due to this "reverse mode") but the second raise was successful in bringing down the fast rates and restoring livetime to ~64%.<br />
2015-236-20:45:42 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-236-20:45:54 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
2015-237-00:03:38 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-237-00:03:48 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
* The front slow count rates were elevated, to try to bring them down we raised the slow front threshold by 0x10 on August 27th. This has an immediate effect lowering the slow front counts by a factor of 2. We also raised the front and rear fast threshold to increase the livetime.<br />
<br />
2015-239-17:57:41 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-239-17:57:50 /IDPLOAD VALUE=0x1C ; was 0x0C<br />
<br />
2015-239-19:33:13 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-239-19:33:23 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-239-21:13:25 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-239-21:13:33 /IDPLOAD VALUE=0x60 ; was 0x50<br />
<br />
*On Sept 14 2015, we raised the rear fast threshold on D3 from 0xA0 to 0xB0, to arrest a live-time decrease. Live time jumped fro 10 to 70%, but was bak to 40% in two days.<br />
<br />
2015-257-17:33:14 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-257-17:33:22 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
* Some threshold changes occurred during the tohban week of Sept 15-22.<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* 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.<br />
<br />
15-276-01:48:22 start idib_chg_thrshld(3, FRONT, SLOW, 0x0C) ; was 0x1C<br />
15-276-01:48:26 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-276-01:48:26 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
15-276-01:48:37 /IDPLOAD VALUE=0x0C<br />
<br />
* 5th October 2015: We increased the front slow thresholds, on detectors G3 and G6. <br />
<br />
15-278-21:28:51 start idib_chg_thrshld(3, FRONT, SLOW, 0x15) ; was 0x0C<br />
15-278-21:28:55 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-278-21:28:55 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
15-278-21:29:13 /IDPLOAD VALUE=0x15<br />
<br />
* On October 7, Detector 3's fast threshold was increased from 0x80 to 0xD0 at 280-22:13:38 UTC. This was due to high fast rates and low livetime in that detector. Results should be checked, **in particular to see if this change was too drastic!**<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
* On October 8, the rear fast threshold was raised to try and raise livetime. Results still need to be assessed.<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
<br />
===D3 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C<br />
|- <br />
| 2015-08-27 17:57:50 UTC || 0x1C (was 0x0C)<br />
|- <br />
| 2015-09-17 06:35:17 UTC || 0x80 (was 0x1C)<br />
|- <br />
| 2015-09-23 19:24:12 UTC || 0x1C (was 0x80)<br />
|- <br />
| 2015-10-03 01:48:22 UTC || 0x0C (was 0x1C)<br />
|-<br />
| 2015-10-05 21:28:51 UTC || 0x15 (was 0x0C)<br />
|- <br />
|}<br />
<br />
===D3 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22<br />
|-<br />
| 2015-06-03 16:58:16 UTC || 0x30 (was 0x22)<br />
|- <br />
| 2015-07-09 19:20:58 UTC || 0x40 (was 0x30)<br />
|- <br />
| 2015-08-20 22:16:41 UTC || 0x50 (was 0x40)<br />
|- <br />
| 2015-08-27 21:13:33 UTC || 0x60 (was 0x50)<br />
|- <br />
| 2015-09-17 06:36:45 UTC || 0x70 (was 0x60)<br />
|- <br />
| 2015-09-22 19:47:12 UTC || 0x80 (was 0x70)<br />
|- <br />
| 2015-10-07 22:13:38 UTC || 0xD0 (was 0x80)<br />
|- <br />
|}<br />
<br />
===D3 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D3 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|- <br />
| 2014-08-26 19:22:56 UTC || 0x50 (was 0x45)<br />
|- <br />
| 2014-08-29 18:33:28 UTC || 0x60 (was 0x50)<br />
|- <br />
| 2015-08-24 20:45:54 UTC || 0x80 (was 0x70)<br />
|- <br />
| 2015-08-25 00:03:48 UTC || 0x90 (was 0x80)<br />
|- <br />
| 2015-08-27 19:33:23 UTC || 0xA0 (was 0x90)<br />
|- <br />
| 2015-09-14 17:33:22 UTC || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-09-17 06:37:06 UTC || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-09-21 20:09:44 UTC || 0xD0 (was 0xC0)<br />
|- <br />
| 2015-10-08 21:57:12 UTC || 0xE0 (was 0xD0)<br />
|- <br />
|}<br />
<br />
<br />
===D3 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 3995 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_5Detector 52015-10-09T00:30:25Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 5 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 5 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
* After the 2014 anneal, detector 5 is UNSEGMENTED.<br />
<br />
* A tweak shortly after the anneal was completed:<br />
G5 front slow to 0x80 (was 0x70) on 2014 Aug. 14 after 03:40 UTC<br />
<br />
* In late December 2014 some weak signal of segmentation were seen on G5. On January 5, 2015 at 14:57 UTC we set new values for the front fast and front slow thresholds on this detector. We need to keep an eye on its behaviour. Detector 5 is now weakly SEGMENTED.<br />
<br />
G5 front slow to 0x0C (was 0x80) on 2015 Jan. 5 after 14:57 UTC<br />
G5 front fast to 0x2E (was 0x60) on 2015 Jan. 5 after 14:57 UTC<br />
<br />
* On 2014 Jan 8, the rear fast threshold was raised since fast counts were eating up a lot of livetime.<br />
<br />
15-008-17:44:15 /IDPULOAD VALUE=0x50 ;(was 0x45)<br />
<br />
* On 2015 May 26 starting at 19:15:09 we increased the rear fast threshold by 0x08<br />
<br />
2015-146-19:15:09 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-146-19:15:21 /IDPLOAD VALUE=0x58 ; was 0x50<br />
<br />
* Aug. 24, 2015: The rear fast threshold was raised, successfully bringing the livetime up to >75%.<br />
2015-236-20:46:37 /IDPUTABLE5 OFFSET=REARFASTDAC<br />
2015-236-20:46:59 /IDPLOAD VALUE=0x70 ; was 0x58<br />
<br />
* On October 8, the front fast threshold was raised to try and raise livetime. Prior to these changes, D5 front livetime was at ~30%. As the changes were made on a BGS pass, the D5 front fast rates fell from 131k to 2100, and the livetimes rose accordingly, so the changes were successful. <br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
<br />
===D5 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x70<br />
|- <br />
| 2014-Aug-14 after 03:40 UTC || 0x80 (was 0x70)<br />
|- <br />
| 2015-Jan-5 after 14:57 UTC || 0x0C (was 0x80)<br />
|- <br />
|}<br />
<br />
===D5 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|- <br />
| 2014-Dec-8 after 20:28 UTC || 0x60 (was 0x30) <br />
|-<br />
| 2015-Jan-5 after 14:57 UTC || 0x2E (was 0x60)<br />
|- <br />
| 2015-Oct-8 21:49:37 UTC || 0x40 (was 0x2E)<br />
|- <br />
|}<br />
<br />
<br />
===D5 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D5 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|-<br />
| 2014-Jan-08 17:44:15 || 0x50 (was 0x45)<br />
|- <br />
| 2015-May-26 19:15:09 || 0x58 (was 0x50)<br />
|- <br />
| 2015-Aug-26 20:46:59 || 0x70 (was 0x58)<br />
|- <br />
| 2015-Sep-21 20:10:04 || 0x80 (was 0x70)<br />
|- <br />
|}<br />
<br />
===D5 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 4510 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_6Detector 62015-10-09T00:29:44Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 6 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 6 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
After the 2014 anneal, detector 6 began its reincarnated life as an unsegmented detector but segmented shortly after (see below).<br />
<br />
<br />
* On 2014 August 14, the HV on D6 was raised to 4926V in an attempt to segment it. This was successful, and D6 now operates as a segmented detector. Since its segmentation is borderline as of Aug/Sept 2014, it commonly unsegments during and just after the SAA.<br />
<br />
* On 2014 Jan 8, the rear fast threshold was raised since fast counts were eating up a lot of livetime.<br />
<br />
15-008-17:44:55 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
15-008-17:45:18 /IDPULOAD VALUE=0x50 ;(was 0x45)<br />
<br />
* * D6 has been showing some strange peaks in the spectrum; these are best seen as multiple lines (that drift) in spectrograms. On Monday, Jan 28 we raised the slow front threshold on D6 to ~10 keV and kept it there for a day before returning to the nominal ~3 keV. This is intended to see if the slow threshold affects the abnormal spectral lines.<br />
15-026-21:57:13 / D6 front slow threshold to 0x30 (was 0x0C).<br />
15-027-21:37:03 / D6 front slow threshold to 0x0C (was 0x30).<br />
<br />
<br />
* D6 fast rates are a bit high (have been rising slowly over the past week). It would be a good idea to raise the front fast threshold a touch. I didn't want to do this at the same time as the slow threshold experiment! <br />
<br />
*D6 front fast threshold was adjusted from default (0x22) due to increased rates, based on the above suggestion. Rates dropped from 3300 to 1250 when the change was made.<br />
15-030-00:19:54 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-030-00:20:17 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* On 2015 February 27 Front Fast threshold was raised <br />
15-058-21:41:11 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-058-21:41:44 /IDPLOAD VALUE=0x40 (was 0x30)<br />
<br />
*Another raise to D6 front fast threshold on 2015 March 9:<br />
15-068-01:26:56 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-068-01:27:07 /IDPLOAD VALUE=0x50<br />
<br />
*On 2015 March 13 another raise was made to D6 front fast threshold and a raise of the rear fast threshold was made:<br />
15-072-22:04:01 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-072-22:04:22 /IDPLOAD VALUE=0x60<br />
<br />
15-072-22:05:07 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
15-072-22:05:17 /IDPLOAD VALUE=0x60<br />
<br />
*Again 2015 March 17 D6 front fast threshold was increased:<br />
15-076-20:44:01 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-076-20:44:14 /IDPLOAD VALUE=0x70<br />
<br />
On 2015 March 20 D6 HV was dropped in two 10 step increments, twice. Also we attempted to lower the front fast threshold to 0x50, but changed this almost immediately when the live time dropped to 3%:<br />
15-079-21:10:49 /IHVDAC DETECTOR=6, VOLTAGE=243<br />
15-079-21:12:47 /IHVDAC DETECTOR=6, VOLTAGE=233<br />
<br />
15-079-22:49:23 /ihvdac detector=6, voltage=223<br />
15-079-22:50:44 /ihvdac detector=6, voltage=213<br />
<br />
15-079-22:52:39 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:52:58 /IDPLOAD VALUE=0x60<br />
<br />
15-079-22:55:07 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:55:19 /IDPLOAD VALUE=0x50<br />
<br />
15-079-22:55:53 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-079-22:56:01 /IDPLOAD VALUE=0x70<br />
<br />
On 2015 March 25 D6 HV was dropped in 20 steps. <br />
15-084-22:45:15 /ihvdac detector=6, voltage=203<br />
15-084-22:46:45 /ihvdac detector=6, voltage=193 (3750 V)<br />
<br />
* April 7 2015: the front fast threshold was raised due to high fast rates that were significantly reducing livetime. This helped, but not a lot, so the action will probably be repeated soon.<br />
15-097-19:56:35 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-097-19:56:45 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* April 9 2015: The front fast and the front slow threshold were raised up to recover the livetime and trying to reduce the noise on the slow valid counts.<br />
<br />
15-099-17:32:59 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-099-17:33:11 /IDPLOAD VALUE=0xA0<br />
<br />
15-099-21:17:16 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-099-21:17:27 /IDPLOAD VALUE=0x15<br />
<br />
* On Abril 14 starting at 14:06 UT we made the next changes for detectors 6 trying to decrease valid counts on the Slow Front segment.<br />
<br />
15-104-14:11:57 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
15-104-14:12:05 /IDPLOAD VALUE=0xA8<br />
15-104-15:45:14 /IDPLOAD VALUE=0xB0<br />
15-104-15:46:24 /IDPLOAD VALUE=0xB8<br />
15-104-15:47:36 /IDPLOAD VALUE=0xB0<br />
<br />
15-104-15:49:18 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-104-15:49:25 /IDPLOAD VALUE=0x1A<br />
15-104-15:50:30 /IDPLOAD VALUE=0x1F<br />
15-104-15:52:06 /IDPLOAD VALUE=0x15<br />
<br />
* On May 21 starting at 19:23 UTC we made the next changes on Front Slow threshold:<br />
<br />
15-141-19:25:36 start idib_chg_thrshld (6, FRONT, SLOW, 0x20) --> Was 0x15<br />
15-141-19:25:46 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-141-19:25:47 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-141-19:25:55 /IDPLOAD VALUE=0x20<br />
<br />
* On May 26 we lowered the HV on detector 6 by 30 counts to a value of 1984 V. This change gave detector 6 the lowest voltage of all the detectors. G6 remained segmented through the pass.<br />
<br />
2015-146-19:11:11 /IHVDAC DETECTOR=6, VOLTAGE=103 (1985 V)<br />
<br />
We also increased the rear fast threshold on detector 6 by 0x08<br />
<br />
2015-146-19:13:07 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-146-19:13:25 /IDPLOAD VALUE=0x68 ; was 0x60<br />
<br />
* On 2015 July 7, D6 rear fast threshold was raised due to decreased livetime<br />
<br />
2015-188-18:49:02 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-188-18:49:19 /IDPLOAD VALUE=0x70 ; was 0x68<br />
<br />
* The rear fast threshold was changed on July 13 2015 due to dropping livetime in the rear:<br />
2015-194-16:34:40 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-194-16:34:52 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* The rear fast threshold was changed on July 24 2015 due to low livetime. However, the change probably wasn't needed; the tohban hadn't noticed that a change had already been made a few days ago. The next tohban can reverse the change if desired.<br />
2015-205-17:19:29 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-205-17:19:45 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
* Aug. 24, 2015: Detector 6: Both front and rear fast thresholds were raised again. This successfully brought the livetime up to 75% in the front, but didn't really change anything in the rear. Another attempt was made with the rear fast threshold, but again no change. The slow threshold was also raised, which brought the slow rates down from 200k to 5k.<br />
<br />
2015-236-20:44:59 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-236-20:45:10 /IDPLOAD VALUE=0xD0 ; was 0xB0<br />
<br />
2015-237-00:02:53 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
2015-237-00:03:04 /IDPLOAD VALUE=0x25 ; was 0x20<br />
<br />
2015-236-20:47:27 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-236-20:47:36 /IDPLOAD VALUE=0xC0 ; was 0xB0<br />
<br />
2015-237-00:04:26 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-237-00:04:34 /IDPLOAD VALUE=0xD0 ; was 0xC0<br />
<br />
* Detector 6 was showing elevated slow front rates. We made a HV change on August 28, lowering the voltage by 200V. The change made the slow front rates to decrease, but still the detector shows elevated slow front counts. On August 31, the rear fast threshold was raised to increase the detector livetime.<br />
<br />
2015-240-17:32:26 /ihvdac detector=6, voltage=93 (from 1984 to 1789 V)<br />
<br />
2015-243-18:01:47 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-243-18:01:56 /IDPLOAD VALUE=0xE0 ; was 0xD0 <br />
<br />
* The rear fast threshold was changed on Sep 9 2015 due to low livetime.<br />
<br />
2015-252-17:53:05 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-252-17:53:18 /IDPLOAD VALUE=0xF0 ; was 0xF0<br />
<br />
* On September 14 2015 we raised the rear fast threshold on D6 from 0xF0 to 0xFF and on September 15 we raised the RHESSI D6 front slow threshold from 0x25 to 0x30.<br />
<br />
2015-257-17:35:39 /IDPUTABLE6 OFFSET=REARFASTDAC<br />
2015-257-17:35:49 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
<br />
2015-258-17:09:29 /IDPUTABLE6 OFFSET=frontslowDAC<br />
2015-258-17:09:38 /IDPLOAD VALUE=0x30 ; was 0x25<br />
<br />
* 2nd October 2015: We increased the front slow thresholds, on detectors G3 and G6. <br />
<br />
15-278-21:29:49 start idib_chg_thrshld(6, FRONT, SLOW, 0x40) ; was 0x30<br />
15-278-21:29:53 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-278-21:29:53 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-278-21:30:03 /IDPLOAD VALUE=0x40<br />
<br />
* 5th October 2015: We increased the front slow thresholds G6<br />
<br />
15-279-00:40:54 start idib_chg_thrshld (6, FRONT, SLOW, 0x50) ; was 0x40<br />
15-279-00:40:58 /IDPUDUMPTABL TABLE=DIBTBL6<br />
15-279-00:40:58 /IDPUTABLE6 OFFSET=FRONTSLOWDAC<br />
15-279-00:41:08 /IDPLOAD VALUE=0x50<br />
<br />
* On October 8, the front fast threshold was raised to try and raise livetime. Prior to these changes, D6 front livetime was at ~20%. As the changes were made on a BGS pass, the D6 front fast rates fell from 100k to 9000, and the livetimes rose accordingly, so the changes were successful. <br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
<br />
===D6 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C (after segmentation)<br />
|-<br />
| 2015 Jan 26 21:57:13 UTC || 0x30 (was 0x0C)<br />
|- <br />
| 2015 Jan 27 21:37:03 UTC || 0x0C (was 0x30)<br />
|- <br />
| 2015 Apr 09 21:17:27 UTC || 0x15 (was 0x0C)<br />
|-<br />
| 2015 Apr 14 15:49:25 UTC || 0x1A (was 0x15)<br />
|-<br />
| 2015 Apr 14 15:50:30 UTC || 0x1F (was 0x1A)<br />
|-<br />
| 2015 Apr 14 15:52:06 UTC || 0x15 (was 0x1F)<br />
|-<br />
| 2015 May 21 19:25:36 UTC || 0x20 (was 0x15)<br />
|-<br />
| 2015 Aug 25 00:03:04 UTC || 0x25 (was 0x20)<br />
|-<br />
| 2015 Sep 15 00:17:09 UTC || 0x30 (was 0x25)<br />
|-<br />
| 2015 Oct 02 21:29:49 UTC || 0x40 (was 0x30)<br />
|-<br />
| 2015 Oct 05 00:40:54 UTC || 0x50 (was 0x40)<br />
|-<br />
|}<br />
<br />
===D6 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22 (after segmentation)<br />
|- <br />
| 2015-Jan-30 00:20:17 || 0x30 (was 0x22)<br />
|-<br />
| 2015-Feb-27 21:41:44 || 0x40 (was 0x30)<br />
|-<br />
| 2015-Mar-09 01:27:07 || 0x50 (was 0x40)<br />
|-<br />
| 2015-Mar-13 22:04:22 || 0x60 (was 0x50)<br />
|- <br />
| 2015-Mar-17 20:44:14 || 0x70 (was 0x60)<br />
|- <br />
| 2015-Mar-20 22:52:58 || 0x60 (was 0x70)<br />
|- <br />
| 2015-Mar-20 22:55:19 || 0x50 (was 0x60)<br />
|- <br />
| 2015-Mar-20 22:56:01 || 0x70 (was 0x50)<br />
|- <br />
| 2015-Apr-07 19:57 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Apr-09 17:33 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Apr-14 14:12 || 0xA8 (was 0xA0)<br />
|- <br />
| 2015-Apr-14 15:45 || 0xB0 (was 0xA8)<br />
|- <br />
| 2015-Apr-14 15:46 || 0xB8 (was 0xB0)<br />
|- <br />
| 2015-Apr-14 15:48 || 0xB0 (was 0xB8)<br />
|- <br />
| 2015-Aug-24 20:45:10 || 0xD0 (was 0xB0)<br />
|- <br />
| 2015-Sep-21 19:47:33 || 0xE0 (was 0xD0)<br />
|- <br />
| 2015-Oct-08 21:49:59 || 0xFF (was 0xE0)<br />
|- <br />
|}<br />
<br />
<br />
===D6 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30 (after segmentation)<br />
|}<br />
<br />
===D6 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45 (after segmentation)<br />
|-<br />
| 2015-Jan-08 17:45:18 || 0x50 (was 0x45)<br />
|-<br />
| 2015-Jan-08 17:45:18 || 0x50 (was 0x45)<br />
|- <br />
| 2015-Mar-17 22:05:17 || 0x60 (was 0x50)<br />
|- <br />
| 2015-May-26 19:13:07 || 0x68 (was 0x60)<br />
|- <br />
| 2015-Jul-07 18:49:19 || 0x70 (was 0x68)<br />
|- <br />
| 2015-Jul-13 16:34:52 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Jul-29 17:19:45 || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-Aug-24 20:47:36 || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-Aug-25 00:04:34 || 0xD0 (was 0xC0)<br />
|- <br />
| 2015-Aug-31 18:01:56 || 0xE0 (was 0xD0)<br />
|- <br />
| 2015-Sep-09 17:53:18 || 0xF0 (was 0xE0)<br />
|- <br />
| 2015-Sep-14 17:35:49 || 0xFF (was 0xF0)<br />
|- <br />
|}<br />
<br />
===D6 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 4510 V (unsegmented)<br />
|- <br />
| 2014-Aug-14 03:40 UTC || 4926 V (was 4510 V) (segmented)<br />
|- <br />
| 2015-Mar-20 21:12 UTC || 4500 V (was 4926 V)<br />
|- <br />
| 2015-Mar-20 22:50 UTC || 4142 V (was 4500 V)<br />
|- <br />
| 2015-Mar-25 22:47 UTC || 3750 V (was 4142 V)<br />
|-<br />
| 2015-May-26 19:11 UTC || 1985 V (was 2573 V)<br />
|-<br />
| 2015-Aug-28 17:32 UTC || 1789 V (was 1985 V)<br />
|-<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_7Detector 72015-10-09T00:28:58Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 7 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 7 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
After the 2014 anneal, detector 7 was unsegmented. As of 11-27-2014 it has SEGMENTED<br />
<br />
* A tweak shortly after the anneal was completed:<br />
G7 front slow to 0x80 (was 0x70) after 03:40 on 2014-Aug-14.<br />
<br />
* 11-27-2014. G7 rear slow rates rose and the detector segmented<br />
<br />
* Front Fast and Front Slow thresholds were changed on January 7, 2015 at 14:20 UTC to default values. Front slow is showing very high values on the monitor rates (~900).<br />
G7 front slow to 0x0C (was 0x10) after 14:21 on 2015-Jan-07.<br />
G7 front fast to 0x22 (was 0x2E) after 14:22 on 2015-Jan-07.<br />
<br />
* On Jan 13 2015, we reverted the front slow thresh back to its previous value, because it was suspected that low-energy D7 events were filling up the SSR.<br />
15-013-19:27:21 /IDPUTABLE7 OFFSET=FRONTSLOWDAC<br />
15-013-19:27:36 /IDPULOAD VALUE=0x10 ; increased from 0x0C<br />
15-013-19:28:17 start idpu_dec_active_vigorous<br />
<br />
* The rear fast threshold was changed on July 13 2015 due to dropping livetime in the rear:<br />
2015-194-16:35:07 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-194-16:35:15 /IDPLOAD VALUE=0x50 ; was 0x45<br />
<br />
* The rear fast threshold was changed on July 24 2015 due to low livetime. However, the change probably wasn't needed; the tohban hadn't noticed that a change had already been made a few days ago. The next tohban can reverse the change if desired.<br />
2015-205-17:19:59 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-205-17:20:08 /IDPLOAD VALUE=0x70 ; was 0x60<br />
<br />
* On August 27 D7 rear fast threshold was rasied to increase its livetime.<br />
<br />
2015-239-17:58:24 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-239-17:58:32 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* On October 8, the rear fast threshold was raised to try and raise livetime. Results still need to be assessed.<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
<br />
===D7 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x70<br />
|- <br />
| 2014-Aug-14 after 03:40 UTC || 0x80 (was 0x70)<br />
|-<br />
| 2014-Dec-4 after 01:09 UTC || 0x10 (was 0x80)<br />
|- <br />
| 2015-Jan-07 after 14:09 UTC || 0x0C (was 0x10)<br />
|-<br />
| 2015-Jan-14 19:27:36 UTC || 0x10 (was 0x0C)<br />
|-<br />
|}<br />
<br />
===D7 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x2E<br />
|- <br />
| 2015-Jan-07 after 14:09 UTC || 0x22 (was 0x2E)<br />
|-<br />
| 2015-May-12 21:01:53 || 0x30 (was 0x22)<br />
|-<br />
| 2015-May-12 21:03:20 || 0x40 (was 0x30)<br />
|- <br />
|}<br />
<br />
===D7 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D7 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|- <br />
| 2015-Jul-13 16:35:15 || 0x50 (was 0x45)<br />
|- <br />
| 2015-Jul-24 17:20:08 || 0x70 (was 0x60)<br />
|- <br />
| 2015-Aug-27 17:58:32 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Sep-17 06:37:46 || 0x90 (was 0x80)<br />
|- <br />
| 2015-Sep-21 20:10:26 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Oct-08 21:57:39 || 0xB0 (was 0xA0)<br />
|- <br />
|}<br />
<br />
===D7 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 4510 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_3Detector 32015-10-09T00:21:47Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 3 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 3 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
Detector 3 is SEGMENTED following the 2014 anneal (yay!)<br />
<br />
* 2014-Aug-26: D3 is suffering a lot from the known light leak problem. This does not affect the quality of the data but greatly reduces livetime at times when light leaks in through the cryostat port. To alleviate this problem, the G3 rear fast threshold was raised from 0x45 to 0x50 at 2014-238-19:22:56 UTC. This didn't seem to fix the problem.<br />
<br />
* Another threshold change b/c of light leak:<br />
14-241-18:34:11 /IDPUTABLE3 REARFASTDAC ;Load address 0x25CC <br />
14-241-18:34:31 /IDPULOAD VALUE=0x60 ;Rear fast from ox50 to 0x60<br />
<br />
* Front Fast threshold increase due to light leak. This lowered fast counts and increased livetime<br />
2015-152-16:58:07 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-152-16:58:16 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* The front fast threshold was increased on July 10 2015 due to low livetime due to high fast rates. This action was effective in raising the livetime.<br />
2015-191-19:20:47 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-191-19:20:58 /IDPLOAD VALUE=0x40 ; was 0x30<br />
<br />
* On Aug 20, 2015 the front fast threshold was raised in order to lower fast rates and free up livetime. This was successful: Livetime rose from ~50% to >90%.<br />
15-232-22:16:08 start idib_chg_thrshld (3, FRONT, FAST, 0x50)<br />
15-232-22:16:30 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-232-22:16:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
15-232-22:16:41 /IDPLOAD VALUE=0x50<br />
<br />
* By Aug 24, 2015 rear livetime was so low that the detector had entered "reverse mode" where fast rates are not fully shown, and so fast threshold changes give the opposite effect to that you might expect. (Light leak shows up as livetime peaks, not valleys, in this mode.) The rear fast threshold was raised in two jumps. The first raise apparently increased fast rates and worsened livetime (due to this "reverse mode") but the second raise was successful in bringing down the fast rates and restoring livetime to ~64%.<br />
2015-236-20:45:42 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-236-20:45:54 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
2015-237-00:03:38 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-237-00:03:48 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
* The front slow count rates were elevated, to try to bring them down we raised the slow front threshold by 0x10 on August 27th. This has an immediate effect lowering the slow front counts by a factor of 2. We also raised the front and rear fast threshold to increase the livetime.<br />
<br />
2015-239-17:57:41 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-239-17:57:50 /IDPLOAD VALUE=0x1C ; was 0x0C<br />
<br />
2015-239-19:33:13 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-239-19:33:23 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-239-21:13:25 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-239-21:13:33 /IDPLOAD VALUE=0x60 ; was 0x50<br />
<br />
*On Sept 14 2015, we raised the rear fast threshold on D3 from 0xA0 to 0xB0, to arrest a live-time decrease. Live time jumped fro 10 to 70%, but was bak to 40% in two days.<br />
<br />
2015-257-17:33:14 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-257-17:33:22 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
* Some threshold changes occurred during the tohban week of Sept 15-22.<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* 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.<br />
<br />
15-276-01:48:22 start idib_chg_thrshld(3, FRONT, SLOW, 0x0C) ; was 0x1C<br />
15-276-01:48:26 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-276-01:48:26 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
15-276-01:48:37 /IDPLOAD VALUE=0x0C<br />
<br />
* 5th October 2015: We increased the front slow thresholds, on detectors G3 and G6. <br />
<br />
15-278-21:28:51 start idib_chg_thrshld(3, FRONT, SLOW, 0x15) ; was 0x0C<br />
15-278-21:28:55 /IDPUDUMPTABL TABLE=DIBTBL3<br />
15-278-21:28:55 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
15-278-21:29:13 /IDPLOAD VALUE=0x15<br />
<br />
* On October 7, Detector 3's fast threshold was increased from 0x80 to 0xD0 at 280-22:13:38 UTC. This was due to high fast rates and low livetime in that detector. Results should be checked, **in particular to see if this change was too drastic!**<br />
<br />
2015-280-22:13:30 /IDPUTABLE3 OFFSET=FRONTFASTDAC<br />
2015-280-22:13:38 /IDPLOAD VALUE=0xD0 ; was 0x80<br />
<br />
<br />
===D3 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C<br />
|- <br />
| 2015-08-27 17:57:50 UTC || 0x1C (was 0x0C)<br />
|- <br />
| 2015-09-17 06:35:17 UTC || 0x80 (was 0x1C)<br />
|- <br />
| 2015-09-23 19:24:12 UTC || 0x1C (was 0x80)<br />
|- <br />
| 2015-10-03 01:48:22 UTC || 0x0C (was 0x1C)<br />
|-<br />
| 2015-10-05 21:28:51 UTC || 0x15 (was 0x0C)<br />
|- <br />
|}<br />
<br />
===D3 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22<br />
|-<br />
| 2015-06-03 16:58:16 UTC || 0x30 (was 0x22)<br />
|- <br />
| 2015-07-09 19:20:58 UTC || 0x40 (was 0x30)<br />
|- <br />
| 2015-08-20 22:16:41 UTC || 0x50 (was 0x40)<br />
|- <br />
| 2015-08-27 21:13:33 UTC || 0x60 (was 0x50)<br />
|- <br />
| 2015-09-17 06:36:45 UTC || 0x70 (was 0x60)<br />
|- <br />
| 2015-09-22 19:47:12 UTC || 0x80 (was 0x70)<br />
|- <br />
| 2015-10-07 22:13:38 UTC || 0xD0 (was 0x80)<br />
|- <br />
|}<br />
<br />
===D3 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D3 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|- <br />
| 2014-08-26 19:22:56 UTC || 0x50 (was 0x45)<br />
|- <br />
| 2014-08-29 18:33:28 UTC || 0x60 (was 0x50)<br />
|- <br />
| 2015-08-24 20:45:54 UTC || 0x80 (was 0x70)<br />
|- <br />
| 2015-08-25 00:03:48 UTC || 0x90 (was 0x80)<br />
|- <br />
| 2015-08-27 19:33:23 UTC || 0xA0 (was 0x90)<br />
|- <br />
| 2015-09-14 17:33:22 UTC || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-09-17 06:37:06 UTC || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-09-21 20:09:44 UTC || 0xD0 (was 0xC0)<br />
|- <br />
|}<br />
<br />
===D3 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 3995 V<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-08T22:34:59Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
On October 8, several detector fast thresholds were raised in order to bring down fast rates and thus free up livetime. Prior to these changes, D5 and D6 front livetimes were at ~30% and ~20% respectively, and livetimes were extremely low for D1,3,7 rear. As the changes were made on a BGS pass, 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. The effects of the rear threshold changes still need to be assessed. Commanding times are below.<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
<br />
<br />
== Attenuator Issues ==<br />
<br />
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%.<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-10-14Tohban Report 2015-10-142015-10-08T22:30:57Z<p>Lglesener: Created page with " {{Infobox Tohban Report| |start_date = 30 Sep 2015 |end_date = 7 Oct 2015 |tohban_name = Lindsay Glesener |tohban_email = glesener@ssl.berkeley.edu |next_tohban = TBD }} == S..."</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 30 Sep 2015<br />
|end_date = 7 Oct 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Temperatures ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
<br />
== Detector issues ==<br />
<br />
On October 8, several detector fast thresholds were raised in order to bring down fast rates and thus free up livetime. Prior to these changes, D5 and D6 front livetimes were at ~30% and ~20% respectively, and livetimes were extremely low for D1,3,7 rear. As the changes were made on a BGS pass, 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. The effects of the rear threshold changes still need to be assessed. Commanding times are below.<br />
<br />
2015-281-21:49:25 /IDPUTABLE5 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:37 /IDPLOAD VALUE=0x40 ; was 0x2E<br />
<br />
2015-281-21:49:49 /IDPUTABLE6 OFFSET=FRONTFASTDAC<br />
2015-281-21:49:59 /IDPLOAD VALUE=0xFF ; was 0xE0<br />
<br />
2015-281-21:50:13 /IDPUTABLE1 OFFSET=REARFASTDAC<br />
2015-281-21:50:24 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-281-21:56:47 /IDPUTABLE3 OFFSET=REARFASTDAC<br />
2015-281-21:57:12 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
2015-281-21:57:30 /IDPUTABLE7 OFFSET=REARFASTDAC<br />
2015-281-21:57:39 /IDPLOAD VALUE=0xB0 ; was 0xA0<br />
<br />
<br />
<br />
== Attenuator Issues ==<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T22:34:00Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = Juan Carlos and Hazel<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
Very active week! There were two active regions (12422 and 12423) that produced many C and M flares. 2423 is now just rotated off (so keep an eye out for awesome occulted events...) and 2422 is a few days away from the west limb. A Major Flare Watch was called a few days ago and is still in effect, so high activity is expected to continue.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 17 47 15 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 10 26 9 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 162 / 79<br />
over the time range 23-Sep-15 30-Sep-15<br />
<br />
== Memory Management ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Temperatures ==<br />
<br />
The cold plate temps have come down a bit, consistent with solar fraction. CP1 = 134.7K, CP2 = 133.1K.<br />
<br />
Brian discussed the temperature trends and the solar fraction trends. He proposes a plan whereby we violate the temperature-power curve for a short time in order to make it into the next two peaks in the sun fraction cycle, when we will presumably stay colder than now. In other words, if we're willing to bend the limits for the cryocooler for a short time (~1 month?), we might stay cold for longer. It's anticipated that we'll drop ~1 degree during the sun fraction peak.<br />
<br />
We also discussed whether it's a good idea to anneal (consensus: at present, no) and what the criteria and parameters of an anneal might be. The idea of annealing at room temperature (which would allow us to turn the cryocooler off entirely, giving it a rest) was brought up. This may be safer for the cryocooler health, but may be less effective reversing radiation damage in the detectors.<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
* It was noticed that Detector 9 ULD events had maxed out in the monitor plots again on Sept. 11. This wasn't noticed because D9 events are still off. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry. The detector remained segmented. The events should be checked to see what the ULD rate actually was before (and after) the HV turndown.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
* Here are plots of the D9 rear resets (proxy for leakage current) around the time of the ULD runaways in August and September. The values are not the same, with the September one being higher. In both plots, the last data point is around the time the ULDs hit max in the monitor rates.<br />
<br />
[[File:D9-resets.png]]<br />
<br />
<br />
== Other notes ==<br />
<br />
The idea was brought up to turn OFF one or multiple detectors (both HV and preamp) in order to save power and thus cooling ability. We could try this initially with D9, since we're not taking events from this detector. But first, we should assess the data from the time when the D9 events were turned back on just prior to the HV drop on the 29th/30th.<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/File:D9-resets.pngFile:D9-resets.png2015-09-30T22:33:32Z<p>Lglesener: </p>
<hr />
<div></div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T22:32:06Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = Juan Carlos and Hazel<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
Very active week! There were two active regions (12422 and 12423) that produced many C and M flares. 2423 is now just rotated off (so keep an eye out for awesome occulted events...) and 2422 is a few days away from the west limb. A Major Flare Watch was called a few days ago and is still in effect, so high activity is expected to continue.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 17 47 15 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 10 26 9 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 162 / 79<br />
over the time range 23-Sep-15 30-Sep-15<br />
<br />
== Memory Management ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Temperatures ==<br />
<br />
The cold plate temps have come down a bit, consistent with solar fraction. CP1 = 134.7K, CP2 = 133.1K.<br />
<br />
Brian discussed the temperature trends and the solar fraction trends. He proposes a plan whereby we violate the temperature-power curve for a short time in order to make it into the next two peaks in the sun fraction cycle, when we will presumably stay colder than now. In other words, if we're willing to bend the limits for the cryocooler for a short time (~1 month?), we might stay cold for longer. It's anticipated that we'll drop ~1 degree during the sun fraction peak.<br />
<br />
We also discussed whether it's a good idea to anneal (consensus: at present, no) and what the criteria and parameters of an anneal might be. The idea of annealing at room temperature (which would allow us to turn the cryocooler off entirely, giving it a rest) was brought up. This may be safer for the cryocooler health, but may be less effective reversing radiation damage in the detectors.<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
* It was noticed that Detector 9 ULD events had maxed out in the monitor plots again on Sept. 11. This wasn't noticed because D9 events are still off. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry. The detector remained segmented. The events should be checked to see what the ULD rate actually was before (and after) the HV turndown.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
* Here are plots of the D9 rear resets (proxy for leakage current) around the time of the ULD runaways in August and September. The values are not the same, with the September one being higher. In both plots, the last data point is around the time the ULDs hit max in the monitor rates.<br />
<br />
[[File:D9-resets.pdf]]<br />
<br />
<br />
== Other notes ==<br />
<br />
The idea was brought up to turn OFF one or multiple detectors (both HV and preamp) in order to save power and thus cooling ability. We could try this initially with D9, since we're not taking events from this detector. But first, we should assess the data from the time when the D9 events were turned back on just prior to the HV drop on the 29th/30th.<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T22:30:26Z<p>Lglesener: /* Temperatures */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
Very active week! There were two active regions (12422 and 12423) that produced many C and M flares. 2423 is now just rotated off (so keep an eye out for awesome occulted events...) and 2422 is a few days away from the west limb. A Major Flare Watch was called a few days ago and is still in effect, so high activity is expected to continue.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 17 47 15 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 10 26 9 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 162 / 79<br />
over the time range 23-Sep-15 30-Sep-15<br />
<br />
== Memory Management ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Temperatures ==<br />
<br />
The cold plate temps have come down a bit, consistent with solar fraction. CP1 = 134.7K, CP2 = 133.1K.<br />
<br />
Brian discussed the temperature trends and the solar fraction trends. He proposes a plan whereby we violate the temperature-power curve for a short time in order to make it into the next two peaks in the sun fraction cycle, when we will presumably stay colder than now. In other words, if we're willing to bend the limits for the cryocooler for a short time (~1 month?), we might stay cold for longer. It's anticipated that we'll drop ~1 degree during the sun fraction peak.<br />
<br />
We also discussed whether it's a good idea to anneal (consensus: at present, no) and what the criteria and parameters of an anneal might be. The idea of annealing at room temperature (which would allow us to turn the cryocooler off entirely, giving it a rest) was brought up. This may be safer for the cryocooler health, but may be less effective reversing radiation damage in the detectors.<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
* It was noticed that Detector 9 ULD events had maxed out in the monitor plots again on Sept. 11. This wasn't noticed because D9 events are still off. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry. The detector remained segmented. The events should be checked to see what the ULD rate actually was before (and after) the HV turndown.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
== Other notes ==<br />
<br />
The idea was brought up to turn OFF one or multiple detectors (both HV and preamp) in order to save power and thus cooling ability. We could try this initially with D9, since we're not taking events from this detector. But first, we should assess the data from the time when the D9 events were turned back on just prior to the HV drop on the 29th/30th.<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_4Detector 42015-09-30T22:26:34Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 4 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 4 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
After the 2014 anneal, detector 4 is UNSEGMENTED.<br />
<br />
* On May 21 starting at 19:24 UTC we raised up the Slow threshold for the Front segment.<br />
<br />
15-141-19:24:10 start idib_chg_thrshld (4, FRONT, SLOW, 0x68) --> Was 0x60<br />
15-141-19:24:22 /IDPUDUMPTABL TABLE=DIBTBL4<br />
15-141-19:24:22 /IDPUTABLE4 OFFSET=FRONTSLOWDAC<br />
15-141-19:24:31 /IDPLOAD VALUE=0x68<br />
<br />
* Raised front fast threshold due to elevated counts. This change reduced counts and increased livetime<br />
2015-152-17:00:18 /IDPUTABLE4 OFFSET=FRONTFASTDAC<br />
2015-152-17:00:31 /IDPLOAD VALUE=0x60 ; was 0x50<br />
<br />
* On 2015 July 7, D4 front fast threshold was raised due to decreased livetime.<br />
2015-188-18:48:17 /IDPUTABLE4 OFFSET=FRONTFASTDAC<br />
2015-188-18:48:34 /IDPLOAD VALUE=0x70 ; was 0x60<br />
<br />
* The front fast threshold was increased on July 10 2015 due to low livetime due to high fast rates. This action was effective in raising the livetime.<br />
2015-191-19:21:17 /IDPUTABLE4 OFFSET=FRONTFASTDAC<br />
2015-191-19:21:25 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* The front fast threshold was increased on July 24 2015 due to low livetime due to high fast rates. This action was effective in raising the livetime, to ~90%.<br />
2015-205-17:22:21 /IDPUTABLE4 OFFSET=FRONTFASTDAC<br />
2015-205-17:22:30 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
* 2015-08-13: Front slow valid threshold was raised by 10 steps; trying to get the slow valid rates down.<br />
2015-225-16:45:08 /IDPUTABLE4 OFFSET=FRONTSLOWDAC<br />
2015-225-16:45:20 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* On Aug 20, 2015 the front fast threshold was raised, in two commands of 16 steps each, in order to lower fast rates and free up livetime. This was successful but probably needs to be repeated. Livetime rose from ~0% to ~50%. The D4 threshold should be raised again to further raise the livetime.<br />
<br />
15-232-22:17:53 start idib_chg_thrshld (4, FRONT, FAST, 0xA0)<br />
15-232-22:18:12 /IDPUDUMPTABL TABLE=DIBTBL4<br />
15-232-22:18:12 /IDPUTABLE4 OFFSET=FRONTFASTDAC<br />
15-232-22:18:25 /IDPLOAD VALUE=0xA0<br />
<br />
15-232-22:19:13 start idib_chg_thrshld (4, FRONT, FAST, 0xB0)<br />
15-232-22:19:23 /IDPUDUMPTABL TABLE=DIBTBL4<br />
15-232-22:19:23 /IDPUTABLE4 OFFSET=FRONTFASTDAC<br />
15-232-22:19:32 /IDPLOAD VALUE=0xB0<br />
<br />
* On Aug 24, 2015 the front fast threshold was raised twice to free up livetime. This was successful. Note that these changes are working, but we're almost out of head room!<br />
2015-236-20:44:08 /IDPUTABLE4 OFFSET=FRONTFASTDAC<br />
2015-236-20:44:22 /IDPLOAD VALUE=0xD0 ; was 0xB0<br />
<br />
2015-237-00:02:14 /IDPUTABLE4 OFFSET=FRONTFASTDAC<br />
2015-237-00:02:22 /IDPLOAD VALUE=0xE0 ; was 0xD0<br />
<br />
* As was discussed during the last meeting, detector 4 showed elevated slow front rates. Following the suggestions of the previous tohban, on August 27 the slow front threshold was increased but no change was observed at all. As the front fast rates were also elevated, a change in the front fast threshold was performed. This change increased its livetimes and the slow front rates, as was expected. Then we decrease D4 HV by 200V, a very conservative value as we would like the detector to segment. However the HV change did not have any impact the front slow rates. The detector remains in the same condition with the slow front threshold at 0xC3. <br />
<br />
2015-239-17:55:53 /IDPUTABLE4 OFFSET=FRONTSLOWDAC<br />
2015-239-17:56:02 /IDPLOAD VALUE=0x90 ; was 0x80<br />
<br />
2015-239-17:56:56 /IDPUTABLE4 OFFSET=FRONTSLOWDAC<br />
2015-239-17:57:05 /IDPLOAD VALUE=0xA0 ; was 0x90<br />
<br />
2015-239-19:34:23 /IDPUTABLE4 OFFSET=FRONTSLOWDAC<br />
2015-239-19:34:32 /IDPLOAD VALUE=0xC0 ; was 0xA0<br />
<br />
2015-239-19:37:01 /IDPUTABLE4 OFFSET=FRONTFASTDAC<br />
2015-239-19:37:09 /IDPLOAD VALUE=0xF0 ; was 0xE0<br />
<br />
2015-239-19:39:38 /IDPUTABLE4 OFFSET=FRONTSLOWDAC<br />
2015-239-19:39:47 /IDPLOAD VALUE=0xC3 ; was 0xC0<br />
<br />
2015-239-21:14:24 /ihvdac detector=4, voltage=226<br />
2015-239-21:15:53 /ihvdac detector=4, voltage=221<br />
<br />
* The front fast threshold was changed on Sep 9 2015 due to low livetime. HV was lowered.<br />
<br />
2015-252-17:50:20 /IDPUTABLE4 OFFSET=FRONTFASTDAC<br />
2015-252-17:50:35 /IDPLOAD VALUE=0xFF ; was 0xF0<br />
2015-252-17:49:33 /IHVDAC DETECTOR=4, VOLTAGE=200 (3898 V)<br />
<br />
* On September 14 2015, HV was lowered again, with no long term effect.<br />
<br />
2015-257-17:36:45 /IHVDAC DETECTOR=4, voltage=185 (3602 V, was 3897 V)<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action MAY need to be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
<br />
===D4 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x50<br />
|-<br />
| 2015 May 21 19:24 UTC || 0x70 (was 0x60)<br />
|-<br />
| 2015 Aug 13 16:45 UTC || 0x80 (was 0x70)<br />
|-<br />
| 2015 Aug 27 17:56:02 UTC || 0x90 (was 0x80)<br />
|-<br />
| 2015 Aug 27 17:57:05 UTC || 0xA0 (was 0x90)<br />
|-<br />
| 2015 Aug 27 19:34:32 UTC || 0xC0 (was 0xA0)<br />
|-<br />
| 2015 Aug 27 19:39:47 UTC || 0xC3 (was 0xC0)<br />
|-<br />
| 2015 Sep 17 06:35:40 UTC || 0xD0 (was 0xC3)<br />
|-<br />
|}<br />
<br />
===D4 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|- <br />
| 2014-Dec-8 after 22:05 UTC || 0x50 (was 0x30)<br />
|-<br />
| 2015-Jun-02 17:00:31 UTC || 0x60 (was 0x50)<br />
|-<br />
| 2015-Jul-07 18:48:34 UTC || 0x70 (was 0x60)<br />
|-<br />
| 2015-Jul-07 19:21:25 UTC || 0x80 (was 0x70)<br />
|-<br />
| 2015-Jul-24 17:22:30 UTC || 0x90 (was 0x80)<br />
|-<br />
| 2015-Aug-20 22:18:25 UTC || 0xA0 (was 0x90)<br />
|-<br />
| 2015-Aug-20 22:19:32 UTC || 0xB0 (was 0xA0)<br />
|-<br />
| 2015-Aug-24 20:44:22 UTC || 0xD0 (was 0xB0)<br />
|-<br />
| 2015-Aug-25 00:02:22 UTC || 0xE0 (was 0xD0)<br />
|-<br />
| 2015-Aug-27 19:37:09 UTC || 0xF0 (was 0xE0)<br />
|-<br />
| 2015-Sep-09 17:50:35 UTC || 0xFF (was 0xF0)<br />
|-<br />
|}<br />
<br />
===D4 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|}<br />
<br />
===D4 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|-<br />
| 2015-Sep-17 06:37:27UTC || 0x55 (was 0x45)<br />
|- <br />
|}<br />
<br />
===D4 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 4510 V<br />
|-<br />
| 2015-Aug-27 21:15:53 UTC || 4289 V (was 4510 V)<br />
|-<br />
| 2015-Sep-09 17:49:33 UTC || 3898 V (was 4289 V)<br />
|-<br />
| 2015-Sep-14 17:36:45 UTC || 3602 V (was 3897 V)<br />
|-<br />
| 2015-Sep-23 19:25:51 UTC || 2598 V (was 3602 V)<br />
|-<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T22:25:13Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
Very active week! There were two active regions (12422 and 12423) that produced many C and M flares. 2423 is now just rotated off (so keep an eye out for awesome occulted events...) and 2422 is a few days away from the west limb. A Major Flare Watch was called a few days ago and is still in effect, so high activity is expected to continue.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 17 47 15 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 10 26 9 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 162 / 79<br />
over the time range 23-Sep-15 30-Sep-15<br />
<br />
== Memory Management ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Temperatures ==<br />
<br />
The cold plate temps have come down a bit, consistent with solar fraction. CP1 = 134.7K, CP2 = 133.1K.<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
* It was noticed that Detector 9 ULD events had maxed out in the monitor plots again on Sept. 11. This wasn't noticed because D9 events are still off. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry. The detector remained segmented. The events should be checked to see what the ULD rate actually was before (and after) the HV turndown.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
== Other notes ==<br />
<br />
The idea was brought up to turn OFF one or multiple detectors (both HV and preamp) in order to save power and thus cooling ability. We could try this initially with D9, since we're not taking events from this detector. But first, we should assess the data from the time when the D9 events were turned back on just prior to the HV drop on the 29th/30th.<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_9Detector 92015-09-30T22:24:53Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 9 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 9 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
Detector 9 is SEGMENTED after the 2014 anneal!<br />
<br />
* 2014 August 20: Due to sporadic noise in D9, the HV was dropped by 20 counts (now at 3600V). Commanding was at 20:57 UTC. This successfully quieted the noise. The noise was mainly fast counts, which cut drastically into the livetime.<br />
<br />
* 2014 October 8: This detector has started to show some periodical spikes during last couple of days. Still is not clear what is their origin. It seems to be periodic with the orbit. So far no action taken.<br />
<br />
* 2014 Oct 31: Elevated noise during the period of Oct 31 - Nov 2. The onset, as well as the abatement was sudden. No commanding was done and the noise returned to regular levels.<br />
<br />
* On 2015 Jan 8, the rear fast threshold was raised since fast counts were eating up a lot of livetime.<br />
<br />
15-008-17:45:50 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-008-17:46:04 /IDPULOAD VALUE=0x50 ;(was 0x45)<br />
<br />
* Rear fast counts are high again, so we raised the rear fast threshold by 16 steps, in two sets of 8, on the BGS pass starting at ~3:30 PST. The new value is 0x60 (was 0x50). Fast rates as eyeballed from the realtime data were approx 58,000 (pre-adjustment), 12,000 (after 8 steps up), and 1600 (after 16 steps up). Livetime percentages were approx 60%, 90%, and 98%, respectively.<br />
<br />
15-021-23:33:58 /idpudumptabl table=dibtbl9<br />
15-021-23:34:03 /idputable9 offset=rearfastdac<br />
15-021-23:34:34 /idpuload value=0x58<br />
<br />
15-021-23:36:47 /idputable9 offset=rearfastdac<br />
15-021-23:36:55 /idpuload value=0x60<br />
<br />
* The rear fast threshold was raised again for the same reasons as the last two adjustments. The threshold was raised in two jumps of hex 8 each.<br />
15-057-18:43:13 /IDPUTABLE9 OFFSET=rearfastDAC<br />
15-057-18:45:14 /IDPLOAD VALUE=0x68<br />
<br />
15-057-20:21:52 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-057-20:22:09 /IDPLOAD VALUE=0x70<br />
<br />
* Rear fast threshold changed again, usual reason.<br />
15-064-19:39:50 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-064-19:40:12 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* And again, on March 11, 2015.<br />
2015-070-22:46:04 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
2015-070-22:46:19 /IDPLOAD VALUE=0x90<br />
<br />
* On March 13, 2015 the rear fast threshold was changed again<br />
15-072-22:06:18 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-072-22:06:31 /IDPLOAD VALUE=0xA0<br />
<br />
* And then again, on March 16, 2015.<br />
15-075-19:24:13 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-075-19:24:28 /IDPLOAD VALUE=0xB0<br />
<br />
* And then again, on March 18, 2015.<br />
15-077-TBD /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-077-TBD /IDPLOAD VALUE=0xC0<br />
<br />
* And again, on March 25, 2015.<br />
15-084-21:07:00 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-084-21:07:14 /IDPLOAD VALUE=0xFF<br />
<br />
* In addition we change the HV on March 25, 2015:<br />
15-084-19:26:07 /ihvdac detector=9, voltage=176<br />
15-084-19:27:17 /ihvdac detector=9, voltage=166<br />
15-084-19:28:33 /ihvdac detector=9, voltage=156<br />
15-084-21:05:17 /ihvdac detector=9, voltage=136 (2622 V)<br />
<br />
* As of early April, detector 9 rear segment is now essentially non functional. Rear fast rates have increased to the point where livetime dropped to zero, and the fast threshold is already turned all the way up so we have no way to control those rates. The front segment appears to be operating normally, though its fast AND slow rates are high (but not worringly so).<br />
<br />
* 2015 April 7: To deal with slightly reduced livetime in the FRONT segment, we changed the front fast threshold. This does NOT seem to have had an effect!!<br />
15-097-19:58:06 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
15-097-19:58:14 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* 2015 April 14: We increase the Front Slow Threshold just to reduce the values on the front slow valid counts<br />
15-104-14:09:00 /IDPUTABLE9 OFFSET=FRONTSLOWDAC<br />
15-104-14:09:12 /IDPLOAD VALUE=0x1A<br />
<br />
* 2015 May 13: D9 front fast was increased <br />
2015-133-19:09:39 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
2015-133-19:09:52 /IDPLOAD VALUE=0x40 ; was 0x30<br />
<br />
* On June 11 2015 the front fast threshold was raised because the fast rates were high and the livetime was low. This action was DID reduce the fast rates but did NOT increase the livetime much! D9 now does not show high fast rates, slow rates, or resets, but yet the livetime is quite low.<br />
<br />
* On August 20 2015 the front fast threshold was raised in an attempt to gain livetime, which was at ~15%. This was unsuccessful.<br />
15-232-22:21:09 start idib_chg_thrshld (9, FRONT, FAST, 0x90)<br />
15-232-22:21:38 /IDPUDUMPTABL TABLE=DIBTBL9<br />
15-232-22:21:38 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
15-232-22:21:46 /IDPLOAD VALUE=0x90<br />
<br />
* On August 20 2015 the rear segment started dumping a huge number of ULD events into the SSR, filling it. Once the problem was pinpointed, D9 events were disabled entirely on the 21st. D9 HV was turned down to 1800V, then 900V, then 800V, in an attempt to bring down the resets. This brought resets down from 30k to 23k and did, indeed, quiet the ULDs. The detector remained segmented. At one point the threshold change to D9 front was reversed to see if that had caused the problem (it hadn't); the threshold change was then re-implemented. Events were turned briefly back on on Aug. 24 and then off, although no danger signs were seen. As of Aug. 25, D9 events are still off. Approximate commanding times are below:<br />
August 21:<br />
1:15 pm PDT: D9 front fast threshold to 0x60 (was 0x90).<br />
2:50 pm PDT: D9 front and rear events disabled.<br />
4:30 pm PDT: HV drop of ~400V, performed in two steps, to 1838V. No change to resets (30k). RTS load to keep D9 events from being re-enabled after eclipse. D9 fast and slow thresholds to max.<br />
6:00 pm PDT: HV drop to ~900V and then again to ~800V. Rear resets before and after are 30k then 25.7k then 23.5k. D9 front fast threshold returned to 0x90.<br />
<br />
* On August 24 2015 D9 events were enabled at 20:42:45 UTC in order to check whether we would still dump too many events into the SSR. The write pointer speed didn't seem to change with this action (although it maybe did change with other detector threshold changes). We left D9 events on, knowing that they'd be turned off again at the next dawn due to the RTS load. As of Aug. 26, D9 events are still off.<br />
2015-236-20:42:45 /itmon value=AFE8 (Detector 9 events turn on)<br />
<br />
* On Sept 9-11, 2015, the rear D9 ULD rose, finally going crazy and maxing out on Sept 11. Since events were off, this wasn't noticed until Sept. 28. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off again at eclipse entry. The ULD event rate should be checked as soon as we get the monitor rate data on it. The detector stayed segmented.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
<br />
<br />
===D9 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C<br />
|-<br />
| 2015 Apr 14 14:09:12 || 0x1A (was 0x0C)<br />
|}<br />
<br />
===D9 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22<br />
|-<br />
| 2015-Apr-07 19:58 || 0x30 (was 0x22)<br />
|- <br />
| 2015-May-13 19:09:52 || 0x40 (was 0x30)<br />
|-<br />
| 2015-Jun-11 20:18:44 || 0x50 (was 0x40)<br />
|-<br />
| 2015-Jul-31 21:42:36 || 0x60 (was 0x50)<br />
|-<br />
| 2015-Aug-20 22:21:46 || 0x90 (was 0x60)<br />
|-<br />
| 2015-Aug-21 ~20:15 || 0x60 (was 0x90)<br />
|-<br />
| 2015-Aug-22 ~01:15 || 0x90 (was 0x60)<br />
|-<br />
|}<br />
<br />
===D9 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|- <br />
| 2015-Aug-22 ~1:15 UTC || 0xFF<br />
|- <br />
|}<br />
<br />
===D9 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|-<br />
| 2015-Jan-08 17:46:04 || 0x50 (was 0x45)<br />
|-<br />
| 2015-Jan-22 23:34:34 || 0x58 (was 0x50)<br />
|-<br />
| 2015-Jan-22 23:36:55 || 0x60 (was 0x58)<br />
|- <br />
| 2015-Feb-27 18:45:14 || 0x68 (was 0x60)<br />
|- <br />
| 2015-Feb-27 20:22:09 || 0x70 (was 0x68)<br />
|- <br />
| 2015-Mar-05 19:40:12 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Mar-11 22:46:19 || 0x90 (was 0x80)<br />
|- <br />
| 2015-Mar-13 22:06:31 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Mar-16 19:24:28 || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-Mar-18 21:52:57 || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-Mar-18 23:32:15 || 0xD0 (was 0xC0)<br />
|- <br />
| 2015-Mar-25 21:07:00 || 0xFF (was 0xD0)<br />
|- <br />
|}<br />
<br />
===D9 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 3995 V<br />
|- <br />
| 2014-Aug-20 || 3603V (was 3995V)<br />
|- <br />
| 2015-Mar-25 || 2622V (was 3603V)<br />
|- <br />
| 2015-Aug-03 || 2230V (was 2622V)<br />
|-<br />
| 2015-Aug-21 || ~2000V (was 2230V)<br />
|-<br />
| 2015-Aug-21 || ~1800V<br />
|-<br />
| 2015-Aug-21 || ~900V<br />
|-<br />
| 2015-Aug-21 || 808V<br />
|-<br />
| 2015-Sep-30 03:01:09 || 490V (was 808V)<br />
|-<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T19:35:54Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
Very active week! There were two active regions (12422 and 12423) that produced many C and M flares. 2423 is now just rotated off (so keep an eye out for awesome occulted events...) and 2422 is a few days away from the west limb. A Major Flare Watch was called a few days ago and is still in effect, so high activity is expected to continue.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 17 47 15 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 10 26 9 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 162 / 79<br />
over the time range 23-Sep-15 30-Sep-15<br />
<br />
== Memory Management ==<br />
<br />
The SSR is a bit high due to high solar activity. '''ADD IN MINMAX!'''<br />
<br />
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.<br />
<br />
== Temperatures ==<br />
<br />
The cold plate temps have come down a bit, consistent with solar fraction. CP1 = 134.7K, CP2 = 133.1K.<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
* It was noticed that Detector 9 ULD events had maxed out in the monitor plots again on Sept. 11. This wasn't noticed because D9 events are still off. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
== Other notes ==<br />
<br />
The idea was brought up to turn OFF one or multiple detectors (both HV and preamp) in order to save power and thus cooling ability. We could try this initially with D9, since we're not taking events from this detector. But first, we should assess the data from the time when the D9 events were turned back on just prior to the HV drop on the 29th/30th.<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T16:38:41Z<p>Lglesener: /* Memory Management */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
Very active week! There were two active regions (12422 and 12423) that produced many C and M flares. 2423 is now just rotated off (so keep an eye out for awesome occulted events...) and 2422 is a few days away from the west limb. A Major Flare Watch was called a few days ago and is still in effect, so high activity is expected to continue.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 17 47 15 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 10 26 9 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 162 / 79<br />
over the time range 23-Sep-15 30-Sep-15<br />
<br />
== Memory Management ==<br />
<br />
The SSR is a bit high due to high solar activity. '''ADD IN MINMAX!'''<br />
<br />
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.<br />
<br />
== Spacecraft Status ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
* It was noticed that Detector 9 ULD events had maxed out in the monitor plots again on Sept. 11. This wasn't noticed because D9 events are still off. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T16:35:53Z<p>Lglesener: /* Solar Activity */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
Very active week! There were two active regions (12422 and 12423) that produced many C and M flares. 2423 is now just rotated off (so keep an eye out for awesome occulted events...) and 2422 is a few days away from the west limb. A Major Flare Watch was called a few days ago and is still in effect, so high activity is expected to continue.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 17 47 15 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 10 26 9 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 162 / 79<br />
over the time range 23-Sep-15 30-Sep-15<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Spacecraft Status ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
* It was noticed that Detector 9 ULD events had maxed out in the monitor plots again on Sept. 11. This wasn't noticed because D9 events are still off. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T16:35:42Z<p>Lglesener: /* Solar Activity */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
Very active week! There were two active regions (12422 and 12423) that produced many C and M flares. 2423 is now just rotated off (so keep an eye out for awesome occulted events...) and 2422 is a few days away from the west limb. A Major Flare Watch was called a few days ago and is still in effect, so high activity is expected to continue.<br />
<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 17 47 15 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 10 26 9 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 162 / 79<br />
over the time range 23-Sep-15 30-Sep-15<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Spacecraft Status ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
* It was noticed that Detector 9 ULD events had maxed out in the monitor plots again on Sept. 11. This wasn't noticed because D9 events are still off. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T16:01:45Z<p>Lglesener: /* Solar Activity */</p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
Very active week! There were two active regions (12422 and 12423) that produced many C and M flares. 2423 is now just rotated off (so keep an eye out for awesome occulted events...) and 2422 is a few days away from the west limb. A Major Flare Watch was called a few days ago and is still in effect, so high activity is expected to continue.<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 17 47 15 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 10 26 9 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 162 / 79<br />
over the time range 23-Sep-15 30-Sep-15<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Spacecraft Status ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
* It was noticed that Detector 9 ULD events had maxed out in the monitor plots again on Sept. 11. This wasn't noticed because D9 events are still off. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T15:58:54Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
How many GOES flares occurred?<br />
Flares above B, C, M, X class were 17 47 15 0<br />
And how many of these are listed in the RHESSI flare list?<br />
Flares above B, C, M, X class were 10 26 9 0<br />
And how many had EXCELLENT coverage?<br />
Flares above B, C, M, X class were 0 0 0 0<br />
<br />
There were RHESSI flares/GOES flares 162 / 79<br />
over the time range 23-Sep-15 30-Sep-15<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Spacecraft Status ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
* It was noticed that Detector 9 ULD events had maxed out in the monitor plots again on Sept. 11. This wasn't noticed because D9 events are still off. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_9Detector 92015-09-30T03:27:04Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 9 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 9 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
Detector 9 is SEGMENTED after the 2014 anneal!<br />
<br />
* 2014 August 20: Due to sporadic noise in D9, the HV was dropped by 20 counts (now at 3600V). Commanding was at 20:57 UTC. This successfully quieted the noise. The noise was mainly fast counts, which cut drastically into the livetime.<br />
<br />
* 2014 October 8: This detector has started to show some periodical spikes during last couple of days. Still is not clear what is their origin. It seems to be periodic with the orbit. So far no action taken.<br />
<br />
* 2014 Oct 31: Elevated noise during the period of Oct 31 - Nov 2. The onset, as well as the abatement was sudden. No commanding was done and the noise returned to regular levels.<br />
<br />
* On 2015 Jan 8, the rear fast threshold was raised since fast counts were eating up a lot of livetime.<br />
<br />
15-008-17:45:50 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-008-17:46:04 /IDPULOAD VALUE=0x50 ;(was 0x45)<br />
<br />
* Rear fast counts are high again, so we raised the rear fast threshold by 16 steps, in two sets of 8, on the BGS pass starting at ~3:30 PST. The new value is 0x60 (was 0x50). Fast rates as eyeballed from the realtime data were approx 58,000 (pre-adjustment), 12,000 (after 8 steps up), and 1600 (after 16 steps up). Livetime percentages were approx 60%, 90%, and 98%, respectively.<br />
<br />
15-021-23:33:58 /idpudumptabl table=dibtbl9<br />
15-021-23:34:03 /idputable9 offset=rearfastdac<br />
15-021-23:34:34 /idpuload value=0x58<br />
<br />
15-021-23:36:47 /idputable9 offset=rearfastdac<br />
15-021-23:36:55 /idpuload value=0x60<br />
<br />
* The rear fast threshold was raised again for the same reasons as the last two adjustments. The threshold was raised in two jumps of hex 8 each.<br />
15-057-18:43:13 /IDPUTABLE9 OFFSET=rearfastDAC<br />
15-057-18:45:14 /IDPLOAD VALUE=0x68<br />
<br />
15-057-20:21:52 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-057-20:22:09 /IDPLOAD VALUE=0x70<br />
<br />
* Rear fast threshold changed again, usual reason.<br />
15-064-19:39:50 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-064-19:40:12 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* And again, on March 11, 2015.<br />
2015-070-22:46:04 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
2015-070-22:46:19 /IDPLOAD VALUE=0x90<br />
<br />
* On March 13, 2015 the rear fast threshold was changed again<br />
15-072-22:06:18 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-072-22:06:31 /IDPLOAD VALUE=0xA0<br />
<br />
* And then again, on March 16, 2015.<br />
15-075-19:24:13 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-075-19:24:28 /IDPLOAD VALUE=0xB0<br />
<br />
* And then again, on March 18, 2015.<br />
15-077-TBD /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-077-TBD /IDPLOAD VALUE=0xC0<br />
<br />
* And again, on March 25, 2015.<br />
15-084-21:07:00 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-084-21:07:14 /IDPLOAD VALUE=0xFF<br />
<br />
* In addition we change the HV on March 25, 2015:<br />
15-084-19:26:07 /ihvdac detector=9, voltage=176<br />
15-084-19:27:17 /ihvdac detector=9, voltage=166<br />
15-084-19:28:33 /ihvdac detector=9, voltage=156<br />
15-084-21:05:17 /ihvdac detector=9, voltage=136 (2622 V)<br />
<br />
* As of early April, detector 9 rear segment is now essentially non functional. Rear fast rates have increased to the point where livetime dropped to zero, and the fast threshold is already turned all the way up so we have no way to control those rates. The front segment appears to be operating normally, though its fast AND slow rates are high (but not worringly so).<br />
<br />
* 2015 April 7: To deal with slightly reduced livetime in the FRONT segment, we changed the front fast threshold. This does NOT seem to have had an effect!!<br />
15-097-19:58:06 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
15-097-19:58:14 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* 2015 April 14: We increase the Front Slow Threshold just to reduce the values on the front slow valid counts<br />
15-104-14:09:00 /IDPUTABLE9 OFFSET=FRONTSLOWDAC<br />
15-104-14:09:12 /IDPLOAD VALUE=0x1A<br />
<br />
* 2015 May 13: D9 front fast was increased <br />
2015-133-19:09:39 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
2015-133-19:09:52 /IDPLOAD VALUE=0x40 ; was 0x30<br />
<br />
* On June 11 2015 the front fast threshold was raised because the fast rates were high and the livetime was low. This action was DID reduce the fast rates but did NOT increase the livetime much! D9 now does not show high fast rates, slow rates, or resets, but yet the livetime is quite low.<br />
<br />
* On August 20 2015 the front fast threshold was raised in an attempt to gain livetime, which was at ~15%. This was unsuccessful.<br />
15-232-22:21:09 start idib_chg_thrshld (9, FRONT, FAST, 0x90)<br />
15-232-22:21:38 /IDPUDUMPTABL TABLE=DIBTBL9<br />
15-232-22:21:38 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
15-232-22:21:46 /IDPLOAD VALUE=0x90<br />
<br />
* On August 20 2015 the rear segment started dumping a huge number of ULD events into the SSR, filling it. Once the problem was pinpointed, D9 events were disabled entirely on the 21st. D9 HV was turned down to 1800V, then 900V, then 800V, in an attempt to bring down the resets. This brought resets down from 30k to 23k and did, indeed, quiet the ULDs. The detector remained segmented. At one point the threshold change to D9 front was reversed to see if that had caused the problem (it hadn't); the threshold change was then re-implemented. Events were turned briefly back on on Aug. 24 and then off, although no danger signs were seen. As of Aug. 25, D9 events are still off. Approximate commanding times are below:<br />
August 21:<br />
1:15 pm PDT: D9 front fast threshold to 0x60 (was 0x90).<br />
2:50 pm PDT: D9 front and rear events disabled.<br />
4:30 pm PDT: HV drop of ~400V, performed in two steps, to 1838V. No change to resets (30k). RTS load to keep D9 events from being re-enabled after eclipse. D9 fast and slow thresholds to max.<br />
6:00 pm PDT: HV drop to ~900V and then again to ~800V. Rear resets before and after are 30k then 25.7k then 23.5k. D9 front fast threshold returned to 0x90.<br />
<br />
* On August 24 2015 D9 events were enabled at 20:42:45 UTC in order to check whether we would still dump too many events into the SSR. The write pointer speed didn't seem to change with this action (although it maybe did change with other detector threshold changes). We left D9 events on, knowing that they'd be turned off again at the next dawn due to the RTS load. As of Aug. 26, D9 events are still off.<br />
2015-236-20:42:45 /itmon value=AFE8 (Detector 9 events turn on)<br />
<br />
* On Sept 9-11, 2015, the rear D9 ULD rose, finally going crazy and maxing out on Sept 11. Since events were off, this wasn't noticed until Sept. 28. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off again at eclipse entry. This should be checked as soon as we get the monitor rate data on it.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
<br />
<br />
===D9 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C<br />
|-<br />
| 2015 Apr 14 14:09:12 || 0x1A (was 0x0C)<br />
|}<br />
<br />
===D9 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22<br />
|-<br />
| 2015-Apr-07 19:58 || 0x30 (was 0x22)<br />
|- <br />
| 2015-May-13 19:09:52 || 0x40 (was 0x30)<br />
|-<br />
| 2015-Jun-11 20:18:44 || 0x50 (was 0x40)<br />
|-<br />
| 2015-Jul-31 21:42:36 || 0x60 (was 0x50)<br />
|-<br />
| 2015-Aug-20 22:21:46 || 0x90 (was 0x60)<br />
|-<br />
| 2015-Aug-21 ~20:15 || 0x60 (was 0x90)<br />
|-<br />
| 2015-Aug-22 ~01:15 || 0x90 (was 0x60)<br />
|-<br />
|}<br />
<br />
===D9 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|- <br />
| 2015-Aug-22 ~1:15 UTC || 0xFF<br />
|- <br />
|}<br />
<br />
===D9 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|-<br />
| 2015-Jan-08 17:46:04 || 0x50 (was 0x45)<br />
|-<br />
| 2015-Jan-22 23:34:34 || 0x58 (was 0x50)<br />
|-<br />
| 2015-Jan-22 23:36:55 || 0x60 (was 0x58)<br />
|- <br />
| 2015-Feb-27 18:45:14 || 0x68 (was 0x60)<br />
|- <br />
| 2015-Feb-27 20:22:09 || 0x70 (was 0x68)<br />
|- <br />
| 2015-Mar-05 19:40:12 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Mar-11 22:46:19 || 0x90 (was 0x80)<br />
|- <br />
| 2015-Mar-13 22:06:31 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Mar-16 19:24:28 || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-Mar-18 21:52:57 || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-Mar-18 23:32:15 || 0xD0 (was 0xC0)<br />
|- <br />
| 2015-Mar-25 21:07:00 || 0xFF (was 0xD0)<br />
|- <br />
|}<br />
<br />
===D9 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 3995 V<br />
|- <br />
| 2014-Aug-20 || 3603V (was 3995V)<br />
|- <br />
| 2015-Mar-25 || 2622V (was 3603V)<br />
|- <br />
| 2015-Aug-03 || 2230V (was 2622V)<br />
|-<br />
| 2015-Aug-21 || ~2000V (was 2230V)<br />
|-<br />
| 2015-Aug-21 || ~1800V<br />
|-<br />
| 2015-Aug-21 || ~900V<br />
|-<br />
| 2015-Aug-21 || 808V<br />
|-<br />
| 2015-Sep-30 03:01:09 || 490V (was 808V)<br />
|-<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Detector_9Detector 92015-09-30T03:25:28Z<p>Lglesener: </p>
<hr />
<div>This page contains information about changes/issues for RHESSI detector 9 after the 2014 anneal. Detector updates from 2012-mid 2014 can be found here: [[Detector 9 anneal 2012]]<br />
<br />
===Notes===<br />
<br />
Detector 9 is SEGMENTED after the 2014 anneal!<br />
<br />
* 2014 August 20: Due to sporadic noise in D9, the HV was dropped by 20 counts (now at 3600V). Commanding was at 20:57 UTC. This successfully quieted the noise. The noise was mainly fast counts, which cut drastically into the livetime.<br />
<br />
* 2014 October 8: This detector has started to show some periodical spikes during last couple of days. Still is not clear what is their origin. It seems to be periodic with the orbit. So far no action taken.<br />
<br />
* 2014 Oct 31: Elevated noise during the period of Oct 31 - Nov 2. The onset, as well as the abatement was sudden. No commanding was done and the noise returned to regular levels.<br />
<br />
* On 2015 Jan 8, the rear fast threshold was raised since fast counts were eating up a lot of livetime.<br />
<br />
15-008-17:45:50 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-008-17:46:04 /IDPULOAD VALUE=0x50 ;(was 0x45)<br />
<br />
* Rear fast counts are high again, so we raised the rear fast threshold by 16 steps, in two sets of 8, on the BGS pass starting at ~3:30 PST. The new value is 0x60 (was 0x50). Fast rates as eyeballed from the realtime data were approx 58,000 (pre-adjustment), 12,000 (after 8 steps up), and 1600 (after 16 steps up). Livetime percentages were approx 60%, 90%, and 98%, respectively.<br />
<br />
15-021-23:33:58 /idpudumptabl table=dibtbl9<br />
15-021-23:34:03 /idputable9 offset=rearfastdac<br />
15-021-23:34:34 /idpuload value=0x58<br />
<br />
15-021-23:36:47 /idputable9 offset=rearfastdac<br />
15-021-23:36:55 /idpuload value=0x60<br />
<br />
* The rear fast threshold was raised again for the same reasons as the last two adjustments. The threshold was raised in two jumps of hex 8 each.<br />
15-057-18:43:13 /IDPUTABLE9 OFFSET=rearfastDAC<br />
15-057-18:45:14 /IDPLOAD VALUE=0x68<br />
<br />
15-057-20:21:52 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-057-20:22:09 /IDPLOAD VALUE=0x70<br />
<br />
* Rear fast threshold changed again, usual reason.<br />
15-064-19:39:50 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-064-19:40:12 /IDPLOAD VALUE=0x80 ; was 0x70<br />
<br />
* And again, on March 11, 2015.<br />
2015-070-22:46:04 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
2015-070-22:46:19 /IDPLOAD VALUE=0x90<br />
<br />
* On March 13, 2015 the rear fast threshold was changed again<br />
15-072-22:06:18 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-072-22:06:31 /IDPLOAD VALUE=0xA0<br />
<br />
* And then again, on March 16, 2015.<br />
15-075-19:24:13 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-075-19:24:28 /IDPLOAD VALUE=0xB0<br />
<br />
* And then again, on March 18, 2015.<br />
15-077-TBD /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-077-TBD /IDPLOAD VALUE=0xC0<br />
<br />
* And again, on March 25, 2015.<br />
15-084-21:07:00 /IDPUTABLE9 OFFSET=REARFASTDAC<br />
15-084-21:07:14 /IDPLOAD VALUE=0xFF<br />
<br />
* In addition we change the HV on March 25, 2015:<br />
15-084-19:26:07 /ihvdac detector=9, voltage=176<br />
15-084-19:27:17 /ihvdac detector=9, voltage=166<br />
15-084-19:28:33 /ihvdac detector=9, voltage=156<br />
15-084-21:05:17 /ihvdac detector=9, voltage=136 (2622 V)<br />
<br />
* As of early April, detector 9 rear segment is now essentially non functional. Rear fast rates have increased to the point where livetime dropped to zero, and the fast threshold is already turned all the way up so we have no way to control those rates. The front segment appears to be operating normally, though its fast AND slow rates are high (but not worringly so).<br />
<br />
* 2015 April 7: To deal with slightly reduced livetime in the FRONT segment, we changed the front fast threshold. This does NOT seem to have had an effect!!<br />
15-097-19:58:06 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
15-097-19:58:14 /IDPLOAD VALUE=0x30 ; was 0x22<br />
<br />
* 2015 April 14: We increase the Front Slow Threshold just to reduce the values on the front slow valid counts<br />
15-104-14:09:00 /IDPUTABLE9 OFFSET=FRONTSLOWDAC<br />
15-104-14:09:12 /IDPLOAD VALUE=0x1A<br />
<br />
* 2015 May 13: D9 front fast was increased <br />
2015-133-19:09:39 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
2015-133-19:09:52 /IDPLOAD VALUE=0x40 ; was 0x30<br />
<br />
* On June 11 2015 the front fast threshold was raised because the fast rates were high and the livetime was low. This action was DID reduce the fast rates but did NOT increase the livetime much! D9 now does not show high fast rates, slow rates, or resets, but yet the livetime is quite low.<br />
<br />
* On August 20 2015 the front fast threshold was raised in an attempt to gain livetime, which was at ~15%. This was unsuccessful.<br />
15-232-22:21:09 start idib_chg_thrshld (9, FRONT, FAST, 0x90)<br />
15-232-22:21:38 /IDPUDUMPTABL TABLE=DIBTBL9<br />
15-232-22:21:38 /IDPUTABLE9 OFFSET=FRONTFASTDAC<br />
15-232-22:21:46 /IDPLOAD VALUE=0x90<br />
<br />
* On August 20 2015 the rear segment started dumping a huge number of ULD events into the SSR, filling it. Once the problem was pinpointed, D9 events were disabled entirely on the 21st. D9 HV was turned down to 1800V, then 900V, then 800V, in an attempt to bring down the resets. This brought resets down from 30k to 23k and did, indeed, quiet the ULDs. The detector remained segmented. At one point the threshold change to D9 front was reversed to see if that had caused the problem (it hadn't); the threshold change was then re-implemented. Events were turned briefly back on on Aug. 24 and then off, although no danger signs were seen. As of Aug. 25, D9 events are still off. Approximate commanding times are below:<br />
August 21:<br />
1:15 pm PDT: D9 front fast threshold to 0x60 (was 0x90).<br />
2:50 pm PDT: D9 front and rear events disabled.<br />
4:30 pm PDT: HV drop of ~400V, performed in two steps, to 1838V. No change to resets (30k). RTS load to keep D9 events from being re-enabled after eclipse. D9 fast and slow thresholds to max.<br />
6:00 pm PDT: HV drop to ~900V and then again to ~800V. Rear resets before and after are 30k then 25.7k then 23.5k. D9 front fast threshold returned to 0x90.<br />
<br />
* On August 24 2015 D9 events were enabled at 20:42:45 UTC in order to check whether we would still dump too many events into the SSR. The write pointer speed didn't seem to change with this action (although it maybe did change with other detector threshold changes). We left D9 events on, knowing that they'd be turned off again at the next dawn due to the RTS load. As of Aug. 26, D9 events are still off.<br />
2015-236-20:42:45 /itmon value=AFE8 (Detector 9 events turn on)<br />
<br />
* On Sept 9-11, 2015, the rear D9 ULD rose, finally going crazy and maxing out on Sept 11. Since events were off, this wasn't noticed until Sept. 28. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
<br />
<br />
===D9 front slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x0C<br />
|-<br />
| 2015 Apr 14 14:09:12 || 0x1A (was 0x0C)<br />
|}<br />
<br />
===D9 front fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x22<br />
|-<br />
| 2015-Apr-07 19:58 || 0x30 (was 0x22)<br />
|- <br />
| 2015-May-13 19:09:52 || 0x40 (was 0x30)<br />
|-<br />
| 2015-Jun-11 20:18:44 || 0x50 (was 0x40)<br />
|-<br />
| 2015-Jul-31 21:42:36 || 0x60 (was 0x50)<br />
|-<br />
| 2015-Aug-20 22:21:46 || 0x90 (was 0x60)<br />
|-<br />
| 2015-Aug-21 ~20:15 || 0x60 (was 0x90)<br />
|-<br />
| 2015-Aug-22 ~01:15 || 0x90 (was 0x60)<br />
|-<br />
|}<br />
<br />
===D9 rear slow LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x30<br />
|- <br />
| 2015-Aug-22 ~1:15 UTC || 0xFF<br />
|- <br />
|}<br />
<br />
===D9 rear fast LLD threshold history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 0x45<br />
|-<br />
| 2015-Jan-08 17:46:04 || 0x50 (was 0x45)<br />
|-<br />
| 2015-Jan-22 23:34:34 || 0x58 (was 0x50)<br />
|-<br />
| 2015-Jan-22 23:36:55 || 0x60 (was 0x58)<br />
|- <br />
| 2015-Feb-27 18:45:14 || 0x68 (was 0x60)<br />
|- <br />
| 2015-Feb-27 20:22:09 || 0x70 (was 0x68)<br />
|- <br />
| 2015-Mar-05 19:40:12 || 0x80 (was 0x70)<br />
|- <br />
| 2015-Mar-11 22:46:19 || 0x90 (was 0x80)<br />
|- <br />
| 2015-Mar-13 22:06:31 || 0xA0 (was 0x90)<br />
|- <br />
| 2015-Mar-16 19:24:28 || 0xB0 (was 0xA0)<br />
|- <br />
| 2015-Mar-18 21:52:57 || 0xC0 (was 0xB0)<br />
|- <br />
| 2015-Mar-18 23:32:15 || 0xD0 (was 0xC0)<br />
|- <br />
| 2015-Mar-25 21:07:00 || 0xFF (was 0xD0)<br />
|- <br />
|}<br />
<br />
===D9 HV history===<br />
{| class="wikitable" <br />
|- <br />
| post 2014 anneal || 3995 V<br />
|- <br />
| 2014-Aug-20 || 3603V (was 3995V)<br />
|- <br />
| 2015-Mar-25 || 2622V (was 3603V)<br />
|- <br />
| 2015-Aug-03 || 2230V (was 2622V)<br />
|-<br />
| 2015-Aug-21 || ~2000V (was 2230V)<br />
|-<br />
| 2015-Aug-21 || ~1800V<br />
|-<br />
| 2015-Aug-21 || ~900V<br />
|-<br />
| 2015-Aug-21 || 808V<br />
|-<br />
| 2015-Sep-30 03:01:09 || 490V (was 808V)<br />
|-<br />
|}</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T03:24:14Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Spacecraft Status ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
* It was noticed that Detector 9 ULD events had maxed out in the monitor plots again on Sept. 11. This wasn't noticed because D9 events are still off. To try and avoid/mitigate potential damage to the detector, we lowered the HV on D9 on Sept. 29 PDT (Sept. 30 03:00 UTC) from ~800V to 490V. We briefly turned on events for G9 as well. Events were then turned off<br />
again at eclipse entry.<br />
<br />
2015-273-03:00:43 /itmon value=AFE8 (Detector 9 events on)<br />
2015-273-03:01:09 /IHVDAC DETECTOR=9, VOLTAGE=26<br />
<br />
<br />
== Other notes ==<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesenerhttps://sprg.ssl.berkeley.edu/~tohban/wiki/index.php/Tohban_Report_2015-09-30Tohban Report 2015-09-302015-09-30T02:42:21Z<p>Lglesener: </p>
<hr />
<div> {{Infobox Tohban Report|<br />
|start_date = 23 Sep 2015<br />
|end_date = 30 Sep 2015<br />
|tohban_name = Lindsay Glesener<br />
|tohban_email = glesener@ssl.berkeley.edu<br />
|next_tohban = TBD<br />
}}<br />
<br />
== Solar Activity ==<br />
<br />
<br />
== Memory Management ==<br />
<br />
<br />
== Spacecraft Status ==<br />
<br />
<br />
== Data Gaps ==<br />
<br />
No data gaps as of Tuesday evening.<br />
<br />
== Detector issues ==<br />
<br />
* On Sept 23, it was decided that the last changes to the slow threshold were probably too drastic, especially considering that the fast threshold was changed at the same time. We backed the front slow threshold back down to 0x1C, which is what it had been before the last adjustment. This needs to be monitored to see how D3 operates in this state, and keep an eye on the slow rates + SSR. UPDATE Sept. 24: the D3 event rate did not significantly change with this threshold drop. Livetime is still ~90% (same as before the drop) so I think this is a stable, working condition. If more livetime is desired, the fast threshold could be raised again.<br />
<br />
2015-266-19:24:00 /IDPUTABLE3 OFFSET=FRONTSLOWDAC<br />
2015-266-19:24:12 /IDPLOAD VALUE=0x1C ;was 0x80<br />
<br />
* Sept. 23 2015: Despite our best efforts, there's been no success in recovering livetime from D4. The front segment livetime is essentially 0. Since desperate times call for desperate measures, we're lowering the HV by 1000V to try and recover some performance. (This was temporarily tried last week, for an orbit, and the livetime did rise to 30%.) The detector does not seem to be anywhere near segmenting. UPDATE Sept. 24: this drop was successful in bringing the fast rates down some, from 4x10^5 to 10^5. This freed up some livetime, which is now at ~35%. However, it also allowed the slow rates to skyrocket, to about 3000. This is probably cutting into the SSR, and so now the SSR fill is gradually rising (13% min today vs ~4% min yesterday). Action should be taken to reduce the fill rate.<br />
<br />
2015-266-19:25:51 /IHVDAC DETECTOR=4, VOLTAGE=134 (2598 V)<br />
<br />
== Other notes ==<br />
<br />
<br />
== Spacecraft Management ==<br />
<br />
It's about time for a spinup.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
| Decimation || Active/Vigorous<br />
|-<br />
| HLAT Decimation || Rear decimation weight 6, no front decimation<br />
|-<br />
| Night time data (fronts) || +/- 4 minutes <br />
|-<br />
| Night time data (rears) || +/- 4 minutes <br />
|-<br />
| Require extra passes? || No<br />
|-<br />
| Requirement for moving pointer? || No<br />
|-<br />
| Attenuator operation || Looks ok.<br />
|-<br />
| Detector problems? || See notes above.<br />
|}<br />
<br />
<br />
[[Category:Tohban Report]]<br />
[[Category:Tohban]]</div>Lglesener