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

[Marcus D Leech]

So reading about askaryan effect, detection seems unlikely, since pulse lengths 
are sub nanosecond. 

The electron precipitation mechanism seems more likely but doesn’t produce 
coherent radiation., but would be concentrated at lower VHF frequencies, AFAIK. 

Sent from my iPhone

> On Apr 9, 2019, at 4:38 PM, Glen I Langston <address@hidden> wrote:
> 
> 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
>