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 ;)]
I also started a similar attempt about a year ago, but never finished
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
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
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.
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
./usrp_rx_cfile.py -R A -d 8 -f 100.0e6 -g 60 -N 8000000 -s capture1
would result in:
Where capture1.xml would contain something like:
8000000 <--dangerous to put in there when you
trunk the capture file afterwards using dd.