# Idea for gr-osmosdr

**URL:** <https://www.ruby-forum.com/t/idea-for-gr-osmosdr/246470>\
**Category:** GNU Radio\
**Created:** [October 14, 2013, 9:33pm UTC](https://www.ruby-forum.com/t/idea-for-gr-osmosdr/246470 "2013-10-14T21:33:28Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\
**Post date:** [October 14, 2013, 9:33pm UTC](https://www.ruby-forum.com/t/idea-for-gr-osmosdr/246470/1 "2013-10-14T21:33:28Z")

</div>

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

> **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org/)**
>
> Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami.

---

<div class="post-metadata">

**Author:** ![Marcus\_DSLeech](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/74df32/32.png) [@Marcus\_DSLeech](https://www.ruby-forum.com/u/Marcus_DSLeech)\
**Post date:** [October 14, 2013, 11:42pm UTC](https://www.ruby-forum.com/t/idea-for-gr-osmosdr/246470/2 "2013-10-14T23:42:00Z")

</div>

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