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

[Glen I Langston]

Hi Marcus,


> 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.

Agreed.

> 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 
(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.

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 
telescope array
would provide a unique contribution to the total count, and energy spectrum, of 
cosmic rays
in the Milky Way galaxy.  Ideally the science aficionados would enjoy mapping 
the 
milky way with their horns, tracking spacecraft and then when done for the day, 
let
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 
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.

Glen