# New FS for VGOS branch ## VGOS FSL10 ### Installation
IP assigned to the new machine in Katherine:
131.217.61.33 (pcfs-2ke.phys.utas.edu.au)
Installing a xvnc server to connect remotely via vnc. Using same installation as used with the HEX upgrade notes. Once the home directory was moved to /usr2/ and the 'old' fs window display was installed the automatic x11 server stop working.
`sudo nano /lib/systemd/system/x11vnc.service` ``` [Unit] Description=Start x11vnc at startup. After=multi-user.target [Service] Type=simple ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /home/observer/.vnc/passwd -rfbport 5900 -shared [Install] WantedBy=multi-user.target ``` `sudo systemctl daemon-reload` `sudo systemctl enable x11vnc.service`
Installation of the new FSL10. See Dave's notes below.
`apt install linux-image-amd64 linux-headers-amd64`
Copying the selection of specific fsl10 packages. ``` scp fsl10.selections observer@pcfs-2ke: observer@pcfs-2ke's password: fsl10.selections 100% 58KB 2.6MB/s 00:00
apt install dselect ``` Initial errors:
``` root@pcfs-2ke:/home/observer# dpkg –set-selections < fsl10.selections dpkg: warning: package not in status nor available database at line 122: default-java-plugin dpkg: warning: package not in status nor available database at line 458: icedtea-8-plugin:amd64 dpkg: warning: package not in status nor available database at line 1609: linux-headers-4.9.0-8-amd64 dpkg: warning: package not in status nor available database at line 1609: linux-headers-4.9.0-8-common dpkg: warning: package not in status nor available database at line 1610: linux-image-4.9.0-8-amd64 dpkg: warning: found unknown packages; this might mean the available database is outdated, and needs to be updated through a frontend method; please see the FAQ <https://wiki.debian.org/Teams/Dpkg/FAQ> ```
The package with linux headers and image is outdated, updated to latest version (4.9.0-9)
sed s/4.9.0-8/4.9.0-9/r fsl10.selections
The other two packages (default-java-plugins and icedtea-8-plugin) might be a bit more tricky to get. They are not part of the official Debian release. So there are some ways around in order to download and install, but I don't know how necessary those are.
`apt-get dselect-upgrade`
The installation might take from half an hour to an hour easily depending on the network connection. Furthermore, we should wait until the md0 array is fully mirrored.
`apt-get clean`
Installing the FS Adapt ``` ftp ftp.hartrao.ac.za kbd:[CR] user: ftp password: anything@utas.edu.au
cd /pub/fs9x
get fsadapt-9.0.1.tgz quit
tar xzf fsadapt-9.0.1.tgz ```
Modifying the files under /usr2/control/. Taking as a template the ones from oper@pcfs-0ke.
Files that are just cloned: ``` antenna.ctl dev.ctl flagr.ctl flux.ctl location.ctl logpl.ctl mdlpo.ctl mk5ad.ctl mk6ca.ctl parpo.ctl skedf.ctl antcn.ctl antcn_p12.ctl ```
Files that have been modified using Hb as a template ``` fila10g_cfg.ctl dbbad.ctl equip.ctl ```
Note: Do we need to modify dbbad and dbba2 in order to have both systems running in parallel, or do we need only one of them?
Note2: ibad.ctl is modified in pcfske, nots sure if it's needed in pcfs-2ke KFwZCxnMQNt2AgjmUYpcKT
Note3: skedf.ctl does not properly show dbbc3 and flexbuff (?)
### Comunication [email2] The selections list of software to be downloaded on the machine is a bit overkill. Some of the java scripts did not install. In principle java is not needed, unless is used for AusCope software MoniCA
All your station code including trakl will need to be ported to 64 bit. The biggest problem comes “long” and “int” types having a different size on 64 bits. On 32 bits, they were the same, and the FS source used both. We decided it was simplest to replace all the “long” declarations with “int” where possible. I have a tool for doing most of that work, which you can find here:
https://github.com/dehorsley/unlongify
The one thing you’ll need to watch is some system calls expect “long”, so you might have to go back and fix those. I don’t recall any of those in trakl though anyway.
The other thing you will need is a newer version of the Fieldtalk library. The older one did not support 64 bits properly. I’m not sure if you will need to purchase a new license or if the one you have covers upgrades. Ed has emailed the developer.
[email1]
The new version of FS with the integration VGOS branch is for the moment called alpha2. The source code is available in my computer and pcfs-2ke. When planning to use a 64-bits codes→ You’ll need to port your station code to 64-bit if you want to do the former. We didn’t have too much trouble porting trakl for our Patriot 12m we have here, though you will need a new version of the Fieldtalk MODBUS library. I can provide you with a tool that will help there.
### VGOS 9.12.13 branch
Communication with Ed Himwich 13.08.2019
What we are distributing is called 9.12.13. This differs from what Onsala has, 9.12.12, only that it has the more complete FS display server that is in 9.13.1. Wettzell has this now too.
This version is primarily aimed at VGOS operations. It might be possible to use it to drive a DBBC3 for S/X operations with some edits of ‘.prc' files. I am not sure. We are hoping to release a version that combines the two branches (and hopefully 32/64 bit compatible) late his summer. That version might work for S/X operations with the DBBC3, but I think there is some work yet to do (like setting the bitmask automatically).
Currently, it has DBBC3 commands:
``` bbcnnn nnn=001…128 ifx x=a…h iftpx x=a…h bbc_gain cont_cal ```
There are help pages for each.
There is no time-setting/monitoring, yet. There is both continuous (procedure ‘cont_enable’ in ‘dbbc3po.prc', see below) and non-continuous (‘cal_enable’, also in ‘dbbc3st.prc') Tsys available (use 'tpicd=tsys’ and ‘caltsys’ respectively). However until we have multicast, continuous cal loads down the system too much to be useful during experiments. What I suggest for now is that non-continuous cal to check the system by manually running ‘caltsys' when the system is waiting for the next observation. Maybe ‘caltsys' could be added to the end of ‘checkmk5’ to do it automatically, but it will not be getting Tsys onsource in either approach. FIVPT and ONOFF work for both types of cal.
In ‘equip.ctl’, you will need to set your rack type to ‘dbbc3’. You will also need an additional line with the firmware version, number BBCs per IF, and number of IFs. For an example, please see:
/usr2/fs-9.12.13/st.default.control/equip.ctl
Please note that if you want to run a VGOS experiment with the DBBC3, we will need to completely update your procedure files in the ‘.skd' files. I think you can only use the DBBC3 with ‘jive5ab’ on the recorder for VGOS. I don’t know anything about the wiring, but Onsala would probably be able to help you with that. You would select ‘dbbc3’ and ‘mark5b’ in ‘drudg’. We can discuss the logistics of schedules when you get closer to using it, but again Onsala may also be able to help. In particular, we need to get as much of the set-up as we can into ‘.skd’ file. I am working on getting this from Rüdiger, but neither of us has had time yet.
There are two example procedures in /usr2/fs-9.12.13/st.default/proc:
dbbc3st.prc - some useful things for the 'station' library dbbc3po.prc - some useful things for 'point' library
These are both works in progress and are for systems with 8 BBCs/IF and 8 IFs. Your feedback and suggestions would be appreciated to improve these. They contain some things that may be Onsala specific (cable and noise diode control) unless you have CDMS and the same control programs are available for them. Also there may be differences in your LOs.
(I think you already set-up for 9.12.x. If so, you won’t need to copy the
/usr2/fs-9.12.13.st.default/control/rdb??.ctl files
to /usr2/control. These must be present even if you aren’t using RDBEs, but in that case they should have no non-comment lines)