Start DBBC control program (either DDC v102 or PFB v14) - the configuration files include a line with “1 fila10g_v2_1.bit” which will load the correct firmware into the Fila10G.

Set up CoMos as per usual and choose the appropriate dbbcform. If you are using the PFB mode, also include the “threshold=on” command.

Once configured, run the fila10g_double.cat program from C:\DBBC\bin. This will set up the ethernet routing between the Fila10G and the Mark5C, set input to VSI2 by default with mark5b format (sutiable for 1 Gbps in DBBC mode or 2 Gbps in PFB mode), and synchronise the Fila10G with the system time. The DBBC should be locked to the NTP source before running fila10g_double.cat.

You can check on the current status of the Fila10G via the PuTTY terminal (which uses the serial interface). A saved mode is available in the PuTTY interface. Once connected, you can issue the time command to get a single readout of the current time, tick to display the current time every second and sysstat to get a summary of the current configuration. Note that the RTC time is the read-out that should be in synch with the NTP time, but be aware that the display can be laggy.

The recording program for the mark5C is called drs and is (somewhat) compatible with the mark5a/mark5b syntax. The currently installed version is 0.9.9-1 (June 2012 vintage), but a newer version is promised.

You can control the software either via the included drs_client software, or by using telnet or nc over port 2620. If you are using nc, please not that all commands need to have a trailing ; to be accepted e.g echo “vsn?” | nc localhost 2620 will be rejected while echo “vsn?;” | nc localhost 2620 will return the current VSN.

One other note - the vsn? query above would fail if it was issued before setting the personality of the mark5c - it has no default settings. The usual sequence of commands to bring the mark5c to readiness is

personality=mark5c:bank
mode=unk
MAC_list=add:ba.dc.af.e4.be.e1
MAC_list=add:ba.dc.af.e4.be.e2
packet=40:0:5008:0:0

The personality type sets the mark5c to be a recorder and the :bank argument tells it to record to only one bank. This is suitable for 2 Gbps recordings.

The mode setting is chosen as unk for unknown. Other alternatives are mark5b and vdif - this only affects the mark5c's internal record keeping and unk does not cause any apparent problems.

The MAC_list sets the allowed list of MAC addresses to record incoming packets from. The listed addresses are the defaults used by the Fila10G.

The packet setting defines how to handle incoming UDP packets. The current settings are appropriate for the Fila10G using mark5b format, but will need to be changed for 4 Gbps VDIF streams.

It's strongly recommended to erase the module before starting any recordings, and to issue the command twice (or three times). This might be due to SDK9 issues.

There is a script in ~oper of mk5ce called Mark5C_start.sh that runs these commands to configure the mark5C and optionally erases the loaded module.

Once configured, you can make a recording with the command

record=on:scan_name:experiment_name:station_code

Note that you do not have a separate scan_name command as in mark5A/B. The recorded data rate is set by the input stream, and no channel-masking/dropping is possible. For the DBBC in DDC mode, it will be a 1 Gbps stream and 2 Gbps for single-VSI PFB mode. record=off stops the recording.

Important - in the current version, with the recording parameters as described, scan_check? will fail and cause drs to lock up. It may be an issue with the mode selection, but there are some other issues with accessing recorded data on the modules…

disk2file does work as in the mark5a/b systems but you do need to use scan_set=1 or the like to explicitly set the scan scan start and stop bytes. Failing to do this will result in disk2file either quietly failing, or causing the drs program to lock up.

pointers? works as usual.

The time-tag of the recorded data seems to be earlier than expected - it might be that the recorded data comes from a FIFO buffer, or that there were synchronization issues with the DBBC/Fila10G. Update - it's more likely due to the timing inaccuracy of the Fila10G. From APEX fringe tests, it appears that it's not uncommon for offsets of up to 2 seconds (integer and in either direction) in the recorded data. Happy fringe-finding!

Also, note that when recording a 4 Gbps that mark5C is allegedly unable to stop a recording reliably - the data stream has to be halted at the Fila10G first.