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

Logged in as guest

Viewing EPICpn/10024
Full headers

From: dlk@astro.caltech.edu
Subject: EPIC pn absolute timing
Compose reply
Download message
Move To:
8 replies: 1 2 3 4 5 6 7 8
8 followups: 1 2 3 4 5 6 7 8

Private message: yes  no

Notes:

Notification:


Date: Tue, 27 Jan 2004 20:55:44 GMT
From: dlk@astro.caltech.edu
To: xmmhelp@xmm.vilspa.esa.es
CC: dlk@astro.caltech.edu
Subject: EPIC pn absolute timing 
Full_Name: David Kaplan
Submission from: (NULL) (131.215.102.92)


Hi.  I have a question regarding the absolute timing accuracy of EPIC pn data.

What is the nature of the time recorded for each event?  Is that the time of
arrival, or the readout time?  If I take a barycentered event list, will that be
in phase with observations taken at different times (months to years apart)? 
What sort of accuracies can I expect?  Are there any corrections to apply beyond
barycentering?  What is the absolute accuracy, both relative to other EPIC pn
observations and to observations with other telescopes?


Reply 1

Resend
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
To: dlk@astro.caltech.edu
Subject: Re: EPIC pn absolute timing (PR#10024)
Date: Wed Jan 28 13:30:23 2004
Dear David

I passed your question to the epic timing experts. Please find
here below the answer to it. 

Cheers,

Maria


> What is the nature of the time recorded for each event? is that the time
of
> arrival, or the readout time ?

the time is the centre of the readout interval

> If I take a brycnetered event list, will that be
> in phase with observations taken at different times (months to years
apart)?

yes and no, because it has not only something to do with the barycentre 
correction. Depending on the Pdot of the pulsar, you will not be able to 
do the same epoch folding for very distant observations. But in principle 
you can always try, using the same start epoch for all observations. 
In any case, you have to take into account the Pdot in the epoch folding. 

> What sort of accuracies can I expect ?

> What is the absolute accuracy, both relative to other EPIC pn 
> observations and to observations with other telescopes?

Please, have a look to the following document

http://xmm.vilspa.esa.es/cgi-doc/ccb/DOC_read?DOC=CAL-TN-0045-1-0

> Are there any corrections to apply beyond barycentering ?

depends on what observation you have 
you might have a time jump (caused by a H/W problem of the EPEA) 
in your data, that is not corrected by the SAS and therefore you
need to correct 'by hand'. You can see the time jumps very easy 
performing a chi2 search of epoch folded light curve versus 
a flat line. 

our experts can help you with this if you wish, please let us
know the observation id in this case

by the way, time jumps should be corrected for 99% of the 
cases with the next sas version, e.g. 6.0, but will only
be public in 1-2 months

In case you have a binary system, you will also have to apply
the binary correction


Maria Santos-Lleo, 
XMM-Newton SOC 
User Support Group


Followup 1

Compose reply
Download message
Date: Wed, 28 Jan 2004 10:42:33 -0800 (PST)
From: David Kaplan <dlk@astro.caltech.edu>
To: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
Subject: Re: EPIC pn absolute timing (PR#10024)
On Wed, 28 Jan 2004, Maria Santos-Lleo wrote:

> Dear David
>
> I passed your question to the epic timing experts. Please find
> here below the answer to it.
>
> Cheers,
>
> Maria
>
>
> > What is the nature of the time recorded for each event? is that the
time of
> > arrival, or the readout time ?
>
> the time is the centre of the readout interval
>
So then the photon times will be systematically off from the actual
arrival times.  Is there any way to correct for this?

> > If I take a brycnetered event list, will that be
> > in phase with observations taken at different times (months to years
apart)?
>
> yes and no, because it has not only something to do with the barycentre
> correction. Depending on the Pdot of the pulsar, you will not be able to
> do the same epoch folding for very distant observations. But in principle
> you can always try, using the same start epoch for all observations.
> In any case, you have to take into account the Pdot in the epoch folding.

Yes, this would be assuming that I have an accurate ephemeris.

>
> > What sort of accuracies can I expect ?
>
> > What is the absolute accuracy, both relative to other EPIC pn
> > observations and to observations with other telescopes?
>
> Please, have a look to the following document
>
> http://xmm.vilspa.esa.es/cgi-doc/ccb/DOC_read?DOC=CAL-TN-0045-1-0

I cannot read this file, and I cannot find it anywhere else.  Could you
send the document to me?
>
> > Are there any corrections to apply beyond barycentering ?
>
> depends on what observation you have
> you might have a time jump (caused by a H/W problem of the EPEA)
> in your data, that is not corrected by the SAS and therefore you
> need to correct 'by hand'. You can see the time jumps very easy
> performing a chi2 search of epoch folded light curve versus
> a flat line.
>
> our experts can help you with this if you wish, please let us
> know the observation id in this case
>
Over what sort of timescale does this happen?  If I fold the data over
small time invervals, then plot the phase, that will identify these jumps?
Or do you mean something else?

Thanks,

-David Kaplan



Reply 2

Resend
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
To: dlk@astro.caltech.edu
Subject: Re: EPIC pn absolute timing (PR#10024)
Date: Thu Jan 29 10:46:57 2004
Dear David, 

I have just sent you the document about EPIC timing

I have also forwarded your following questions to the epic experts
and will come back to you as soon as I get an answer from them

With best regards

Maria
Maria Santos-Lleo, 
XMM-Newton SOC 
User Support Group


Reply 3

Resend
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
To: dlk@astro.caltech.edu
Subject: Re: EPIC pn absolute timing (PR#10024)
Date: Thu Jan 29 15:30:44 2004
Dear David

Please, find attached the answer from our epic experts.

Sincerely

Maria


--------------------------------------

>>So then the photon times will be systematically off from the actual
>>> > arrival times.  Is there any way to correct for this?

no that is not correct:
The times actually have an uncertainty related to the integration time.

for example in ff Mode this is 73 ms

so the time you get has always an uncertainty of .73/2 ms (in FF mode)
that's how a CCD works


>>Over what sort of timescale does this happen?  If I fold the data over
>>> > small time invervals, then plot the phase, that will identify
these
jumps?

exactly,

or you can look at the raw data and synthesize your time form the
coarse and fine time frame counter ( not so trivial)

Maria Santos-Lleo, 
XMM-Newton SOC 
User Support Group


Followup 2

Compose reply
Download message
Date: Thu, 29 Jan 2004 12:55:42 -0800 (PST)
From: David Kaplan <dlk@astro.caltech.edu>
To: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
Subject: Re: EPIC pn absolute timing (PR#10024)
Hi.  Thanks for your reponses.

I am having trouble correctly analyzing EPIC pn data for timing purposes.
For example, I am looking at observation 0124100101.  I have not been able
to identify any of the hardware jumps that you mentioned.  I have also
looked for 1-second errors such as those mentioned in Zane et al. (2002,
MNRAS, 334, 345) and did not find any (as far as I could tell, all even
times were very close to multiples of the frame time).

I processes the EPIC-pn data using atthkgen, tabgtigen, and epproc with
standard option (epchain will not work due to problems with perl).  I then
barycented using barycen.  Finally I extract the events in my source
region, restricting the energy range slightly (0.12-1.2 keV).

I then measure the period of the data, using techniques & routines that I
have verified elsewhere.  I measure a period of 8.39122(2) sec.  This does
not agree with the published period of 8.391133(21) by about 93 msec, or
about 4.5-sigma (I also have other reasons to believe that the period I
measure here is wrong).  The file that I used claims that I have
barycentered (TIMESYS & TIMEREF are correct), but the period is
significantly off.

Am I doing something wrong?  Is there some error that I didn't correct?

(Below are the commands that I used; I can also send files if
necessary).

Thanks,

-David Kaplan

ln -s 0124100101/odf/ ODF
setenv SAS_ODF ODF
cifbuild calindexset=P0124100101BX000CALIND0000.FIT
setenv SAS_CCF P0124100101BX000CALIND0000.FIT
rm -f ODF/*SUM.SAS *SUM.SAS
odfingest
setenv SAS_ODF *SUM.SAS
atthkgen atthkset=P0124100101BX000ATTTSR0000.FIT timestep=1
tabgtigen table=P0124100101BX000ATTTSR0000.FIT:ATTHK \
 gtiset=P0124100101BX000ATTTSR0000.FIT \
 expression='\!isnull(AHFRA) && \!isnull(AHFDEC) &&
\!isnull(AHFPA)'
epproc
barycen table=0078_0124100101_EPN_S003_ImagingEvts.ds:EVENTS



Reply 4

Resend
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
To: dlk@astro.caltech.edu
Subject: Re: EPIC pn absolute timing (PR#10024)
Date: Mon Feb  2 09:43:39 2004
Dear David

I forwarded your question to the EPIC timing experts

I will let you know as soon as I get an answer from them

Cheers

Maria

Maria Santos-Lleo, 
XMM-Newton SOC 
User Support Group


Reply 5

Resend
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
To: dlk@astro.caltech.edu
Subject: Re: EPIC pn absolute timing (PR#10024)
Date: Wed Feb  4 15:55:28 2004
Dear David, 

The epic experts are currently analyzing your question

I got from them that they will look in the time jump records, 
but need inputs from the EPIC-pn instrument team. This will 
therefore take some more time. 

We hope that you can still wait a bit more for the answer, 
but wanted to let you know that we are working on it. 

Regards

Maria


Followup 3

Compose reply
Download message
Date: Wed, 4 Feb 2004 10:42:05 -0800 (PST)
From: David Kaplan <dlk@astro.caltech.edu>
To: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
Subject: Re: EPIC pn absolute timing (PR#10024)
On Wed, 4 Feb 2004, Maria Santos-Lleo wrote:

> Dear David,
>
> The epic experts are currently analyzing your question
Great.

>
> I got from them that they will look in the time jump records,
> but need inputs from the EPIC-pn instrument team. This will
> therefore take some more time.

OK.
>
> We hope that you can still wait a bit more for the answer,
> but wanted to let you know that we are working on it.
>
That's fine for now.

Thanks,


-David Kaplan



Reply 6

Resend
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
To: dlk@astro.caltech.edu
Subject: Re: EPIC pn absolute timing (PR#10024)
Date: Fri Feb  6 16:41:46 2004
Dear David, 

Please find attached the answer from the epic instrument team
regarding to your question.

Hope this helps

Maria

----------------------------------------

we had a look into the exposure 0078_0124100101_PNS003 and
indeed, the public SAS-5.4.1 leaves an uncorrected time anomaly.
Such anomalies can easily be detected if one divides the time
interval between two consecutive events of one CCD by the nominal
frame time. The resulting numbers should be very close to integer
values, i.e. the fractional number should be less than, say, 0.01
(which is caused by jitter due to limited time resolution in the
AUX FTFINE entries used to compute the arrival times).

In the case of 0078_0124100101_PNS003 the background increases
significantly toward the end of the exposure, i.e. after 43 ks
more and more counting mode intervals occur. The first such
interval gets a length of 87.7911s assigned by the infrastructure
OAL, corresponding to 1196.65 frames (FF mode = 73.364320 ms].
However, in this countimng mode interval one of these well-known
1s-jumps had occured, and the counting mode interval actually did
not last for 87.7911s but only for 86.7911s (= 1183 frames).

There are several solutions to this problem, you can choose one 
of the following as you like:

1) wait for SAS-6.0 (due March 2004), and use the file that the
   epic experts have created:

   ftp://ftp.xray.mpe.mpg.de/people/mjf/SPR/P0124100101PNS003PIEVLI0000.FIT.gz

2) disregard all events after t = 74615773.7035 (start = 74572316.1097)

3) manually subtract 1s from all time entries after 74615861.4946 (end
   of first counting mode interval where that jump occured), i.e. from
   photon times in quadrant 1 (CCDNR = 4,5,6), exposure times, and
   good time intervals.



Followup 4

Compose reply
Download message
Date: Mon, 9 Feb 2004 17:48:29 -0800 (PST)
From: David Kaplan <dlk@astro.caltech.edu>
To: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
Subject: Re: EPIC pn absolute timing (PR#10024)
Hi.  Thank you very much for the response.  When I correct this exposure
as directed, I recover the known period.

I have not been so successful with some other exposures, though.  I
searched through them manually for 1-s jumps like that discussed below,
but did not find any.  But I am a little confused about how this works.  I
plotted the remainder of the arrival time (not barycentered) divided by
the frame time.  I found that when using the frame time given below, there
was a substantial slope to the residuals.  I could get rid of most of this
(for exposure 0078_0124100101) by adjusting the frame time to 73.36522
msec.  When I tried this for other exposures, I needed slightly different
frame times, and for some I could not find a frame time that would
eliminate all structure in the residuals.  Often, a roughly parabolic
function was left.  I would expect something like that in the barycentered
data, but as I said I was looking at the non-barycentered events.  Why
isn't the frame time constant?

Although it didn't appear to be constant, I did not find any jumps in the
arrival times, so I assumed that the 1-s problem does not appear.
However, for about 1/2 of the observations of this particular object, the
period I find from these XMM data differs from what I
find using other data, and also differs from previous analyses of the XMM
data (for 0175_0132520301_EPN_S003).  If I only look at one portion of the
data (one GTI interval), then I get something like the correct period.
But if I use all of the data together then there are problems.

Any ideas here what the problem is?  Is there any way that I can get the
new SAS sometime soon to check and see if it fixes my problems, or do I
have to wait until March?

Thanks,


On Fri, 6 Feb 2004, Maria Santos-Lleo wrote:

> Dear David,
>
> Please find attached the answer from the epic instrument team
> regarding to your question.
>
> Hope this helps
>
> Maria
>
> ----------------------------------------
>
> we had a look into the exposure 0078_0124100101_PNS003 and
> indeed, the public SAS-5.4.1 leaves an uncorrected time anomaly.
> Such anomalies can easily be detected if one divides the time
> interval between two consecutive events of one CCD by the nominal
> frame time. The resulting numbers should be very close to integer
> values, i.e. the fractional number should be less than, say, 0.01
> (which is caused by jitter due to limited time resolution in the
> AUX FTFINE entries used to compute the arrival times).
>
> In the case of 0078_0124100101_PNS003 the background increases
> significantly toward the end of the exposure, i.e. after 43 ks
> more and more counting mode intervals occur. The first such
> interval gets a length of 87.7911s assigned by the infrastructure
> OAL, corresponding to 1196.65 frames (FF mode = 73.364320 ms].
> However, in this countimng mode interval one of these well-known
> 1s-jumps had occured, and the counting mode interval actually did
> not last for 87.7911s but only for 86.7911s (= 1183 frames).
>
> There are several solutions to this problem, you can choose one
> of the following as you like:
>
> 1) wait for SAS-6.0 (due March 2004), and use the file that the
>    epic experts have created:
>
>    ftp://ftp.xray.mpe.mpg.de/people/mjf/SPR/P0124100101PNS003PIEVLI0000.FIT.gz
>
> 2) disregard all events after t = 74615773.7035 (start = 74572316.1097)
>
> 3) manually subtract 1s from all time entries after 74615861.4946 (end
>    of first counting mode interval where that jump occured), i.e. from
>    photon times in quadrant 1 (CCDNR = 4,5,6), exposure times, and
>    good time intervals.
>
>

-David Kaplan



Reply 7

Resend
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
To: dlk@astro.caltech.edu
Subject: Re: EPIC pn absolute timing (PR#10024)
Date: Tue Feb 10 09:15:52 2004
Dear David, 

I forwarded your question again to the epic experts. 

I am afraid, regarding SAS 6.0 you have to wait until it 
is public. 

Cheers

Maria

Maria Santos-Lleo, 
XMM-Newton SOC 
User Support Group


Reply 8

Resend
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
To: dlk@astro.caltech.edu
Subject: Re: EPIC pn absolute timing (PR#10024)
Date: Fri Mar 26 16:12:55 2004
Dear David, 

Please find below the answer from the EPIC experts to your question .
Sorry for the delay, but it took them some time to analyse the 
problem and they were at the same time very busy with the 
new SAS release , which is already out. 

Hope this helps

Best regards

Maria

------------------------------------------------------------------

The problem you had  should be gone with SAS 6.0.
However we can provide in any case a processed
event file at the below mentioned place.
For detailed information see also comments below 
from a Max-Planck EPIC-pn instrument expert :

I had a look at the observation 0175_0132520301_PNS003 with
SAS-5.4.1 and SAS-6.0.0-pre and compared the messages issued
by the OAL related to event time computation.

Apparently, the OAL of the public SAS (5.4.1) as well as the
new one (6.0.0-pre) give the same event times. There are, however,
sublte differences in the informational messages. I have copied an
event file processed with a recent SAS version to

ftp://ftp.xray.mpe.mpg.de/people/mjf/SPR/P0132520301PNS003PIEVLI0000.FIT.gz

This is the relevant SAS_VERBOSITY=5 output (5.4.1):

epframes:- ... entering OAL_frameCountersToObt ...
epframes:- Discontinuities in auxiliary data from
`/xmm/public/data/0175/0132520301//./0175_0132520301_PNS00300AUX.FIT:PNAUX1' for
CCD/Quadrant: 0/1 [4] :
epframes:-
   spurious 32767-frames: 205
   late-reset frames    : 0
   missing frames       : 57400
   normal resets        : 0
   premature increments : 0
   negative jumps       : 0
   positive jumps       : 0
   wrong quadrant/CCD   : 0
   unidentified deltas  : 1 [13582/15815(-6.016)]

   minimum delta        : -6.016s
   maximum delta        : 8.364s

epframes:- ... finished OAL_frameCountersToObt ...

while this is the one for 6.0.0:


epframes:- Statistics on auxiliary data from
`/xmm/public/data//0175/0132520301//./0175_0132520301_PNS00300AUX.FIT:PNAUX1'
for CCD/Quadrant: 0/1 [4] :
epframes:-    spurious 32767-frames: 205
   late-reset frames    : 0
   missing frames       : 57310
   normal resets        : 0
   premature increments : 0
   negative jumps       : 0
   positive jumps       : 0
   wrong quadrant/CCD   : 33
   unverifiable deltas  : 0
   unidentified deltas  : 0

   minimum delta        : 0.07334s
   maximum delta        : 8.364s

epframes:- ... finished OAL_frameCountersToObt ...



Followup 5

Compose reply
Download message
Date: Fri, 26 Mar 2004 17:13:10 +0100 (MET)
From: Mail Delivery Subsystem <MAILER-DAEMON@esacom51-int.vilspa.esa.int>
To: <xmmhelp@xmm.vilspa.esa.es>
Subject: Returned mail: see transcript for details
This is a MIME-encapsulated message

--i2QGDADk002696.1080317590/esacom51.vilspa.esa.int

The original message was received at Fri, 26 Mar 2004 17:13:00 +0100 (MET)
from xvsoc01.vilspa.esa.es [193.147.152.102]

   ----- The following addresses had permanent fatal errors -----
<dlk@astro.caltech.edu>
    (reason: 553 5.1.8 <xmmhelp@xmm.vilspa.esa.es>... Domain of sender
address xmmhelp@xmm.vilspa.esa.es does not exist)

   ----- Transcript of session follows -----
... while talking to phobos.caltech.edu.:
>>> MAIL From:<xmmhelp@xmm.vilspa.esa.es> SIZE=3052
<<< 553 5.1.8 <xmmhelp@xmm.vilspa.esa.es>... Domain of sender
address xmmhelp@xmm.vilspa.esa.es does not exist
501 5.6.0 Data format error

--i2QGDADk002696.1080317590/esacom51.vilspa.esa.int
Content-Type: message/delivery-status

Reporting-MTA: dns; esacom51.vilspa.esa.int
Received-From-MTA: DNS; xvsoc01.vilspa.esa.es
Arrival-Date: Fri, 26 Mar 2004 17:13:00 +0100 (MET)

Final-Recipient: RFC822; dlk@astro.caltech.edu
Action: failed
Status: 5.1.8
Diagnostic-Code: SMTP; 553 5.1.8 <xmmhelp@xmm.vilspa.esa.es>... Domain of
sender address xmmhelp@xmm.vilspa.esa.es does not exist
Last-Attempt-Date: Fri, 26 Mar 2004 17:13:10 +0100 (MET)

--i2QGDADk002696.1080317590/esacom51.vilspa.esa.int
Content-Type: text/rfc822-headers

Return-Path: <xmmhelp@xmm.vilspa.esa.es>
Received: from xvsoc01.vilspa.esa.es (xvsoc01.vilspa.esa.es [193.147.152.102])
	by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id
i2QGD0Dk002692
	for <dlk@astro.caltech.edu>; Fri, 26 Mar 2004 17:13:00 +0100 (MET)
Received: from localhost (localhost [127.0.0.1])
	by xvsoc01.vilspa.esa.es (8.12.10/8.12.10) with ESMTP id i2QGCr1N003232
	for <dlk@astro.caltech.edu>; Fri, 26 Mar 2004 16:12:54 GMT
Date: Fri, 26 Mar 2004 16:12:54 GMT
Message-Id: <200403261612.i2QGCr1N003232@xvsoc01.vilspa.esa.es>
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
To: dlk@astro.caltech.edu
Subject: Re: EPIC pn absolute timing (PR#10024)
X-Loop: xmmhelp@xmm.vilspa.esa.es

--i2QGDADk002696.1080317590/esacom51.vilspa.esa.int--



Followup 6

Compose reply
Download message
Date: Fri, 26 Mar 2004 17:17:45 +0100 (MET)
From: Mail Delivery Subsystem <MAILER-DAEMON@esacom51-int.vilspa.esa.int>
To: <xmmhelp@xmm.vilspa.esa.es>
Subject: Returned mail: see transcript for details
This is a MIME-encapsulated message

--i2QGHjDk002867.1080317865/esacom51.vilspa.esa.int

The original message was received at Fri, 26 Mar 2004 17:17:39 +0100 (MET)
from xvsoc01.vilspa.esa.es [193.147.152.102]

   ----- The following addresses had permanent fatal errors -----
<dlk@astro.caltech.edu>
    (reason: 553 5.1.8 <xmmhelp@xmm.vilspa.esa.es>... Domain of sender
address xmmhelp@xmm.vilspa.esa.es does not exist)

   ----- Transcript of session follows -----
... while talking to phobos.caltech.edu.:
>>> MAIL From:<xmmhelp@xmm.vilspa.esa.es> SIZE=3014
<<< 553 5.1.8 <xmmhelp@xmm.vilspa.esa.es>... Domain of sender
address xmmhelp@xmm.vilspa.esa.es does not exist
501 5.6.0 Data format error

--i2QGHjDk002867.1080317865/esacom51.vilspa.esa.int
Content-Type: message/delivery-status

Reporting-MTA: dns; esacom51.vilspa.esa.int
Received-From-MTA: DNS; xvsoc01.vilspa.esa.es
Arrival-Date: Fri, 26 Mar 2004 17:17:39 +0100 (MET)

Final-Recipient: RFC822; dlk@astro.caltech.edu
Action: failed
Status: 5.1.8
Diagnostic-Code: SMTP; 553 5.1.8 <xmmhelp@xmm.vilspa.esa.es>... Domain of
sender address xmmhelp@xmm.vilspa.esa.es does not exist
Last-Attempt-Date: Fri, 26 Mar 2004 17:17:45 +0100 (MET)

--i2QGHjDk002867.1080317865/esacom51.vilspa.esa.int
Content-Type: text/rfc822-headers

Return-Path: <xmmhelp@xmm.vilspa.esa.es>
Received: from xvsoc01.vilspa.esa.es (xvsoc01.vilspa.esa.es [193.147.152.102])
	by esacom51.vilspa.esa.int (8.12.10/8.12.10/ESA-External-v3.2) with ESMTP id
i2QGHdDk002863
	for <dlk@astro.caltech.edu>; Fri, 26 Mar 2004 17:17:39 +0100 (MET)
Received: from localhost (localhost [127.0.0.1])
	by xvsoc01.vilspa.esa.es (8.12.10/8.12.10) with ESMTP id i2QGHY1N003395
	for <dlk@astro.caltech.edu>; Fri, 26 Mar 2004 16:17:34 GMT
Message-Id: <200403261617.i2QGHY1N003395@xvsoc01.vilspa.esa.es>
From: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
To: dlk@astro.caltech.edu
Subject: Re: EPIC pn absolute timing (PR#10024)
Date: Fri Mar 26 16:12:55 2004

--i2QGHjDk002867.1080317865/esacom51.vilspa.esa.int--



Followup 7

Compose reply
Download message
Date: Fri, 26 Mar 2004 16:21:38 +0000
From: Maria Santos-Lleo <msantos@xmm.vilspa.esa.es>
To: dlk@astro.caltech.edu
CC: xmmhelp@xmm.vilspa.esa.es
Subject: Re: EPIC pn absolute timing (PR#10024)
Dear David,

I tried to send below message from the xmmhelp but was returned to
me. I try now from my personal account, but , please, reply to
the helpdesk only. Hope it works ...

Maria

-------------------

Dear David,

Please find below the answer from the EPIC experts to your question .
Sorry for the delay, but it took them some time to analyse the
problem and they were at the same time very busy with the
new SAS release , which is already out.

Hope this helps

Best regards

Maria

------------------------------------------------------------------

The problem you had  should be gone with SAS 6.0.
However we can provide in any case a processed
event file at the below mentioned place.
For detailed information see also comments below
from a Max-Planck EPIC-pn instrument expert :

I had a look at the observation 0175_0132520301_PNS003 with
SAS-5.4.1 and SAS-6.0.0-pre and compared the messages issued
by the OAL related to event time computation.

Apparently, the OAL of the public SAS (5.4.1) as well as the
new one (6.0.0-pre) give the same event times. There are, however,
sublte differences in the informational messages. I have copied an
event file processed with a recent SAS version to

ftp://ftp.xray.mpe.mpg.de/people/mjf/SPR/P0132520301PNS003PIEVLI0000.FIT.gz

This is the relevant SAS_VERBOSITY=5 output (5.4.1):

epframes:- ... entering OAL_frameCountersToObt ...
epframes:- Discontinuities in auxiliary data from
`/xmm/public/data/0175/0132520301//./0175_0132520301_PNS00300AUX.FIT:PNAUX1' for
CCD/Quadrant: 0/1 [4] :
epframes:-
    spurious 32767-frames: 205
    late-reset frames    : 0
    missing frames       : 57400
    normal resets        : 0
    premature increments : 0
    negative jumps       : 0
    positive jumps       : 0
    wrong quadrant/CCD   : 0
    unidentified deltas  : 1 [13582/15815(-6.016)]

    minimum delta        : -6.016s
    maximum delta        : 8.364s

epframes:- ... finished OAL_frameCountersToObt ...

while this is the one for 6.0.0:


epframes:- Statistics on auxiliary data from
`/xmm/public/data//0175/0132520301//./0175_0132520301_PNS00300AUX.FIT:PNAUX1'
for CCD/Quadrant: 0/1 [4] :
epframes:-    spurious 32767-frames: 205
    late-reset frames    : 0
    missing frames       : 57310
    normal resets        : 0
    premature increments : 0
    negative jumps       : 0
    positive jumps       : 0
    wrong quadrant/CCD   : 33
    unverifiable deltas  : 0
    unidentified deltas  : 0

    minimum delta        : 0.07334s
    maximum delta        : 8.364s

epframes:- ... finished OAL_frameCountersToObt ...




Followup 8

Compose reply
Download message
Date: Wed, 7 Apr 2004 11:42:35 -0700 (PDT)
From: David Kaplan <dlk@astro.caltech.edu>
To: Maria Santos-Lleo <xmmhelp@xmm.vilspa.esa.es>
Subject: Re: EPIC pn absolute timing (PR#10024)
Hi.  Thanks for the response.

I have downloaded SAS 6.0.0, as well as updated by calibration database.
I then reprocessed the observations.  I found that the timing
discontinuity seems to have gone away.  However, there is a strange
problem that I am having.  For some of the observations (e.g.,
_0124100101, which had worked before) I find that the CCDs with the source
on them dissapear from the data a third of the way through the
observation.

There is only one bright source in this observation, and it's on CCD 4.
Most of the events on the other CCDs are background.  But if I plot a
histogram of events binned by CCD, I find that CCDs 1-3 have the most
evens, followed by 7-12, with 4-6 having the fewest.

If I separate the data into 10 time slices, the first 3 look OK.  At the
fourth, CCDs 4-6 fade out, while by 5 they are gone.  The other CCDs look
OK until the last slice or two, when CCDs 1-3 have significantly more
background events than 7-12.

Is there any reason for this?  I don't know how to check the detailed
processing of the file to figure out why those CCDs are rejected.  I don't
think that it has anything to do with GTIs, but I am not sure.

Thanks,

On Fri, 26 Mar 2004, Maria Santos-Lleo wrote:

> Dear David,
>
> Please find below the answer from the EPIC experts to your question .
> Sorry for the delay, but it took them some time to analyse the
> problem and they were at the same time very busy with the
> new SAS release , which is already out.
>
> Hope this helps
>
> Best regards
>
> Maria
>

-David Kaplan


Up to top level
AO15   AO16   AO17   AO18   AO19   Backgrounds   Calibration   Conference   Data   Docs   EPICMOS   EPICpn   Feedback   Gallery   Misc   OM   Pending   PhD_Theses   Publications   RGS   RadMonitor   SAS_Hardware   SAS_WS   SASv16.0   SASv16.0_Installation   SASv16.1   SASv16.1_Installation   SASv17.0   SASv17.0_Installation   SASv18.0   SASv18.0_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