<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
One tidbit of information that may be useful on the number of
independent (3 dB spaced) beams per element. CSIRO's analysis predicts
this to be 2.4 elements per beam. I checked their analysis, and found
that it is accurate for large N, but breaks down for small arrays,
since small arrays have a larger field of view in relation to the
number of elements than large arrays. For a 19 element array, the
number of independent beams is about 11.<br>
<br>
Recently Bruce Veidt sent out a communication which suggested 6
elements per beam, but I'm not sure where this came from, and that
value doesn't jibe with my analysis.<br>
<br>
In case "independent beams" is confusing to anyone, think of it this
way. With an N element array, if one forms M beams, and uses those
beams to image the array field of view, then as M is reduced from N to
zero the average sensitivity over the field of view to an arbitrarily
located point source drops off slowly, but when M is smaller than the
number of 3 dB spaced half-power beams that tile the field of view, the
average sensitivity begins to drop off rapidly. So, it's very
convenient to think of the area of the field of view measured in half
power beam (HP) areas as the number of independent beams, since only a
modest improvement in sensitivity can be had by forming more beams,
whereas average sensitivity rapidly becomes small if fewer beams are
formed. <br>
<br>
It is true that the ripple in sensitivity over FoV caused by forming
fewer than N beams is not desirable. When I was in Sydney, CSIRO was
struggling to determine the optimal "oversampling" factor (i.e., how
many more beams to form than the HPB area of the FoV), balancing signal
processing hardware with sensitivity flatness, but the right answer is
still somewhere between the HPB area and a small multiple of the HPB
area.<br>
<br>
It hasn't been shown yet, but I conjecture that same conclusion holds
whether eigenbeams or point beams are formed.<br>
<br>
Karl<br>
<br>
Brian Jeffs wrote:
<blockquote cite="mid:F1B30E75-FF84-4E85-B346-E00BECA3767D@byu.edu"
type="cite">
<pre wrap="">Rick and all,
On Feb 4, 2010, at 11:47 AM, Rick Fisher wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Brian,
Thanks very much for the beamformer outline. How does Jason handle
the
frequency dependence of the beamformer weights? Is there an FIR is
each
signal path or maybe an FFT - iFFT operation?
</pre>
</blockquote>
<pre wrap=""><!---->
The beamformer weights are applied per frequency channel, each of
which is less than 1 MHz wide. Thus broadband beamforming is
effectively implemented by using potentially different weights for
each narrow band. This is actually overkill since the fractional
bandwidth per freq. channel is very small. We could probably get away
with using the same weights over 20 MHz of adjacent channels.
</pre>
<blockquote type="cite">
<pre wrap="">What to do with the high bandwidth beam outputs at high time
resolution is
a standard pulsar problem. Since the beam outputs are essentially the
same as you'd have with a conventional horn feed, all of the current
tricks of the trade will apply. As far as I know, all pulsar
surveys are
done by generating spectra with a frequency resolution consistent
with the
highest expected pulse dispersion, squaring the signals, integrating
for
the selected resolution time, and streaming this to disk. Pulse
searches
are then done off-line in computer clusters or supercomputers. (Our
pulsar experts can chime in here.) We'll need to match our output
data
rates with available storage and post-processing capabilities - a
time-dependent target. Maybe someone could give us some currently
feasible numbers and time derivatives
Before completely buying into the voltage sum real-time beamformer we
should keep in mind that a lot of single dish applications don't need
voltage outputs as long as the time and frequency resolution
parameters
are satisfied. If there are big computational savings in a
post-correlation beamformer, and we satisfy ourselves that there's
not a
hidden gotcha in this approach, we should keep it on the table.
</pre>
</blockquote>
<pre wrap=""><!---->
The real driver here seems to me to be the required time resolution.
This will control the integration time, and thus the data rate. The
numbers I quoted for data rate assumed no integration, i.e. output
every sample to the next downstream system. This is clearly beyond
our near term capabilities, so we must have some integration going on
in the CASPER beamformer.
There are no computational advantages to post correlation beamforming
unless either a) you need to do the correlation anyway; then
beamforming is almost free, or b) the number of computed beams is
significantly larger than the number of array elements. In either
case, the time resolution imposed by the correlator STI time must
match the observation goals.
</pre>
<blockquote type="cite">
<pre wrap="">My guess
is that any computational advantages evaporate or even reverse when
the
required time resolution approaches the inverse required frequency
resolution.
</pre>
</blockquote>
<pre wrap=""><!---->
I agree with this statement.
Brian
</pre>
<blockquote type="cite">
<pre wrap="">Rick
On Thu, 4 Feb 2010, Brian Jeffs wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Rick,
See below:
</pre>
<blockquote type="cite">
<pre wrap="">Is your assumed beamformer architecture voltage sums or post-
correlation?
In other words, are the beams formed by summing complex weighted
voltages
from the array elements or by combining cross products of all of the
elements? John's reference at <a class="moz-txt-link-freetext" href="http://arxiv.org/abs/0912.0380v1">http://arxiv.org/abs/0912.0380v1</a>
shows a
voltage-sum beamformer. The post-correlaion bamformer may use fewer
processing resources, but it precludes further coherent signal
processing
of each beam.
</pre>
</blockquote>
<pre wrap="">Our plans are based on a correlator/beamformer developed by Jason
Manley for
the ATA and some other users (the pocket packetized correlator).
He recently
added simultaneous beamforming to the existing correlator gateware,
so they
run concurrently. In our application the only time this is
required is
during interference mitigation. Normally we correlate during
calibration and
beamform otherwise.
His design is a voltage sum real-time beamformer. At this point he
does not
compute as many simultaneous beams as we need to, so I think we
will have to
exploit the computational trade-off to do either beamforming or
correlation
but not both, or it will not fit in the FPGA. Post-correlation
beamforming
is really quite trivial, and has a low computational burden, so
that could be
added to the correlator and run simultaneously. I believe that
when we need
simultaneous voltage sum beamforming and correlations (as when doing
interference mitigation) we will have to reduce the effective
bandwidth. We
really cannot take Jasons' existing code and plug it right in for our
application, but it will serve as a very good template. That is
why we have
Jonathan out at UC Berkeley for 6 months, so he can learn the ropes
and then
work on our correlator/beamformer.
</pre>
<blockquote type="cite">
<pre wrap="">Very roughly, the science requirements for a beamformer fall into
two
camps, which may be operational definitions of first science and
cadallac/dream machine: 1. spectral line surveys with bandwidths
in the
3-100 MHz range and very modest time resolution and 2. pulsar and
fast
transient source surveys with bandwidths on the order of 500+ MHz
and <=50
microsecond time resolution. The 2001 science case says pulsar work
requires bandwidths of 200+ MHz, but the bar has gone higher in the
meantime. One can always think of something to do with a wide
bandwidth,
low time resolution beamformer, but it would be a stretch. The GBT
sensitivity isn't high enough to see HI at redshifts below, say,
1350 MHz
in a very wide-area survey. Hence, building a beamformer with wide
bandwith but low time resolution may not be the optimum use of
resources.
Also, the 2001 science cases assumes 7 formed beams, but the
minimum now
would be, maybe, 19 and growing as the competition heats up.
</pre>
</blockquote>
<pre wrap="">We are operating under the assumption of at least 19, and probably
more than
40 formed beams. If we only use the correlator for calibration,
then we
should be able to achieve both relatively wide bandwidth (250 MHz)
and high
time resolution (we will get a beamformer output per time sample,
not just
per STI interval). Dan and Jason feed that based on their
experience with
existing codes this is achievable on the 40 ROACH system we
sketched out, but
we will have to wait and see. If we run into bottlenecks we will
have to
reduce either bandwidth or the number of formed beams.
One issue I am not clear on yet is what we do with the data streams
for 40+
voltage sum beams over 500+ frequency channels. How do we get it
off the
CASPER array, and what will be done with it? For 8 bit complex
samples at
the beamformer outputs you would need the equivalent of fourty 10
Gbit
ethernet links to some other big processor, such as a transient
detector. If
this is unreasonable then either the number of bits per sample,
bandwidth, or
number of beams will need to be reduced. Alternatively, it is not
hard to
add a spectrometer to the beamformer outputs inside the
correlator/beamformer, and this provides a huge data rate
reduction. But how
do we handle data for transient observations where fine time
resolution is
critical?
Brian
</pre>
<blockquote type="cite">
<pre wrap="">Counter-thoughts?
Rick
On Wed, 3 Feb 2010, Brian Jeffs wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Rick,
We have a rough architecture and cost estimate for a 40 channel
correlator/beamformer capable of 40 channels (19 dual pol
antennas plus
reference or RFI auxiliary) over 250 MHz BW. We worked this out
with
CASOER
head Dan Werthimer and his crack correlator/beamformer developer
Jason
Manley. It will require 20 ROACH boards, 20 iADC boards, 1 20-
port 10
Gbit
ethernet switch, and some lesser associated parts.
Our recent ROACH order was $2750 each, iADC: $1300 each,
enclosures: $750
each, XiLinx chip: free or $3000, ethernet switch: $12000.
You can use your existing data acquisition array of PCs as the
stream-to-disk
farm, but will need to buy 10 Gbit cards and hardware RAID
controllers.
The total (which will be a bit low) assuming no free XiLinx parts
and not
including is: $168,000.
Of course this does not include development manpower costs.
Brian
On Feb 3, 2010, at 3:05 PM, Rick Fisher wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This is an incomplete question, but maybe we can beat it into
something
answerable: Do we know enough about existing applications on
CASPER
hardware to make a conservative estimate of what it would cost
to build
a
PAF beamformer with a given set of specs? I'm looking for at
least two
estimates. What is a realistic set of specs for the first
science PAF
beamformer, and what would the dream machine that would make a big
scientific impact cost? You're welcome to define the specs that
go
with
either of these two questions or I'll start defining them by
thinking
"out
loud". The first science beamformer will guide the initial system
design,
and the dream machine will help get a handle on longer range
expectations.
Cheers,
Rick
_______________________________________________
Pafgbt mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pafgbt@listmgr.cv.nrao.edu">Pafgbt@listmgr.cv.nrao.edu</a>
<a class="moz-txt-link-freetext" href="http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt">http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">_______________________________________________
Pafgbt mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pafgbt@listmgr.cv.nrao.edu">Pafgbt@listmgr.cv.nrao.edu</a>
<a class="moz-txt-link-freetext" href="http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt">http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
Pafgbt mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pafgbt@listmgr.cv.nrao.edu">Pafgbt@listmgr.cv.nrao.edu</a>
<a class="moz-txt-link-freetext" href="http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt">http://listmgr.cv.nrao.edu/mailman/listinfo/pafgbt</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Karl F. Warnick email: <a class="moz-txt-link-abbreviated" href="mailto:warnick@byu.edu">warnick@byu.edu</a>
Associate Professor Tel: (801) 422-1732
Department of Electrical & Computer Engineering FAX: (801) 422-0201
Brigham Young University
459 Clyde Building
Provo, UT 84602
</pre>
</body>
</html>