[evlatests] EA24 C

Mike Revnell mrevnell at nrao.edu
Thu Oct 11 12:22:22 EDT 2007


This morning I find the aligners back on and happy. This would put 
delays back where they were. I think Rob and company put in the piece of 
cable we've been treating this symptom with.

This morning Kerry found 25 C and D acting up. We disabled the aligners. 
This time we manually adjusted the FIFOs after disabling the aligners. 
To do this one must have a functioning F display. The delays should not 
be far wrong.

For reference here is a summary of what I think goes on.

There is some timing related bug in the DTS module formatters. We intend 
to fix this in the big upgrade we're planning at the deployment of the 
3-bit digitizers. The bug manifests itself when the relative timing 
between some two or more of the modules references, there are 3. This is 
why inserting a cable somewhere clears it up.

This disturbs the frame header information in the data frames on the IF 
fiber which in turn confuses the frame alignment logic in the 
deformatters. We can disable this logic and it settles things down until 
the piece of cable can be installed.

The alignment mechanism is only needed at startup or when some problem 
causes an interruption in data flow into the deformatter. When the 
alignment logic is disabled we need to be watchful for some problem with 
the antennas so we can get things started again.

The alignment logic is turned off at a moment when it is acting up so 
where things stop is more or less random. The FIFOs are quite deep, 32 
words at 16ns each, so the delay change when we do this can be quite large.

When the symptom is treated and the aligner is turned back on the delay 
will go back to where the antenna was before the problem appeared.

We use the baseband spectrum to establish synchronization between 
optical signals carrying the data. Since this is antenna based 
information there is no way to determine what the delay change might 
have been.

Until this morning we haven't made any effort to fix the delay. In 
future when we have to do this we will try to set the delays manually if 
the system is in a mode that gives us a useful fringe amplitude.

Mike.

Barry Clark wrote:
> This is the IF with "schredding".  Kerry Shores realigned the frame
> synchronizer:
>
>   
>> From: Kerry Shores <kshores at nrao.edu>
>>
>>    I looked at the auto-aligner on the Deformatters, it was indeed lost 
>> (we believe this is the cause of the 'shredded levels').  I've manually 
>> aligned the frames, and disabled the auto-aligner.  This should work 
>> fine, until a timing hiccup happens (or somebody resets/power cycles the 
>> timing system).  At which point, the auto-aligners will likely need to 
>> be re-enabled.  Could somebody please verify that the 'shredded levels' 
>> disappeared after ~11:00AM this morning?
>>
>>     
> This resulted in a change in delay by 150 ns.:
>
>   
>> From: Ken Sowinski <ksowinsk at nrao.edu>
>>
>> The delay error looks "large", about 150 ns.  Do you believe
>> it can be that big a change?  If you are still around let me
>> know what you think.
>>
>>     
>
> >From the delay check during startup yesterday, it the delays were found
> wrong by about 150 ns again, returning to their starting point.  Anybody
> know what's going on?
> _______________________________________________
> evlatests mailing list
> evlatests at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>
>   




More information about the evlatests mailing list