3-Mar-2017
On Friday, March 3, we put some new RHESSI data accumulation software
online in the hessi atest directory. For the most part, the changes
should be transparent to almost every user.
The modifications include improvements that have been in development for
more than a year when we discovered that the livetime in extremely small
time bins (<512 binary microseconds) was not being reported
correctly. Fine time bins of that order are generally only necessary
for real spatial structure on the order of a few arcseconds. If you
were imaging sources far from the spin axis with Grid 1 this might have
affected your results.
Additionally, a problem with the detector electronics for data after Jan
2014 is dealt with in this release. This problem, which occurred at
the end of datagaps, was pushing a small fraction of events to energies up
to 100-150 keV higher than their actual energy. This effect was
getting worse with time. If you found higher energy emission than expected,
you should look again with this new software.
Details:
- Packet_bunches - we cannot expect to accumulate data requests
by analyzing a single set (bunch) of packets. The boundary management
was always a bit unreliable. Datagaps and livetime procedures mean
that you always have needed to look forward to complete any
accumulation. It's managed much more cleanly using a 2 second
overlap for every bunch as we've been using a 2 second extension for
many years. Working with that has made the packet-eventlist
software much cleaner. Also, there is a one-to-one relationship between
the eventlist elements and the data longwords in the packets until just
before the eventlist is returned to eventlist_strategy::process from the
return in ::process_hook. This enables clearly knowing the originating
packet of any event which greatly simplifies dealing with the time
overlaps.
- Livetime - There are a number of issues. Livetime isn't reported
in the datagaps. In the original telemetry schema that would have meant
nearly 100% livetime. The maximum time resolution for livetime reporting
is 512 binary microsec (busec). High resolution imaging may
require 256 busec or finer time bins. Livetime is only reported in 3
events following an interval or not at all so there has always been the
issue of interpolating/integrating the livetime at both short and long
time intervals (128 busec to thousands of seconds).
The old software mapped the livetime poorly for time bins lt 512
busec. The new software is robust at all timescales although there
is still potential for modest improvement at sub-512 busec. Finally, the
datagaps have to be integrated with the reported livetime. In the new
software, the datagaps force the livetime during the gaps to be zero and
it's a value that tells the follow-on software that it is a gap value of
zero, different from a livetimecounter value of 0 which would mean 100%
livetime.
- Datagaps - The CSA reset method used in the first few years was
unreliable and so now datagaps are always detected by the absence of
events. This new software doesn't support the old CSA event method
at all. The gap detection size limit varies with the rate. There
are more possibilities for extending and prepending added time on the
gap intervals.
Over the last several years we have started to see anomalous higher
energy events at the end of datagaps while the baseline was restoring to
normal levels over 10s of milliseconds. Because of their
appearance in the time series we called this phenomenon "ramps." Now,
the post-gap ramps are detected and removed from the spectrogram data
(they're actually still in the eventlist as negative numbers and not
used). Also, event detection for datagaps goes to channels down to 0 keV
by default. Although there are no datagaps (maybe) in the rear segments
this code is used to detect detector off intervals as well (SAA for
example) and thus to control the livetime integration over large time
intervals better.
New (and existing) control parameters for datagaps:
dp_extend_sec - fltarr(18), seconds to extend
datagap for times after dp_extend_utlim for each detector segment
dp_extend_def - fltarr(18), seconds to extend
datagap for times before dp_extend_utlim for each segment
dp_extend_utlim - dblarr(18), time boundaries
for use of dp_extend_sec or dp_extend_def for each segment
dp_append_def - fltarr(18), same as
dp_extend_def. Only effective if > dp_extend_def (or ...sec
depending on time)
dp_prepend_def - fltarr(18), seconds to
prepend to datagap
dp_append_nvalid - fltarr(18), number of
additional valid events after a gap to extend gap by
dp_prepend_nvalid - fltarr(18), number of
additional valid events before a gap to extend gap by
New info parameter:
info_dp_extend - fltarr(2,18), seconds
that gap was extended before and after gap for 18 detector segments
(this does not include the nvalid additional extensions)
Notes:
So the time extension at the end of a
datagap will be the greater of dp_extend_def (or ...sec depending on
time) and dp_append_def.
dp_append_nvalid and dp_prepend_nvalid are applied after the time
extension.
Gap tests are now done on all segments so controls that were previously
fltarr(9) are now fltarr(18).
For rear segments, there are no short datagaps. The datagap code now
handles long periods when the detectors are off (didn't previously).
Richard and Kim