USRP emulation?

GNU Radio
1

somethin i have in my head i want to throw out there…

how hard would it be ( or is it even possible? ) to create a device that
appears to gnuradio to be a functioning USRP but actually passes data to
and
from capture files. This would be nice when working on programs but away
from hardware, and for people that dont have a usrp to play with all the
example programs…
just a idea

dave

2

Hi Dave,

On Fri, May 15, 2009 at 03:51:33AM -0400, davek wrote:

somethin i have in my head i want to throw out there…

how hard would it be ( or is it even possible? ) to create a device that
appears to gnuradio to be a functioning USRP but actually passes data to and
from capture files. This would be nice when working on programs but away
from hardware, and for people that dont have a usrp to play with all the
example programs…
just a idea

In my opinion, this is a really good idea. We’re actually working on
this as part
of a bigger simulation project, which abstracts the USRP and the
wireless channel.
It not far along yet, but we’ll put it on CGRAN once there is something
to share.

Best regards,
Jens

3

In my opinion, this is a really good idea. We’re actually working on this as part
of a bigger simulation project, which abstracts the USRP and the wireless channel.
It not far along yet, but we’ll put it on CGRAN once there is something to share.

Can’t wait! I’ve been thinking about doing something like this, I’m
glad you’re making progress [AKA: so I don’t have to ;)]

Jason

4

On Fri, 2009-05-15 at 08:16 -0500, Jason U. wrote:

In my opinion, this is a really good idea. We’re actually working on this as part
of a bigger simulation project, which abstracts the USRP and the wireless channel.
It not far along yet, but we’ll put it on CGRAN once there is something to share.

Can’t wait! I’ve been thinking about doing something like this, I’m
glad you’re making progress [AKA: so I don’t have to ;)]

Jason

I also started a similar attempt about a year ago, but never finished
it.

In my opinion it would be great to have an abstraction layer for sample
sources and destinations.
That way it doesn’t matter if it is a USRP, USRP2, filesource, audiocard
or something else.

I am thinking of a source and destination block which (also) can parse
commandline parameters itsself (to choose the type and set generic and
specialized parameters)
It could also have its own optional GUI part for these parameters.

In the end you could then do something like.
./myscript.py --src usrp --src-rf-freq=80.0e6 --src-decimation=8
–src-gain 30 --src-rx-subdev-spec A

with the same script
./myscript --src file --src-filename test.raw --src-if-freq 200.0e3
–src-samplerate 8000000

I have also worked with other sources as USRPs and I always had to
rewrite all my scripts just because it was another sample-source.
(Although I tried to keep the interface similar)

Another thing I found myself struggling with is how to remember the
parameters used when capturing to file.
In the end I always encoded them in the filename but there should be an
easier way to do this.
examples:
wfm_f103.5M_g30_8msps_60sec_cshort.raw
gsm_f903.2M_g20_200ksps_60sec_cfloat.raw
tv_BBC1_PAL_10sec_f484.25e6_d32_g30_N20000000_cshort.raw

A header is probably not the way to go because I routinely trunk capture
files by using dd.
Maybe a separate xml file with the same filename but different extension
would work

./usrp_rx_cfile.py -R A -d 8 -f 100.0e6 -g 60 -N 8000000 -s capture1
would result in:
capture1.raw
capture1.xml

Where capture1.xml would contain something like:

capture1 1 8000000 <--dangerous to put in there when you trunk the capture file afterwards using dd. 0 usrp 4.5 TVRX 2.0 A 100.0e6 60.0 8 complex signed_int 16 0 32

Martin