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

On 04/09/2019 03:00 PM, Glen I Langston wrote:

Hi Marcus,

Thanks for your comments.   Looks like you've been making very good progress at your observatory.

On Apr 9, 2019, at 1:50 PM, Marcus D. Leech <patchvonbraun@gmail.com> wrote:
\

...

The radio astronomy graphs have been used with Airspy, Airspy-mini, the various RTLSDR dongles, PlutoSdr and LimeSdr
hardware.

So, one of the problems with "singleton" events is that they aren't unambiguously "the thing that you're looking for".  Glitches from
  RFI are very common, for example.  If you had events like this from two independent antennae+receiver chains, they might be
  "meaningful", for certain values of "independent".  

Yes, single events certainly are suspect, if not in some way confirmed. We did a longer term test, March 5-9, 2019,

and did see a pattern in the event rate with a single horn.   Plot below shows most events are found during the

day, and maybe are due to airplanes, spacecraft or Sun.   We see a dramatic drop in rates at night.

Concerning immediate confirmation, we also have had two horns observing simultaneously and do see

rough coincidence between the events in the two horns.  The data are not completely conclusive

and I'm preparing to make some software changes to get better time tagging of events.

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.

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.

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

We'd like to update the Pluto firmware to perform this task, while simultaneously allowing Gnuradio to
run on the host pc/single board.  

The code is already complete, but not ported to the PlutoSdr.  Anyone interested in collaborating
on this project?

Thanks again for your suggestions,

Best regards,

Glen