#85 single pulse - incorrect start time in output headers

[Mike Keith]

When writing single pulse data the start times (e.g. STT_OFFS, etc) are not set correctly for each pulse.

In particular, the start time is set to phase zero for a "nearby" pulse (I think just one pulse either side of the actual pulse). This means that it is difficult to correctly determine the location witin the original data that the pulse originated, or to synchronise with other observations.

As noted by Patrick W., we expect that this is due to the fact that for folded observations there is an intrinsic ambiguity in which phase zero epoch is used, but for single pulses there is only one correct.

I will try to investigate this at some point, but any hints at where to look would be appreciated.

[Willem van Straten]

Hi Mike,

You might start with dsp::PhaseSeries::get_mid_time, defined in Signal/Pulsar/PhaseSeries.C

It defines the "mid time" of an integration, and calls Phase::Floor in an attempt to always choose the start time of a single pulse. However, if RFI has been flagged, or reference_phase is set to a number greater than 0.5, this code might fail to lock onto the start time and Predictor::iphase might converge on the end time.

[Sorry I can't debug this code myself.]

Cheers,
Willem

[Mike Keith]

I have an update for this bug. I believe that this is not actually a bug in dspsr, but for future reference and in case someone else has a similar issue here is my current understanding.

After some investigation of the code and more carefull looking at the files I have determined that although dspsr does write the same start time to some files, these files also get a large OFFS_SUB in the "subint" header, which puts the start time of bin zero at the correct place. This is caused when the phase of bin zero is slightly before 0 (i.e. 0.99999). The time is computed correctly, but the way it is written into the header is strange.

The error I had observed in my added archives was caused by installing a new predictor into the archives before combining them (this is done using the python inteface, I'm not sure if the same thing happens with pam & psradd). This caused the start time of some of the single-pulse subints to jump by one period. I guess this is caused by the same kind of issue that causes the strange start times in the dspsr header, but I haven't fully traced the cause.

Of course, it is kind of nonsensical to install a new predictor to single-pulse data anway, but this is currently needed as part of the single-pulse pipeline in meertime to correctly add together the two sub-bands in the "old" data. This has been solved by installing the new predictor after adding the archives, which seems to work ok, though I'm not sure why it makes any difference.

This bug can be closed.

[Andrew Jameson]

Hi Mike,

Thanks for logging the reply here - hopefully others who encounter this issue will read it :) I'll close this ticket.

Cheers,

Andrew