Re: [Discuss-gnuradio] Event Detection and Spectral Line Radio Astronomy Working.

[Marcus D. Leech]

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.