1 / 16

Absolute LAT Timing

GPS. David Smith CENBG/In2p3/CNRS Bordeaux, France. Absolute LAT Timing. Motivation. For pulsar studies, bad event absolute time stamps would be nearly as bad a disaster as gyroscope failures. Many missions have had issues, including recent ones.

tyler-mejia
Télécharger la présentation

Absolute LAT Timing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GPS David Smith CENBG/In2p3/CNRS Bordeaux, France Absolute LAT Timing

  2. Motivation • For pulsar studies, bad event absolute time stamps would be nearly as bad a disaster as gyroscope failures. Many missions have had issues, including recent ones. • I set out to compare the timestamps at the very end of the hardware+software chain with some independent measure, if possible, and with anything at all for starters. • This talk: • plausible dates using NRL FSW muons. • Current events • Future prospects

  3. Example of “real life” timing problem • While reading up on PSR J0205+6449 I came across this:

  4. CHANDRA pulsar timing problems, cont’d

  5. CHANDRA pulsar timing solution They recovered, but apparently with some loss of pulsed sensitivity…

  6. LAT pulsar timing tests • Ongoing discussions with Eric Grove and a growing list of experts. • From Pat Hascall, 17 April: “LAT 13x tests performed at SLAC to demonstrate the 10uS timestamp requirement (Level 3 req’t 5.2.11). Tests described in LAT-MD-02730. (The accuracy of the 1PPS signal is a spacecraft requirement). Test results will be analysed and documented in LAT-TD-xxxxx*.” • Gregg Thayer prepared the tests. See for example run 77005274, “intSeApp_e2e_LAT-13x_0.17hr”, from 2006-05-24 19:53. • * yesterday I asked Pat if xxxxx exists and who’s writing it, and he said “you are!”.

  7. Real GPS timestamps in real data • FSW (=Flight Software) gets GPS absolute time stamp for individual triggers from the VSC (virtual space craft, see next slide). • Except that, at present, it gets it from a highly reliable internet time source at power up, and then counts forward in time using a computer clock, because of some thorny VSC+FSW issues. Hence, timestamps drift over time. • The elements for building MET (=Mission Elapsed Time, that is, seconds since 2001 January 1, the input to gtbary, the first step towards calculating pulsar spin phase) are “TimeTone at PPS” and “50 ns ticks since last PPS” and appear in the digi.root and SvacNtuple.root files.

  8. VSC = Virtual Space Craft GPS • A French 100-meter It’s just a VME crate with some ordinary and some special modules.

  9. How to build MET from raw data Slide 9 of Anders Borgland’s talk, http://www-glast.slac.stanford.edu/IntegrationTest/SVAC/Instrument_Analysis/Meetings/05262006/SVAC.pdf

  10. Timestamps in SVAC & Merit Tuples • I followed Anders’ recipe, using a recent muon run from NRL, 77005390. Generated plausible METs.Learned lotsa nifty little details. • Continue down the software chain? There used to be a .fits file from the pipeline, I wrongly thought it was like the .fits we used in DC2. • But a) it was the MeritTuple with a .fits wrapper, and b) it’s gone since the switch from Latte to FSW. • So I looked at EvtElapsedTime in the MeritTuple. It’s sort of within a second of the SVAC-derived time: (here, 10 of first 10,000 events, at ~440 Hz). • int diff = TTCGemTimeTicks-TTPGemTimeTicks ; if (TTPGemTimeTicks>TTCGemTimeTicks) diff = TTCGemTimeTicks+(33554432-TTPGemTimeTicks) ; • float fraction=TTCTTicks/(float)diff ; Expect TTCTSecs+TTicks/Diff to equal EvtElapsedTime • EvtID TTCTSecs TTicks/diff EvtElapsedTime • 3695052 170449260 1.064380 170449261.065369 • 3696052 170449263 1.620004 170449263.226898 • 3697052 170449265 0.450713 170449265.435852 • 3698052 170449267 0.951812 170449267.623566 • 3699052 170449269 1.489436 170449269.799530 • 3700052 170449271 0.367067 170449272.023560 • 3701052 170449274 0.968614 170449274.353455 • 3702052 170449276 1.543594 170449276.554779 • 3703052 170449278 0.355703 170449278.734436 • 3704052 170449280 0.830439 170449280.823669 E-mailed with Anders & Heather about this. To me, seems that Merit value should be replaced by TTCTSecs+TTicks/diff(Anders’ recipe) but they concluded something different that I didn’t understand. Nota bene – Joanne Bogaert selects rdb calibration files using these event times.

  11. (What does “plausible” mean?) • Run 77005390 started at 2006-05-27 18:59:38, according to IA runs database. • MET (=Mission Elapsed Time is seconds since 2001 January 1) . <78>smith:borlin57.cenbg.in2p3.fr% /bin/date -u --date="1 Jan 01 00:00" '+%s‘  978307200 <79>smith:borlin57.cenbg.in2p3.fr% /bin/date -u --date="27 May 06 18:59:38" '+%s‘  1148756378 Difference is 170,449,178 (MET of begin run). SVAC recipe shows 170,449,260 82 second difference “plausible” EvtID TTCTSecs TTCTTicks TTCGemTTix TTPGemTTix diff TTicks/diff 3695052 170449260 21287574 2918647 16473104 19999975 1.064380 3696052 170449263 32400049 29364140 9364165 19999975 1.620004 3697052 170449265 9014258 2255226 15809683 19999975 0.450713 The 20 MHz scaler counts 19999975 times per second instead of counting 20000000. Fine. TTicks/diff would, naively, never be more than 1 but apparently some PPS's get lost, which is also fine.

  12. (A glance at the status words) NEXT: quick look at the many status variable... "FlyWheeling" always zero for the above. if (TTCincomplete!=0 || TTPincomplete!=0) nHOLA++ ; ten thousand times! Always 65536. printf(" Current flags: %d %d %d %d %d \n",CFlagsValid, CMissingGps, CMissingCpuPps, CMissingLatPps, CMissingTimeTone) ; Ditto “Previous” For all 10 events sampled from 10,000 events, here's what you get: Current flags: 1 1 0 0 0 Previous flags: 1 1 0 0 0 Anders says: features known from the digi reports, and under investigation.

  13. Current events (downstream) • As stated: ultimate goal is to check the absolute time stamp at the very end of the SC+LAT+FSW+Pipeline chain against a more-or-less GLAST independent reference time. • So I enquired to Julie & Seth about plans for the DC2-like .fits files to exist with real data. • She said: currently discussions at GSFC, including e.g. choice of time standards (how to deal with leap seconds, etc). • A suggestion: as part of the DC3-like “service challenges”, process LAT ground cosmics all the way through MOC and ISOC to the .fits files data servers. Include LAT orientation during muon runs (e.g. the orbital elements of NRL…) so that (RA,dec) as well as MET are filled as realistically as possible. • Then perform pulsar searches on atmospheric gammas (and muons?) -- good way to stress all software. • First one to see pulsed muons from Cyg-X3 looses!

  14. Current events (upstream) • [ Intermediate goal – verify that TimeStamp downstream of LAT+FSW+pipeline is still precisely correlated with original TimeStamp.] • Eric Grove told me that data from the VSC comes in a CCSDS* file, part of which becomes the Science Stream and hence our digi.root and SVAC files. • It further contains info from “upstream” of the LAT, e.g. space craft attitude and position and the TimeTone of the most recent PPS. • Bryson Lee confirmed, and thought he could provide me with some ascii dumps. Then we a) learned that it’s not really GPS and that b) what are you going to learn by comparing 440 Hz with asynchronous 1 PPS anyway? This task is temporarily adrift… * See ccsds.org

  15. Future prospects • The current “internet time at power-on followed by freewheeling” will be upgraded, to either use the (now unused) GPS that is in the VSC VME crate, hopefully before the LAT leaves NRL, or by the GPS on the real space craft once the LAT is in Arizona. • What seems groovy to me: at NRL, use a muon telescope to trigger an external GPS (see next slide) while LAT triggers on cosmix, and then perform offline analysis of the independent data streams. Like “if TKR track points at paddles then compare our time and LAT time”. • Or do that after integration with spacecraft, to really get the whole shbang? Both is better. • Quandry: • on the one hand, waiting is appealing – the VSC+FSW folks are progressing, and CERN is looming. • On the other hand, access will be even harder once the LAT leaves NRL. • Or just trust 10 uS verification, and SpaceCraft absolute time verification?

  16. An independent, external muon timestamp? • The VME GPS that Denis Dumora and I used to see the Crab optical pulsar with CELESTE is in our basement. We got PMTs, NIM logic, etc. If this task is deemed critical and no one else is available to do it, we could get it working again and bring it to NRL, but then we’d be (mostly) absent from CERN.

More Related