[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Event Detection and Spectral Line Radio Astronomy
From: |
Marcus D. Leech |
Subject: |
Re: [Discuss-gnuradio] Event Detection and Spectral Line Radio Astronomy Working. |
Date: |
Tue, 09 Apr 2019 17:02:14 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 |
On 04/09/2019 04:38 PM, Glen I Langston wrote:
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
(TAUP 2015)
https://arxiv.org/abs/1704.07240).
The radio flashes come from cosmic rays hitting the Earths atmosphere, so are
not dispersed.
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.
Ah, yes. I rather suspected something like that. I'm not familiar with
the physics in detail, but something that precipitated
electrons into the upper atmosphere should produce something akin to
synchrotron emissions, which are necessarily
clustered around the lower frequencies.
The Askaryan effect mentioned in the article would appear to produce
effects noticeable at shorter wavelengths, so some fraction of your
events might be due to this. Interesting. Just when I thought my
"distraction stack" was deep enough...
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.
The AD9361 chip is happy to move samples at those rates. The rest of
the hardware (with the
exception of the FPGA)? Not so much.
An assumed event capture design would include a biggish circular buffer, say
100,000 samples.
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.
For 50Mhz bandwidth, you're very likely going to have to do an FPGA
implementation, and that implementation will have to be
"smart" unless you have 50Mhz of protected bandwidth--which you
almost certainly won't, except perhaps at Green Bank :)
For riometry, I've had to implement a hybrid RFI-excision scheme using
both FFT analysis, and time-domain median filtering. It can
still get overwhelmed, but does much better, on average, than an
olde-skool analog riometer.