Idea for gr-osmosdr

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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs