discuss-gnuradio
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]