Hi John, If there's already a C++ or Python driver (or one that can be easily wrapped/called by one of those languages) then the additional code (an Out Of Tree module) to expose the device into GRC is usually very straightforward. I've done a few hardware devices now from DC power supplies up to more complicated pieces of equipment. The GNU Radio tutorials cover how to do this. https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python#3.2._Where_Do_Blocks_Come_From.3F
It looks as if IAI's website is down, and I don't see much in the way of signs of life from the company in the last two years. Looking at the RFNest's documentation from Google's cache they don't mention any user facing API code, but have documented all the control packets. Perhaps you have access to more information than is publicly available. https://webcache.googleusercontent.com/search?q=cache:gNq-u32akcEJ:https://www.i-a-i.com/wp-content/uploads/2017/07/RFnest_API_v2.pdf+&cd=1&hl=en&ct=clnk&gl=uk&client=ubuntu GNU Radio does have some channel model blocks already included in it's core and it would be excellent to see more developed. I think it's pretty safe for me to say that we'd welcome enhancements to existing blocks and new functionality into the core codebase. https://www.gnuradio.org/doc/doxygen/group__channel__models__blk.html Regards, Derek On 08/01/2020 13:22, John Wood via GNU Radio, the Free & Open-Source Toolkit for Software Radio wrote: > On 1/8/20 7:14 AM, Müller, Marcus (CEL) wrote: >> Dear John, >> >> you mean an external device that can interact with GNU Radio's sample >> streams? >> >> Well, I'd say it's not very hard per se – all you need is to write a >> driver for that device. That driver needs to have an interface that you >> can use to transmit samples from your PC to the device, or get samples >> from that device into your PC. >> Then, you'd call that from within a GNU Radio block. It's pretty much >> exactly what the USRP sink and source, or the audio sink and source do. >> >> The question of "how hard is it" is, however, tends to be dominated by >> boundary conditions: How fast do you need things to be? How experienced >> are you at building devices, and how experienced at writing drivers? Or >> do driver and device already exist, and you only need to write that GNU >> Radio block? Then it's mostly a question of programming proficiency. >> >> Best regards, >> Marcus >> > Marcus, > > Thanks much for the quick reply. I guess I was thinking mostly about > GRC control of an external device but as you point out that would > require both a representation in GRC as well as a driver. I have one > candidate in mind, the RFnest RF channel emulator. It comes with its > own GUI ("RFView") but as a GRC block might be valuable in that it > could be used with USRPs or other GRC-defined block radios within the > GRC environment in performing link-quality assessments (oexpected > perating range/propagation loss, Doppler shift, multipath etc). VTY, > > > John Wood >