Forum: GNU Radio USRP emulation ??

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
1465dec64294fe2d825ade08ca1ee1b2?d=identicon&s=25 davek (Guest)
on 2009-05-15 09:53
(Received via mailing list)
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
3d1bbca20dabfeca5cce1687c1e70660?d=identicon&s=25 Jens Elsner (Guest)
on 2009-05-15 10:05
(Received via mailing list)
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
A183460a6345f698900d4394de8212ce?d=identicon&s=25 Jason Uher (Guest)
on 2009-05-15 15:17
(Received via mailing list)
> 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
3719f4fea703e38bcbf8de6fe6bcdf55?d=identicon&s=25 Martin DvH (Guest)
on 2009-05-15 18:20
(Received via mailing list)
On Fri, 2009-05-15 at 08:16 -0500, Jason Uher 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:

<xml>
 <source>
  <name>capture1</name>
  <nchannels>1</nchannels>
  <nsamples>8000000</nsamples>   <--dangerous to put in there when you
trunk the capture file afterwards using dd.
  <channel>
   <channelnumber>0</channelnumber>
   <hardware>
    <type>usrp</type>
    <revision>4.5</revision>
    <daughterboard>
     <type>TVRX</type>
     <revision>2.0</revision>
     <side>A</side>
    </daughterboard>
   </hardware>
   <settings>
    <rf-freq>100.0e6</rf-freq>
    <rf-gain>60.0</rf_gain>
    <decimation>8</decimation>
   </settings>
   <format>
    <type>complex</type>
    <numberformat>signed_int</numberformat>
    <precision>16</precision>
    <padding>0</padding>
    <nbitspersample>32</nbitspersample>
   </format>
  </channel>
 </source>
</xml>

Martin
This topic is locked and can not be replied to.