DBBC Test Procedures

Datacheck procedure for Mark5B

During testing and operation of the DBBC, specially at the beginning, it is good to verify that everything is okay. Usually I used the Mark5B tools from Haystack like bpcal, bstat, vlbi2 or vlbi0. Those work, but are mostly written for 2 Gbps PFB tests, or other 16 channel observation, and therefore can give confusing outputs when used with less channels.

During the TOG in Onsala Alessandra introduced the mark5access package.The mark5access package is much more flexible and can be used for all kind of VLBI data formats, like Mark5A, B, VLBA, or MarkIV and even some VDIF is supported. At the workshop in Bonn we had the idea to make an online display of VLBI data during recording.

Since the mark5access programs have to be called with the correct mode this was a bit complicated at the beginning. I tried to prepare scripts for the most common modes and attached those to each prc-file of an observation, but this needs an additional step after drudging and was a bit complicated.

As a result of the discussion at the TOG in Wettzelll I've now written a small python script that sorts out the required information from the current log file and prepares a shell script and a plot file for gnuplot. After some interation with Jonathan this script is now in a shape that we think it can be used by a wider comunity. It is still not real time, but it can be executed after every scan in checkmk5 and does a check of the first few bytes from the last scan. It just uses a basic python installation (an old 2.4 works as well), the mark5access package, gnuplot, and/or gv (gv is optional).

gnuplot and mark5access should be installed on the Mark5B recorder and if you prefer postscript figures also gv. Since the FS PC has usually password free access to the Mark5 recorder one can execute programs via ssh. For now you get autocorrelation plot of all BBCs and the bit statistics (see images below). The checkdata.py script gets the IP address from the mk5ad.ctl.

Once the mode has been detected the checkdata.py copies a plot-file for gnuplot to the Mark5 using 'scp'. Then an 'ssh -f' command is issued that runs m5spec, m5bstate, and gnuplot on the Mark5, open a plot using gv, and kills this plot after 1 min. The complete command can be found at the end of the checkdata.py script. A printout of the commands would look like this:

ssh -f -X mark5-671 'm5spec systest.m5b Mark5B-512-16-2 4000 1024 spec.out -dbbc > m5spec.tmp;gnuplot < plot_16x8ul_DBBC_all; m5bstate systest.m5b Mark5B-512-16-2 200 | tee -a m5bstate.log ;gv systest.ps > & /dev/null & ; sleep 60 ; pkill gv' &

Note that the syntax is for csh, which usually runs on the Mark5. If you use bash the syntax needs to be changed.

If all the software is in place there is not much needed than adding a few lines to the checkmk5 procedure in your stations.prc to get it running. The installation of the mark5access package is explained in the INSTALL note within the tar-archive. I just had to install the fftw3 libraries to run it. The python script 'checkdata.py' should go to /home/oper/bin. The files are attached at the end of this page.

This is my new checkmk5 procedure:

define  checkmk5      00000000000x
mk5=rtime?
scan_check
data_check
disk_stats
mk5=dir_info?
mk5=vsn?
mk5=disk_serial?
mk5=bank_set?
" query needed for checkdata.py
mk5b_mode
form
" write out some bytes from beginning of the last scan
!+1s
mk5=scan_set=::+20000000
!+1s
mk5=disk2file=systest.m5b:::w
!+3s
" run checkdata
sy=exec /home/oper/bin/checkdata.py `lognm` systest.m5b &
"
enddef

So first, a protion (20 MB) of data from the last scan are written to the disk. Then the python script is executed with the logfile and the data file name as an input paramter. In Effelsberg we use the oper home directory, if you prefer /tmp you need to choose that in disk2file and as an input parameter to checkdata.py.

The statistics are stored in a file, like 'exp-code.bstate', but all the other files that are written have always the same name and will be overwritten with the next scan, so it doesn't fill your disk id it runs for a complete EVN session. If somebody want to save those one could change the script to give them individual names. There are some individual options at the start of the script that you might want to edit.

# Option: include a timestamp on last graph?
timestamp=1

# Option: Use gv of a postscript output file instead of a gnuplot_x11 display
postscript=0

# Option: Time to display output for (seconds, use 0 for a persistent window)
display_time=60

# Option: display m5bstate statistics for 2-bit data
m5bstate=1

# Option: print out some debug info about the recording format and BBC settings found
fmt_debug=1
 

For now I haven't add much information about the channels to the plots, but one could think of adding the correct sky frequencies as labels. The information could come form the prc-file, but as I tried that I gave up with observation that use more than one mode and one has to look which setup is used. Maybe I'll add this later.

Fig. 1: Here is a snapshot of the FS screen during a 1 Gbps 18cm observation with a lot of RFI.

Fig. 2: This plot is from N13C1 with 8 MHz filters and phasecal on.

/@api/deki/files/4326/=mark5access-1.4.5.tar.gz

/@api/deki/files/4330/=checkdata.py

Checking Phases from the DBBC

The goal of this second section is to show a method to verify the stability of the phases of the different channels in the DBBC at the stations using a DBBC, a Mark5B and a diskpack. A phase cal system inject tones at the receiver is required. We have developed this small test because we found that our DBBC at Yebes was producing fringes with lower quality than the ones obtained with the VLBA terminal. Phase jumps were seen along time at the correlator for some bands.

 The basic idea of this test is to use the phase cal tones injected in the receiver and monitor the phase of one tone along time.  The script included here uses a geodetic setup: X band and S band feeding IFs 1 and 2 and 3 and 4 respectively. The data are recorded for some minutes. Later some slots of data, 1 second long and spaced 30 seconds or 1 minute, are extracted in the Mark5B. bpcal is ran on top of the data and the phases for all channels and a selected tone are written on an ASCII file and plotted with gnuplot.

This procedure requires a modification in station.prc and a python script to run the whole process. The new procedure in station.prc is called  phasecalvsti  and it is attached at the bottom. phasecalvsti triggers an external python script, checkphases.py, which extracts the data and plots the results. checkphases.py should be placed in /usr2/oper/bin. The selected tone to monitor its phase is 2010 KHz. The tone can be changed in the previous procedure.

In order to make this check work, gnuplot should be installed in the FS computer and bpcal should be installed in the mark5B. bpcal can be obatined from Haystack web: ftp://web.haystack.mit.edu/pub/mark5/B/util/

The current procedure lasts 8 minutes and blocks the FS for that time. At the end a plot will be shown in the screen and it is required to click on the plot to close it and to press enter in the log window.

A typical result from Yebes DBBC which shows some phase jumps in some of the channels is depicted below. In a DBBC without problems all lines should be flat with time, that is, phase of the phase tones should remain stable.

The previous plot shows jumps in channel 0 (BBC01 USB) because of the ambiguity of the phase close to +- 180 degrees. Channels 4 to 7 do have problems and point to something wrong in the 2nd block (ADB+CORE) of the DBBC. Channels 8 and 9 should be disregarded because in geodesy they correspond to LSB (lower side band) and when mixing the tones with the local oscillator, no signal with a frequency multiple of 1 MHz plus 10 KHz is available.

Before using this method it should be checked that the phase cal is on and it is working correctly. The Mark5B should be using a 2 bit scheme. All this settings are set in phasecalvsti.

The procedure in station.prc is prepared for a DBBC with 3 ADB1 boards and 4 CORES. If your setting is different the procedure should be modified accordingly.