Countrate high

Location

Purpose

Steps for UDS to run

• IDPUCOUNTRATE limit violations are caused by high count rates which should show up as ISFTYRATEOP limit violations in the "errors" and high count rates in the graphs (see below), but anyway, look at the time in the email which merely hints at when the problem happened (it will give a time up to a few hours after: DO NOT MENTION THIS TIME FROM THE SERS EMAIL OR JUST COPY THE EMAIL TO ANYONE AS IT WILL ONLY CONFUSE).
• Check the angle graphs on http://twins.swift.psu.edu/hk.html or http://msslje.mssl.ucl.ac.uk/hk.html to find out when the countrate really was high. Obviously, you'll have to wait until after the MAL pass and after the ITOS playback before you'll see the angles graph. You should check approx. the 4 angles graphs immediately before the time on the email. If you can't access this web site, log onto a machine at Penn State or MSSL and download the images from there.
• You should be checking the page http://twins.swift.psu.edu/hk.html or http://msslje.mssl.ucl.ac.uk/hk.html approximately every day anyway to look for "errors" displayed in the right hand column. A "high violation ISFTYRATEOP" is the definitive evidence for a high count rate and there should be one of these when there is a high violation IDPUCOUNTRATE. Whenever there is a "high violation ISFTYRATEOP", the high countrate should be visible in the corresponding angles and counts graphs on the same line of the table.
• Checking the corresponding *_icuevents.log should indicate what the uvotmode was, what the filter was and what the ICU was doing at that time.
• The rateop on the *_counts.png graph is an accurate measurement of countrate, the dpucountrate is less accurate and the limit violation itself only tells you it is way above the number given.
• Remember, the time of the IDPUCOUNTRATE limit vioation in the SERS event email is simply wrong and will never be fixed: DO NOT MENTION THIS TIME FROM THE SERS EMAIL OR JUST COPY THE EMAIL TO ANYONE AS IT WILL ONLY CONFUSE (see SERS anomaly G-0165 or SOARS S-Swift-0342).
• Grism observations (also white, B, and sometimes others) are often bright and still useful so if it is a grism observation that is only just over the limit and obviously caused by a bright field (the countrate graph is flat) or obviously caused by the Earth (high countrate when the Earth angle is low) then there probably isn't a problem worth telling everyone about: in which case just email pjs1.
• If it looks interesting, send to people like Caryl, Sally, Dan, Pete and uvot_cal. Report as many of the following as possible:
  • The countrate
  • The time of the high countrate (NOT THE EMAIL TIME).
  • The uvotmode: this will be in the *_icuevents.log (and the MasterPPST if it wasn't an AT).
  • The filter: this will be in the *_icuevents.log (and this is implicit in the uvotmode).
• If you, the UDS, don't understand or are not 100% sure, email pjs1 with the details you find for checking first.
• This is not an emergency so there's no need to telephone anybody, just email.

Example email