[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Idea for gr-osmosdr
From: |
Ethan Trewhitt |
Subject: |
Re: [Discuss-gnuradio] Idea for gr-osmosdr |
Date: |
Mon, 14 Oct 2013 17:40:47 -0400 |
Marcus,
What about the "selector" and "valve" blocks in GRC? You could build
your single top_block in GRC then instantiate and call it within an
external Python script that switches the selector/valves based on the
radio choice you want to make. Then you have a top_block that is still
maintainable within GRC but still have the advantage of manual
scripting elements on the external script. Basically just copy the
main() method in the GRC-generated file into your own script.
Ethan
On Mon, Oct 14, 2013 at 3:32 PM, Marcus D. Leech <address@hidden> wrote:
> In developing simple_ra, I've run up against the issue that GRC doesn't
> really allow run-time reconfiguration of flow-graphs, but I have an emerging
> need to support slightly-different hardware configurations, involving
> either one or two input devices.
>
> This is both for interferometer support, and differential radiometer
> support. Now, I *could* laboriously maintain several different flow-graphs,
> and carefully maintain "operational consistency" between them, but I'd
> vastly prefer to support it all in a single flow-graph, with the ability
> to configure "features" at run time.
>
> I think I can get most of the way there with existing functionality in GRC,
> but I'd like the ability to ask for a "fake" device (perhaps producing
> zeros, or gaussian noise). That way, for single-device configurations,
> the 2nd channel can just be noise or zeros, which I just use a bit
> of flow-graph "algebra" to "do the right thing" with.
>
> The gr-osmosdr source already provides a gaussian-noise stream when you
> misconfigure devices, but it's fixed at 1Msps. It would be useful
> if this functionality could be made more "formal", and allow the effective
> sample rate to match the sample-rate of the "hardware participant"
> in a pair.
>
> This isn't really the "right" way to go about this, but the "right" way
> requires a fair amount of roto-routering of GRC, or that I write my code
> in Python, and avoid GRC. I'd rather not do that.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio