Field Notes

VSI connectors and data flow (Gino, email 20.01.2011)

What is received by the second Core2 in the 'vsi1' position is shifted by the second Core2 into the
'vsi2' place -- thus the output of the second Core2 will be {vsi1out:own data, vsi2out:previous board}

The agc_if tool

In the Polyphase firmware the agc_if tool modifies settings of IF A, B, C and D. Apparently agc_if can and should be run at the same time as test_poly16. The test_poly16 software does not configure the IF boards itself and neither does it report IF power levels.

To change IF A settings, choose 'a'. For editing IF B, choose 'b' and so on. Next you can change the signal input (example: 'a'->'i'->'2' to set IF A to use input #2), toggle the AGC on/off, choose the filter for the desired Nyquist zone (1=0..512, 2=512..1024, 3=1024..1536, example: 'a'->'l'->'2'), and set the AGC target value (example: 'a'->'c'->'22000).

In the Tunable firmware agc_if settings are overriden by the Control software. It seems both programs should never be run at the same time.

Clock phase calibration with the Polyphase firmware

A test tone at 764 MHz is injected to input 1 of all IF boards. Calibration is run with 'C' in the test_poly16 control program. Prior to calibration, use 'p' to list the total powers of all channels and verify that channel#8 has maximum power while other channels have near zero power. After calibration (~5 minutes) a list of detected optimal phase values for each of the boards is printed. These values can be applied with "f=<boardNr>,<phaseValue>". They should be entered into the C:\dbbc_conf\*.txt file as well.

Note that after 'C' completes all boards remain set to the last tested phase (255 255 255 255). You should use manual "f=..." or restart test_poly16 to apply more proper values immediately after the 'C' run.

Clock phase calibration with the Tunable firmware (Gino, email 20.01.2011)

"There is a dbbc_config_file.txt with calibration setting. Here is reported. The goal of this calibration is to find the best phase relation between data and clock in the internal FPGA capture point. To do so a tone at an almost central frequency in the second Nyquist zone is injected and the 4 bbcs present in one Core2 are tuned equispaced in the entire band widh respect to this central tone. No bbc is tuned to see the tone. When things are correct the tone should not produce a contribution to the total power detected in all the 8 basebands 16 MHz wide (4U+4L). Indeed when phases are not correct spurious and additional components are generated and are visible in the bbcs' bands producing a total power contribution. Hope this could clarify the procedure."

Clock phases can be set manually with "f=<boardNr>,<phaseValue>".

Analog Monitor output

One channel may be viewed on the Analog Monitor output with "m=<boardNr>,<channelNr>". For the Tunable firmware the syntax is "mon=<boardNr>,<channelNr>".

Modifying the phase of a board higher up in the stack will affect the spectrum of a monitor signal copied from farther down from the stack. "Changing the phase in the Nth Core2 will change the phase relation you use to capture data from the monitor bus, with such consequences. Calibration is taking care of information produced and 'resident' only in the board under analysis, the total power. A more clever calibration process is anyway probably necessary."

Mark5C and mode=...

Although Mark5C DRS 0.9 in Mark5B-mode does recognize channel bitmask commands such as mode=0x0000ffff:1; (or in FieldSystem: mk5b_mode/ext,0x0000ffff,1,1), the 5C will in reality ignore the bitmask and in any case records all channels. (Status of 01/2011)

1PPS clock drift on Mark5B+

It has happened that a Mark5B+ connected via VSI to a DBBC will loose 1PPS sync. Even after a dot_set=:force; the 5B dotmon output signal will immediately and visibly drift away from the DBBC 1PPS Monitor signal. In some cases the problem disappears again for a longer time if DBBC electronics are power cycled.

The drift is due to a bad VSI data clock and may be due to two causes:
1) VSI connector not inserted properly, cleaning and re-seating should help. After a new dot_set=:force; you should see the 5B dotmon output stay in sync.
2) if the above did not help, yet power cycling the DBBC seems to fix the issue, the problem is likely a set of missing resistors on the FILA board. These are the 'enable' signals for the LVDS line drivers that drive the VSI cable. On a few FILA board the resistors were missing. Contact Michael Wunderlich for fixing.

Firmware configuration files C:\DBBC_CONF\*.txt

Tunable (DDC) example:

1 dbbc2.bit 684.99 16
1 dbbc2.bit 700.99 16
1 dbbc2.bit 716.99 16
1 dbbc2.bit 732.99 16
1 dbbc2.bit 134.99 16
1 dbbc2.bit 150.99 16
1 dbbc2.bit 166.99 16
1 dbbc2.bit 182.99 16
1 dbbc2.bit 597.00 16
1 dbbc2.bit 682.00 16
1 dbbc2.bit 853.00 16
1 dbbc2.bit 938.00 16
0 dbbc2.bit 597.00 16
0 dbbc2.bit 682.00 16
0 dbbc2.bit 853.00 16
0 dbbc2.bit 938.00 16
55000 55000 55000 55000
0 0 0 0
CAT1 1024

The first number in the tunable version is indicating whether the bbc is present or not. In the DBBC2 this works in groups of 4 (e.g. if you have bbc1 you'll have also 2--3-4 and so on).   This is necessary to the software to know the hardware configuration, number and address of boards to
configure have a dialogue.   The tunable version still don't have this additional possibility to configure the Fila10G, as the polyphase has (even if still needs to be fixed).

Polyphase example:

0 poly_dbbc.bit
1 poly_dbbc.bit
2 poly_dbbc.bit
99 poly_dbbc.bit
99 ACE.bit
99 fila10g.bit
22000 22000 22000 22000
0 0 100 0
CAT2 1024

The first number in the Core2 board number onto which the firmware should be loaded.