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 <mle...@ripnet.com> 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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
