Help : Using another Hardware in gnuradio

Hi everyone ,
I think this is true that gnuradio is a general purpose signal
processing framework , not only for USRP. Now i have a question
regarding
this , suppose i have a hardware in which
the hardware drivers are given in .vi [ labview ] or matlab compatible
format . At this situation what i can i do, is I can make a share
library
.so format of my hardware interaction block and embed it
to my gnuradio core as like the usrp block.
So, what i want to ask is that , is the idea which i am thinking is
alright
or that ll not be possible. If not possible how can we solve such kind
of
situation.
Thanks in advance and any illogical question if mistaken from my side ,
I
highly apologize for that.

Thanks.

On Sat, Apr 16, 2011 at 1:27 AM, ton ph [email protected]
wrote:

situation.
Thanks in advance and any illogical question if mistaken from my side , I
highly apologize for that.

Thanks.

I’m not sure I fully understand what you’re saying, possibly just due to
lack of details. But in general, yes, if you can make a library hardware
driver with an API to set the proper parameters and to get and send
samples,
then you can work with it in GNU Radio. You would probably want to write
something like a “gr-<your_hw>” block that wraps your device driver
library
in a way that works with GNU Radio, much like how we have gr-usrp,
gr-usrp2,
and gr-uhd right now.

Tom

Thanks tom …
As the question sounds to be a bit ambigous , what i was trying to
figure
out was that , I have a hardware drivers written in labview programming
ie.
.vi format, now as per the usrp it uses .rbf files to talk to the usrp
hardware . But now as i want a new hardware to be used there would not
be
any .rbf
files but instead the hardware driver written in the .vi form . So what
i
was trying to figure out was that , is that possible to make a block in
gnuradio where i will replace the usrp block with my abcd block , and if
so
how can i do this .

thanks for the immediate reply and highly apologize for the ambiguity.
Thanks

As the question sounds to be a bit ambigous , what i was trying to figure
out was that , I have a hardware drivers written in labview programming ie.
.vi format, now as per the usrp it uses .rbf files to talk to the usrp
hardware . But now as i want a new hardware to be used there would not be
any .rbf

The rbf file is an FPGA configuration file for the altera FPGA in the
USRP1. My understanding is that a VI is a program that runs in the
labview runtime environment. Not related.

files but instead the hardware driver written in the .vi form . So what i
was trying to figure out was that , is that possible to make a block in
gnuradio where i will replace the usrp block with my abcd block , and if so
how can i do this .

100% possible

Any arbitrary hardware can work with gnuradio. You need to write a class
in C++ that inherits from a gr_sync_block and talks to your device. Are
you willing and able to do that?

– another option –

Some people use a named pipe to share streaming data between a gnuradio
file source/sink and another software environment that produces/consumes
the samples.

-Josh

On Sun, Apr 17, 2011 at 1:00 PM, Josh B. [email protected] wrote:

USRP1. My understanding is that a VI is a program that runs in the
labview runtime environment. Not related.

Thanks josh regarding the VI programming , yes it does run on labview
,
so what i can do with
this part of my problem is that , i can think of generating a .so
library
which does the work of interacting
/talking to my device and by importing this files in my gnuradio block i
could think of integrating with my
gnuradio custom block.
Hope u understand my point , and i highly apologise if my thinking is
wrong.

Any arbitrary hardware can work with gnuradio. You need to write a class
in C++ that inherits from a gr_sync_block and talks to your device. Are
you willing and able to do that?

– another option –

Some people use a named pipe to share streaming data between a gnuradio
file source/sink and another software environment that produces/consumes
the samples.

thanks for your guidance .