On Wed, Feb 23, 2011 at 1:00 AM, Johnathan Corgan < [email protected]> wrote:
> On Tue, Feb 22, 2011 at 15:36, Marcus D. Leech <[email protected]> wrote: > >> On 02/22/2011 06:24 PM, Alexandru Csete wrote: >> >>> > >> Well, implementing it as UHD device seems a bit overkill from a >>> programming point of view because one would have to implement the "audio >>> source", which is readily available in GNU Radio. So a GNU Radio source just >>> like the old pre-UHD USRP drivers seems to be most feasible. >>> >> > If implemented as a C++ hierarchical block, then you can encapsulate an > audio source and the float to complex transformation blocks internally. > You'd hold an instance of the libfcd library and expose an external set of > accessors that resolve internally into the calls to the libfcd instance. > This is not that much coding, and makes something that works "just like" a > native GNU Radio block. It would be able to be used in pure C++ GNU Radio > apps, in Python GNU Radio apps, or instantiated and controlled entirely from > within a GRC flowgraph. > Yes, I agree with this. With the "overkill" I meant a pure UHD device that does not use existing GNU Radio blocks. Alex
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
