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 <glen.i.langston@gmail.com> wrote:
>
> Hi Marcus,
>
>
>>> On Apr 9, 2019, at 4:10 PM, Marcus D. Leech <patchvonbraun@gmail.com> 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
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment