GUPPI Project Closeout

The GUPPI project is winding down, with most objectives completed. This page is an attempt to organize and catch all the little things that need to be done before we can claim that the project is complete. Please add your suggestions here!

GUPPI Project Status

Both the Search mode machine and the timing mode machine are virtually complete. There are some integration and testing items left for the timing modes, and some issues relating to the installation and maintenance of the software that we would like to clean up. A few features are missing, and bugs remain in the Timing mode code.

Two features which we expressly are not including in the wrap-up are the narrow-band modes featuring a DDC in the IBOB, and the baseband sampling modes. These features can be added later, and are out of scope for this document. Any items which do not provide baseline functionality, i.e. all the items in the "GUPPI Controller Enhnacements" section are out of scope for completion of the project.

What to do with tabled MR and/or software features? ModificationRequest14C209 I assume they remain tabled, but should be recorded somewhere for posterity. (ALS)

Items to Complete

The following is a list of items that we think need to be completed.


The system is complete, with the exception of the following:
  • DONE Complete building and testing of PFBs with 0.95 bandwidth and 12 taps in all modes <= 1024 channels.
  • DONE Fix the "Dropped Packet" problems with GPU 5, 6, and 7.

M&C Software

  • DONE Complete the integration of the timing modes with Astrid, configtool, and the manager

GUPPI Software

  • GUPPI Controller Enhancements Out of Scope
    1. Establish a configuration scheme so that each branch of the guppi controller (guppi-controller, wuppi-controller, bee2, daq-interface) is working from the exact same code and pulling directives from a friendly config file.
    2. Package the guppi controller project so that it's installable by e.g. `easy_install guppi`. (DAQ could use this too, via configure && make. In that case, we could even have a makefile to install both the controller and the DAQ software.)
    3. Clean up the command-line interpreter to make it easy to configure: user scripts, motd, prompt behavior, ...
    4. Integrate error reporting.
    5. Use something lighter than SOAP for serialization since our command scheme is far simpler than what SOAP is good for. (This requires a manager change, but hopefully superficially.) Not just for cleaner design, but faster responses.
    6. Collect some guppi recipes for useful things to do in the user scripts area or with scripts/guis calling out to the guppi command-line.
    7. Provide hooks for extending tab-completion (assuming the expert interface is still a focus).
  • Timing Mode Stuff
    1. Finalize/test integration with astrid/config_tool/etc.
    2. DONE Fix the continual low-level packet loss to gpu5-7. This may be as simple as getting new cables.
    3. Fix a lingering GPU folding bug that messes up the profiles when packets are lost.
    4. Automate the process of pulling/merging results from gpu nodes to beef.
    5. misc gpu cluster sysadmin stuff: NTP occasionally stops working, this is bad for pulsar timing. Kernel upgrades break the nvidia drivers, making GPU code unusable til the drivers are reinstalled. Start all required guppi software components on bootup. Make the /home/pulsar64 situation less kludgey.
    6. Investigate more of the existing coherent mode data taken so far to look for any problems. Decide if we need any more telescope test observations to be happy.
    7. Revisit the precise timestamping issues (fractional sample start time, full system delay measurement) and decide what, if any, work needs to be done.
    8. Build/test 12-tap, 0.95-width PFBs for all the different N_chan.


One key part of completing the project is documenting the project so that it can be maintained by those who did not build it, and so that others can duplicate it if they wish to do so. We're woefully behind on this part of the project, as usual. Here's something Ron said that sums it up:

"On a general note, we should make sure our documentation is up-to-date on installing all the software, including configuration hints and documented dependencies. We could also use a little polish on the front to make sure all the loosely federated documents are coherent and easy to find; that we are telling a useful story to someone with fresh eyes."

  • Hardware Documentation
    1. DONE Drawings showing all the interconnects between boxes, modifications to boxes (i.e. the fan mod to the ibob chassis), parts lists
    2. Documents for the FPGA personalities. The DSP personalities don't need much description, the output FPGAs need a lot. A complete list of personalities we have should be developed.
    3. Papers on the tricky bits. The Xaui synchronization is worthy of a memo, for instance. As is the pipe configuration and settings explanation. Probably others.
  • User Documents
  • Software Documents
    1. A man page or equal on each user program/function (like guppi_plot_adc_hist)
    2. Enough code documentation so that the average programmer/scientist can figure out what's going on
    3. A road map to the system, so that people know where to find code that does certain functions.
    4. A list of all the required versions of the required libraries.
    5. A how-to guide for installing and configuring all the host computers and software.
Topic revision: r6 - 2010-12-02, JohnFord
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