[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Event Detection and Spectral Line Radio Astronomy
Glen I Langston
Re: [Discuss-gnuradio] Event Detection and Spectral Line Radio Astronomy Working.
Tue, 9 Apr 2019 16:38:08 -0400
> On Apr 9, 2019, at 4:10 PM, Marcus D. Leech <address@hidden> wrote:
>> My goal is to get 4 horns arranged in a “Y” and correlate the common events,
>> since we’re recording
>> time tagged voltages. With a total spacing of 40’, we might achieve
>> localization of about 1 degree
>> uncertainty on the sky. All 4 horns have computers that are time-served by
>> the same local, GPS-based, time
>> server computer on the network.
> A diurnal pattern to RFI and noise bursts is nearly uniquely indicative of
> human activity during low solar activity.
> Solar noise bursts tend to sweep in frequency.
Yes RFI is certainly a likely explanation. However an advantage of Horns is
that they are more resistant
to RFI than dishes, but not immune.
> If you have N antennae pointing at notionally-different parts of the sky, and
> they all produce some kind of correlated "blip",
> then that tells you that the source event is "local". We were going to use
> this approach at SBRAC, and had an array
> of 5 C-band feeds in a pentagon configuration at the feedpoint of the dish.
> Use anti-coincidence to weed out "local"
> events. But that project imploded before we got a chance to do that. The
> feeds are still "up there”
> I've been doing SDR-based radio astronomy experiments since 2004. I've
> noticed a diurnal pattern in "annoyances" in nearly
> every observing situation.
> For FRBs, one needs to de-disperse prior to detection, and since the DM is
> unknown, the approach that is often used is to do post-facto
> analysis of baseband data, or have enough compute-horsepower available in
> real-time to have several different DM hypotheses
> "in play" at any given time
We’re not actually looking for FRBs (although we’ed be happy detect an unusual
one). The keys science
goals is more aligned with the Auger experiment Radio Engineering array.
(See The Auger Engineering Radio Array and multi-hybrid cosmic ray detection
The radio flashes come from cosmic rays hitting the Earths atmosphere, so are
They’re using 20-80 MHz, we’re using 1420+/-6 MHz. The horn beam is 15
degrees, so we’d only be localizing
flashes within the field of view of the horn. If the events are planes, then
we’d hope to see them
traveling across the horn beam in a few minutes.
During the day we do see the events clustered in time. The software change
just implemented is to
allow writing more than one event a second.
These flashes only have a footprint on the ground of a few 100-meters, so each
would provide a unique contribution to the total count, and energy spectrum, of
in the Milky Way galaxy. Ideally the science aficionados would enjoy mapping
milky way with their horns, tracking spacecraft and then when done for the day,
the telescopes count cosmic ray events.
>>>> We’d like to use the Analog Devices PlutoSdr internal computer to sample
>>>> at a higher data rate (50 MHz or so), but
>>>> only detect rare transients at a rate of once or twice a minute.
>>> That's not likely to be fruitful. The PlutoSDR internal ARM CPU is in no
>>> way "up to the task", and the FPGA is rather full, but if it's
>>> at all possible, the FPGA is the place to do it.
>> Well, I’m certainly not yet up to being able to write the code, although I
>> learned a good bit from
>> “unixpunk”. They’ve put a pretty powerful version of the PlutoSdr firmware
>> on the web.
>> ( see https://github.com/unixpunk/PlutoWeb )
> I'm going to guess that their "leansdr" framework is NOT sufficiently more
> efficient than Gnu Radio that you'll be able to achieve
> 50Msps with it on the PlutoSDR. The built-in ARM processors just don't
> have the grunt even to move samples between the FPGA
> and the CPU, let alone try to *do* things with those samples. But I'm
> willing to be proved wrong, as always…
I was assuming that if the PlutoSdr system was designed to operate at 50 MHz
samples, there might be
some capacity for getting a block of data off the device at that rate.
An assumed event capture design would include a biggish circular buffer, say
The code would compute a rough RMS continually, and just wait to flag and
freeze the buffer for big events,
greater than say 6-sigma. Processing would stop until the buffer was written
out to the host
computer. Processing would then resume again on the PlutoSdr. Since events
are expected only
every few minutes or hours, only a small fraction of samples would be lost
during the stoppage
for data transfer.
That is how the C++ code we put on GitHub works inside gnuradio.
This is my hope, reality is always more challenging.