[evla-sw-discuss] pulsar data

[Michael Rupen]

Hi Walter,
   hey, this is fun!  A response to your response...

>> I thought we had one timer per each of *eight* 2 GHz basebands (four BB
>> pairs, 2 pol'ns each).
>
> That could be.  It won't be a typical case where RR and LL will want
> different pulse phases though -- I'm inclined to think it shouldn't be
> supported.

Brent says we have one per BB pair.  And yes, we should make this clear in the
Project Book.

>> I'm confused as to gating vs. time bins -- I thought these were separate
>> beasties.  Gating just means "correlate only at these times, and store one
>> output stream"; time binning means more output streams.  I'm not clear on the
>> "beating" between the gating and the phase bins.
>
> Gating is time binning with only 1 bin.  No distinction is made.  Am I
> wrong?  In any case clocking is done by the pulsar timers.

According to Brent they're distinct, as I described.  Though he doesn't see 
much use for gating, given the phase bins.

>> Am I right in thinking pulsar monitoring requires phasing up the array for
>> maximum sensitivity?  WIDAR will be delivered with 8 digitally phased
>> sub-bands for a total BW of 1 GHz.  WIDAR can phase up all 18 sub-bands of
>> every baseband, but we won't initially have that hardware.  Antennas may be
>> assigned to multiple phased sub-arrays; phased sub-arrays may be defined
>> differently on different sub-bands.  This implies for instance that one has
>> to have accurate positions which may be different for the different
>> sub-arrays, and for the different sub-bands.
>
> The idea is that the correlator is the backend -- no phasing is needed.
> The entire FOV is available to the gated signal.  Pulsar "mode" is not a
> phased-array mode.


Yes, I was just off confusing myself here.  Sigh.


>> Am I right in thinking this limit of 4 stems from the maximum of 4 phased 
>> sub-arrays per sub-band?  Does this increase if one is willing to spend 
>> fewer than the full number of sub-bands on each pulsar?
>
> The four comes from the 4 timers (though you say 8 which could be the
> case -- the Project book is ambiguous if you ask me!).  In any case each
> BB can be locked to only 1 pulsar at a time, so you are BB limited.

Right.

> Pulsar searches are not done in pulsar mode -- they'd just fast dump mode.
> The pulsar specific hardware is only useful for synchronous (to a known
> period) observations.  If you know the period but not the phase (ie from
> X-ray timing) then you can use the pulsar bins with equal spacing across
> the pulse period.

Right.  I just wasn't sure whether there was anything more to pulsar searching 
than dumping really fast, with lots of channels.

>> Are these likely to be refined during the observation? or is that too painful
>> to contemplate? I'm wondering whether one might start with an even
>> distribution of bins, then zoom in on the phases of interest.
>
> Almost certainly not within a schedule block -- there are many reasons why
> you won't want to automate this!  If this is needed the astronomer should
> reduce the data from scheduling block 1, calculate a new ephemeris and use
> it in a second scheduling block to follow.

That sounds reasonable.  Though as I mentioned in my reply to Brent,
the only real change might be to what's written out by the CBE, in which case
it could all go in the same scheduling block (assuming I understand such
things).

>> Is the ionospheric dispersion likely to be important at the lower
>> frequencies?
>
> it is many orders of magnitude (perhaps 6 or 7?) less important.

Hooray for an easy life ;)

> No phased array needed in pulsar mode.  As far as I know there is no
> bandwidth limits in pulsar mode as a result.

Yep, cf. "mpr's an idiot" above.

>>> 2. How does pulsar mode interact with sub-arrays?
>>
>> See above for some aspects of this.  A related question:
>>
>> * Can one trade phased antennas for phased bandwidth?  I think not, but
>>  this should be checked.
>
> I'm almost certainly sure that you cannot.

And irrelevant here, as you said.


> The concerns I had were:
>
> 1.	Can one subarray apply the pulsar gate on all BBs while the other
> subarray does not?
>
> 2.	In the case that the same pulsar is being observed in 2 subarrays
> at different frequencies, can each get its own peculiar delay (in the
> pulsar sense)?
>
> 3.	Can the software keep track of all of this?
>
> ...

Hopefully Brent can respond to the first two.

> As an addendum to my original message I would like to put up for 
> consideration that "pulsar mode" is not actually an observing mode.  In the 
> current lingo modes are excusive (ie cannot do mosaicing and other mode 
> simultaneously).  Rather I think the pulsar capability can be applied to any 
> existing mode.  It is in Bryan's words "an intent".  If so I'd like to have 
> finer-grained intents : "pulsar timing" and "pulsar imaging". This is mainly 
> for the benefit of downstream software.

I don't think that's right.  Intents are labels which are irrelevant except
for the downstream software.  Gating and binning actually affect the setup of 
the backend (the correlator), and/or which data are stored, so you need to
know them at the time you observe.   On the other hand it doesn't seem like
a "mode" like mosaicing, fast switching, tipping, etc.  I think it's more
nearly a scan attribute (apologies to Dave for getting the term wrong),
like the integration time, which in Dave's scheme I would think would just
go in with the overall Resource settings (like the number of spectral
channels, recirculation factor, and so forth).

            -- Michael