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 <address@hidden>
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.
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
|