Up to top level
AO15   AO16   AO17   Backgrounds   Calibration   Conference   Data   Docs   EPICMOS   EPICpn   Feedback   Gallery   Misc   OM   Pending   PhD_Theses   Publications   RGS   RadMonitor   SAS_Hardware   SAS_WS   SASv15.0   SASv15.0_Installation   SASv16.0   SASv16.0_Installation   SASv16.1   SASv16.1_Installation   SciSim   Simulators_other   Suggestions   Trash   Visibility   XMM-bouncing   XMM-news   XRPS   XSA   esas   incoming  

Logged in as guest

Viewing Calibration/7553
Full headers

From: Peter.Woods@nsstc.nasa.gov
Subject: PN absolute timing
Compose reply
Move To:
3 replies: 1 2 3
1 followups: 1

Private message: yes  no

Notes:

Notification:


Date: Mon, 25 Nov 2002 22:43:38 GMT
From: Peter.Woods@nsstc.nasa.gov
To: xmmhelp@xmm.vilspa.esa.es
CC: Peter.Woods@nsstc.nasa.gov
Subject: PN absolute timing
Full_Name: Peter Woods
Submission from: (NULL) (198.122.193.171)


First, I have four figures and a log file that are essential to understanding
my question.  Please tell me an ftp site where I can place these so you can
view them, or alternatively, an email address where they can be mailed.

I have been trying to use an XMM observation (0038140101) in conjunction with
several RXTE observations for timing of a pulsar (1E 2259+586).  When looking
at the XMM PN (small window mode) data, I found that there were some
irregularities.  Werner Becker suggested I run epchain on the odf products and
produce a new event list.  I did that and saved the log file.  The log file
indicated that there were no "unidentified deltas" which Werner warned me
indicates integer second jumps in the data.  However, when I looked more
closely at the output time tags, I found that there was evidence for time
jumps.  To look for these jumps, I plotted the times MOD the time resolution
(~0.0056718 sec).  Contrary to what was returned in the log file, I found two
discontinuities in the "readout phases" (see figure).  Moreover, I found that
the readout phases have a strong quadratic term (i.e. the readout time frame is
changing considerably within the observation).  As far as the discontinuities
go, I could reconcile those by introducing two 1 sec jumps for the middle and
end segments of data.  This fixed the discontinuities in the readout phases as
well as the phases of the pulsar (see figure; this is a 7 sec pulsar), so I am
very confident in the relative phase.  I further confirmed this by using the
pipeprod data.  This data set had the same problems (i.e. it shouldn't have
anything to do with my use of epchain).  Next, I addressed the issue of
absolute timing.  I found that a 2 sec (overall) jump comes close to fixing the
relative timing with RXTE, but not quite.  Given the timing irregulaties I have
encountered so far, I am not willing to attribute this discrepancy to the
source as yet.  Obviously, it is important to know where this discrepancy
arises (detector, software, or source) before we proceed with further
analysis.  So, I have several questions:

1 - Why is the PN small window readout time frame changing by so much during
the observation?

2 - Have there been any advances which identify and correct these time jumps?

3 - How sure can I be of the absolute timing?

As you can see, this observation does not become public soon.  However, there
is a complimentary observation (ToO) that does, so we would be very
appreciative of a quick response.

Best regards,

Pete Woods



Reply 1

Resend
From: Matteo Guainazzi <xmmhelp@xmm.vilspa.esa.es>
To: Peter.Woods@nsstc.nasa.gov
Subject: Re: PRIVATE: PN absolute timing (PR#7553)
Date: Tue Nov 26 08:02:49 2002
Dear Peter,

 please, put the figure on an ftp site, and let me know how I can
retrieve them. Once I have retrieved these figures, I will discuss
your questions with the EPIC Calibration Scientist.

 Thanks,

 Matteo Guainazzi
 User Support Group
 XMM-Newton Science Operation Center


Followup 1

Compose reply
From: "Woods, Peter" <Peter.Woods@msfc.nasa.gov>
To: xmmhelp@xmm.vilspa.esa.es
Cc: "Woods, Peter" <Peter.Woods@msfc.nasa.gov>
Date: Tue, 26 Nov 2002 09:42:17 -0600 (CST)
Subject: Re: PRIVATE: PN absolute timing (PR#7553)
Dear Matteo,

I just placed 4 files on the ftp site sao-ftp.harvard.edu.  They are
located in the public/woodspm directory.

epchain.log - epchain log file
frame_phases_ao1.ps - Frame phases (i.e. (time mod time_res)/time_res)
	for this observation.  Note the phase jumps at ~27500 and ~33000
	sec since beginning of obs.
phases_ao1_nofix.ps - phases of the pulsar (1e 2259+586) before any 
	correction to the times.
phases_ao1.ps - phases of the pulsar after correcting for the phase 
	jumps in the readout phases.

Let me know if you would like any further clarification.

Best regards,

Pete Woods



On 26 Nov, Matteo Guainazzi wrote:
> Dear Peter,
> 
>  please, put the figure on an ftp site, and let me know how I can
> retrieve them. Once I have retrieved these figures, I will discuss
> your questions with the EPIC Calibration Scientist.
> 
>  Thanks,
> 
>  Matteo Guainazzi
>  User Support Group
>  XMM-Newton Science Operation Center



Reply 2

Resend
From: Matteo Guainazzi <xmmhelp@xmm.vilspa.esa.es>
To: Peter.Woods@nsstc.nasa.gov
Subject: Re: PRIVATE: PN absolute timing (PR#7553)
Date: Wed Nov 27 11:25:53 2002
Dear Peter,

 briefly to tell you that we have retrieved your files. Your findings
are being discussed by the EPIC Calibration Team. I will come
back to you as soon as a conclusion is reached.

 Thanks a lot for your careful analysis. Regards,

 Matteo


Reply 3

Resend
From: Matteo Guainazzi <xmmhelp@xmm.vilspa.esa.es>
To: Peter.Woods@nsstc.nasa.gov
Subject: Re: PRIVATE: PN absolute timing (PR#7553)
Date: Fri Dec 20 23:45:58 2002
Dear Peter,

 please, find below the answer to your questions on the timing analysis
with EPIC from the EPIC Instrument Team:

1. The frame time of the pn is determined by a free running oscillator
with a stability of 10**-5 to 10**-6. However, the frame times, and
hence the photon arrival times, are measured with the accuracy of the
S/C clock, which is much higher. If the electronics temperature would
have changed during the observation, there may well be a non linear
term in the readout phases.

2. Due to a hardware problem, the counter for the coarse time (1 Hz
counter), shows some unpredictable jumps by more than one (so-called
one second jumps). These jumps should in principle be corrected by
SAS, but we know that there are cases where this correction fails.
There is an easy way to check for those jumps. Just calculate the
time difference between adjacent events. In small window mode this
should be zero (events from the same frame) or a multiple of the
frame time. If one finds instead jumps by (n x frame time + m x 1
seconds), this indicates such a time jump. In most cases one simply
can determine the value for m. This time error then affects all
following event times. To correct, just substract m seconds. Caveat:
this analysis should be done before the barycenter correction is
applied!

3. There is still an error of 1-3 ms in the absolute XMM time. We still
work on this problem and  would be very much interested in results from
parallel XMM and RXTE observations.

 Regards,

 Matteo

Up to top level
AO15   AO16   AO17   Backgrounds   Calibration   Conference   Data   Docs   EPICMOS   EPICpn   Feedback   Gallery   Misc   OM   Pending   PhD_Theses   Publications   RGS   RadMonitor   SAS_Hardware   SAS_WS   SASv15.0   SASv15.0_Installation   SASv16.0   SASv16.0_Installation   SASv16.1   SASv16.1_Installation   SciSim   Simulators_other   Suggestions   Trash   Visibility   XMM-bouncing   XMM-news   XRPS   XSA   esas   incoming  

Logged in as guest


Please make your (short) question the subject of your request!


Web interface using JitterBug ... back to the XMM home page