Pulsar Observing


Description: The pulsar observing mode commissioningcovers the testing, development and documentation of observingstrategies and post-processing guidelines. In addition, the outline/designof the use of hardware/software resources is developed and implementedthrough this group.


  • Leader: Demorest/Brisken
  • Primary Participants: Frail, Ransom, Rupen, Robnett, Sowinski
  • RSRO Participants: Deller, Lazio

Pulsar Observing Documentation

Coarse Commissioning Plan & Status

Note: All pulsar tickets in JIRA may be found by doing a quick search on 'Pulsar'; you can also go under 'Issues'->'Search for issues', select on Project: EVLA Commissioning and Science Verification and Components: Pulsar.

Target Responsible Quarter Status
157 - Pulsar Observing Documentation (Parent) Demorest 2011-Q2 choice-no
- 158 Pulsar observing commissioning plan Demorest 2011-Q2 choice-no
- 159 Pulsar observer recommendations documentation Demorest 2011-Q4 choice-no
160 - Pulsar Observing Preparation (Parent) Demorest 2011-Q3 choice-no
161 - Pulsar Observing Staged Testing Demorest 2011-Q4 choice-no

Notes and Reports

Software Requirements

An initial set of requirements for real-time coherent mode pulsar observations for the VLA via phased array mode and VDIF packets. (Adapted from an email by S. Ransom [2011 September 23].) These constitute the information needed for processing.
  1. Observing mode (i.e., is the array in phased array mode and are VDIF packets being transmitted?)
  2. Pulsar being observed (via standard name, if possible -- the name would be used to grab an appropriate ephemeris file which would eventually be provided by the observer)
  3. Number of subbands (or channels) in total
  4. Number of CBE nodes to be used (allows the number of subbands per node to be computed)
  5. Bandwidth per subband (which should be signed so that upper vs. lower sideband can be distinguished)
  6. Center (or edge) frequency for each subband
  7. Number of polarizations
  8. How the raw data is stored in each VIDF packet (i.e., are there multiple pol'ns or multiple subbands in each packet?)

Subsequent to this set, it has been recognized that certain metadata or user-supplied data are also needed.

folding experiments

the following intent needs to be set to specify that on-line de-dispersion will be conducted and the data folded at a specified period

In addition, the user should provide a .par file or equivalent and have the capability to specify

Final freq resolution (or number of channels)

Integration or dump time per fold
Number of pulse phase bins for folding
Number of poln products to save (eg, summed-poln, two-pol or full-stokes)

In an email exchange, it has been decided that the following intents will be used for specifying these user-specified parameters:


searching experiments

The following intent needs to be set to indicate that the equivalent of filterbank data will be dumped


In addition, the user should have the capability to specify

Freq resolution or nchan
Time resolution
Number of poln products
Number of bits in output.

As above, the searching will involve the following intents:


Testing,Meeting Minutes, and Email Correspondence

2013 October 2 week

Wharton, Cordes, Chatterjee (Demorest?) visiting; Rupen, Butler, Sowinski at AOC


[from Bryan]
  1. we decided in the morning meeting that the focus should be on three areas:
    1. a - packet collision
    2. b - 2-bit
    3. c - yuppi_gluer
  2. note that script and VCI files are in /home/mchost/evla/scripts/test/realtimePulsar/2013-Oct-01
  3. we started out by just reproducing the observing done previously.we verified that things basically worked, including the pulsar software, and that multiple subband phasing still doesn't quite work (no surprise!).
  4. ken and michael figured out how to avoid the packet collisions by both increasing the number of CBE nodes in use and by using anon-zero value for the lag packet interframe delay. huzzah! we essentially saw no packet collisions after that. the setting is now in the VCI file in use. (Ken notes later, reproduced below, that this approach avoids but does not solve the problem.)
  5. we tested 2-bit, which seemed to work, but the reported number of dropped packets in that case was very large. we scratched ourheads and went off to lunch.
  6. paul figured out the cause of (5) and fixed it, and 2-bit seemed to work after that. but paul needs to have a look at the actual data in the stored files to be sure. can we get a status from you on that, paul?
  7. we took a full SB's worth of data in search mode, for robert to start investigating yuppi_gluer. he has a preliminary version that works for search mode, but has not had a "real" dataset to test it on. paul has a preliminary version of yuppi_gluer for fold mode.
  8. ken showed that when multiple subarrays are observing, the pulsar software does not discriminate between them, so if a non-pulsar subarray starts a non-pulsar scan, the pulsar software thinks it needs to stop recording. we need to invent a way to identify scripts/SBs/subarrays and paul will have to modify the code. i'll send a separate email with some details on that after our 10:00 meeting.
  9. scott reminded us that the approved globular cluster project is S-band 2 GHz. in order to do that we will have to set up a new script and VCI file for the tuning and correlator setup (almost all of the work is in the VCI edits). and paul will have to change the pulsar software so that multiple versions can run on the same CBE node (we will have to send out twice as much data to each node,but we will send it to two NICs).
  10. robert had a quick look at some of the 8-bit data and it looks like the changing levels are going to be a real problem.

[from Bryan]

what we did this afternoon.
  1. i edited the script so that it would tune at S-band, with non-overlapping basebands. it covers roughly 2500 to 3500 MHz, which should be a mostly RFI-free region (above XM and Sirius in the 2300-2400 range, and below the cell phone crud at 3700). i also edited it so that it waits until the antennas get on source before it starts doing anything real, so we don't have to start and stop as we've been doing.
  2. i also edited it to look at B1937+21, to begin with at least (see 3e below for the exception).
  3. we then did 6 tests:
    1. 8-bit folding. this was just to convince ourselves that things were mostly working, and i hadn't fat-fingered any of my edits (of course i had, but they were easy to fix!). we spent a few minutes in this mode actually on the pulsar.
    2. 2-bit folding. this was to test paul's fix of the bit-order in the 2-bit pulsar code. we also spent a few minutes in this mode on the pulsar.
    3. 8-bit searching. we did this as we have done before, for a control. we did it for the full 10 minutes of the first set of pulsar scans. there was one oddity during this data; cbe-node-12 was reporting about 0.08% of dropped packets. that was the only instance of dropped packets we noticed (there may have been others that we didn't notice - at times we weren't looking that closely).
    4. 8-bit searching. this time, ken sent out the magic command to turn off the automatic windowing, which seemed to work. at least the X-bar GUI showed it as turned off. we took about 10 minutes of pulsar data again. ken executed the command at about 21:17 UTC.
    5. 2-bit searching. this was mostly so robert can have some files in this mode to play with. note that we thought that the magic command would be replaced with the default (which is having the automatic windowing turned on), but we found out before doing the next test that it didn't. so this test was also done with the automatic windowing turned off. that should be "interesting" for 2 bits!
    6. 8-bit searching, ransom & demorest pulsar (Ter 5A, at ~ 17:48, -24:46). this was to test whether S-band, at 1 GHz, is good enough for that observation. if it is, then we can almost observe any time we want - we're basically there. if not, then we either have to go to L-band, where RFI is a much bigger problem, or try to implement 2 GHz of bandwidth, which is a lot of work for the pulsar software.
  4. some comments on multi-subband phasing and RFI. when we were observing B1937+21, the spectrum looked extremely clean, and the multi-subband phasing worked extremely well. all subbands, antennas, and IFs phased well. in test 3e, we finally started to see some RFI in subbands 1 and 2 (0-relative), and we saw some of the same multi-subband phasing problems that we've seen at L-band and in our other tests. for test 3f, the RFI was a bit worse still. there was RFI in many of the subbands, though it was very time-variable - there was little persistent RFI. but it had the same effect on the phasing. so, we're wondering if all of the multi-subband phasing problems are due to RFI. it deserves more testing.
so, paul should have a look at the 2-bit folded data to see if the bit-order is correct now, and robert will have a look at the 2- and 8-bit search data. but i need to copy some data over for him so he can do that. i'm off to do that now.

(Paul later looked at these data and reported that they look good. B1937+21_yuppi_20131002.ps contains four pages, the first three are 8-bit observations, the final one is 2-bit.)

[from Paul]

We definitely have some detections of J1022+1001 in folded 2-bit mode ( J1022+1001_2bit.png). It looks like the dispersion removal within each subband might be a little messed up though. This could come from bit-ordering issues so I'd like to do a few more tests sometime. Do you guys think it will be possible to get to 1937+21 during test time? Or is that too late in the day? That would be an ideal source for checking this stuff.

Also we didn't take any 8-bit observations of 1022 to compare with. Next time we get a chance it would be good to do the 8-bit scan immediately followed by 2-bit scan on the same source. Does this require rephasing?

[from Robert]

The first plot ( J1022_nchan640.png) is the prepfold plot folding on the known period and dispersion measure of the pulsar. It shows a clear detection, but there's some RFI present and there's no signal for some of the sub-bands. The central plot (with "Phase" on the bottom axis and "Frequency" on the right axis) can be compared to the plot Paul sent around. By eye, at least, the plots seem to match up well.

The second plot ( J1022_mean_subs.png) is a dynamic spectrum of the observation, where the mean intensity has been calculated over 1 second for each channel. The central plot shows these values in the Time-Frequency plane. The top plot shows the average over the full observation for each channel. The right plot shows the average in frequency over each sub-band (with an offset added for clarity).

The most obvious feature of this second plot is that there are regions in each sub-band where there signal is either bottomed out at zero or maxed out at 255 for long stretches of time. I'm still looking into the timescales for these jumps, but by eye it looks like smallest time scale is about 10 seconds. I'll have a better answer to that in a bit.

[from Bryan]

i had been thinking that we really should add a new intent to the first scan of any SB that observes pulsars to indicate that pulsars will be observed therein. in thinking more about it, i don't think we should do that.

the first time an Observation.xml document appears to the pulsar software that has a ScanIntent that contains OBSERVE_PULSAR (these are defined as OBSERVE_PULSAR_FOLD and OBSERVE_PULSAR_SEARCH right now), the pulsar software should just take that as the equivalent of the above intent in the first scan of the SB.

in that same Observation.xml document there will be two other intents that will be needed to tie all of this together. at least for simple cases - for more complex cases we may have to invent a more clever scheme. those intents are SBID and subarrayId. that uniquely identifies the SB (the "script" if you will), and the subarray within that script.

so, the first time an Observation.xml document contains an "intent" element that is like "ScanIntent=OBSERVE_PULSAR*" (which we're already triggering on), then those other two "intent" elements should be parsed from the XML (the SBID element will look something like: "SBID=24212513" and subarrayId is actually an attribute of the main element). subsequent Observations.xml documents should only be honored by that thread if they have a matching SBID and subarrayId. that should persist until an Observation.xml document arrives with a source name (the XML element is just called "name") that is "FINISH", at which point the thread should know that it is done with this SB (and yuppi_gluer can be run).

[from Ken, on the issue of avoiding packet collisions]

Bryan wrote originally, "ken and michael figured out how to avoid the packet collisions by both increasing the number of CBE nodes in use and by using a non-zero value for the lag packet interframe delay."

The following is more satisfying and likely to be more robust in the long run, which works as long as the visibility data mapping is one-to-one from baseline boards to CBE NICs and all LTAs on a baseline board go to the same NIC.

Arrange for a new VCI attribute, probably in summedArray which causes VDIF packets to be transmitted on SFP1 instead of SFP2 and that VDIF packets have priority (because there is plenty of buffering for lag frames); and ensures that the destination IP and MAC addresses are the same as where lag frames are being sent from that board.

This uses the GigE chip to gurantee that there are no conflicts because only one output wire is used. It works as long as the total data rate from lag frames and VDIF packets is less than one Gbit/sec. Routing of packets to the correct destination in the CBE node is handled by the TCP stack using the UDP port address so it works transparantly at the CBE end.


  1. a new version of telcal was installed this morning. we first did a quick test of looking at a northern pulsar to see how the multiple subband phasing was working, and also how the pulsar software was working. it seemed mostly as before.
  2. after a break where we got details of the NRAO shutdown, michael and i then edited the VCI document we've been using to get a full 2 GHz in S-band. we (well, mostly michael of course!) managed to get it right the first time. we did a quick test of that, and all seemed good. this was using 2-bit, folding.
  3. i then mucked with the script, in order to try to make one that could run for 2 hours or so for a long test looking at Ter 5A. in the process of doing that, i found that the script we've been using was not doing the phasing quite right (it's a detail of how the phases are communicated, stored, and applied). after fixing that, several tests showed the multiple subband phasing working quite well! i believe our problems with this have been related to this and RFI. i also fixed up a small problem at the beginning of the script with the "wait on source" bit. and i put in a fix so that the scans will start and stop on integral UTC 1 second tick boundaries. scott said that pulsar reduction software might be expecting this. note that we don't know what this reallymeans about the exact timing of the VDIF packets, but it's as much as we can do easily from the script level.
    • Paul comments, I don't think you need to do anything special at the script level about the scan start/stop times. The VDIF packets already have complete timestamps included in their headers, and VDIF is specified to always have a integer number of packets per second. The pulsar code currently does the following at startup:
      - wait for a VDIF packet
      - when the first VDIF packet appears, read its timestamp
      - discard this packet and all others until the next integer second
      The main point of this is to make sure that all the nodes use the same data start time. This isn't an absolute necessity, but it makes some the later data processing a bit simpler.
  4. we then tried running the script in 2-bit, searching mode. at this point, the yuppi status screen showed very bizarre behavior where after a few seconds of normal operation, it would start showing large amounts of lost packets, along with a "NET" status of "blocking" (rather than the normal "receiving"). with very random and erratic behavior (wildly varying packet loss fractions, nodes going into and out of "blocking", etc.).
  5. given that, we tried to do the 2-bit folding mode (this still with 2 GHz total bandwidth). the behavior was different but still seemed to be broken. what would happen is that at a scan boundary, the pulsar software would seem to operate normally for a few (maybe as much as 10?) seconds, then the "NET" status would go to "blocking" and would just sit there. no packet loss was indicated. nothing would change (so it wasn't like the above test where things were changing crazily), it would just sit there. until the next scan boundary when it would do the same thing. at this point, i thought the pulsar software might be confused, so i stopped and restarted it several times (along with stopping and restarting the script), but that didn't change anything.
  6. went back to 1 GHz bandwidth, just to be sure we could get back to something we know should work. same result as the test in (5).
  7. gave up. to sleuth what's going on in the pulsar software we now need paul. he should be able to help tomorrow.

while sitting there in the war room, i drew up a state diagram for scott to describe what we were talking about with trying to keep track of scripts and subarrays yesterday. i've attached a better version of this here. note that my assumption is that the <datasetId> element really is unique for both script/SB and subarray. if it turns out that is not the case then we'll let you know. (also note that currently the element is called <datasetID> with a capital "D" but we're supposed to be changing that soon.)
  • Bryan noted later that condition (4), to get to the GLUEING state, should also contain a timeout so that if no state change has happened in, say, two hours, then the assumption is that something went wrong with the generation or broadcast of the FINISH scan document and the glueing should be initiated anyway.
  • Michael notes that an "abort" is likely needed. Bryan asks if yuppi_gluer needs to run at an "abort" or not

for right now it's probably enough to just assume we'll only be running one pulsar script and subarray at a time and put this all in the master program (yuppi_controller). eventually, the way i would code the program is that once you're in the WAITING state, every time you receive an Observation document that indicates pulsar observing with a new <datasetId>, i'd spawn a new thread to handle it (which immediately goes into the COLLECTING state). then each script + subarray is handled by its own thread, and you naturally support multiple ones running at once. then the thread just expires after it is done with the glueing (no need to go back to WAITING - that is handled by the master program). at that point we'll have to do some profiling though to test for collisions again, both in the dataflow and in the CPU/memory usage on the CBE nodes.

[Edited for clarity is the editorial comment made by JL about NRAO shutdown.]



2013 September 23

Butler at AOC

this was mostly simple infrastructure testing, to see if i could make things run without intervention from paul. but also some testing of phasing up 16 subbands per baseband.

for the phasing tests, i ran the same setup we had previously, but moved up to X-band. i sent more details to ken, michael, and vivek, but the bottom line is that it mostly works (aside from a small number of subband/IF combinations that seem to fail). so our failure to phase up is almost certainly because of RFI. we will investigate the ability to use solutions from a "clean" subband to set the phase for the others (i think that is the right solution in the end).

for the pulsar tests, i ran exactly the same file we ran the last time, but from the new subdirectory /home/mchost/evla/scripts/test/realtimePulsar/2013-Sep-23/. the pulsar 1012+5307 was used - i have no idea whether the tempo file is still accurate - this wasn't a true test for that. if it is valid, i guess paul could have a look at the resultant files and see how things look in the end.

i started up the pulsar software on the CBE nodes before starting the script, and unlike last time, everything worked perfectly. after the pulsar scan started, the status page showed most packets coming through, but there was a similar problem to last time, where there was a somewhat repeatable pattern of integrations that had missing packets. last time the pattern was 4 integrations (1 second each) of no missing packets, then 1 integration with missing packets. this time the pattern was different - there were either 5 or 6 integrations with no missing packets, then 2 integrations with missing packets. but not all 8 of the CBE nodes always had missing packets, sometimes a few didn't. i'm sure this pattern is telling us something, but i'm not sure what. we did have a different number of antennas this time than last (1 or 2 fewer this time), but i'm not sure that should make a difference.

2013 September 6

Demorest on phone, Butler (others?) at AOC

[morning, from Paul]

Here is a plot showing two 10-minute scans on 0329+54 from today ( B0329+54_phasing_20130906.png). The left panel is from early on when we were only phasing 2(?) subbands. The right panel is the final scan that Bryan describes below. I clipped the plot color scale at 10% of the max so you can see the off-pulse noise. The pulsar is bright enough to see even without phasing, but I think the phased-up plot definitely looks better.

For these plots, I blanked out a ~20 MHz-wide band near 1620 MHz that has bad RFI, but otherwise didn't do any zapping. These also only show data from baseband 1, which was not affected by the dropped packet problem.

[afternoon, from Bryan]

. we started on 0329 just to reassure ourselves that things were still
in the same shape as when we left off in the morning. paul had
done some modifications to the pulsar software to try to make it
robust against problematic CBE nodes (i think this is right - paul,
if i've got it wrong you can tell us what your really changed!).
unfortunately these caused it not to work. he got it fixed up after
a bit of tweaking. note that one thing is different - if the
monitoring program can't get the status from one of the nodes, it
lists it with the problem 'No shmem'. this does not mean there
is really no shared memory access (which was the problem with node
17 this morning) - it just means it can't get the status. see the
attached screen shot.

. once we got that squared away, 0329 was down in the weeds, so we
moved to 1022+1001. i had modified the script to do the phasing
of all of the subbands in a more elegant way, and that turned out
to work OK, but there was quite a bit of confusion because the
phasing was quite a bit rattier than in the morning. more on that
further down.

. we verified that things were working as previously this morning,
after some fits and starts. then we went on to search mode, and
showed that that worked as well. both of the modes now get the
proper intents from the script itself, and honor them properly.

. i started thinking about the phasing problems, and wondered if the
sun was acting up today. when i mentioned it to paul, a he had a
light-bulb moment - it turns out 1022+1001 is essentially at 0 deg
ecliptic latitude, and goes right behind the sun each year. i had
a look at the sun's ephemeris, and sure enough we were pointed only
a few degrees away. sigh. no wonder the phasing wasn't working.

. so, we moved to 1012+5307 and did one final test, in the folding
mode. that worked pretty well, though there are still some oddities
in the phasing.

[summary, from Bryan]

1. the pulsar software still mostly works (EVLAPulsarSoftware). paul can comment more here,
on changes that he made and tested, but from my end, modulo a few
wrinkles, it mostly works. at least the part that's in place now;
we did not test 2-bit, yuppi-gluer, or other parts.

2. paul's instructions on the wiki page are sufficient for us to run
things here. on the other hand, i think we would be hard-pressed
right now to do detailed testing without paul on the phone. that
will certainly get better with time, but that's the situation right

3. we do, however, still need to sort out the permissions to run the
pulsar software. paul put in a work-around this morning but it's
perhaps not a good long-term solution.

4. there are also still some robustness issues with the pulsar software.
in particular, being robust to broken CBE nodes, or ones with which
the monitoring software cannot communicate.

5. the pulsar software properly picks up the intents that are set in
the script to define things like the tempo file location, number of
channels & polarizations, etc. this works for both fold and search

6. we can properly include the instructions in the script to attempt to
phase up all of the subbands. this is not a statement that the
phasing up is working properly. i think there is still something
odd going on, but it is hard to tell in the presence of the RFI in
L-band. more tests are definitely warranted. note that i tried
setting the time for phasing scans to 20 seconds, and adding another
phasing scan; neither seemed to make any significant difference.

7. there is a curious pattern in the dropped packets. the monitoring
software updates itself every second. while watching it, there is
a clear pattern where there are 4 updates (4 seconds) with no drops,
then 2 updates (2 seconds) with drops. this may be a clue as to how
or why packets are being dropped at all.

8. 1022+1001 is a very naughty pulsar, and, like icarus, flies too close
to the sun.

2013 August 05 week

Lazio, Demorest, Cordes, Wharton visiting AOC; Rupen, Sowinski, Butler at AOC.

Working from a list of tests described initially by Butler, we started a series of tests.


Summary of testing conducted:

0. Software was (mostly) installed in /opt/cbe-local/yuppi. Final location may change, but it was agreed that this location was better than the previous location (on the lustre). Still to be moved is the yuppi_controller code. Also agreed on port 50000 for VDIF input to CBE NICs.

Testing number corresponds to lists of tests from Bryan.
1. Test that software continues to work, given changes since the last time that it was tested. Tests completed. The packet sniffing script was run, on all CBE nodes (1-32), with CBE proper running on nodes 25-32. Multiple CBE "personalities" invoked. The different "personalities" (or modes or whatever the correct term is) were
  • CrsroXrsro - run for an hour or so
  • Cquad1234
  • C_osro16, with BIB stacking
  • 3-bit, using k3eq1ref_2GHz_pickSrc.evla & K3delay.evla
  • CBE time averaging, using CBEintCheck _pickSrc.evla
One remaining item is to rename the yuppi_controller program from its current name (async_mcast.py) to yuppi_controller.

2. Conduct timing tests of software on CBE nodes - not yet conducted.

3. Run yuppi_daq_server while the script from item 1 is running to ensure that there are no collisions between pulsar software and standard CBE software. Test completed, as for #1.

4. Run the entire system, gathering and writing data. Started, and verified that the VDIF packets were reaching the CBE nodes. The data acquisition code did not appear to be reading the VDIF packets, but we had to yield the array for science before this test could be completed.


> 4 - they need to run the entire system, gathering and writing data.
> i believe they have sorted out how and where to write data, but
> i am not positive of this - we need to find out. this will just be
> PSRFITS files. this is really the nuts and bolts of the thing,
> and the real test of the system. it will shake out if they
> really have all of the information they need. for this test, we
> should use pre-defined nodes, which are not being used by the CBE.

Focus of today (and shown at the Science Tea).

We ran .evla scripts located in /home/mchost/evla/scripts/test/realtimePulsar/2013-Aug-05. Data were dumped to /lustre/evla/pulsar/data, in PSRFITS format, in "folding" mode (OBSERVE_PULSAR_FOLD intent).

Observations were conducted of a single 32 MHz sub-band. We believe that this is the largest bandwidth that can be transmitted across the 1Gig links, given the constraint that the current pulsar software assumes 8 bits samples. Both yuppi_controller and yuppi_daq_server were started by hand.

The first observations were of PSR B0329+54, a strong, relatively slow pulsar. Parameters for folding were taken from /lustre/evla/pulsar/tzpar/0329+54.par.

Figure 1 (B0329+54_profile.png) shows the folded profile of the pulsar, obtained by real-time processing. The profile is as expected, consistent with previously published profiles.

Figure 2 (B0329+54_freq-profile.png) shows the frequency-resolved profile. The frequency structure is real and is the result of interstellar scintillation.

Figure 3 (B0329+54_dynamicspectrum.png) shows the dynamic spectrum (power as a function of time and frequency). The structure is real, results from interstellar scintillation, and is consistent with previously published dynamic spectra for this pulsar.

Figure 4 (B0329+54_bitselectionwindow.png) illustrates a problem that we discovered (or re-discovered). The bit selection window can move around, leading to data loss (on time scales of 0.5 seconds) and adjustments in the gain.

Following PSR B0329+54, we repeated these tests on PSR B0809+74. This pulsar is substantially weaker, formally 20x weaker than B0329+54, though interstellar scintillation result in large (100%) variations in the actual flux density at any given time. We were able to detect it.

We also attempted PSR J1022+1001, which is a millisecond pulsar. This pulsar is weaker yet, approximately 2x weaker than B0809+74, and again subject to flux density variations from interstellar scintillation. We did not detect it, which can be plausibly explained given the interstellar scintillations and restricted bandwidth.

Next highest priority steps are to demonstrate that yuppi_controller and yuppi_daq_server can be started automagically and obtain more than 32 MHz of bandwidth, potentially to demonstrate that we can obtain the full 1 GHz of bandwidth.


Started with observations of PSR J0437-4715, a strong millisecond pulsar, with 32 MHz of bandwidth, single subband. This pulsar was detected, just as it was setting.

Moved to observations at 1 GHz bandwidth. We set up an initial .vci document within the RCT, and exported it via model2script. The 1 GHz bandwidth was achieved by 2 basebands, with 16 subbands of 32 MHz bandwidth each. Michael hand-edited it to direct the baseline boards to the CBE nodes. Started with observations of PSR B0329+54. The pulsar was detected, but there was also clear data dropouts. (.vci document is 2X512MHz)

We experimented with trying to turn off the lag frames, so that the only traffic through the switch would be VDIF packets. We discovered that there was no easy way to do so. Ken was able to turn off lag frames from a few baseline boards by selecting them within the GUI. We re-started the observations, this time with only a single antenna in the array as a way of faking the turning off the lag frames. There were still data dropouts.

We then decreased the bandwidth to 512 MHz, as 2 basebands, of 8 subbands of 32 MHz each. (.vci document is 2x256MHz) There were still data dropouts. There was a particular pattern as well, that the first four subbands showed essentially no data dropouts, the next four showed approximately 1/2 of the required data rate, the next four showed approximately 1/3 of the required data rate, ....

James suggested that the VDIF packet delay was set so long that the packets were not able to be transmitted. The explanation is that the VDIF packet delay algorithm adds 6 microseconds for each subsequent board, but the VDIF packets need to be sent every 75 microseconds, otherwise they pile up. Setting the packet delays to all be 0 (aPacketDelay and bPacketDelay attributes in the VDIF element in the VCI). This change solved the data dropout problem, there were no longer any data dropouts.

(Somewhere in here we also configured it so that the VDIF packets and lag frames were not being sent to the same nodes.)

Having detected PSR B0329+54, we switched to PSR J1022+1001, a weaker millisecond pulsar. This pulsar was attempted yesterday, and not detected, but when we had only 32 MHz of bandwidth. We were not able to detect it, but the array was experiencing considerable difficulty in phasing.

We changed the baseband centers in an effort to avoid regions of potential RFI. This change initially appeared to help the phasing, but the ability to phase quickly degenerated, and it was not clear that the array was ever phased.

Significant changes to the pulsar software include
- the ability to initialize and start it on all nodes;
- inserting timing capability to start the pulsar recording when a pulsar scan starts, not when the obs document is received.
However, there may still be a timing issue in that our pulsar test scans are typically 10 min long, but the pulsar recording appears to stop after about 3 minutes.

There was also agreement on additional pulsar intents, reflecting user-specified parameters to be set ahead of time (e.g., within the OPT), and transmitted to the pulsar software. (See above.)

Bruce also updated his cmib command to allow turning off (or on) the automatic tweaking of the "sliding window" (to select which bits go out the VDIF socket). This is "phaseAutoWindow[Off][On]". It is not clear if this feature has been tested yet.


Michael compiles a list of "to-do" items, with additions from Bryan and Ken (and much later, Joe):

In discussions during the week, everybody finally agreed

- /home/mchost/evla/scripts/test/realtimePulsar/ as the location for .evla and .vci files.
- port 50000 for VDIF input to CBE NICs.

This afternoon: talk with Martin, talk with Claire
Claire: what's needed to turn on observing?
gluer? SDM entries? other stuff?
extend the project to next array? (DDT, Gal Ctr, ...)

If the pulsar folk were staying another week, what would we do?
* Check 32-subband phasing
: script to do it
: speed of TelCal: how short can scans/integrations be (benchmarking)

* Send lag frames and VDIF to same NIC, with max. interframedelay
- ponder OPT change to override default interframe delay
- ponder architecture change to have single piece of software decide which NICs are used for what (routing)

- develop better vdif packet delay algorithm, since if multiple VDIF streams are arriving on a single NIC (which we'll need for > 1 GHz bandwidth), they need to not arrive at the same time

* Benchmarking psr software
- what is the max. output data rate for search mode, during a psr observation?
- can we handle 2 128MHz subbands per node?

* Pulsar checks
- check the searching data
- check the visibilities (regular data)

* Sky tests
- 1 GHz observations when phasing works
- run for a week (not observing pulsars)
- long observation of a pulsar -- hours
- phase while observing pulsar (Sgr A*)
: check that SgrA* phasing would work at Ku band (archival data huzzah!)

* OPT mods [Bryan notes that these may be m2s issues]
: turn noise tubes off
: summedArray element: setting MAC/IP addresses (or move this to CBE...)
set VDIF packet delay
: intents: _FOLD, _SEARCH, settings, VDIF_MONITOR (read VDIF but don't write anything -- d10-like display)

: other intents that pass along quantities to the psr s/w. TempoFileName, PsrNumChan, et al. these have to be tested, and then added in to m2s

: decide how to specify that scans are pulsar (and of what flavor). and also how to specify the items i just noted. for instance, can they change per scan, or are they all the same for the entire SB? where do they fit in in the GUI, etc.

* Pulsar software work
- robustness
- handle 2 subbands per node (needed for > 1 GHz/pol'n)
- handle < 8-bits (needed for >2 GHz/pol'n)
- yuppi_glue

- display modes

- documentation (at least at the level of being able to start and stop things, until more automated)

* VCI-ish stuff
- AGC on & off
- sliding window on & off

* Think about
- requantizer gains
- 3-bit (shudder)

* Unified status display: CBE, pulsar software, real-time trans. software...

2012 May 23

[This bug has since been fixed. There was a subtraction of half the width of a subband that was being done unnecessarily. JL]

The existing pulsar software to capture the data flowing into the CBE is known to contain a bug in that it does not get the frequency information correct. A test was conducted to assess whether the bug had been fixed.

At the time of this test, S. Ransom reported that the calculated (center) sky frequency from 1 subband was

BW = 128 MHz
Fctr = 1264.0 MHz

B. Butler noted that the center frequencies for the two subbands should be 1328 and 1456 MHz---1264 MHz is the signed sum of the LOs, or the lower edge of the lower frequency subband. The suspicion is that a subband bandwidth divided by 2 factor is being missed.

The following is taken from an email by B. Butler:
the script is at:


note the "-new" in the name.

The following is from an email by S. Ransom:

It is just packet-capturing software right now. So what I do is login to a cbe node:

> ssh cbe-node-09
> cd /users/sransom/EVLA_pulsars/multicast
> ./async_mcast.py > packet.log

That's it. In that directory there is an example how you can read things back and calculate info from the packets: example_use.txt

I have it running now, so if you run it it you will get a socket error. You could run it on another cbe node, though...

2012 May 3

Attending: Cordes, Demorest, Jones, Ransom, Wharton, Lazio

Actions [Suggested responsibility]:
  • Check whether a CBE node is processing single or dual polarization (relevant to timing mode). [Lazio]
  • Conduct test of real-time data packets flowing into software. An initial test could be performed on any target, not just a pulsar. [Team, coordinated with NRAO]
  • Pulsar software running on CBE nodes must be provided with information about the frequency of the sub-band that it is processing. Requires mapping between baseline boards and CBE nodes be made available (and/or suitable API). [NRAO]
  • Expand 'intent' keyword to describe pulsar observations and allow VCI document to carry additional information for pulsar observations. [NRAO]
  • Provide listing of additional information desired for pulsar observations. [Ransom]
Lazio reviewed previous meeting. Suggested that we consider pulsar observations as "search" and "timing" mode. Also noted that PSRFITS is an acceptable file format for the Archive. In the previous meeting, there was some concern about the fact that the metadata and data are stored in the same file, which is not the current architecture for the Archive; subsequent discussions have suggested that this concern is not a significant issue.

For "search" mode, PSRFITS standard allows for scans to be broken in time, frequency, or both. Thus, data flow could be from baseline board to CBE node, with each CBE node processing a separate sub-band and sending the results into the Archive as PSRFITS. Agreement that the only processing on the CBE node required was the extraction of data from the VDIF packets, accumulation for user-specified time (for GC project this would be 0.5 ms), then writing to the Archive as PSRFITS format (or to a cache for subsequent writing to the Archive).

For "timing" mode, the de-dispersion and folding can be done on an individual sub-band basis, provided that each sub-band contains both polarizations. Data flow would be similar for search mode. The key requirement for pulsar timing is that the processing software needs to know which frequency is being processed on which CBE node. Team believes that no API exists for how this information would be multi-cast so that the processing software could access it.

For pulsar observations, additional information is needed to construct the PSRFITS header. An easy way to support this additional information would be to expand the 'intent' keyword. For example, 'Pulsar Timing' for pulsar timing and 'Pulsar Searching' for pulsar searching. These intents are in addition to the "autophasing" intent that exists currently within the OPT. Previous conversations have suggested that this approach would be reasonable.

2012 May 1

Attending: Brisken, Clark, Mioduszewski, Rupen, Lazio, Wharton

A summary of the current status of the phased array was presented. Phased array work is effectively split into two parallel tracks. One track focuses on a single sub-band capability, which is most relevant to VLBI observations. This mode has been reasonably well tested, including by Deller, Demorest, and Ransom for pulsar observations (NRAO eNews). It is not currently working, but it is believed that an impending software upgrade will restore its functionality. The second track focuses on phasing all sub-bands. It is known that the correct delays are not being applied to the sub-bands, only the 0th sub-band delay is computed correctly. Clark believes that he has at least a partial solution, may be able to test this week.

There was discussion of the format for data to be stored in the Archive. PSRFITS is a widely recognized standard format, which Lazio suggested would meet both pulsar and NRAO requirements. There was initial agreement that this format seemed reasonable, however, Rupen then pointed out that PSRFITS stores both the metadata and the data in the same file, which is not the approach used in the Archive. Metadata and data are stored in different files, on different file systems. Accessing the metadata from the CBE nodes may not be straightforward. [Subsequent discussions with Butler suggest that PSRFITS may be acceptable and that there may be a way to access the metadata.]

There was discussion about whether the various sub-bands need to be processed together or can be processed simultaneously. Rupen (and others?) emphasized that inter-process communication between sub-bands would be difficult.

2011 November 29

Action: Demorest to identify factor of 2 error in computing frequencies.

Demorest, Ransom, and Butler tried a test of broadcasting the frequency information so that CBE nodes could identify which frequency was being processed. A factor of 2 error was present in that the calculated center frequency was 1264 MHz, but should have been 1328 MHz. The frequency of 1264 MHz was the lower edge of the sub-band, suggesting that there was an error of (sub-band bandwidth)/2 in the code. (Reference: email exchange)

During this observation, a new intent was introduced (by hand, OBSERVE_PULSAR_DEDISPERSION). The MCAF routine did not recognize it and replaced it with UNSPECIFIED, which is appropriate behavior. However, the original intent should have been retained in the Observations log and could be used during subsequent processing. (Reference: email exchange)

2011 November 7

G. Jones and Lazio attempted phased array observations of the Crab pulsar. Monitoring of the array status in the Correlator war room suggests that the array was phasing correctly, over a 64 MHz (128 MHz?) bandwidth. However, it was attempted to write the data to a VLBI Mk5c unit, which failed.

[Demorest and Ransom attempted to capture the data in real-time? Not clear if this was successful.]

2011 October 5

Demorest modifies GUPPI code to allow it to read and convert VDIF packets from two polarizations (two streams) on the network. The data are buffered in memory until dpsr can access it and coherently de-disperse it. A test of "playing back" the data from a Mk5c unit onto the network demonstrated that the code could re-detect a pulsar.

2001 September 29

Subject: Re: Required info from multicast (or other) was Re: Pulsars at the EVLA
Date: Thu, 29 Sep 2011 10:34:41 -0600
From: Bryan Butler <bbutler@NRAO.EDU>
To: Scott Ransom <sransom@NRAO.EDU>
CC: Joe McMullin <jmcmulli@aoc.nrao.edu>, Paul Demorest <pdemores@NRAO.EDU>,James Robnett <jrobnett@aoc.nrao.edu>,Bryan Butler <bbutler@aoc.nrao.edu>,Rich Moeser <rmoeser@aoc.nrao.edu>,Michael Rupen <mrupen@aoc.nrao.edu>,Martin Pokorny <mpokorny@aoc.nrao.edu>

let's pick an easy one - item 2. [See S. Ransom's set of Software Requirements.]

the executor sends out what we call the Observation Document at the beginning of each scan. actually, it's before the scan begins; during
normal operation it's roughly one scan ahead.

this document is sent out as an XML document as UDP packets over multicast. i've attached the current schema for this document to this email, but note that for any production software, the schema should be retrieved from our commons area, so that if changes are made, they are picked up automatically. the multicast information is:
port: 53001
similar to the observation document schema, for production software this needs to be pulled from our commons area (EVLAConstants.java contains
this information - you're looking for X2DCAF _SOURCE_IP and X2DCAF _SOURCE_PORT for group and port).

in the observation document is an element called <name> which will have the source name. something like:
or similar.

the edge frequencies (per item 6) are also available in this document. there will be something like:
<sslo Sideband="1" FEfilter="0" BWcode="0" IFid="AC" Receiver="6GHz">

the rest of the information is going to be trickier, and will probably have to come from the CBE. well, except item (1), which will have to come from elsewhere (it might be in the observation document, but not as directly as you might think or like).


Subject: Re: Required info from multicast (or other) was Re: Pulsars at the EVLA
Date: Thu, 29 Sep 2011 14:03:07 -0400
From: Scott Ransom <sransom@nrao.edu>
Organization: NRAO
To: Bryan Butler <bbutler@nrao.edu>
CC: Joe McMullin <jmcmulli@aoc.nrao.edu>, Paul Demorest <pdemores@nrao.edu>,James Robnett <jrobnett@aoc.nrao.edu>,Bryan Butler <bbutler@aoc.nrao.edu>,Rich Moeser <rmoeser@aoc.nrao.edu>,Michael Rupen <mrupen@aoc.nrao.edu>,Martin Pokorny <mpokorny@aoc.nrao.edu>

OK, sweet. Thanks for this.

So in the last hour I've gotten the following to work:
  1. I have a little python loop that is running and catching all of the Observation Documents via multicast.
  2. I've used the python tool generateDS.py to create a python parser for the Observation.xsd XML schema file
  3. Using the code resulting from #2 (which is auto-generated), I'm able to parse the multicasts and easily extract any of the observing info (which are all set attributes in a python class).
So if I can get the info about the other required multicasts and their XML schemas, I think I can have a config-file generator written for the pulsar dedispersion software in very little time.

-------- Original Message --------
Subject: Re: Required info from multicast (or other) was Re: Pulsars at the EVLA
Date: Thu, 29 Sep 2011 13:50:14 -0600
From: Bryan Butler <bbutler@nrao.edu>
To: Scott Ransom <sransom@nrao.edu>
CC: Joe McMullin <jmcmulli@aoc.nrao.edu>, Paul Demorest <pdemores@nrao.edu>,James Robnett <jrobnett@aoc.nrao.edu>,Bryan Butler <bbutler@aoc.nrao.edu>,Rich Moeser <rmoeser@aoc.nrao.edu>,Michael Rupen <mrupen@aoc.nrao.edu>,Martin Pokorny <mpokorny@aoc.nrao.edu>

[The following reference Software Requirements.]

1. Observing mode (i.e. are we in phased array and will we be getting vdiff packets?)

in the observation document, there will be one or more lines like:


for the pulsar observing, there will be one of these like:




you should key off of those to know that the scan is for pulsar observing. we will have to at some point sort out which pulsar observing is meant to be sent to your software and which is "normal" WIDAR pulsar observing, but let's not worry about that now.

note that the start time, in LST, of the scan that the observation document describes is given in an element like:


you'll want to convert this to UTC to get timing right to know when to start your programs up.

2. Pulsar we are observing (via standard name if possible -- we would use this to grab an appropriate ephemeris file which would eventually be provided by the observer)

i think we covered this already.

3. number of subbands (or channels) in total

this one i'm not sure where it is best to get the information from. michael, martin, or rich can comment.

4. number of CBE nodes to be used (allows us to compute the number of subbands per node)

ditto on this one. it will depend somewhat on the testing for now. martin or james could chime in.

5. bandwidth per subband (this should be signed so that we know whether upper or lower sideband)

another one i'm not sure where best to get the information. the CBE passes this information to MCAF in a multicast document (i think? this isn't in the document that we just changed to HTTP is it?) so you might intercept it there. martin or rich should comment.

6. center (or edge) freq for each subband

i think we covered this already.

7. number of polarizations

this is in the same category as 3 and 5. martin or rich could comment.

8. how the raw data is stored in each vdiff packet (i.e. are there multiple polns or multiple subbands in each packet?)

i think there's only one way it's stored - we don't have any options. michael, do you know? we could (or should) ask adam, walter, or brent.

2011 September 23

Portions of an email exchange on required information for getting the phased array mode implemented. Email is listed chronologically.

Subject: Re: Required info from multicast (or other) was Re: Pulsars at the EVLA

Date: Fri, 23 Sep 2011 14:16:22 -0600
From: Joseph P. McMullin <jmcmulli@nrao.edu>
To: Scott Ransom <sransom@nrao.edu>
CC: Bryan Butler <bbutler@nrao.edu>, Paul Demorest <pdemores@nrao.edu>,James Robnett <jrobnett@aoc.nrao.edu>

And for my end, here's the pointer to the documentation:


(Note that I still need to add a polarization fraction table).

My understanding was that:
- James will send out the multi-cast group information
- Bryan will send out the XML schema as appropriate for parsing the key info areas

The outstanding phased array issue was:
- might need to add in the model2script the usePhasing command; there was some confusion about the sequence but this appears to be needed following a registerPhasing; talking with Amy/Dave about this.
- you should be able to set up (mostly) valid phased array observations via the OPT now (with the caveat from the first point). I'm hoping that Amy can support you in this as needed.

Subject: Re: Required info from multicast (or other) was Re: Pulsars at the EVLA
Date: Fri, 23 Sep 2011 14:29:26 -0600
From: Bryan Butler <bbutler@nrao.edu>
To: Joe McMullin <jmcmulli@aoc.nrao.edu>
CC: Scott Ransom <sransom@nrao.edu>, Paul Demorest <pdemores@nrao.edu>,James Robnett <jrobnett@aoc.nrao.edu>,Bryan Butler <bbutler@aoc.nrao.edu>

we can't send out multicast group info until we determine which multicasts they will need to subscribe to. problem is, from just a quick perusal of the list, it won't come from a single one. some will come from the Observation document, which goes over the main M&C multicast, but i think some is going to have to come from CM or CBE, and that is a different channel. and some we don't even have at all in the current system (like item 8). so it's not as straightforward as it might seem.

ditto the XML schemata - we have to determine where in the system all of the information is coming from first.

we could send them information on all of our multicast group/port combinations, and all of our XML documents, but i think that is kind of silly since they'll only want a couple of them in the end, probably.

we should sit down some time next week with the folks that know (michael, sonja, martin, rich, joe, me, maybe barry) and sort out that bit first.

we are also going to have to discuss item 2, because that is information that should come via the OPT, but it's unclear what the pathway is. it should be stored in the SDM somewhere, so needs to be passed around, but don't think there is currently a table in the SDM for it (because ALMA isn't interested in pulsars, and we haven't forced the issue yet). in the short-term we can use a short-cut as scott suggests, just have them read in a file from somewhere that can key off of source name (from a known list), but eventually this won't suffice.

the other outstanding issues that i can think of:
- calibration (flux density and polarization come to mind, but what about bandpass?)
- how we are going to do the phasing and pulsar operationally? are we going to switch off one or the other, for resource purposes in the CBE nodes, at the appropriate times? this is the major unknown left in the whole thing. if we can't make this work, then the pulsar processing has to be done on its own hardware.


Subject: Re: Required info from multicast (or other) was Re: Pulsars at the EVLA
Date: Fri, 23 Sep 2011 14:35:15 -0600
From: Bryan Butler <bbutler@nrao.edu>
To: Joe McMullin <jmcmulli@aoc.nrao.edu>
CC: Scott Ransom <sransom@nrao.edu>, Paul Demorest <pdemores@nrao.edu>,James Robnett <jrobnett@aoc.nrao.edu>,Bryan Butler <bbutler@aoc.nrao.edu>

oh, and in the long-term sense, add to the outstanding issues:

- how we are going to archive the data

short-term it's not an issue, but once it becomes an operational mode, we have to archive it somehow. i'd really like it to be stored as SDM+BDF, but if that is hugely impractical then we may have to find another solution.


-- JosephMcMullin - 2011-03-13

  • 2013 August 5 Figure 6: frequency-phase plot for PSR J0437-4715; signal-to-noise ratio may be poor because the pulsar was setting and it may have been below the elevation limit of many of the antennas:
    J0437-4715 vla freq-phase.png

  • photograph of white board from AOC discussion during week of August 5:
    IMG 1605.JPG

  • 2013 September 6 figure - phasing tests over a single sub-band, and all sub-bands:
    B0329+54 phasing 20130906.png

  • 2013 October 2 figure - J1022+1001 in 2-bit "folding" mode, likely issue with bit ordering causing sub-band de-dispersion removal issues:
    J1022+1001 2bit.png

  • 2013 October 2 figure - J1022+1001 in 8-bit mode, shown in a prepfold:
    J1022 nchan640.png

  • 2013 October 2 figure - J1022+1001 in 8-bit mode dynamic spectrum:
    J1022 mean subs.png

  • 2013 October 3 figure - state diagram developed by B. Butler:
    Butler PulsarStateDiagram.jpg
Topic attachments
I Attachment Action Size Date Who Comment
B0329+54_bitselectionwindow.pngpng B0329+54_bitselectionwindow.png manage 25 K 2013-08-08 - 01:23 JosephLazio 2013 August 5 Figure 4: illustration of the effects of the bit selection window; there is both data loss and a change in gain
B0329+54_dynamicspectrum.pngpng B0329+54_dynamicspectrum.png manage 29 K 2013-08-08 - 01:22 JosephLazio 2013 August 5 Figure 3: dynamic spectrum for B0329+54; the structure is real and is the result of interstellar scintillation
B0329+54_freq-profile.pngpng B0329+54_freq-profile.png manage 94 K 2013-08-08 - 01:21 JosephLazio 2013 August 5 Figure 1: frequency-pulse phase for B0329+54; the frequency structure is real and is the result of interstellar scintillation
B0329+54_phasing_20130906.pngpng B0329+54_phasing_20130906.png manage 130 K 2013-10-02 - 22:40 JosephLazio 2013 September 6 figure - phasing tests over a single sub-band, and all sub-bands
B0329+54_profile.pngpng B0329+54_profile.png manage 6 K 2013-08-08 - 01:20 JosephLazio 2013 August 5 Figure 1: profile of B0329+54
B1937+21_yuppi_20131002.psps B1937+21_yuppi_20131002.ps manage 1 MB 2013-11-16 - 16:32 JosephLazio 2013 October 2 figure - B1937+21 folded data, both 8- and 2-bit
Butler_PulsarStateDiagram.jpgjpg Butler_PulsarStateDiagram.jpg manage 404 K 2013-11-16 - 17:41 JosephLazio 2013 October 3 figure - state diagram developed by B. Butler
IMG_1605.JPGJPG IMG_1605.JPG manage 1 MB 2013-08-21 - 11:03 JosephLazio photograph of white board from AOC discussion during week of August 5
J0437-4715_vla_freq-phase.pngpng J0437-4715_vla_freq-phase.png manage 23 K 2013-08-08 - 19:11 JosephLazio 2013 August 5 Figure 6: frequency-phase plot for PSR J0437-4715; signal-to-noise ratio may be poor because the pulsar was setting and it may have been below the elevation limit of many of the antennas
J0437-4715_vla_profile.pngpng J0437-4715_vla_profile.png manage 9 K 2013-08-08 - 19:10 JosephLazio 2013 August 5 Figure 5: profile of PSR J0437-4715; signal-to-noise ratio may be poor because the pulsar was setting and it may have been below the elevation limit of many of the antennas
J1022+1001_2bit.pngpng J1022+1001_2bit.png manage 37 K 2013-10-02 - 22:57 JosephLazio 2013 October 2 figure - J1022+1001 in 2-bit "folding" mode, likely issue with bit ordering causing sub-band de-dispersion removal issues
J1022_mean_subs.pngpng J1022_mean_subs.png manage 520 K 2013-10-02 - 23:03 JosephLazio 2013 October 2 figure - J1022+1001 in 8-bit mode dynamic spectrum
J1022_nchan640.pngpng J1022_nchan640.png manage 585 K 2013-10-02 - 23:02 JosephLazio 2013 October 2 figure - J1022+1001 in 8-bit mode, shown in a prepfold
Topic revision: r17 - 2015-10-06, PaulDemorest
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