The Flexbuff is our new data recorder, designed to handle VGOS data at 16+ Gbps recording rates. We're testing it out during AUSTRAL15 at 1 Gbps. It records to a large interal array of hard drives rather than a special diskpack as in the mark5b.
The recorder is being controlled by a “spare” pcfs machine - pcfsho. It's running the a15**hb.snp snap file to get the correct scan names and recording times. There is a VNC session running on this machine which can be viewed with “vncviewer pcfsho:1”. The FS output will likely be displaying a large number of errors which can be safely ignored.
Use the PuTTY session running on dbbchb to issue the “reset” command, followed by “timesync 2015-02-06T15:37:27+11:00” [replace the date string with an AEST timestring in the near future {The +11:00 code at the end sets the time zone}]. When the time is approximately correct, press enter to start the timesync procedure. NB - don't worry about exact precision at this point as there are occasionally large and impossible to predict latencies in the software.
Once synchronised, you should make a test recording to confirm that the time-stamping is correct. In pcfsho's oprin, enter these commands - “scan_name=test,test,test,10,10” and “disk_record=on”. Wait 10 seconds and then send “disk_record=off”. Check the output of jive5ab [visible in the “observer@thor” window in the upper right of the pcfsho VNC session] for the time when “Reply: !record=0” was sent. This should be the correct time, which we then need to compare with the apparent time in the recorded data. There is now a script which makes this relatively painless - run “~/timecheck.sh” as ovserver@thor [a.k.a the flexbuff]. Compare the reported timestamp against the correct time - if the difference is a non-integer number of seconds (to within 10 ms) then there's a nastier problem. If the difference is an integer offset, you can correct this using the following procedure.
In the PuTTY session in dbbchb, enter the command “tick”. You should get some dates and a message about how to adjust the time. It's nominally live, but doesn't seem to be completely working. In any case, please enter the necessary correction by pressing the - or + keys the appropriate number of times, checking that the tick display has been updated correctly, and then stopping the tick display by pressing “t”. NB - if the time reported by “timecheck.sh” is ahead of the true time, you need to apply a negative
correction with -.
After adjusting the times, please repeat the recording test to confirm that the jive5ab and file timestamps are aligned (again, to within 0.01 seconds). If so, then you're set to resume the recording.