On Wed, Feb 23, 2011 at 1:00 AM, Johnathan Corgan
<address@hidden> wrote:
On Tue, Feb 22, 2011 at 15:36, Marcus D. Leech
<address@hidden> 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