[Top][All Lists]

[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)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]