Vegas Pulsar Commissioning Tests

Notes on how to test pulsar observing modes for the VEGAS backend system.

Recent Changes

  • Added basic instructions for running the dealer/player software (-RL, 2/23/15)
  • Created sub-pages for detailed notes for tests of each mode (-RL, 2/17/15)
  • Created Google spreadsheet for summarizing testing progress for each mode (-RL, 2/17/15)
  • Expanded on specific tests to run on the test pulsar to check for properly recovered pulse and timing (-RL, 2/13/15)

Mode Tests Summary

Initial Setup and Configuration

Descibe here how to configure your account / session in order to run the tests. e.g.
  • source /home/gbt/gbt.bash
  • source /home/gbt/sparrow/sparrow.bash
  • source /home/pulsar64/guppi/guppi.bash
  • Astrid session to use... (TODO)
  • Where the data will go... (TBD)

Running the Dealer and Player

  1. Start the player on srbs-hpc1
    1. ssh into srbs-hpc1 as monctrl (may need someone else to do this for you -- this will be annoying for testing, we should fix this (PBD) )
    2. source /home/dibas/dibas.bash
    3. Run 'player'
  2. As yourself and from any computer on network, source /home/dibas/dibas.bash and run 'dibas_status'. This will let you check that things are being configured properly
  3. Launch and interact with the dealer
    1. As yourself, ans from any computer on network, source /home/dibas/dibas.bash
      1. if python2.7 directories under /opt/local already exist in your PYTHONPATH this seems to break things. A workaround is to 'unset PYTHONPATH' before sourcing dibas.bash (PBD 2015/02/27)
    2. Run 'dealer' to bring up an ipython session with the dealer and player tools pre-loaded
    3. Connect to the dealer using 'd = Dealer()'
    4. Connect to the player using 'p = d.players['BANKA'] (note that different banks can be specified here)
    5. Set the desired mode using 'p.set_mode(<MODENAME>); for a list of available modes type 'd.list_modes()' or check /home/dibas/etc/config/dibas.conf
    6. Set other parameters; for a list type 'p.help_params()'
    7. To start, type 'p.prepare()' followed by 'p.start()'
  4. Check dibas_status to find which directory your data is being written to.

Hardware testing

RichardPrestage comments: for each of these sections it would be nice to have subsections:
  • how precisely to invoke the test
  • what to look for during the test
  • how to run any necessary data analysis software
  • expected results, or how to compare to a "standard" data set.
  • other useful notes

Tests of the data coming from the FPGA systems that do not depend on the "real" software.
  • Use udp_recvor similar low-level software to inspect data packets directly:
    • Check basic packet format (number of bytes, counter values, etc) look as expected.
    • Check that packet counter increments as expected, and resets on arm.
    • Check that data packets are being received at the correct rate at all expected destinations.
  • Use FPGA data-capture blocks(?)
    • Check ADC histograms
    • Check spectrum for expected shape (no spurs, tone shows up in correct channel, etc).
  • For coherent modes, can use guppi2_stream library to generate/inspect spectrum.

Software testing

Tests of the software components that do not depend on having the "real" hardware.
  • Can use udp_send or similar to generate data packets for testing.
  • Check that everything runs as expected (ie, no errors/segfaults/etc).
  • Check that software components create readable output files
    • Verify with standard data-processing packages (PSRCHIVE, presto, fold_psrfits)
  • Check that software can keep up with expected data rates.

Integrating SW and HW

  • Test M&C framework for loading FPGA designs
  • Test code for loading parameters, read back correct values.

Testing with locally generated signals

Tests of the full system using lab-generated input signals.
  • Sine-wave input
    • Input sine wave(s), check that they appear at the correct freq in output files
  • Artificial pulsar
    • Uses python scripts in /users/pdemores/dibas/test_scriptsto test various modes
      • NOTE: These scripts may need to be edited for VEGAS
      • Check scripts for hard-coded parameters (e.g. observer, project ID) before running
      • tests a single coherent dedispersion mode
      • tests a single mode and multiple VEGAS Banks
      • tests a single incoherent dedispersion mode
      • tests coherent dedispersion modes
      • tests incoherent modes
      • tests multiple scans of a single mode
    • Check that correct pulse period is recovered
      • If the data are on search mode, they will need to be folded first. PRESTO or PSRCHIVE can be used for this:
        • If using PRESTO, run a command like prepfold -p <period> -nosearch -npart 60 <filenames>
        • If using PSRCHIVE, run a command like fold_psrfits -t 10 -F <freq> <filenames>
      • Visually inspect the folded profiles
        • If using PRESTO, open the output poscript file (*
        • If using PSRCHIVE, use pav
          • pav -DFT displays integrated pulse profile
          • pav -YFpd displays phase vs time
          • pav -GTpd displays phase vs frequency
        • Does the pulse appear stable in phase?
        • Are there any dropouts or gaps in the data?
      • Calculate TOAs
        • Will need to make a standard template
        • If using PRESTO run a command like -g <template> -n 6 <pfdfile> where <pfdfile> is the PRESTO *.pfd output
        • If using PSRCHIVE run a command like pat -F -f princeton -s <template> <filenames> where <filenames> are the folded fits files
      • Use Tempo to recover the pulse period
        • Make a dummy parfile with the expected period
        • Make a tim file using the TOAs (Should the site code be set to @ (i.e., barycenter) for the test pulsar?
        • Run tempo -f <parfile> <timfile>. The fitted period should be correct and the residuals should be flat.
    • Run long (multiple-hour) test, check for time jumps
      • Follow the same procedure as above and check the Tempo output for any jumps
    • Run multiple-restart test, check for consistent pulse phase
  • Polarization response (needs correlated signal; AP can be used for this)
    • Check cross-term phase stability during long test
    • Check cross-term phase stability on multiple restarts

Testing with astronomical signals

Tests of the full system using real telescope signals.
  • Observe a test pulsar (preferably an MSP; B1937+21 is ideal).
    • Make sure pulsar is detected in all modes
    • Make sure timing aligns correctly between different modes, restarts, etc
  • Long (multi-hour) test in certain modes?

Other notes

-- RyanLynch - 2015-01-29
Topic revision: r10 - 2015-09-28, RyanLynch
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback