FS DBBC3 Operations Manual

1. Introduction

This document describes FS DBBC3 support in the latest FS version, 10.2. It outlines the features and model for FS operations with the DBBC3. Some NOTEs are included to describe how support in FS 10.1 is different. Versions before 10.1 had minimal support for DBBC3s and are not covered here.

The FS supports the DDC_E, DDC_U, and DDC_V personalities.

Note	In FS 10.1: Support for the DDC_E personality is not available. Support for DDC_V versions other than v124 is not available and even for v24 is only correct for very early releases. T_sys fivpt, and onoff support for polarities other than `2` may not be correct.

The appendix Configuring the FS for use with a DBBC3 gives the steps for customizing the FS. The appendix DBBC3 specific environment variables explains the use of those variables. The appendix Verifying polarity and USB/LSB TPI swaps provides methods for checking those two specific issues.

Additional appendices, Minimizing the use of setup procedures, Thread procedure, and Recorder tuning describe features that intended primarily for use with the DBBC3, but can be used with other systems.

Support for several items that utilize the multicast data, including the T_sys monitor display and multicast data logging, is built on DBBC3 multicast unpacking software developed by Dave Horsley (Hobart) using his C struct packing and unpacking code generator (https://github.com/dehorsley/packgen).

2. DBBC3 related commands

The following SNAP commands support DBBC3s. You can access information on the details of the commands with help=command.

bbcnnn — nnn from 001 to 128 — BBC setup and monitoring
bbc_gain — Setup and monitor BBC gains

cont_cal — Setup and monitor continuous calibration configuration

Caution

The syntax of this command is different than the DBBC2 version. Most significantly, the samples parameter has been moved. The meanings of the frequency and option parameters are changed somewhat. There are additional parameters for T_sys filtering.

Note	For FS 10.1, operation was only tested with polarity `2` and for early releases of DDC_U and DDC_V firmware. That support was discovered to be incompatible with some later DDC_V v124 releases. There were also no T_sys filtering parameters.

core3h — Low-level communication with Core3H boards

core3h_mode — Setup and monitoring of Core3H boards

This command has an unusually large number of features, which are described in its help page. You don’t need to be familiar will all the features if you only use it as described in the Setting the experiment mode configuration section below.

Caution

For the DDC_E and DDC_U personalities, the Core3H board uses up to two Ethernet outputs per board. The first output is used for the first eight BBCs; the second, for up to an additional eight. In the DDC_E personality, only the first eight BBCs are available. For each output that is active, the number of channels must be a power of two, from 1 to 16, and all channels must use either only one-bit sampling or only two-bit sampling. If both outputs are in use for a board, they must use the same number of channels and bits per channel.

An unusual feature of this command is that instead of having just the two typical monitor and command forms, it has monitor, checking, and force forms. The latter is most similar to the typical command form, but rarely used.

Click here for more details on the command forms

Monitor form

The monitor form is similar to the monitor form for other commands, which usually have no parameters and show the actual hardware configuration. That will work for core3h_mode, which will query all the boards. In addition, you can query a single board by specifying its number as the first parameter.
Checking form

The checking mode is an unusual feature of this command. Like a traditional command form, it is used with parameters to define the board configuration, but doesn’t command the board with them. Instead, it compares them to the board’s configuration to see if they agree. Any deviations are reported as errors. The actual configuration is reported in the same format as the monitor form. This form is used to check the configuration.
Force form

The force form is similar to the checking mode, but a literal force is specified as the sixth parameter. In this case the board is actually configured. However, this is not recommended for operational use, except as part of determining the correct setup from a schedule, as described in the Setting the boot configuration for the mode subsection below. The force form is most similar to the traditional command form.

dbbc3 — Low-level DBBC3 communication
fb_mode — Setting the FlexBuff recording mode — An alias for mk5c_mode
fivept — Pointing measurements
if — This command was expanded to have conditions for whether each possible DBBC3 BBC and IF is active and whether the DBBC3 firmware is DDC.

Usage examples can be found in the iread, bread, and caltsys procedures in the default /usr2/fs/st.default/d3fbstation.prc procedure library.

Note
In 10.1, DDC is not available as a condition for the DBBC3 and caltsys is not included.
ifx — x from a to h — IF CoMo setup and monitoring
iftpx — x from a to h — IF CoMo total power monitoring
mcast_time — display of multicast time information
onoff — SEFD and antenna calibration measurements
setup_proc — Conditional execution of setup procedure

This command does not have a specific DDBC3 aspect to it, but its use for DBBC3s is important because the setup procedures for DBBC3 racks are very time consuming and their execution needs to be limited. This command is added by drudg to .snp files if selected by the setup_proc option in skedf.ctl control file. Please see the Minimizing the use of setup procedures appendix for more details.
tpi, tpical, tpdiff, tpzero, caltemp and tsys — Support non-continuous calibrations T_sys measurements.

Note
If FS 10.1, formbbc and formif are not supported as mnemonics to specify DBBC3 detectors for channels/IFs that are configured for recording.
tpicd — TPI (multicast) recording control daemon setup

3. FS DBBC3 channel and IF labels

The DBBC3 channel labels are of the form nnns, where:

nnn is the BBC number, 000-128
s is the side-band, l or u

For example, 032u is BBC 32 upper side-band.

The DBBC3 IF labels are of the form ix, where:

x is the IF, a-h

For example, id is IF D.

4. Configuring the DBBC3

This section assumes that when the DBBC3 is booted, it is set-up according to either the “Setting up the DBBC3 for DDC_E mode”, “Setting up the DBBC3 for DDC_U mode”, or “Setting up the DBBC3 for DDC_V mode” document, as appropriate.

4.1. Local configuration changes

This subsection covers changes that may be needed for experiments but aren’t conveyed by the schedule file, yet. Some examples are given below.

4.1.1. Ethernet configuration

The Ethernet configuration of a Core3H board can be set in the DBBC3 boot configuration file. It can be changed on demand with a predefined SNAP procedure with contents such as:

Important

If you place non-private IP address or FQDNs in your SNAP procedures, they will be visible to anyone who can access your log files, e.g., on a log server. Even if this does not violate your local IT policies, it should probably be avoided. If possible, use only private addresses.

core3h=1,tengbcfg eth0 ip=192.168.1.16 gateway=192.168.1.1 nm=27
core3h=1,tengbcfg eth1 ip=192.168.1.17 gateway=192.168.1.1 nm=27
core3h=1,tengbarp eth0 2 00:60:dd:44:47:60
core3h=1,tengbarp eth1 3 00:60:dd:44:47:61
core3h=1,destination 0 192.168.1.2:46220
core3h=1,destination 1 192.168.1.3:46221

Note	The above example is for one board. Settings for multiple boards can be combined in one procedure or one procedure can call a separate sub-procedure for each board.

Tip	A reset and sync is not required for Ethernet configuration changes.

4.1.2. Changing thread numbers

The following command changes the thread numbers on Core3H board 1 for eth0 to 3 (196608/65536) and eth1 to 4.

core3h=1,regupdate vdif_header 3 196608 0x03FF0000

4.2. Setting the experiment mode configuration

Setting the experiment mode configuration is broken into two parts: setting the Core3H board configuration which is covered in Setting the Core3H board configuration subsection below, and setting the rest of the configuration, which happens implicitly when using the Checking the mode subsection farther below.

4.2.1. Setting the Core3H board configuration

Currently, the recommended method for configuring the mode for the Core3H boards is from the DBBC3 boot configuration. This is because that is the only safe method for syncing the boards, which is required for changing Core3H settings that vary with the mode. A consequence is that only one mode that changes the Core3H mode related settings can be used per experiment.

Tip	You can change the Ethernet configuration as described above in the Ethernet configuration subsection above after the boot as long as you don’t change any `destination`s that are set to `none` according to the procedure below.

Note	An alternate method for setting the mode configuration can be found in the appendix Alternate Core3H board configuration method, but at this time it not recommended. Even when it is recommended, it requires manual steps and takes so long that schedules are still effectively limited to one mode.

You can determine the values for your boot configuration yourself, but this can be complicated for an arbitrary schedule unless it uses a well known mode. The method provided in the Setting the boot configuration for the mode subsection below can be used to determine the correct Core3H board boot configuration for an arbitrary mode from a schedule. It is not entirely automatic, but will provide the needed information in a fairly straightforward format.

4.2.1.1. Setting the boot configuration for the mode

This subsection assumes your boot configuration sets up the DBBC3 except for the details of the observing mode. The non-Core3H board mode configuration is handled by the drudg generated setup procedure outside of the boot configuration, e.g., by use of the method in the Checking the mode subsection below. The following procedure can be use to set the boot configuration of the Core3H boards for the schedule mode:

drudg the schedule to make the .prc (and .snp) file. For this example, the schedule is r5012 for station Kk.

Make sure the DBBC3 has the firmware personality and version that you will use for the observation loaded and that equip.ctl and dbbc3.ctl agree with what is in the DBBC3.

Important

Although some modes can be observed with either the DDC_E/DDC_U or DDC_V personalities, the setup is different. The setup for DDC_E/DDC_U will not work for DDC_V, and vice-versa. This procedure will give you a personality, and possibly version, specific setup.

Start the FS
Open a new log. You may like to use a log file name related to the schedule. Just be sure that each time you use this method you are making a new log file. For example:
```
log=r5012
```
Open the experiment procedure library. For example:
```
proc=r5012kk
```
Enable echo output:
```
echo=on
```
Execute the normal Core3H setup procedure, perhaps core3h01, with the force parameter. For example:
```
core3h01=force
```
This command will generate an error when it tries to start with data transmission without the boards being re-synced. This is normal and benign in the current context (but not generally).
Disable echo output:
```
echo=off
```
Close the log file by switching back to the default
```
log=station
```
Extract the needed information with the shell command::
```
core3h_conf /usr2/log/r5012.log
```
The information will be displayed as a series of lines starting with the Core3H board number they apply to and a comma. An example of the output for board 1:
```
1,vsi_samplerate 128000000 2
1,splitmode on
1,vsi_bitmask 0xcccccccc
1,reset
1,vdif_frame 2 8 8000 ct=off
```
Tip
If you did not open a new log before executing the Core3H setup procedure, you can use the last series of these lines. Be sure you start from lowest numbered board used in this mode.

Edit the displayed commands (after the comma) into the corresponding Core3H configuration files.

The files are usually called ddc_E_core3H_<N>.fila10g, ddc_U_core3H_<N>.fila10g, and ddc_V_core3H_<N>.fila10g, depending the personality you are using and how many Core3H boards you have, <N> running from 1 to a maximum of 8.

For only the boards with commands shown in the output:

In the appropriate file, place the commands in the order shown, starting just after the inputselect command, deleting any existing lines with the same commands.

Tip	You may be able to copy-and-paste on the DBBC3 using the builtin editor and using putty to connect to the FS machine.

Note

NOTE : If you need to change the VDIF payload size, you can make the change directly in the vdif_frame commands that you enter, replacing 8000 with your value. Please also read the introductory part of the Handling other VDIF frame payload sizes appendix for information about the error messages that changing the payload size will cause. (You will also need to modify the payload size used by the recorder with an additional jive5ab=VDIF_… , as described in that same section.)

Set the destination lines.

Inspect the core3h01 procedure to determine which masks are non-zero for each board. They appear in the order mask2,mask1 in the core3h_mode command lines. Please be aware that the default (null) value for mask2 is zero; while for mask1 it is non-zero. drudg will insert an explicit zero only for mask1.

For a given board, if only mask1 has a non-zero value, set the destination for output 1 to none. If only mask2 has a non-zero value set the destination for output 0 to none. For all masks that have a non-zero mask, make sure the corresponding outputs (0 for mask1, 1 for mask2) have an IP:port set for the destination.

Tip	For DDC_V, you do not have to set `destination 1 none`. It is disabled by the firmware regardless of how it is set and the FS ignores it.

Use start vdif after the timesync command, removing any stop command that may be present.

For boards with no commands shown in the output:

Use stop after the timesync command, removing any start vdif command that may be present.

Reboot the DBBC3 with this configuration.
Verify the configuration of the Core3H boards.

Using the same procedure library, enter:
```
core3h01
```
There should be no errors reported. If any errors are reported, use the error messages to determine what needs to be fixed in your boot configuration files and try again, repeating until there are no errors.
Proceed to the Checking the mode subsection below. In addition to checking the configuration of the Core3H boards, it configures the non-Core3H board settings for the mode.

4.3. Checking the mode

Before observing, it is essential to check that the mode has been configured correctly. This will implicitly set the non-Core3H board aspects of the observing mode, which is also essential.

Important

The IF target levels need to verified for each observing mode. Please see IF target levels.

The setup procedure can be executed (without the force parameter) to check that the setup is correct. Assuming the schedule procedure library has already been opened as described in the Setting the boot configuration for the mode subsection above (or Configure Core3H boards subsection below), then for example use:

setup01

Caution

Verify that no errors are reported when it is executed. If there are errors, the data may not be recorded properly. This is how the setup is checked within a schedule. This also checks that the personality and firmware version agree with the FS control files.

Tip

There can be a lot of log output from a setup procedure, which can make it hard to identify errors. If you use the erchk window, which only lists errors, it should be easier to identify them. If you don’t already have that window setup (it is more generally useful anyway), directions are include in the Configuring the FS for use with a DBBC3 section below.

Note

If you only want to check the Core3H configuration, you can use the corresponding Core3H configuration procedure instead. For example:

core3h01

This is not recommended for checking the mode, since it does not configure the non-Core3H board aspects of the observing mode to verify that there is no error when commanding them.

5. IF target levels

Due to the very wide input bandpass (4 GHz) of the DBBC3, it is very important have the correct IF target levels. If they are too high, the samplers will saturate, which which will result in gain compression and loss of VLBI sensitivity. The nominal target for 4 GHz BW input signal is 32000 counts. For a 1 GHz BW input signal around 22000 might be good. For 0.5 GHZ input BW signal, 10000 may be realistic.

If you use continuous calibration, you can check for compression by adjusting the target level for each IF while watching the Tsys monitor display for that IF. Once setup for a mode, reduce the target level for that IF from 32000 until the BBC T_sys values reach a reasonable minimum. If you use legacy (noncontinuous) calibration, you can do the same, but you will need to use the caltsys procedure to check T_sys. The onoff command can also be useful for this, adjusting to get the Comp (compression) value close to unity. You can also use a noise source to measure the change in TPI levels, with the gains locked, at different operating levels and find the highest value before it becomes non-linear. All of these methods rely on avoiding gain compression for the TPI counts. It is expected that eliminating compression for them will do the same for the VLBI data.

If you find you need to set target levels other than 32000 and there are values that will work for all your bands and modes per IF, you can set them for drudg using the dbbc_if_target option in skedf.ctl. See st.default/control/skedf.ctl (https://github.com/nvi-inc/fs/blob/main/st.default/control/skedf.ctl) for more information. If you cannot use the same targets for each mode, you will need to modify the IF setup procedures provided by drudg for some cases. We are hoping to have a feature in a future release that will better automate this. If you need such a feature, please contact Ed to explain what is needed for your case.

6. Multicast time-outs

The DBBC3 provides multicast packets, nominally, every second. They provides a wealth of data including for amplitude calibration. A subset of the data is logged, as described in the Multicast logging section below. Sometimes no data may be received for one or more seconds. The FS reports each missing packet as a multicast time-out.

Generally speaking, the Time value in the T_sys monitor display will be shown in inverse video for each time-out (but it can be inverse for other reasons as well). Except when data_valid is off (see below), the FS will report an error for the first time-out that occurs after there have been none in the last 60 read attempts. After the initial report, it will give a summary error report of the time-outs in batches of 60 attempts, ending with a report of no time-outs for 60 attempts, when that occurs.

Note	In FS 10.1, each time-out is reported individually, i.e., there is no summary.

When data_valid is off, the FS will only report a time-out if it does not appear to be associated with DBBC3 command usage.

Note

We believe that there will be no “extra” reports caused by DBBC3 commands when data_valid is off. However, we cannot be sure every case has been caught. There is some chance that there will be extra reports one to three seconds after the most recent DBBC3 communication. Please contact Ed about this if you encounter it. It is easier to fix if you have a, even if only intermittently, repeatable example.

When data_valid is on, i.e., during recording or eVLBI, the FS will report any loss of multicast messages, even if DBBC3 commands were used.

Important

You should avoid use of DBBC3 commands when data_valid is on, i.e., during a scan, since they may cause loss of calibration data.

There seems to be three primary causes of time-outs:

The DBBC3 is busy — Some DBBC3 commands, particularly those associated with the Core3H boards, appear to inhibit the generation of multicast when they are being processed. These are not reported as an error when data_valid is off because they are expected and of limited consequence. They are reported when data_valid is on since they cause loss of calibration data.
Network traffic conflicts — How this affects the multicast is not clear. If there is significant other traffic on the network, there may be collisions that cause packets to be dropped.
Overrun of the 1 PPS — It appears that the generation of the multicast is triggered by the 1 PPS. If the generation takes so long that it overruns the next 1 PPS, making the packet late. That appears to inhibit the generation of the packet for the next second. Whether or not this happens seems to depend on the number of Core3H boards, the firmware version, the DBBC3 CPU speed. There seem to be three regimes for this:
- No overruns — This is the typical case.
- Intermittent overruns — This may happen if the packet generation usually finishes close to but before the next 1 PPS. There seems to be a variable delay of up to about an additional 0.25 seconds that can cause packets to be late.
- Consistent overruns — This occurs when the packet generation always overruns at least the next 1 PPS. This will cause a time-out every other read attempt if just the next 1 PPS is overrun consistently. For example, this is known to happen for DDC_U v126 with eight Core3H boards, for at least some CPUs/clock-speeds.
Usually, log entries for late packets will have a timestamp centiseconds (0.01 seconds) of 19 or less.

The late arrival time will also be visible in the Arrival time of monit7 and in the last field,hsecs (centiseconds), of the mcast_time/0 output, if you happen to catch them for the late packet. For monit7, late arrival times are shown in inverse video. For consistent overruns, the arrival times may, or may not, be before the late arrival limit used by monit7.

When a late packet occurs, an inverse video Time value will occur before the time-out. This happens because when the packet arrives late, data from the previous packet has already been displayed again with the time unchanged (inverse because it did not advance). In the update for the next second, the data from the late packet is displayed (along with the late arrival time, which is inverse video). The Time value will not be inverse video because the late packet, usually, has a different time.

Note
The limit monit7 uses for late arrival times can be adjusted with the -l command line option.

Note
In FS 10.1, arrival times are not shown in the monit7 window and there was no -l option.

7. Firmware version checking

The FS checks that the DBBC3 firmware being used agrees with what is in the FS control files, equip.ctl and dbbc3.ctl. The personality, DDC_E, DDC_U, or DDC_V, is checked first. If the personality agrees, the version for that personality is then checked. If there is a mismatch, the discrepancy is reported along with the string received from DBBC3.

If one of these errors is detected, you should either load the correct firmware/version into the DBBC3 and/or correct the FS control files. What is appropriate depends on what you are trying to do. Ignoring, or masking off the display of, the errors is not recommended.

The checks are made in two different situations:

Multicast data

The version information is checked for each multicast reception. (If there is no multicast being received, these errors will not be reported this way.) The minimum reporting interval is one minute, but can be increased up to 10 minutes with the environment variable FS_DBBC3_MULTICAST_VERSION_ERROR_MINUTES. Please see the Other options section of the DBBC3 specific environment variables appendix below for the details.

Note	In FS 10.1, the interval for reporting version errors detected with the multicast data is 20 seconds and cannot be adjusted.

If for some reason you wish to ignore this very persistent error information, you can use the tnx to suppress it from being displayed. It will still be logged, As an example, if you are getting the errors dn -30 and dn -37 you can stop them from being displayed with:

tnx=dn,-30
tnx=dn,-37

Warning

Suppressing the display of this error information will not prevent possible loss of data and/or other error messages if the firmware/version in the FS control files doesn’t agree with what is loaded in the DBBC3.

Use of the core3h_mode command

The core3h_mode command checks the version in the two cases:
- For core3h_mode=end commands, with or without the force parameter being used.
  
  This command is the last command executed by drudg generated Core3H setup procedures. A firmware/version error will be nearly, in some cases actually, the last error shown. That should help make it easier to identify.
- A core3h=n,…,force command.
  
  An error is reported for these commands in case one of them is used by itself. This also maintains the historical precedent of checking the version whenever the formatter is configured.

8. Control files

8.1. equip.ctl

For DBBC3 use, the rack type in equip.ctl should be dbbc3_ddc_e dbbc3_ddc_u, or dbbc3_ddc_v depending on the firmware that is loaded.

Note	For FS 10.1, `dbbc3_ddc_e` is not supported.

8.2. dbbc3.ctl

The DBBC3 specific control file parameters are in the dbbc3.ctl control file. An example of the contents is:

Note	In FS 10.1, the second non-comment (and its associated preceding comment) line below, for the DDC_E firmware version, is not present.

* Two fields: BBCs/IF (8, 12, 16 or nominal (U:16,EV:8)), IFs (1-8)
  nominal 8
* DDC_E firmware version (v121 or later, but DDC_E starts at v126)
  v126
* DDC_U firmware version (v121 or later, but DDC_U starts at v125)
  v125
* DDC_V firmware version (v121 or later, but DDC_V starts at v124)
  v124
* mcast delay 0-99 centiseconds
  57
* setcl board
  1
* DBBC3 clock rate, >= 0, but DDC only supports 128
  128

Note	The use of `nominal` for BBCs/IF is recommended.

8.3. dbbad.ctl

The dbbad.ctl file was expanded for use with DBBC3s. For the DBBC3 it can now include the multicast address, port, and the interface. If the last three parameters are omitted, receiving multicast data is disabled. If there are only comments in the file or the file is empty, use of a DBBC3 will be disabled. An example of the contents (commented out) is:

*dbbad.ctl example file
* one uncommented line with up to six fields:
*    host(IP address or name)
*    port(4000)
*    time-out(centiseconds)
*    multicast address
*    multicast port
*    multicast interface
* If there are no uncommented lines, DBBC(2)/DBBC3 access is disabled.
* For DBBC(2), the first three fields are required and no more can be used.
* For DBBC3, there must be either the first three fields or all six. If the
*    final three are missing, multicast reception is disabled.
* Using an IP address instead of a name avoids name server problems.
* DBBC2 example:
*  192.168.1.2 4000 500
* DBBC3 example:
*  192.168.1.2 4000 800 224.0.0.19 25000 eno2

8.4. skedf.ctl

The skedf.ctl file now includes new options and expansion of some options for DBBC3 support. The are listed in the drudg support section below. More discussion of the two new DBBC3 related options can be found in the Minimizing the use of setup procedures and the Thread procedure appendices below. The details of the syntax for all the options is available in the /usr2/fs/st.defaul/control/skedf.ctl example file.

9. Tsys monitor display

The T_sys monitor display (monit7) is organized per IF and updates at a 1 Hz rate. The displayed information includes: LO, time, multicast arrival time, time difference between DBBC3 and the FS, PPS delay, T_sys and polarization for each IF/Core3H board as well as BBC frequencies and T_sys values. By default the display will cycle through the appropriate IFs, dwelling for two seconds on each. It is designed to provide useful information without operator intervention. The operator can adjust the display as desired using the features described in the Commands subsection below.

monit7 has three command line options:

-h — print command line option help output
-l n — change the late arrival time limit from 20 to n centiseconds. The range is 0-100, 0 disables late arrival processing, 100 marks all packets as late. Arrival times less than the limit are considered late. The interpretation of arrival times is discussed in the section Multicast time-outs above under “Intermittent overruns.”
-r — reverse the foreground colors (swapping white and black) for cyan, green, yellow, red, and blue backgrounds.

If there is an error when the options are parsed, an explanatory message is printed, then the program pauses for 10 seconds before terminating. This gives the user a chance to see the message if the window it is in closes automatically when the program ends.

Note

In FS 10.1:

The polarization and the multicast arrival time are not shown. In place of the arrival time, the VDIF epoch is shown as --. The epoch was expected to be available but has not been included in the multicast yet.
For DDC_V firmware versions after v124, Time is incorrectly shown as 00:00:01 on the first day of the current VDIF epoch and DBBC3-FS is shown as dollar signs (too big to fit). Normally for DDC_V firmware no time would be available. There was a misunderstanding about whether it would be included for these later versions.
There were no command line options for monit7.

Except for Time, the DBBC3 based data are from the previous second’s multicast. (Hence for continuous calibration, the T_sys values are from two seconds in the past.) For DDC_V firmware, time is not available in the multicast so the message arrival second is used instead.

If the system is operating normally, Time shows a value one second more than for the previous second’s multicast to avoid confusion with times displayed in other windows. (Logged values of the time are the raw received values.) This leads to the somewhat odd situation that for a Core3H board that is not synced, with non-DDC_V firmware, its Time value will be shown as 00:00:01 on the first day of the current VDIF epoch.

The Time value is shown with inverse video if it is not changing, i.e., it is not advancing. Typically, this happens for multicast time-outs, but may also occur for non-DDC_V firmware for other reasons. An example of the latter is if one or more of the Core3H boards is not synced. When the time is inverse video due to a lost (or late, see below) message, the data displayed will be from the last received message, i.e., it will be stale.

The DBBC3-FS time difference, in seconds (positive if the DBBC3 time is later than the FS), is shown in inverse video if it is not zero. For DDC_V firmware, DBBC3-FS is shown as ------.

The Arrival value is the centiseconds (the 0.01 seconds) of the arrival time of the multicast message. Generally values of 20-99 indicate that the message arrived on-time in the second it is for. Values of 0-19 generally indicate that the message arrived late, i.e., are from the previous second, and are shown in inverse video. If the multicast was late, the Time and the DBBC3-FS values are increased by one to compensate. The limit in monit7 for when an arrival time is considered late can be adjusted with the -l command line option.

If a message is late in arriving, the time will be shown in inverse because there is no new data available when the display is updated. The late message inhibits the DBBC3’s next multicast causing it to be lost. The late message will be displayed in its place. That will display a new Time value, removing the inverse video. In this case, as well as for a message that is simply missing, Time will be inverse for one cycle. Unlike for a simply missing message, it will be inverse before the loss of the message is detected.

If the LO and its polarization are defined for the displayed IF, the polarization will be shown as (L) or (R).

Note

(L) or (R) are displayed regardless of what polarization pair is in use: Left/Right, Horizontal/Vertical, or X/Y. Following the usual alphabetical order convention within a pair: LR, HV, and XY, you can assume: L=H=X and R=V=Y. Until the FS is updated to recognize pairs other than Left/Right, you need to know which pair is active to interpret what is shown.

Note	In FS 10.1: The polarization is not shown. The late packet arrival processing and monit7 command line switch `-l` are not included.

9.1. Modes

The T_sys monitor display has three modes that affect how T_sys data is displayed:

Rec shows IFs with channels configured for recording

Only BBC T_sys fields for channels being recorded are populated. This is intended for normal observing.
Def shows IFs with defined LO values

All BBC T_sys fields on defined IFs are populated. This may be useful for pointing or calibration runs.
All shows all IFs

If no IFs are defined and no channels are being recorded (e.g., at FS startup), T_sys fields for all side-bands are blank.

By default, if any channels are configured for recording (selected by the bit masks in the core3h_mode commands), the display will go into the Rec mode. If there are no channels being recorded, but there are LOs defined for some IFs, it will go into the Def mode. If neither the Rec nor Def mode is triggered, it will go into the All mode and automatically change to one of other modes as appropriate. It is also possible to change to the All mode from Rec or Def with a single character (l) command. Another l will toggle the display back to the appropriate non-All mode. The current mode is displayed in the upper right hand corner.

Note

During the transition of configuring the Core3H board between core3h_mode=begin and core3h_mode=end, which channels are being recorded is not fully defined. The T_sys display will show the most recently selected channels (new or old) to avoid having the values disappear momentarily if the old configuration is re-commanded.

9.2. Tsys values

There are two regimes, described below: Continuous calibration and Legacy (noncontinuous) calibration.

9.2.1. Continuous calibration

For all displayed (non-blank) BBC T_sys fields, the values will be shown if they can be calculated. If they can’t be, a hint, in inverse video, for the cause of the problem will be displayed in the corresponding field instead. There may be more than one issue, but only the first encountered is reported. The order is:

N bbc — the BBC is not configured
N lo — the LO is not defined
Ntcal — no T_cal value was found
N cal — continuous calibration not enabled (and a legacy measurement has not been made yet)

Finite values outside of the range, -999. to 999.9, which won’t fit in the available field width, are displayed as dollar signs, $$$$$.

The T_sys values are calculated using the averaging and filtering methods described in help=cont_cal. Negative (including out-of-range) values as shown in inverse video, unless colorization for filtering overrides that (see below). Invalid and out-of-range data are always shown whenever they occur.

Invalid data is shown with a cyan background. The cases are:

If the BBC “on” and/or “off” TPI values overflow (65536), ovrfl is shown.
If the “on” and “off” TPI values are zero, tpi=0 is shown.
If the “off” TPI value is zero, off=0 is shown.
If the “on” TPI value is zero, on=0 is shown.
If the “on” and “off” TPI values are equal (and not zero), inf is shown.

If filtering is in use, there is a green background when 1-2 values have been rejected, or clipped, in a row; yellow, 3-5; red; 6 or more. Once in the red clipping zone, you may also see the background transition to blue for one cycle to show there has been auto-reset (see help=cont_cal for information on auto-reset). Invalid results (infinity, overflow, and the “off” and/or “on” values being zero) and out-of-range positive and negative values are still displayed as such and are not included in the clipped count.

For certain reverse video terminals, for example with the normal FS black/linen settings for foreground/background, the white and back foreground colors are swapped when the background is cyan, green, yellow. red, and blue. To get the intended foreground colors, you can use the -r command line switch with monit7. Unfortunately, it is not possible for monit7 to detect the need for this automatically. If colors are not available for the terminal, inverse video is used instead.

Note

In FS 10.1:

Nccal is used in place of N cal and only applied to continuous calibration.
Averaging and filtering are not available.
All invalid values (negative, infinity, overflow) are displayed as dollar signs.
“off” and/or “on” TPI values being zero are not identified as invalid.
The monit7 command line switch -r is not available.

9.2.1.1. Diagnosing problems

With the way T_sys data is displayed, certain problems can be readily identified as the values update:

All, or most, values are negative — the calibration polarity is incorrect
All, or most, values are very large positive or negative values, including dollar signs, perhaps with some inf mixed in — the diode is not firing. You may also see some clipping and auto-resets if you are using filtering and have significant RFI.
Some fields have overfl — the gain is set too high for those BBCs
off=0 is seen — the FS has continuous calibration set to “on”, but the DBBC3 has it “off” (legacy).
on=0 is seen — the FS has continuous calibration set to “on”, but the DBBC3 has it “off” and the DBBC3 has polarity 2.
tpi=0 is seen — This may appear in some situations when the DBBC3 firmware is being reloaded.

Turning off averaging (setting the samples parameter of cont_cal to 0), can be useful for troubleshooting. You will see the T_sys values calculated sample-by-sample with no averaging or filtering.

Note

In FS 10.1, the error conditions that are identified are all shown as dollar signs and thus cannot be distinguished. The most likely problems in that case are the polarity being wrong or the noise diode not firing. The T_sys values being unrealistically low could be a symptom of the FS having continuous calibration “on”, but the DBBC3 having it “off”. Examining the raw count data, either with the BBCnnn commands, or from logged multicast data, can help identify the problem.

9.2.2. Legacy (noncontinuous) calibration

Legacy calibration refers to explicitly turning the noise diode on and off to make calibration measurements. Incorrect values (negative, infinity, and overflow) and for BBCs or LOs not configured are displayed as dollar signs, $. If the T_cal is not defined, Ntcal is shown in inverse video. If no measurement has been made yet, N cal is shown in inverse video.

Note	When legacy calibration is set (`cont_cal=off,…`), the polarity is forced to `0` to make sure the TPI data will populate the expected fields in DBBC3 command responses and multicast data. A warning is issued if this is different than the user requested polarity.

Note	In FS 10.1, information for legacy calibration T_sys is not displayed in monit7 and the polarity is not forced to `0`.

9.3. Commands

The T_sys display accepts several one character commands:

a-h — show only that IF, up to the maximum defined in dbbc3.ctl

This might be useful, for example, when troubleshooting a single IF.
n — next IF, wrapping at the end. Single IF display is entered if not previously selected.
p — previous IF, wrapping at the end. Single IF display is entered if not previously selected.
1-9 — seconds of display time for each IF (default is 2)
i — toggle display of IF or RF frequency for BBCs (default is RF if the LO is defined; IF, if not)

If no LO is defined for an IF, it will not be possible to display the RF frequencies for the corresponding BBCs.
l — toggle between All and Rec/Def modes (see the Modes subsection above for defaults)
0 — reset to all defaults
? or / — show help summary
Ctrl+c — exit
Any other key (e.g., space) — resume cycling

Note

In FS 10.1:

Esc can also be used to exit. Some key combinations, e.g., Ctrl+Alt+↓ generate escape sequences. Thus, if they are used while monit7 has the focus, they will probably cause it to exit.
If one IF is manually selected before the IF and BBC configuration was defined (or at startup of the display window before any IF had been displayed), it is not be possible to toggle between display modes until cycling has been restarted.
In some cases, no longer active BBC T_sys fields are not cleared.

10. Checking DBBC3 time

The mcast_time command should be placed in the local midob procedure to monitor the time in the DBBC3 for each scan. An error will be reported if the multicast data is more than 20 seconds old. For DDC_V firmware, mcast_time, cannot report the time, but will still report the pps_delay. For non-DDC_V firmware, an error will be reported if any Core3H board’s time differs from the FS time.

For DDC_V firmware, the dbbc3=time command can be used. However, the output can be difficult to interpret because the boards may be sampled in different seconds.

Note	We expect that future firmware versions, possibly beginning with v130, will report the VDIF epoch in the multicast. In that case, `mcast_time` will report if there is a VDIF epoch mismatch between the boards. Other checks may also be added in the future.

11. Setting FS time

It is expected that normally the FS computer will be using NTP and the FS time model will be set to computer (see /usr2/fs/misc/ntp.txt for more information). If good NTP servers are available, that should give the best time in the FS. The setcl program should not be used with DBBC3 and NTP. The best way to monitor DBBC3 time is with the mcast_time command, which should at least be placed in midob and can of course be used manually as well.

No suitable NTP servers may be available either because network connectivity is poor and/or there are no local functioning NTP servers. In that case the FS program setcl can be used with non-DDC_V versions to set and adjust FS time (see misc/fstime.txt for the general information).

The implementation of setcl for the DBBC3 depends on two values from the dbbc3.ctl control file:

The delay of the multicast

This is the delay for when the multicast arrives after the 1 PPS. It seems to be fairly stable for a given configuration. It does vary with the number of Core3H boards installed, the firmware loaded, and the DBBC3 CPU speed.

The value in dbbc3.ctl can be adjusted as appropriate. It should be easy to measure it for a given system when NTP is available, using the output of the mcast_time command. The system will need to be synced to NTP and the computer model selected in time.ctl. In this case, the last parameter, hsecs (centiseconds), on the mcast_time/0 output is the value to put in the file; it may vary at the few centisecond level. (If setcl it being used, it will probably work to subtract the last value on the #setcl#model/old from hsecs before putting it in the file.) You can also get the value from the timestamps of logged multicast data or the Arrival value of the T_sys monitor display (monit7).

Tip

You will not be able to get a suitable value for the delay if the multicast packet generation is overrunning the next 1 PPS as described in the Multicast time-outs section above. If setting the FS time is needed in such a case, please contact Ed, a patch can be provided. If you only get multicast time-outs rarely, you probably don’t have this problem.

Note	In FS 10.1, the `Arrival` value is not available in monit7.

The board number to use for measuring the time.

There can be up to eight to choose from. Board 1 will be in all systems and should be adequate for the purpose, but which board is used can be changed in the control file if need be.

Note

setcl will only be able to get a useful time from the selected board if it is synced. setcl detects a lack of sync when the Core3H board’s time in the multicast is 00:00:00 or 00:00:01 on the first day of the current VDIF epoch. As a result, twice a year for about two seconds each, setcl can incorrectly think the board is not synced. Each run of setcl tries to get the time for up to four attempts, each for a different second, so even if the first two tries incorrectly show the board as unsynced, a subsequent attempt should be okay. A lack of sync will also be shown as unsynced in the core3h_mode command monitor output.

Using setcl to set the FS time this way will only be useful to level of stability of the delay of the multicast. Network congestion may also cause variations, but hopefully will be minimal in situations where this method is needed.

Even if there are significant variations, even a significant fraction of a second (which seems unlikely), in the arrival of the multicast, the clock model determined should be useful. Individual offset measurements should be fairly accurate. If the clock model is determined over a significant amount of time, a day or more, the fractional error in the model rate should be small. The use of adjust option of setcl in each midob should keep the FS close to the correct time. In any event, it should be good enough to run a schedule. It should be better than any other approach without NTP. Since the DBBC3 will be running on the correct time, small errors in the FS time should not cause problems unless the scans are very short.

12. Multicast logging

Logging of DBBC3 multicast recording is controlled by the tpicd command. It will automatically be enabled by drudg generated setup procedures. When logging is enabled, for each multicast message received (nominal 1 Hz rate), the following information, shown with their log entry labels, is logged:

The arrival time of the message — represented by the time-tag of the log entry with centisecond precision

The fractional seconds should agree with the last value, hsecs (centiseconds), on the mcast_time/0 line with small variations at the centisecond level.

time — for each Core3H board in the system

Note

In FS version 10.1 for DDC_V firmware versions after v124, the time is incorrectly logged as 00:00:01 on the first day of the current VDIF epoch, except for board 5 for which the arrival time of the message will be logged. Normally for DDC_V firmware no time would be available. There was a misunderstanding about whether it would be included for these later versions.

pps2dot — (pps_delay) in nanoseconds for each Core3H board
tpcont — only if continuous calibration is in use — TPI counts for each BBC and IF configured for recording

The counts are given in the order of diode on then off
tpi — only if continuous calibration is not in use — TPI counts for each BBC and IF configured for recording
tsys — only if continuous calibration is in use — T_sys for each BBC and IF configured for recording

The T_sys values are calculated using the averaging (and filtering) method described in help=cont_cal. They are logged every samples (from the cont_cal command) iterations of the cycle period for the tpicd command (see help=tpicd). In other words, the T_sys logging interval is the product of samples times cycle. Normally, the value of cycle should be 100 centiseconds (one second), resulting in T_sys being logged every samples seconds.

When averaging is turned off, invalid (overflow, infinity, and “on” and/or “off” zero TPIs) and out-of-range values are logged as dollar signs, $. When averaging is turned on, the same invalid values are logged as dollar signs only if no valid in-range values have occurred. Negative values indicate that the polarity selected with the cont_cal command is wrong.

Note
For FS 10.1, negative T_sys values are recorded as dollar signs, $, and averaging (and filtering) is not implemented.

Even when not being logged, multicast data is normally being received. A subset can be seen in the T_sys monitor display. For continuous calibration, the current values can be displayed in the log display window (and logged) at anytime by using the command tpicd=tsys.

Note	By default, the plog utility will push both reduced logs, with the multicast data squeezed out, and compressed full logs. Please see `plog -h` for more information.

13. drudg support

The DBBC3 related drudg features include:

Support for up to eight IFs (a-h) with up to 16 dual side-band BBCs each (overall 001-128) for VEX (.vex) schedule files.

Support for up to two IFs (a and b) with up to eight dual side-band BBCs (001-008) on IF a and up to eight dual side-band BBCs (009-016) on IF b for Mark IV (.skd) schedule files.

Note

For a .skd schedule that would normally have a number of channels for an IF that is not a power of two, the channels for that IF will need to be increased to the next power of two. For example, for S/X: X-band using 10 channels will need to be expanded to use 16 (or reduced to eight); S-band using six channels will need to be expanded to eight. The different set of channels to be recorded can flow from the catalog, so their use could be automatic for the scheduler and the station. These are just examples that will allow recording. Other adjustments may be needed for efficient media use, data transfer, and correlation.

The appropriate DBBC3 related commands are used in setup procedures.
New skedf.ctl options setup_proc and vdif_single_thread_per_file as described in the Minimizing the use of setup procedures and the Thread procedure appendices.
drudg inserts a mk5c_config or fb_config procedure call into the setup procedures when the selected recorders are Mark 5C or FlexBuff, respectively. Please see the Recorder tuning appendix for the details.
The following previously DBBC2 specific skedf.ctl options can also now be used for DBBC3s:
- cont_cal
- cont_cal_polarity
- dbbc_if_targets
- dbbc_bbc_target
- default_dbbc_if_inputs
The full syntax for these options can be found in the example /usr2/fs/st.default/control/skedf.ctl file.

Appendix A: Configuring the FS for use with a DBBC3

This appendix provides the steps needed to configure the FS to support a DBBC3. You must have version FS 10.1, or later, installed before using these directions. All steps, except as noted, are to be executed as oper.

Update equip.ctl.

Change your rack type to dbbc3_ddc_e, dbbc3_ddc_u, or dbbc3_ddc_v, as appropriate.

Note
For FS 10.1, dbbc3_ddc_e is not available.
Update dbbc3.ctl.

Update the dbbc3.ctl control file for the details of your DBBC3. The comments in the /usr2/fs/st.default/control/dbbc3.ctl file may be helpful for determining what values to use. You can also refer to the dbbc3.ctl subsection above.
Update dbbad.ctl.

Insert the correct IP address and port for your DBBC3 in the (only) non-comment line. Add additional fields to increase the number to six, using the correct information for the multicast data. Please see the dbbad.ctl subsection above, or /usr2/fs/st.default/control/dbbad.ctl, for an example. The example’s multicast address and port may be correct. The multicast interface used is usually your primary interface, typically eno1 or eth0.

Update /usr2/control/skedf.ctl.

You should probably add use_setup_proc yes.

This is recommended because the setup for a DBBC3 may be long enough to interfere with timely schedule execution. This feature is described in the Minimizing the use of setup procedures appendix.

Consider whether to add the vdif_single_thread_per_file option and how to set it.

This probably depends on what correlators you are sending your data to and how they want the threads organized. The option and how to use it are described in the Thread procedure appendix.

Note

If you are using a jive5ab version before v3.1.0-rc1 and use the single-thread-per-file option, you should remove the scan_check command from your checkmk5 and/or checkfb procedure as described in the Thread procedure appendix. Upgrading to v3.1.0-rc1 or later is recommended to eliminate this complication.

Consider adding or updating other DBBC3 related options.

They are:
- cont_cal
- cont_cal_polarity
- dbbc_if_targets
- dbbc_bbc_target
- default_dbbc_if_inputs
Consider copying the new or updated explanatory comments for the new and updated parameters from the example file (/usr2/fs/st.default/control/skedf.ctl) to your local copy.

This may help if you need to make more changes later.

Update your station procedure library.

To make a comprehensive update will require some care and time. Both quick start and more complete options are presented below:
1. In the short-term, with pfmed, you should:
  1. Add the mcast_time command to the midob procedure.
  2. If you have not already done so, add mk5c_config and/or fb_config procedures, depending on what recorders you will be using.
    
    Initially, these procedures can be empty, but you can add commands as appropriate. This is described in more detail in the Recorder tuning appendix.
2. In the long run you will need to think about how to handle updating the station library in a more systematic way. There are two basic methods as described below:
  1. Continue what was started with the short-term solution above and modify your station library to use the DBBC3.
    
    You will probably want to update many other procedures or replace them with DBBC3 versions. The example/default DBBC3 station procedure library is /usr2/fs/st.default/proc/d3fbstation.prc. You can place a copy in your /usr2/proc/ directory with (adjusting the target file name appropriately to avoid overwriting an existing file; use 18 (in FS 10.1: eight) characters or less for the part before .prc:
    
    cd /usr2/proc cp /usr2/fs/st.default/proc/d3fbstation.prc d3fbstat.prc
    
    You can the use pu commands in pfmed to remove old procedures in your station library and st to copy replacements (or additional procedures) from d3fbstat (or whatever name you used). These might include iread and bread. In other cases, you may need to make a detailed comparison to determine how to modify the version in your station library. You should use pfmed commands ed, emacs, or vi to edit procedures.
  2. Replace your station library with the DBBC3 version.
    
    This method is particularly well suited for installing a new system but can be useful for updating an existing system as well. If the FS is running, terminate it first. Then use the commands (adjusting the target filename in the mv command appropriately to avoid overwriting an existing file; use 18 (in FS 10.1: eight) characters or less for the part before .prc:
    
    cd /usr2/proc mv station.prc statold.prc cp /usr2/fs/st.default/proc/d3fbstation.prc station.prc
    
    If there are any procedures you want from your old station library. You can copy them from statold (or whatever name you used) with the st command in pfmed. You should use pfmed commands ed, emacs, or vi to edit procedures.

Setup the DBBC3 T_sys display window (monit7)

Update clpgm.ctl.

Compare your local copy to the example

cd /usr2/control
diff clpgm.ctl /usr2/fs/st.default/control/ | less

and consider whether and what changes you should make. Typically, the new line for monit7 would be added to your local copy.

Tip	If you are familiar with vimdiff, you may find it a more convenient way to compare files and update your local copy. Like vim, vimdiff may be challenging to use until you are familiar with it. Some help is available from web searches. Don’t use it if you aren’t comfortable with it.

Update stpgm.ctl.

If you are using the display server and you want to have T_sys display (monit7) start automatically with each client (including at FS start up), add a line for it to stpgm.ctl. The easiest way to do this is to make a copy of the line for monit2 and update for monit7 (changing 2s to 7s). If you don’t have a line for monit2 in your stpgm.ctl, you can use the one in the example file, /usr2/fs/st.default/control/stpgm.ctl, as a guide.

Add the erchk window (optional)

If you aren’t already using the erchk window, its use is recommended to make it easier to identify error messages. This can be particularly helpful with a DBBC3 to make it easier to see any errors in the mode configuration checking for the Core3H boards.
1. Update /usr2/control/clpgm.ctl.
  
  The easiest way to accomplish this is to copy the corresponding line in /usr2/fs/st.default/control/clpgm.ctl to your clpgm.ctl.
2. Update /usr2/control/stpgm.ctl.
  
  If you are using the display server and you want to have the erchk window start automatically with each client (including at FS start up), add a line for it to stpgm.ctl. It is recommended. The easiest way to accomplish this is to copy the corresponding line in /usr2/fs/st.default/control/stpgm.ctl to your stpgm.ctl.

Update your local rc files:

Update ~/.Xresources.

Add the needed lines

Compare your local file to the default:

cd ~
diff .Xresources /usr2/fs/st.default/oper | less

The new lines for monit7, and optionally erchk if you are adding it, should be added to your local file.

Note

The default geometry resource in /usr2/fs/st.default/oper/.Xresources for monit7 handles having up to 16 BBCs per IF. If you have fewer, you might want to adjust the resources in your local file according to the Tsys monitor display geometry values table below.

Table 1. Tsys monitor display geometry values
BBCs/IF	width-by-height
8	`24x13`
12	`24x17`
16	`24x21`

Tip	If you vary the number of BBCs per IF in your configuration, you can setup the geometry for the most you use and can resize the window to a smaller size after it is opened or leave it as is, whatever you prefer.

Adjust the position of the windows.

Fine tuning the positions in the geometry values is probably best done with the windows open while the FS is running. So you may want to defer the tuning until you restart the FS.

You can find an effective strategy to help with setting the geometry values for an xterm window (and others with a name property) in the Setting geometry values in .Xresources section of the Installation Reference document.

If you use the default window manager for the console, update ~/.fvwm2rc.

Compare your local file to the default:

cd ~
diff .fvwm2rc /usr2/fs/st.default/oper | less

The new lines for monit7, and optionally erchk if you are adding it, should be added to your local file.

Note

If your file uses Style "monit*" NeverFocus to prevent the monit<n> windows from getting the focus (it is recommended), you will need to add the Style "monit7" ClickToFocus line (or Style "monit7" MouseFocus, if you prefer) in order to be able use the T_sys display monitor commands on the console.

Log out and back in to put these changes into effect.
You should make the corresponding changes for prog while logged in as prog. Unless prog's rc files have special customizations, this might be done by copying oper's updated files.

Start the FS, or restart it if it was already running.
Determine what DBBC3 specific environment variables need to be set.

A reasonable first approach would be to not set any at this point, but you should revisit this issue once you have the FS otherwise working with the DBBC3. A full discussion of the variables can be found in the DBBC3 specific environment variables appendix below. In particular, the section Determining what values to use may be helpful.

Appendix B: DBBC3 specific environment variables

Several environment variables are defined for use with the DBBC3. These are generally broken into two groups, described in sections Swaps of TPI and gain values, and Other options. These environment variables exist to help the end user adapt to variations in DBBC3 behaviour between different firmware releases. Several variables are provided to give flexibility for handling different situations.

Note	In FS 10.1, none of these environment variables are available.

While some firmware releases may require setting a subset of these variables, we have set the default values so that the end user should not typically need to define them. We have verified that they should not need to be defined for the firmware releases in the Tested DBBC3 releases table below.

Table 2. Tested DBBC3 releases
Personality	Version	Release date
DDC_E	v126	2022-10-25
DDC_U	v125	2021-04-29
DDC_U	v125	2021-08-19
DDC_U	v126	2022-11-03
DDC_V	v124	2021-09-26
DDC_V	v125	2022-09-12

Other releases may require setting some environment variables. In particular, some earlier releases of DDC_V v124 may require FS_DBBC3_MULTICAST_BBC_ON_OFF_SWAP to be set to 1, when the continuous calibration polarity is 2.

If you have experience with releases other than those listed in the Tested DBBC3 releases table above, please email Ed with the polarity you are using, which environment variables you needed to define, and their values, or if you did not need to define any. What is needed (or if nothing is needed) for that release will be added to this document. To the extent possible, we will build those settings into the FS, but we are only able to do that per personality and version, not release date.

For all these environment variables, if they have been set to a non-default value, the actual value set, followed by the default in parentheses, will be included in the log header each time a log is opened or reopened.

B.1. Determining what values to use

A reasonable first approximation is to not set any of these environment variables. Then some can be set as needed. For information on how to set environment variables, please see Setting environment variables in FS environment Variables document.

Tip

What needs to be set may vary by firmware personality, version, and release date. If you only use one release, you can set the values in your ~/.profile or ~/.login file, as appropriate. If you use more than one release, you may want to set the values that need to be changed between releases in either a script or an alias that you use to run the FS for that release.

It should not be necessary at this time to change any of the USB/LSB swaps from the default. So far, our experience is that all personalities and versions need these swaps. If there is any question about this, please verify it using, for example, USB/LSB TPI swap status in the Verifying polarity and USB/LSB TPI swaps appendix.

You can detect if additional cal-on/cal-off TPI swaps are needed from results without any of the environment variables set. Assuming you are using the correct polarity (see Continuous calibration polarity in the Verifying polarity and USB/LSB TPI swaps appendix), then if:

T_sys for the BBCs in the monitor display window is negative, you may need to define FS_DBBC3_MULTICAST_BBC_ON_OFF_SWAP as 1.
T_sys for the IFs in the monitor display window is negative and your polarity is 0, you may need to define FS_DBBC3_MULTICAST_CORE3H_POLARITY0_ON_OFF_SWAP as 1.
T_sys for the IFs in the monitor display window is negative and your polarity is 2, you may need to define FS_DBBC3_MULTICAST_CORE3H_POLARITY2_ON_OFF_SWAP as 0.
T_sys for the BBCs from onoff is negative (or an overflow, $s), you may need to define FS_DBBC3_BBCNNN_ON_OFF_SWAP as 1.
T_sys for the IFs from onoff is negative (or an overflow, $s) and your polarity is 0, you may need to define FS_DBBC3_IFTPX_POLARITY0_ON_OFF_SWAP as 1.
T_sys for the IFs from onoff is negative (or an overflow, $s) and your polarity is 2, you may need to define FS_DBBC3_IFTPX_POLARITY2_ON_OFF_SWAP as 0.

Note	For FS 10.1, the monitor display window shows `$$$$$` for negative T_sys values, but DBBC3 specific environment variables, including these, are not available.

B.2. Swaps of TPI and gain values

Two general types of swaps may be needed: (i) USB/LSB swaps, and (ii) cal-on/cal-off swaps. Generally, USB/LSB swaps are always needed (and are enabled by default). They can be adjusted separately for the TPIs in the bbcNNN commands, gains in the bbcNNN commands, the bbc_gain command, and the multicast.

Typically, cal-on/cal-off swaps are only needed in two situations (and are enabled in those two cases by default). They can be adjusted separately for the bbcNNN commands, the iftpX commands, the BBCs in the multicast, and the IF (Core3H) values in the multicast. Additionally for the iftpX command and IF values in the multicast, separate control is provided for polarity 0 (and 1) versus polarity 2 (and 3).

The variables, along with their default values, are given in the DBBC3 TPI swap environment variables table below. The table is sorted by USB/LSB verses cal-on/cal-off swaps. Their names are verbose to make their applicability clear. The CORE3H values for the multicast refer to the IF TPI values. A value of 0 for the variable disables its effect; a value of 1 enables it. If the variable is not defined in the session before the FS is started, the behavior will be that of the default value. If need be, the variable can be defined as 1 to enable, or 0 to disable it, before starting the FS. Any other defined value is interpreted as 0.

Table 3. DBBC3 TPI swap environment variables
Environment variable	Default
`FS_DBBC3_BBCNNN_GAIN_USB_LSB_SWAP`	`1`
`FS_DBBC3_BBCNNN_TPI_USB_LSB_SWAP`	`1`
`FS_DBBC3_BBC_GAIN_USB_LSB_SWAP`	`1`
`FS_DBBC3_MULTICAST_BBC_TPI_USB_LSB_SWAP`	`1`
`FS_DBBC3_BBCNNN_ON_OFF_SWAP`	`0`
`FS_DBBC3_IFTPX_POLARITY0_ON_OFF_SWAP`	`0`
`FS_DBBC3_IFTPX_POLARITY2_ON_OFF_SWAP`	`1`
`FS_DBBC3_MULTICAST_BBC_ON_OFF_SWAP`	`0`
`FS_DBBC3_MULTICAST_CORE3H_POLARITY0_ON_OFF_SWAP`	`0`
`FS_DBBC3_MULTICAST_CORE3H_POLARITY2_ON_OFF_SWAP`	`1`

B.3. Other options

A few other environment variables can be used to control other options:

FS_DBBC3_MULTICAST_CORE3H_TIME_ADD_SECONDS

This variable can be used to adjust the timestamp in the multicast packets. Normally it does not need to be set and defaults to 0. If the multicast packets being received have a fixed offset from the correct time, this variable can be set to correct the values. Any 32-integer value can be used. Any non-integer value is interpreted as 0. The value is added to the timestamps. This does not correct the time that the DBBC3 is using internally and in the VDIF packets sent to the recorder. This can only be used to eliminate FS indications of incorrect time in the DBBC3. Please see the warning immediately below.

Warning
Having the wrong timestamps may be an indication that the DBBC3 was not properly synchronized. It may be that the DBBC3 needs to be rebooted to resynchronize it properly.
FS_DBBC3_MULTICAST_CORE3H_TIME_INCLUDED

This variable controls whether time is expected in the multicast packets. Normally it does not need to be set. It defaults to 0 for DDC_V and 1 for others. Setting it to 1 means that time in the multicast packet is expected. Any other value is interpreted as 0, i.e., time is not expected and no attempt will be made to use it.
FS_DBBC3_MULTICAST_VERSION_ERROR_MINUTES

This variable controls the error reporting interval, in minutes, if the DBBC3 firmware (DDC_X) or version (vNNN) in the multicast does not agree with the FS control files. The default is 1. It can be set to any value 1-10. Any other values are interpreted as 1.

Appendix C: Verifying polarity and USB/LSB TPI swaps

This appendix provides methods for verifying the Continuous calibration polarity and the USB/LSB TPI swap status. You should verify the polarity before checking the USB/LSB swap status.

Note	In FS 10.1, these procedures can be used without the environment variables, which are not available, to check the related aspects of the system.

C.1. Continuous calibration polarity

A polarity of 0 corresponds to the noise diode in the receiver being active for the low TTL output level of the DBBC3 continuous calibration signal; 2, active for the high TTL output level. The best case is to know what the polarity should be from the design of your system. If that is not practical, or to verify it, you can use the methods in this section.

Generally the easiest way to verify, or empirically determine, your calibration polarity is from the T_sys monitor display. Hopefully, one setting of the polarity, 0 or 2, will produce usable T_sys values. If so, that is probably the correct polarity. However, if there is an issue with the order of the cal-on and cal-off values in the multicast, you may get the wrong result. In that case, fivpt won’t work and onoff will not return usable T_sys values.

A more reliable, but also not perfect, way to determine the correct polarity is with the output of a bbcNNN command. The following procedure should normally work. If the results do not agree with your expected polarity, please contact Ed.

Make sure the environment variable FS_DBBC3_BBCNNN_ON_OFF_SWAP is not set, or if it is set, that it is set to 0.
Start the FS.
Configure the system for an observing mode.
Set the polarity to 0:
```
cont_cal=on,0
```
For a BBC that is configured for observing, maybe BBC001, sample its state:
```
bbc001
```
Examine the last four numbers of the output. They are, in order:
1. USB TPI_on (cal-on)
2. LSB TPI_on (cal-on)
3. USB TPI_off (cal-off)
4. LSB TPI_off (cal-off)
If the TPI_on values, per side-band, were higher than the TPI_off values, you should use polarity 0. You may want to sample a few times to make sure the results are consistent. If the TPI_off values are higher than the TPI_on values, proceed to the next step.
If in the previous step, the TPI_off values, per side-band, were higher than the TPI_on, you should try:
```
cont_cal=on,2
```
and re-sample the BBC. If the TPI_on values are now higher than the TPI_off value, you should use 2 as your polarity.

C.2. USB/LSB TPI swap status

To verify your USB/LSB TPI swap status you need a strong test signal in one side-band of a BBC. This could either be a phase calibration test tone, or an astronomical source such as a Maser, that makes a strong signal in only one side-band of one BBC.

Follow the steps below. If the results do not show that the test signal is in the expected side-band, please contact Ed.

Verify the Continuous calibration polarity in the previous section.
Make sure the environment variable FS_DBBC3_MULTICAST_BBC_TPI_USB_LSB_SWAP is not set, or if it is set, that it is set to 1.
Start the FS.

Configure the system for an observing mode.

Caution

You must use an observing mode that at least has a nominal .rxg file that supports it. If there isn’t one, you can use the output of the bbcNNN command (with FS_DBBC3_BBCNNN_USB_LSB_SWAP not set or else set to 1) for the BBC where the test signal is expected to appear and hand calculate the $\mathit{T_{sys}}$ value for each side-band using (see the Continuous calibration polarity section for the $\mathit{TPI}$ variable meanings, use a nominal value for $\mathit{T_{cal}}$):

$\mathit{T_{sys}=0.5(TPI_{on}+TPI_{off})\frac{T_{cal}}{TPI_{on}-TPI_{off}}}$

Verify that the side-band that is expected to have the test signal has the higher $\mathit{T_{sys}}$ value.

In the $\mathit{T_{sys}}$ monitor display, verify that the $\mathit{T_{sys}}$ value of the side-band of the BBC where the test signal is expected to be is in fact higher than the other side-band.
We have not seen it, but it might be possible for the multicast and bbcNNN commands to have different USB/LSB swaps. So in principle both the T_sys monitor display and bbcNNN commands should be checked (see the CAUTION above for the latter). It is also possible to verify the USB/LSB swaps status for both the gains in the bbcNNN command and those in bbc_gain command. Separate environment variables are provided for each case to allow them to be adjusted independently.

Appendix D: Minimizing the use of setup procedures

Note	This can be used for any system, not just those with DBBC3s.

Normally, the FS sets the mode for each scan (unless there is continuous recording). If this takes too long (as is the case for the DBBC3) or makes the equipment unstable, the drudg option use_setup_proc yes in skedf.ctl can be used to minimize the execution of the setup procedure.

Caution

Not executing the setup each scan may not be robust if the equipment sometimes loses its configuration. Each station will need to determine for its particular situation whether minimizing its use is better than always using it.

With this option enabled, drudg will replace the calls to setup procedures (e.g., setup01) in the .snp file with, e.g.:

setup_proc=setup01

When the FS encounters this command, it will conditionally execute the setup procedure if either of the following is true:

This is the first setup since the schedule was last started.

This will make sure the setup is run at the start and any restart of the schedule. There should be sufficient time for the setup procedure in these cases as long as the schedule is started as little as even just a few minutes before the first scan. The schedule may need to be started even earlier to allow enough time for the antenna to slew to the first source.
If there was a mode change, i.e., the name of the setup procedure changed.

Note
Mode changes within schedules is not supported yet for DBBC3s.

The use_setup_proc option in skedf.ctl has three possible settings:

yes — use the setup_proc command
no — do not use the setup_proc command
ask — to prompt for yes or no for each schedule

If the option is not used, it defaults to no.

Note	The fesh program was expanded to support an environment variable, `FESH_GEO_USE_SETUP_PROC`, and a command line option, `-u`, to set the answer for an interactive prompt for whether or not to use `setup_proc` commands when drudging geodesy schedules. Please see `fesh -h` for more information.

Thanks to Jon Quick (HartRAO) and Marjolein Verkouter (JIVE) for suggesting this approach. They also suggested that it may be utilized as part of future features for additional checking and resetting of the system.

Appendix E: Thread procedure

Note	This can be used for any system with a Mark 5C or FlexBuff recorder, not just one with a DBBC3.

When a Mark 5C or FlexBuff recorder is in use, drudg can optionally insert a threadsuffix procedure in each setup procedure (where suffix is a mode specific suffix, e.g., 01). This can be used to control whether the recording for a mode is multi-threaded or single-thread-per-file. As generated by drudg, the contents of the procedure is the same for every mode in the schedule. If it needs to be different for some modes, the corresponding threadsuffix procedures can be edited.

This feature is controlled by the vdif_single_thread_per_file option in the skedf.ctl control file. The option only needs to be used by stations that need to record a single-thread-per-file, at least some of the time; the default for jive5ab after being restarted is multi-threaded. If the option is not present, no threadsuffix procedure is inserted. If it is present, the possible settings are (where command is mk5 or fb depending on the type of recorder):

yes — to store a single-thread-per-file, in which case, the threadsuffix procedure contents are:

command=datastream=clear
command=datastream=add:ds{thread}:*
command=datastream=reset

The ds is passed (case preserved) to jive5ab to be used as part of the lowercase datastream label portion of the filename. This results in filenames like ev024g_mc_no0009_dsds1. The double ds is intentional.

Caution

If you are using a jive5ab version before v3.1.0-rc1 and you select storing a single-thread-per-file, the scan_check command will not work properly. You should comment it out or remove it from your checkfb and/or checkmk5 procedure. Alternately, if you only select single-thread-per-file sometimes, you may want to edit the procedure depending on your choice. Upgrading to v3.1.0-rc1 or later is recommended to eliminate this complication.

Note	In FS 10.1, the `add` command is `command=datastream=add:{thread}:*` and there is no double ds.

no — for normal multi-threaded recording, in which case, the threadsuffix procedure contents are:
```
command=datastream=clear
command=datastream=reset
```
ask — to be prompted once per schedule for what to do

Caution
If you are using single-thread-per-file, see the CAUTION about scan_check for the yes setting above.

Note

The fesh program was expanded to support an environment variable, FESH_GEO_VDIF_SINGLE_THREAD_PER_FILE, and a command line option, -T, to set the answer for an interactive prompt for whether or not to use a single-thread-per-file when drudging geodesy schedules. Please see fesh -h for more information.

Appendix F: Recorder tuning

Note	This can be used for any system with a Mark 5C or FlexBuff recorder, not just one with a DBBC3.

This appendix describes the default recorder configuration used by the FS and how to make changes in your SNAP procedures to tune some aspects of the configuration of your Mark 5C and/or FlexBuff recorders.

F.1. mk5c_config/fb_config procedure

Each mode SNAP setup procedure produced by drudg for Mark 5C and FlexBuff recorders includes a call to a mk5c_config/fb_config SNAP procedure, depending on the type of recorder. This procedure call is inserted immediately after the mk5c_mode/fb_mode command (and after the optional Thread procedure call, if present). The procedure is mode independent, i.e., the same procedure is used for all modes.

This procedure is a local station library procedure to allow tuning some aspects of the configuration of jive5ab for the specifics of the recorder, including overriding the “default” FS configuration, described next below, given by the mk5c_mode/fb_mode command in the setup procedure.

F.2. Default FS configuration

The mk5c_mode/fb_mode command sends configuration information, beyond what is set with jive5ab mode command. What is sent depends on which recorder is selected in equip.ctl, mk5c or flexbuff, and the total data rate. It does not depend on which command is used; fb_mode is just an alias for mk5c_mode. The commands sent also depend on the data type, VDIF or 5B/Ethernet. All the cases are listed below.

Tip	You can see the full details of the FS setup of the recorder by the `mk5c_mode`/`fb_mode` command by using `echo=on` before the command and `echo=off` afterwards.

F.2.1. FlexBuff recorder

Default mtu setting:

The mtu command sent to the recorder depends on the data type:
1. VDIF data
  mtu = 9000 ;
2. 5B/Ethernet data
  mtu = 6000 ;
Default net_protocol setting:

There is a variable field socketbuffer in the net_protocol command sent to the recorder. Its value is independent of the data type.
```
net_protocol = udpsnor : socketbuffer : 256000000 : 4 ;
```
Where the socketbuffer field depends on the total data rate:
- 32000000 — data rate < 1 Gbps
- 64000000 — 1 Gbps < data rate ⇐ 4 Gbps
- 128000000 — data rate > 4 Gbps
The socketbuffer parameter is an important setting for trying to minimize risk of packet loss when starting the recording. For (very) high data rates, the mk5c_config/fb_config procedure can be used to increase the socketbuffer size to values appropriate for that. This assumes that the FlexBuff has been tuned (especially the kernel network buffer sizes) along the lines of the FlexBuff tuning documentation at https://www.jive.eu/~verkout/flexbuff/flexbuf.recording.txt.
Default record = nthread setting:

There is a variable field nWriters in the record = nthread command sent to the recorder. Its value is independent of the data type.
```
record = nthread : : nWriters ;
```
where nWriters is calculated as max( data_rate / 6 + 1, 2) and data_rate is the total data rate in Gbps.

F.2.2. Mark 5C recorder

Default net_protocol setting:

The net_protocol command sent to the recorder is independent of the data type:
```
net_protocol = : 128k : 2M : 4;
```
Default packet setting:

The packet command sent to the recorder depends on the data type:
1. VDIF data
  packet = 36 : 0 : 8032 : 0 : 0 ;
2. 5B/Ethernet data
  packet = 36 : 0 : 5008 : 0 : 0 ;

F.3. Overriding the defaults

You can override the commands sent by the mk5c_mode/fb_mode command or add more by putting them in your local mk5c_config/fb_config procedure. This works because mk5c_config/fb_config is called after mk5c_mode/fb_mode command (and after the call to the optional Thread procedure, so it can overridden by the same mechanism) in the setup procedure. An example of a local customization is shown in the Changing net_protocol subsection below.

Some suggestions for recoder turning, both for jive5ab commands in mk5c_config/fb_config and more generally, can be found at: https://www.jive.eu/~verkout/flexbuff/flexbuf.recording.txt.

Caution

If you put any commands in mk5c_config/fb_config that depend on the data type, VDIF or 5B/Ethernet, you would need to change them if there is a change in the data type. This is not a concern for most stations.

F.3.1. Changing net_protocol

If you use different values for net_protocol, you can leave any field blank that your don’t need to change from what the FS has already sent. For example to only set the socketbuffer size to 64000000, use:

net_protocol = : 64000000

Appendix G: Alternate Core3H board configuration method

It may be possible to configure the Core3H broads from the FS, but at this time it is not considered safe to do so. This appendix describes a method for this in case it is determined to be safe to use. Currently, this should be viewed as a “bleeding edge” engineering test method. It may be that this approach can be adapted for use when new DBBC3 features that make it safe become available.

The fundamental issue is that it is not considered safe to re-sync the boards except by booting the DBBC3. Most of the changes in Core3H board configuration that depend on the observing mode require a re-sync afterwards. Consequently, these features should only be set from the boot configuration.

As a result, during a schedule the configuration of the Core3H boards is not set; it is only checked. A mechanism is provided to force the setting of the mode configuration. In principle, this can be used before the experiment starts to place the Core3H boards in the correct configuration without having to decode the schedule configuration and set the Core3H boards up as part of the boot configuration. However, this mechanism is not currently recommended.

G.1. Configure Core3H boards

To configure the Core3H boards for the schedule mode:

drudg the schedule to make the .prc (and .snp) file
Start the FS
Open the experiment procedure library, e.g.:
```
proc=r5012kk
```
Execute the normal Core3H board configuration procedure, perhaps core3h01, with the force parameter, e.g.:
```
core3h01=force
```
This command will generate an error when it tries to start data transmission without the boards being re-synced. This is normal and can serve as a reminder that re-syncing is needed.
Set the Core3H output destinations

The FS does not set the destinations for the Core3H boards. When checking the configuration, it does verify that outputs that are not expected to be recorded have their destination set to none and outputs that are to be recorded do not. You will have to verify that that the outputs that are being recorded have the correct destination addresses set.

Tip
For DDC_V, you do not have to set destination 1 none. It is disabled by the firmware regardless of how it is set and the FS ignores it.

You can check that the destinations are set to none in the correct places with, e.g.:
```
core3h01
```
Note
This will also check the other aspects of the Core3H board setup. Any non-destination related errors should also be resolved at this time.

If any destination related errors are reported, you must correct them. You can use commands similar to those in the example in the Ethernet configuration subsection above, as needed. It is not necessary to reboot the DBBC3 to fix this.

You can display the destinations that are set for the n^th board with:
```
  core3h=n,destination 0
  core3h=n,destination 1
```
Important
Depending on your site’s IT rules, you may need to be careful to avoid recording public IP addresses in your experiment logs.
Continue to the Sync time and then the Start data transmission subsections below for the steps to complete the setup.

G.1.1. The configuration details

For each Core3H that is in use, the following information/commands will be sent when using force, in this known-to-work order:

Decimation
Splitmode
Bitmask
reset
vdif_frame …

For example:

core3h=1,vsi_samplerate 128000000 2
core3h=1,splitmode on
core3h=1,vsi_bitmask 0xcccccccc
core3h=1,reset
core3h=1,vdif_frame 2 8 8000 ct=off

Note	The FS hard codes a VDIF frame payload size of `8000`. If a different size is needed, please see the Handling other VDIF frame payload sizes appendix.

G.2. Sync time

After the Core3H boards are configured, the operator needs to sync the PPS, sync each Core3H, and sync the PPS a final time. In principle, this would consist of:

dbbc3=pps_sync
!+1s
core3h=1,timesync
core3h=2,timesync
core3h=3,timesync
core3h=4,timesync
core3h=5,timesync
core3h=6,timesync
core3h=7,timesync
core3h=8,timesync
!+1s
dbbc3=pps_sync

It may be necessary to increase the delays after/before the pps_sync commands to achieve reliable results. If you have fewer than eight boards, only include the timesync commands for the boards you have.

It may take the boards a few tens of seconds to stabilize after the commands. During that the period, the times reported for the boards may vary. When the times have stabilized, continue to the Start data transmission subsection below to complete the setup.

Important

The above commands may work for syncing. The following conditions are required, but may not be sufficient, to verify that the sync worked:

There were no errors in the execution of the commands.
All boards have the same, correct, time.
All boards have the same, correct, VDIF epoch.
All boards have pps_delay values of no more than a few tens of nanoseconds and are not drifting. However, if a GPS 1 PPS is used as input, some drift may be unavoidable.

The best way to check the time for non-DDC_V firmware is with the mcast_time command. For DDC_V firmware and versions before v124 the dbbc3=time command can be used, but the output can be difficult to interpret because the boards may be sampled in different seconds.

The VDIF epoch and the time can be checked per board with core3h=board,time, where board is the board number.

The pps_delay values can be viewed with the mcast_time command.

Note

All the Core3H boards in the system need to be synced, even those not sending data. For now, the only safe way to configure a DBBC3 is with the boot configuration. A new DBBC3 feature is being developed to allow syncing the PPS and then syncing, in parallel, the Core3H boards without needing to reboot.

G.3. Start data transmission

After the boards are synced, data transmission needs to be started or stopped for each board, as appropriate for the mode. Assuming the setup procedure for the mode has been used previously with the force parameter as described in the Configure Core3H boards subsection above, this can be accomplished with the command:

core3h_mode=end,force

Note

After the boards have been synced, data transmission can be freely started and stopped on individual boards as needed. For example to start transmission on board 1, you can use:

core3h=1,start vdif

To stop transmission, use:

core3h=1,stop

Caution

Using these commands may make whether the board is transmitting data inconsistent with the FS configuration and may lead to problems.

G.4. Check the mode

After the Core3H boards have been configured, you should check the mode as described in the Checking the mode subsection above in the main document. That step will also implicitly set the non-Core3H configuration for the mode, which is necessary for a complete setup.

Appendix H: Handling other VDIF frame payload sizes

The value of 8000 for the VDIF frame payload size is hard coded in the FS for the DBBC3 and jive5ab (and DBBC2/FiL10G as well). Currently this is the correct value, but some day in the future, different values may be needed. If that occurs before the FS is updated to accommodate other values, this section gives a recipe for handling it for the DBBC3 and jive5ab in the meantime. It is a little complicated, but should work. Hopefully, the FS will be updated before it is necessary.

After you command a different VDIF payload size, the FS will complain that the DBBC3 vdif_frame payload is not correct when you check the DBBC3 configuration (i.e., using the setup procedure without the force parameter), but if that is the only complaint, there should not be a problem. The display of these errors can suppressed with the tnx command.

If you are using the boot configuration method of configuring the Core3H boards, there is a NOTE in the Setting the boot configuration for the mode subsection above that explains what to do.

This remainder of this appendix is only useful of you are using the Alternate Core3H board configuration method appendix. As such, it continues the examples of that appendix.

The basic strategy is to Determine the other settings needed in the DBBC3 vdif_frame and jive5ab mode commands, Update the SNAP procedures to include the new payload size, and then Command the devices with the new value. These are all described in the following subsections.

H.1. Determine the other settings

The settings can be calculated from first principles. However, another way to determine them is to use the echo output from the FS for what would otherwise be the correct setup:

proc=r5012kk
echo=on
setup01=force
echo=off

You will need to identify the #dbbcn#[core3h=n,vdif_frame … and #mk5cn#[mode = VDIF_8000-… records in the output and use the displayed values as shown in the next subsection.

H.2. Update the SNAP procedures

This example uses 8200, which is not an allowed value, as a different payload size.

Caution

The examples below do not necessarily contain correct values. They are just offered to show the form of the commands.

Create a new SNAP procedure, perhaps called vdif_8200, that contains all the other values in the core3h=n,vdif_frame … commands recorded in the previous section, but with the new payload size. For example, insert:

dbbc3=core3h=1,vdif_frame 2 8 8200 ct=off
dbbc3=core3h=2,vdif_frame 2 8 8200 ct=off
dbbc3=core3h=3,vdif_frame 2 8 8200 ct=off
dbbc3=core3h=4,vdif_frame 2 8 8200 ct=off
dbbc3=core3h=5,vdif_frame 2 8 8200 ct=off
dbbc3=core3h=6,vdif_frame 2 8 8200 ct=off
dbbc3=core3h=7,vdif_frame 2 8 8200 ct=off
dbbc3=core3h=8,vdif_frame 2 8 8200 ct=off

In the same procedure, add a jive5ab=mode=VDIF_… command that contains all the other values from the mode = VDIF_… command recorded in the previous section, but with the new payload size. For example, add the command:
```
jive5ab=mode=VDIF_8200-8192-64-2
```

Note	Not putting this command directly into your `mk5c_config`/`fb_config` procedure allows it to be mode specific. If you want to apply this change universally, you can put it into your `mk5c_config`/`fb_config` procedure instead, but be wary of other modes.

H.3. Command the devices

Continuing the example, enter:

proc=r5012kk
setup01=force
vdif_8200

Important

The order of the last two commands above is critical to avoid having the overall setup procedure overwrite the new payload value.

Afterwards, you need to re-sync the time as described in the Sync time subsection and start the data transmission as described in the Start data transmission subsection, both in the Alternate Core3H board configuration method appendix.

Note

The reason for setting the new Core3H payload size outside of the overall setup procedure is so that when using that procedure without force to check the DBBC3 configuration (and/or to configure the non-Core3H parts of the system), the added core3h=n,vdif_frame … commands won’t trigger a requirement to re-sync the boards.