Running the NEW DFB at Jodrell Bank Observatory

To see newest data goto DFB Data

Of course everything I know about the DFB came from the FINE MANUAL, Warwick Wilson's SPD command list and DUMMSY command list (UPDATED 090915)

Complete startup from a shutdown machine (both PC and DFB powered off)

Power up PC (dfb0.ast.man.ac.uk). If you are not at JBO and it seems inaccessible, you may need to ask the controller to help. (it sometimes sticks from a "restart" and should be shutdown and then powered back on!")
Power up the DFB. The embedded PC on the DFB downloads its system from the PC using tftpboot. It takes approx 30 secs and when complete will have displays on the small display and various flashing LEDS! Again, if you are trying to do this remotely, and there's no communication with l-bcc11 from dfb0, you may need the controller to power cycle the DFB crate
Log in to the dfb0 as corr and start a vnc session for the controller using the command startvnc1 Open vncsession :1
If the last shutdown was unclean, a lock file will have been left and vncserver will complain and not start. You can check whether vnc is running using ps -elf | grep vnc, if it isn't, remove the file, and rerun startvnc1
Start and set up the ATDC
Type atdc in an 80x24 xterm. and select the defaults for access, then 2 for clock control.
Follow the instructions to set the time correctly (you will need to ask the controller to read back his GPS time display or find a reliable synchronised time display from another computer used for observations.
Select the clock display option and accept the defaults for clock phase monitoring (yes and 600 secs), double check that it is right to the second and the day, month, year etc are correct.
Finally see if the tick phase (displayed bottom right) is somewhere between 0 and 399 nS. It can be adjusted in 200ns steps by typing s and entering the amount of slide required in nS. Leave the clock running.
Leap secs need to be changed in TWO places! The first is to type a new DUTC when starting the ATDC. The value set here will be remembered as a default. The second is to change the environment variable DUTC which is set in a dfb startup script /home/corr/cor/define (you will at least need to stopdfb rerun the define script and startdfb. If you manually run a testobs the DUTC will be shown in the dummsy window as the obs. starts. If it hasn'r changed, you'll need to reboot the DFB PC.
Hmmm.. you may also want to add the leap sec to $TEMPO2/clock, but this isn't critical
New startup script
To start from nothing, in a convenient xterm, type startdfb
This will start pdfb4, dummsy and dscom in their own windows. You may need to adjust window positions
(conversely, if any part of the running software has failed or got stuck use stopdfb which will stop any running processes and cleanup everything ready for a restart. This script also reboots the DFB so it may be useful to try this if things don't start. ( The ATDC, SPD and PSRCONTROL are not affected).
stopstart will run stopdbf then startdfb
Now start spd with the command restartspd which brings up a new xterm, running spd in the required configuration.
Finally, start the VAX connection which lets the controllers schedule and run observations, by typing psrcontrol. This program does an auto-telnet to ARTHUR, and runs the scheduling software psrlist.
If psrcontrol refuses to start, there may be too many users logged in to ARTHUR (it has a max. of 10 interactive logins). A lot of these may be instances of PSRLIST, which can get left lying around if the controller loses or kills the psrcontrol telnetted xterm rather than tidily exiting the ptogram. The only way to sort this is to find somewhere already logged in to arthur (I often leave an arthur xterm running on ector, and Andrew usually has one open.) once you've managed to find somewhere logged in you can find all the current users by typing WHO.
If there a multitude (ie more than one) versions of PSRLIST running, KILL THEM!
You can kill a process on a VAX by typing:
STOP/ID=pid where the pid is given in the first column of the results of the WHO command.
If the telescope is in operation, you can get the controller to start an observation and if all goes well, the software should start by doing a configuration (a config window will appear, stuff happens, then if successful, it will iconize to the bar at the bottom). If it fails the screen will stay there with an error message (you can try Return, then program to try the config again - but running stopstart is the easiest way out of this)
If the telescope is observing, ask the controller to start the observation. There will be activity on all the windows, and with luck a "good" spectrum will appear after the third subint (ie ~30secs or 60secs for 20 sec subints). If it doesn't work, try typing restart in an xterm window in corr's home directory, or for a complete flush out and restart, use the command stopstart
If the telescope is not observing, you can check that the DFB is properly setup, by going to the PDFB4 gui. Try to reconfigure by selecting a 512MHz file (the BW is the middle term) eg pdfb4_1024_512_1024 and CONFIG. If this is successful, start a run going by typing go in the DSCOM window. Integrations and folding should start, with a spectrum appearing after ~3 integrations. (halt will stop the integration)
PDFB4 is the DFB monitor.
dummsy sends commands to the DFB and gets status info
dscom is our link between the observing schedule and dummsy. (Our standard configurations are loaded into dscom from ~corr/dscom.cfg)
SPD graphics display - will monitor bandpass and folded data

To run manually - ie without the link to the controllers schedule
open a few xterms
Start pdfb4 and use the gui to load a config. Check that the DFB configures without errors (or at least doesn't get stuck and says OK Done at the end) this is shown in a window called CFG. which flashes up for a few seconds then gets minimised.
Start tkds
you can now run the DFB manually - see Warwick Wilson's dummsy command list

Manual DFB control through tkds - Folded data
Configure the DFB - Choose a config file from the pull down list For folded data, choose a file pdfb4_bins_bw_chans and click on the COnfig button. Check that the DFB configures without errors (or at least doesn't get stuck and says OK Done at the end) this is shown in a window called CFG. which flashes up for a few seconds then gets minimised. Our default is pdfb4_1024_512_1024.
(Pulsars with periods less than ~4 ms need a different config - we use pdfb4_128_512_2048) Work your way down the GUI using the following selections (JB defaults)
- Observer - Your pick :-)
- Obs Type - PSR WBPSR
- Source - Name of pulsar including B or J eg B1931+24
  As far as I can see from the src code, if the source name starts with B or J, there will be a call to psrcat to produce a par file (online.eph) and a call to tempo2 in predictor mode ro produce a t2pred file. This is the default behaviour which we are using. See notes about catalogue at the end
  It appears to be possible to supply a polyco file. This will be searched for as Sourcename.polyco if the source does not start with B or J or possibly if some undocumented commands are used. In the code there is a tkds command "POLYCO". Warwick says that using this command will force the software to load a file /home/corr/cor/pulsar/online.polyco.
  Fill in the other fields on this line (coords and epoch). Stick to J2000 if you are using PSRCHIVE, it grumbles about B1950 coordinates. (The software will still run without changing these fields but you'll have misleading info in the data files header.
- Freqs: We only use one freq. band
  Frequency - 1532.0 Sky frequency in MHz of the centre of the baseband. ie for a 512MHz band, supply the sky frequency equivalent of 256MHz
  Bandwidth - 512. It should match that selected in the Config file or the software will grumble (but run)
  Rest Frequency 1420.405 - "Defines the rest frequency, in decimal MHz, of one spectral line contained in each band"
  Inverted - Yes
  Write Chans - 128-895 This can be "ALL" or a subset of channels to write to the output data files. We are saving disc space and time by only dumping the part with a signal in it. It's a good idea to make the number of channels a power of 2 - some software won't handle it otherwise, and it makes bscrunching easier!.
- Commands: These are the Jodrell defaults
  fold For folded data :-)
  site 8 for Lovell
  cycle 10 - cycle time (default), needs to be at least twice the pulse period. Range 2s to 32s.
  avg 1Number of cycles to average before writing to file
  fo Filename.rf Open a file
- GO starts the dfb on the next 10sec line - activity happens in the pdfb4 window!
  .
  .
  .
  .
- STOP The DFB takes 1-2 cycle times to empty its buffers, finally a STOP will appear in the pdfb4 window. (HALT will do an untidy but immediate stop).
- fc Close the data file
PSRCAL drives the noise diode in phase with the pulsar period to produce a folded data profile of the noise diode. the qualifiers are offset and duration (in pulse periods) so the command PSRCAL 0.5 0.5 will give a folded profile with the noise diode OFF/ON
I'll write up Search data later - but basically you need to use a srch_bw_bin config file, set WBPSR,SSET (search set mode),SNB,SNP,SSAMT,(AVG 1,CYCLE 10 maybe) and with no file open, do a short run. This sets dclevels and spans etc. Then use command SEARCH (rather than SSET), open a file, GO ..... STOP, FC

SPD
To view the data live, you can use SPD (See Warwick Wilson's SPD command list

spd

chan 600 800
auto
sel bi

chan 450 700
auto
sel dp (In manual mode, the DM will have to be set using the PSRDM xx command. At Jodrell, this ) set manually

chan 450 700
sca a 0 2000
sel aa bb
x

Finally, if you want to start observations from the controllers Scheduling program, while arthur is still in use, tycho (currently) or goedel must be running hsl2mcastreceiver and repeater (current version is repeater_hsl2_art - see /etc/rc.local for tycho startups). ector must be running doobs 1, and arthur_server
In (yet) another xterm (there should be one left!) start dscom. This reads the messages from doobs on ector, and runs the DFB according to this data and the current dscom.cfg which specifies the centre freq, bandpass and DFB configs to use.
(If you need to change the DFB config, you'll need to change the dscom.cfg softlink and restart dscom. To stop dscom tidily, type (no echo) VAXSTOP in the dscom window, then type exit. to restart it type startdscom.
Useful commands - dscom commands (typed with no echo!) vaxstop and vaxgo stop the analogue filterbank mirroring without exiting dscom
if you crash out of pdfb4 or tkds, exit them both and type corkill a couple of times to remove any processes before trying to strt things again.
bcckill will stop and restart the bcc process - (need to be root)

Cleaning and Timing Analysis

At the end of each pulsar obs, a script is run which send the .rf file to mamba for cleaning, which is done on mamba:2 (for dfb data)
If mamba has been restarted, ssh pulsar@mamba and run vncserver -geometry 1600x900 :2 .
Open the vncviewer and you will find startup instructions for the cleaning and processing software in a text file on the desktop.
mamba autocleans each file as it arrives from the DFB, and makes a wrk file. We then do a manual clean on the wrk file, after which this clean is applied to the full resolution file. The resulting file (now with a zzz extension) is sent to rook, where scripts are run to scrunch the file, produce toas and send these to /psrdata/timing.

Known problems

Catalogue problems. Obsolete. The original catalogues are held at /home/corr/psrcat
The supplied psrcat holds some VERY out of date ephems. There are add on catalogues called obs99.db and obscat.db which may or may not be better, but not it appears for things not observed by Parkes. Using the data from these catalgues gave me pulsars (especially the "classics") which were obviously drifting in phase over runs as short as a few minutes.
I have replaced all the supplied catalogues with one generated from the eph files used on the VAX which I know are up to date.
Observation will give obscure errors about pulsar period (in pdfb4) if it isn't found in the catalogue under the name used by the VAX (if dscom is running) or by the name entered in tkds. The name should be preceded by a B or J.
Update 2017, we have moved away from the catalogue to individual parfiles for each pulsar and they can be found in /home/corr/psrcat/parfiles. These are a copy of those on the roach and cobra2. (I thought I'd left an rsync script around to keep them up to date from roach, but I can't find it!)
At the start of an observation, tkds searches for a parfile in this folder and copies it to /home/corr/cor/pulsar/online.eph
Then it runs this though tempo2 in prediction mode to get polycos for folding
tempo2 -f /home/corr/cor/pulsar/online.eph -pred "8 54843.530968 54843.67713 1284 1560 12 2 12688"
You can run these two commands from a terminal to see if they work. (Check the online.eph produced and see what tempo2 makes of it). If the problem lies with the pulsar name used by the VAX this will have to be fixed in the pulsar observing list and ephemeris files held on the VAX
The max. subint is 32s and this means that the max pulsar period which will work is 15 s. (perhaps alternate configs with different phase bins or freq. chans will allow longer subints - needs a look at the documentation - Nope looks like 32s is a fixed max.)
Another source of error are that FITS file headers do not have spaces for some ephemeris variables, and the FITS file header writer does not handle this problem gracefully - it fails to write each subint. DM2 and F4 have so far caused this problem so it's advisable not to use these in inline parfiles

Changing the DFB code

Log in as caj
cd $COR_SRC
Most of the sources came from Parkes and are the originals.
The following modules are modified for JBO:
- tkdummsy has some special code to retrieve telescope status data. Most/all comes from ector in the form of a mcast messages used by dfb/roach/cobra2 etc. There are also mods to do with retrieving par files (we no longer use the supllied psrcat, but individual files).
- dscom was supplied as a skeleton and has been filled in. It receives messages from ector describing an observation and uses this to pick all the config details required by the dfb and send them to dummsy as commands.
Edit the code as required in $COR_SRC. But the code should be compiles using make in /home/caj/jbcor/xxxxxx/.
There is a description of why this should be done somewhere in the documentation, tidiness, I guess, since you can also make in the $COR_SRC area

If you have any queries please contact ChrisJ (alternative programmers may be available!)

Jodrell Bank Centre for Astrophysics

Department of Physics and Astronomy

Our Research

Running the NEW DFB at Jodrell Bank Observatory

Of course everything I know about the DFB came from the FINE MANUAL, Warwick Wilson's SPD command list and DUMMSY command list (UPDATED 090915)

Complete startup from a shutdown machine (both PC and DFB powered off)

Cleaning and Timing Analysis

Known problems

Changing the DFB code