User Tools

Site Tools


hardware:dbbc.currentissues

This wiki is not maintained! Do not use this when setting up AuScope experiments!

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
hardware:dbbc.currentissues [2011/01/10 01:49]
Jamie McCallum
hardware:dbbc.currentissues [2012/01/10 21:47] (current)
Jim Lovell
Line 1: Line 1:
-**DBBC-HB**+**DBBC-HB ​at Yarragadee**
  
-  * Backplane ​issue has been fixed with new PCI7200 card.  +  * Currently working OK. Occasional jumps in delay now seem to be a Mark5 issue (Jan 2012) 
-  * The time difference between the PPSMON output and the maser PPS is drifting very rapidly (~80 milliseconds/​second). The "​PPS"​ led (1st from the bottom) ​is not in sync with the input PPSHowever, ​the "Board Write Enable"​ LED (4th from the bottom) is synchronised. The PPS is of adequate amplitude (+4 V if the input is 50 ohms) as is the 10 MHz input. Both 10 MHz and 1PPS are from the Vremya maserThe drift is obvious when looking at the input PPS and the PPSMON on an oscilloscopeI have had a look at the system clock with a spectrum analyzer and the 1024 MHz peak is present. It appears to be stronger from DBBCHB than from Auscope3 (+21 dB in a 10 MHz span compared to +16 dB from Auscope3) and also appears to have two secondary peaks in the spectrum at 1022 and 1026 MHz (both at  amplitudes of -20 dB). These secondary peaks do not appear in the System Clock output of Auscope3.  +  * Main problem ​is low gain through DBBC Conditioning Module B in the upper X-band channelAt the moment we have an alternative firmware config which puts the upper X-band channels through CoMo A and lower through CoMo BThis is giving good results but the underlying problem still needs addressing.
- +
  
-**DBBC-AUSCOPE2**+**DBBC-AUSCOPE2 ​in Katherine**
  
-  * Timing issues - clock-1024.exe was not starting correctly when DBBC Control was run and this lead to serious timing errors from the PPS, where a drift of ~0.5 microsec/​sec was seen in the PPSMon-GPS difference. Fixed temporarily by restarting clock-1024.exe from C:​\DBBC\bin. The problem has not recurred in such a rapid formbut the PPSmon-GPS output is often drastically incorrect. We have measured an offset of 100-200 microseconds where the maser PPS-GPS is 12 microseconds. pps_sync does not correct this. The problem can sometimes be resolved by power cycling the electronics and reconfiguring. At the best, a slow trend is seen in the PPSMon-GPS, of a few microseconds in tens of minutes. This is still too high for use in geodesy. 
- 
-  * Missing channels - Some channels (9,13) appear to be permanently stuck with the recorded data consisting entirely of -1 (1-bit recording). The problem is not fixed by power cycling the electronics. Other channels intermittently appear distorted and full of weak, spurious tones (1-8). ​ 
- 
-  * LEDs on front panel show that they occasionally go into a fault state without apparent cause. No PPS is seen in the FPGA module and the device requires a power cycle of the electronics to function. The only LED lit up on the fault modules is the 10th from the bottom (10 kHz retuning enable?) 
   * dbbcifc always reads slightly low (52000-54000). ​ We have switched CoMos without make any difference and amplifying the signal does not affect this.    * dbbcifc always reads slightly low (52000-54000). ​ We have switched CoMos without make any difference and amplifying the signal does not affect this. 
-  * This DBBC is currently powered on with 10 MHz & 1 PPS applied but no input IFs.  +  * Otherwise OK
-  CoMos do not seem to have good isolation on the input selector switch. Inputs without any attached IFs can still read as having significant total power. ​+**DBBC-AUSCOPE3 in Hobart**
  
-**DBBC-AUSCOPE3**+  ​Currently in use for IVS observations and seems to be performing reliably although it is necessary to monitor the delay through the system as it can sometimes drift. The channel drop-outs and unusual bandpass shapes described below seem not to occur often. It looks like performance has improved since the front perspex cover was removed from the front of the unit. Perhaps ventilation has been a problem. 
 +  ​dbbcifd power always reads slightly low (52000-54000). We have switched CoMos without make any difference and amplifying the signal does not affect this.  
 +  ​* **This  problem now occurs VERY rarely:** Performance seems ok except that channels 3 and 4 intermittently drop out, with recorded data consisting solely of -1 (1-bit recording). There are no indications of this error state in the LEDs of the front panel. NOTE: as of 4 Nov 2010, not always channels 3 and 4. This time channels 1, 9, 11 and 12 dropped out: \\ {{:​hardware:​before.png|Autocorrelation plot}}. \\ On another occasion channels 1, 2, 9 and 11 dropped out while channels 12 and 14 looked strange: \\ 
 +{{:​hardware:​before2.png|}}
  
-  * Currently in use for IVS testing observations. Performance seems ok except that channels 3 and 4 intermittently drop out, with recorded data consisting solely of -1 (1-bit recording). There are no indications of this error state in the LEDs of the front panel. NOTE: as of 4 Nov 2010, not always channels 3 and 4. This time channels 1, 9, 11 and 12 dropped out: \\ {{:​hardware:​before.png|Autocorrelation plot}}. \\ On another occasion channels 1, 2, 9 and 11 dropped out while channels 12 and 14 looked strange: \\ 
-{{:​hardware:​before2.png|}} 
-  * dbbcifd power always reads slightly low (52000-54000). We have switched CoMos without make any difference and amplifying the signal does not affect this.  
-  * This machine is currently in use (4th October-6th October). Do not make any changes to the configuration until after this IVS run! 
/home/www/auscope/opswiki/data/attic/hardware/dbbc.currentissues.1294624154.txt.gz · Last modified: 2011/10/26 06:37 (external edit)