[evlatests] [Fwd: Re: Numerology and a historical perspective]

Mike Revnell mrevnell at nrao.edu
Sat Jan 10 12:27:57 EST 2009


DTS info. and plans that may be of interest here.

I have changes to the DTS formatters and deformatters that I am planning 
to deploy soon.

Formatters

The plan is to have new L305s send 10 second timing to the formatters. 
The formatters will then generate 10ms, 1sec, and 10sec timing and send 
it over the high speed data links. For transition antennas which have 
19.2 hz timing the formatters detect this and forward 19.2 timing to the 
deformatters. The new formatters detect which timing they receive and adapt.

Deformatters

Must be able to cope with data from interim modules or new modules. If 
they receive 10ms timing they just pass it on to the correlator. If they 
receive 19.2Hz timing they generate the 10ms, 1sec, and 10sec time 
internally and use the generated time on the correlator interface. 
Generating this time involves getting the offset between TAI and UTC right.

The deformatters in the prototype correlator currently do part of this.

Deploying the deformatter code involves migrating the transition to a 
new OS and FPGA firmware. I have this all written and mostly checked 
out. I should be able to deploy it any time. Exact timing will be driven 
by 3-bit sampler rollout. The OS changes is moving from the bootleg 
antique Slackware I'm currently using to a Red Hat based OS James Robnet 
set up. The main requirement is to move from the Linux 2.4 kernel to a 
2.6 kernel which has much better support for NTP and timekeeping in 
general. This has to do with the TAI-UTC problem.

Deploying the formatter changes will be done concurrent with 3-bit 
sampler rollout. I have the code written and mostly checked out.

If all works according to my plan the DTS will be able to adapt to 
whatever timing basis an antenna is using and make it mostly transparent 
to the correlator.

Mike.

Barry Clark wrote:
> Ray is right - I had totally spaced out.  We need the 19.6 Hz
> to run the phase switching.  Is it possible to install a switch
> to change the frequency?
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [evlatests] Numerology and a historical perspective
> From:
> Ray Ferraro <rferraro at nrao.edu>
> Date:
> Fri, 09 Jan 2009 14:07:21 -0700
> To:
> Barry Clark <bclark at nrao.edu>
>
> To:
> Barry Clark <bclark at nrao.edu>
>
>
> Barry,
>     I would just like to point out that to be compatible with the VLA 
> correlator phase switching at the antenna must occur at the 19.2 Hz 
> rate. I'm not sure where this is done, but I would guess the L302 DDS.
>         Ray
> Barry Clark wrote:
>> Pursuant to the email message below, we have an annoyance that the
>> antenna heartbeat frequency is 19.2 Hz, and the Widar correlator
>> heartbeat frequency is 100 Hz, so that these time references only line
>> up every 1.25 seconds.  I am convinced that this will become an
>> increasing annoyance as we commission Widar.  Rather than writing
>> software to handle the case of misalignments, I think we need to take
>> care of this with a small design change, and that it should be done
>> at this time.  We should change the heartbeat signal to the L302s
>> to 20 Hz.  I would like to see this done on all new L305s.  Existing
>> ones can change when convenient - living with a mixed system will be
>> less disruptive than continuing the 19.6/100 Hz asynchronisity into the
>> future.
>>
>> It is probably least confusing if the MIBs in the LO rack are also
>> changed to 20 Hz.  The drive for the calibration noise sources must
>> remain at 9.6 Hz for compatibility with the VLA baseband system while
>> the VLA correlator is in use, and it is probably better to leave the
>> frontend rack MIBs at 19.2 Hz.
>>
>> It is my belief that the software in the L302 MIBs (and other LO rack 
>> MIBs) will handle a 20 Hz heartbeat transparently, although this needs
>> to be checked.
>>
>> For current VLA operation, scripts generated by obs2script synchronize
>> things with 10 second ticks, which are coincident times of the 20 Hz and
>> 19.2 Hz cycles, so this also should work transparently.
>>
>> I think that probably the best way to proceed with the Executor software
>> is to change it for the 20 Hz rate, and to accept the fact that the
>> antennas with the 19.6 Hz heartbeat may (or may not) have phase jumps
>> when used with scripts which are not synchronized with 10 seconds.
>> Alternately, we could put a parameter in the database saying which type
>> L305 we have, and execute code appropriately.
>>
>> Not quite the right email list for requesting a design change, but all
>> the relevant people listen to this one, I think.
>>
>> Barry Clark wrote:
>>> The heartbeat frequency at the antennas is 19.2 Hz.  This was chosen,
>>> rather than 20 Hz, to avoid a simple ratio relationship with the (then)
>>> ubiquitous 60 Hz.  Heartbeats are synchronized such that a heartbeat
>>> pulse occurs on an even TAI 10s.
>>>
>>> The L302 synthesizers are driven by a 128 MHz signal.  To be 
>>> synchronized
>>> reliably, they must be commanded to sync at integer number of cycles of
>>> this rail.  This occurs on every third cycle of the 19.2 Hz, every 
>>> 0.15625 seconds.  The Executor software selects appropriate heartbeat
>>> pulses to synchronize the L302s.
>>>
>>> The VLA correlator is commanded every 10 seconds, with commands 
>>> taking effect on the even TAI 10 seconds.  EVLA scripts are in UTC; 
>>> the .obs
>>> files from which they are (usually) derived are in LST.  When making 
>>> scripts for the EVLA Executor, obs2script caters to that peculiarity
>>> of the correlator, forcing source changes to occur on the TAI 10s
>>> (with a few interesting exceptions).
>>>
>>> Widar has its own numerology.  Its heartbeat is 100 Hz, anchored to 
>>> UTC.
>>> When we run hand edited scripts that are not synchronized to 10s TAI,
>>> we see phase jumps, almost certainly due to improper truncating when 
>>> these various periods do not line up.
>>>
>>> Possible fixes:
>>>
>>> 1.  Require observations to be synchronized to the shortest common 
>>> multiple
>>> of the intervals.  This is 1.25 seconds.  Problem:  this is too long 
>>> for OTF mosaicing.
>>>
>>> 2.  Change the antenna heartbeat; make the 19.2 Hz change to 20 Hz 
>>> on command.  Problem:  the L302s are sensitive to the line lengths 
>>> of the heartbeat signal.  Problem:  getting the L302s to work 
>>> reliably again after changing to 20 Hz might be traumatic.
>>>
>>> 3.  Software fix in Executor; the commands to L302s could be 
>>> synchronized
>>> differently from those to Widar.  Problem:  something will be doing the
>>> wrong thing for a few milliseconds at source changes.
>>>
>>> 4.  Software fix in Widar.  The information to correct the phases is 
>>> available in the message to Widar.  Problem:  as above,  something 
>>> will be doing the wrong thing for a few milliseconds at source changes.
>>> _______________________________________________
>>> evlatests mailing list
>>> evlatests at listmgr.cv.nrao.edu
>>> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>>>
>>>
>> _______________________________________________
>> evlatests mailing list
>> evlatests at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>>
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> evlatests mailing list
> evlatests at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>   




More information about the evlatests mailing list