>
> 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.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment