[widar-wg] Blanking at subarray changes

[Brent Carlson]

Bruce,

Yes...they will slither on down when enable data flow is enabled.  So,
perhaps blocking frames from the corr chip would be better, and would be
more like "discard frames" in the GigE, as the slithering wouldn't be
delayed.

There is a way to clear the LTA.  "Disable data flow", and then write 0's
to the semaphore table in the LTA.  But, this would leave partially
integrated data in LTA memory, and when dumps come along, would integrate
with it, so that's not good.  So, the above option is probably the best.

--Brent

> I'm getting strong deja vu from this topic.
>
> If the LTA is told to stop sending (via 'enable data flow'), do the
> previously integrated frames in the various phase bins still exist and
> eagerly await an 'enable data flow' to slither on down to the CBE? I
> believe the purpose of the blanking was to give the CBE a cleaner
> transition, no old/new frames mixing together. At the station board
> side, I do a 'Dump-Discard' when a new dump trig is started but this
> has only coarse timing and could still allow some old frames to be
> produced with a new CC configuration.
> At one time we had tried to disable correlation (at the CC), set up
> the sub array, then re-enable correlation. Perhaps we would need a
> simpler way to implement this (i.e. use a single enable mask) or have
> a way to clear the LTA from the LTA interface (to get the required
> timing).
>
> -Bruce
> On Jun 10, 2011, at 2:41 PM, Brent Carlson wrote:
>
>> The mechanism for blanking at the LTA is already in place.  It can be
>> done by disabling correlation in the correlator chip, or in the LTA,
>> by
>> blocking frames coming from the correlator chip.  The former will
>> result
>> in the first output frame having an accumulator overflow condition,
>> but
>> the latter would not have such a problem as the correlator chip would
>> still be humming along and dumping frames, which the LTA just throws
>> away.
>>
>> A simpler (well, set 1 bit instead of 16) way yet is in the LTA, turn
>> off the "Enable Data Flow", which will cause the LTA to stop sending
>> out
>> frames, and ignore frames coming from the correlator chip.  When data
>> flow is enabled again, the first frame coming out will be labelled
>> as an
>> overrun frame, not bad in itself, just indicating that the correlator
>> chip was discarding frames because its output frame buffer was full.
>>
>> So, take your pick.  I think the 2nd way is the cleanest all around.
>>
>> Brent
>>
>> On 10/06/2011 10:30 AM, Michael Rupen wrote:
>>> In testing Martin's new subarray code this morning we noticed that
>>> the output frame rate from the BlBs goes to 0 whenever a subarray
>>> correlator configuration is changed.  This means that one loses data
>>> for ALL subarrays, whenever any subarray has a configuration change
>>> (e.g.,
>>> when you first start up a new subarray).
>>>
>>> The root of this is that blanking is currently done on the GigE chip,
>>> which affects the entire BlB.  (This should mean that BlBs which
>>> are not
>>> used by the changing subarray aren't affected, but we have not
>>> checked that
>>> directly yet.)
>>>
>>> Would it be possible to blank at the LTA instead of at the GigE chip?
>>> or otherwise implement different blanking per CC?
>>>
>>>         -- Michael
>>> ________________________________________________________________________________
>>> There is a web page, used as a document repository, associated with
>>> this list.
>>> The URL for the web page is:
>>> http://listmgr.cv.nrao.edu/pipermail/widar-wg/
>>>
>>
>> --
>> Brent R. Carlson
>> Brent.Carlson at nrc-cnrc.gc.ca
>> Tel: 250-497-2346                  |  Fax: (250) 497-2355
>> Design Engineer                    |  Ingenieur Concepteur
>> National Research Council Canada   |  Conseil national de recherches
>> Canada
>> Dominion Radio Astrophysical Obs.  |  Observatoire federal de
>> radioastrophysique
>> P.O. Box 248, 717 White Lake Rd    |  C.P. 248, 717 Rue White Lake
>> Penticton, BC, Canada V2A 6K3      |  Penticton, (C.-B.), Canada V2A
>> 6K3
>> Government of Canada               |  Gouvernement du Canada
>>
>> "When and where humans are involved, mistakes inevitably happen"
>>
>> ________________________________________________________________________________
>> There is a web page, used as a document repository, associated with
>> this list.
>> The URL for the web page is:
>> http://listmgr.cv.nrao.edu/pipermail/widar-wg/
>
>