GNU Radio, One Step at a Time: January 2010

Sunday, January 31, 2010

Re: [Discuss-gnuradio] How to implement 64QAM?

Any response?

alanluo wrote:
>
> Hi, everyone:
>
> recently I have a project which need to use higher modulation scheme, such
> as 16QAM or 64 QAM. I noticed that in python/gnuradio/blksimpl, there is
> no demodualtion part for higher modulation schemes. Does that mean we need
> to finish it by ourself?
> And i also noticed that from the maillist attached as below, Tom seems
> working on the modualtion models. Did he finish this work, and post at
> some place i just did not find ?
>
> I really appreciate any help from you guys. Since I am very new to the
> python language and dont have confidence to programme the model in such
> short time.
>
> ====
> RE: constellation mapping
>
> by trondeau Mar 06, 2007; 05:44am :: Rate this Message: - Use ratings
> to moderate (?)
>
> Reply | Reply to Author | Print | View Threaded | Show Only this Message
>> -----Original Message-----
>> From: discuss-gnuradio-bounces+trondeau=vt.edu@... [mailto:discuss-
>>
>> On Sun, Mar 04, 2007 at 06:20:07PM -0500, njm25@... wrote:
>>
>> > I want to do constellation mapping in pyhton. I have code that does
>> > a gr.packed_to_unpacked_bb and then gr.chunks_to_symbols_bc using a
>> > constellation of:
>> >
>> > constellation=array((1+1j,1-1j,-1-1j,-1+1j),Complex)
>>
>> Use this:
>>
>> constellation=(1+1j,1-1j,-1-1j,-1+1j)
>>
>> > My understanding is that this is the constellation mapping for QPSK.
>> > I want to do constellation mapping for BPSK and 64-QAM. I don't
>> > have a lot of GNU radio experience so I'm not really sure how to do
>> > this. Is all I do is change the array (all the possibilities from
>> > 4+4j to -4-4j for 64-QAM and 1+0j to -1+0j for BPSK) and the code
>> > will do the rest to map the data for the other modulation schemes?
>>
>> Have you looked at the mpsk code that's in the tree? Most of this
>> stuff is already in place. I believe that Tom Rondeau is working on
>> QAM too.
> ... [show rest of quote]
>
> Yep, you can already look in python/gnuradio/blksimpl for DBPSK and DQPSK.
> I'm finishing up the tests on the new stuff now and hopefully will get
> those
> checked in to the trunk by the end of today.
>
> This will include D8PSK and a number of square QAM modulations up to
> M=256.
> These are currently disabled until the receivers are finished, but the
> code
> will be there to see how I'm doing it. The modulators have been verified
> using our signal analyzer.
>
> Tom
> ====
>
>
> Best wishes,
>
> Alan
>

--
View this message in context: http://old.nabble.com/How-to-implement-64QAM--tp27396489p27400007.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP2 MIMO setup problem

Hi all,
I am trying to create a two transmitter setup with two USRP2s connected with the MIMO cable. I use the trunk version of GNURadio (Friday, Jan 29,2010) on laptops running Ubuntu 9.04.

From previous emails and looking at the code, the relevant code for two transmitter setup seems to be the test_mimo_tx file in usrp2/host/apps. I update the firmware of the master USRP2 with mimo_tx.bin as pointed out in http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ.

sudo ./u2_flash_tool --dev=/dev/sdb -t s/w apps/mimo_tx.bin -w

and for the slave USRP2, I use

sudo ./u2_flash_tool --dev=/dev/sdb -t s/w apps/mimo_tx_slave.bin -w

When I invoke the transmission program at the sender laptop using

sudo ./test_mimo_tx -f 2.412G -I a.dat -i 100 -r

I observe the following message:

usrp2::ctor reset_db failed.

The USRP2 freezes after this and the host cannot find it using find_usrps. The archives of the mailing list suggest updating the firmware to solve this issue. But I want to use the MIMO firmware and not the usual txrx.bin.

1. Is there firmware for the MIMO master and slave, which does not have this problem?

2. What modifications need to be incorporated to the current MIMO files to fix this problem?
If there is not a solution already, I am thinking of modifying the existing MIMO USRP2 related files. Any pointers on what are to be taken care of, will be very useful.

Thanks,
Sri

RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2

Hi Manav

I haven’t really fixed it, but rather get a different error. To do this, I updated to the latest copy of firmware and fpga images as Josh had suggested.

I am yet to try the debug port and see if it is failing to lock. Hopefully I can try this today.

Ian.

From: Manav Seth [mailto:smartymanav@gmail.com]
Sent: Friday, 29 January 2010 6:11 PM
To: Ian Holland
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2

Hey Ian,

How did the problem get fixed? I mean what frequency you are setting with the "-f" option?

Regards,

Manav

On Thu, Jan 28, 2010 at 10:17 PM, Ian Holland <Ian.Holland@rlmgroup.com.au> wrote:

Thanks Josh

This partially fixed the problem, in the sense that samples are now
displayed on the fft window when running usrp2_fft.py, and it no longer
says "channel 0 not receiving". However, it still fails to set the
frequency of the receiver. Also, when I run usrp_siggen.py, I still get
the same problem that the Tx frequency can't be set. In verbose mode,
the output of usrp_siggen.py is as below. Any ideas on what else could
be wrong?

Regards

Ian.

USRP interpolation rate: 16
USRP IF bandwidth: 6.25MHz
Set TX gain to: 15.0
Using auto-calculated mid-point frequency
Failed to set freq.
(...etc...)

>Your firmware and fpga images on the sd card are probably out of sync.
>You can find images here: http://gnuradio.org/releases/usrp2-bin/trunk/

>and here are instructions on how to burn:
>http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ

>-Josh

On 01/28/2010 06:14 PM, Ian Holland wrote:
> Hi Matt
>
> I have tried usrp2_fft.py -f 2.4G and also usrp2_fft.py -f 5.7G as you
> suggest below. In both cases, the fft window opens but no trace is
> displayed, and I see the following output in the terminal:
>
> usrp2: channel 0 not receiving
> usrp2::rx_sample() failed
>
> I only recently received my USRP2s and XCVR2450s, which were shipped
at
> the end of December. Are there any known issues with the firmware on
the
> SD cards at this time, or do you have any other idea why I can't seem
to
> tune frequencies on these cards?
>
> Thanks
>
> Ian.
>
> -----Original Message-----
> From: Matt Ettus [mailto:matt@ettus.com]
> Sent: Friday, 29 January 2010 12:35 PM
> To: Manav Seth
> Cc: Ian Holland; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450
on
> USRP2
>
>
>
> The -f argument to usrp2_fft.py is the frequency. By putting "-f
1000"
> you are telling the system to try to tune the xcvr2450 to 1 kHz. The
> specified range is 2.4-2.5 GHz and 4.9 to 5.9 GHz. 1 kHz is WAY
outside
>
> of that range. I would suggest you try something like:
>
> usrp2_fft.py -f 5.7G
>
> Matt
>
> On 01/28/2010 05:35 PM, Manav Seth wrote:
>> Actually no...its always returning false...
>> when I use usrp2_fft.py with -f 1000 then output does come but still
> it
>> is unable to set the initial frequency though it did receive.
>>
>> I am still trying to figure out the problem...
>>
>> On Thu, Jan 28, 2010 at 3:43 PM, Ian Holland
>> <Ian.Holland@rlmgroup.com.au<mailto:Ian.Holland@rlmgroup.com.au>>
> wrote:
>>
>> On Wed, Jan 27, 2010 at 8:52 PM, Ian Holland
>>
<Ian.Holland@rlmgroup.com.au<mailto:Ian.Holland@rlmgroup.com.au>>
>> wrote:
>> Hi All
>>
>> I have been trying to set the Tx and Rx frequencies when using
an
>> XCVR2450 with a USRP2, but it seems these keep failing. A
snippet
> of my
>> source code is below for setting the Tx frequency.
>> The output of this portion of code is "Failed to tune Tx", and
the
>> frequencies are all 0, with spectrum_inverted being false.
>> I have also tried to use usrp2_fft.py, and this fails saying
> nothing is
>> received on channel 0.
>> Does anyone know what the problem could be?
>>
>> Thanks
>>
>> Ian.
>>
>> /* try tuning Tx to a test frequency */
>> double Fc = 2400000000.0;
>> usrp2::tune_result TxTuneResult;
>> bool successTx = device->set_tx_center_freq(Fc,
>> &TxTuneResult);
>> if(successTx) {
>> cout<< "Tx Tune
Successful:\n";
>> cout<< " Baseband Frequency: "<<
>> TxTuneResult.baseband_freq<< "\n";
>> cout<< " DxC Frequency: "<<
>> TxTuneResult.dxc_freq<< "\n";
>> cout<< " Residual Frequency: "<<
>> TxTuneResult.residual_freq<< "\n";
>> cout<< " Spectrum Inverted: "<<
>> (TxTuneResult.spectrum_inverted ? "true" : "false")<< "\n";
>> }
>> else {
>> cout<< "Failed to tune Tx.\n";
>> cout<< " Baseband Frequency: "<<
>> TxTuneResult.baseband_freq<< "\n";
>> cout<< " DxC Frequency: "<<
>> TxTuneResult.dxc_freq<< "\n";
>> cout<< " Residual Frequency: "<<
>> TxTuneResult.residual_freq<< "\n";
>> cout<< " Spectrum Inverted: "<<
>> (TxTuneResult.spectrum_inverted ? "true" : "false")<< "\n";
>> }
>> cout<< "\n";
>>
>> _______________________________________________
>>
>> >From: Manav Seth [mailto:smartymanav@gmail.com
>> <mailto:smartymanav@gmail.com>]
>> >Sent: Thursday, 28 January 2010 3:29 PM
>> >To: Ian Holland
>> >Cc: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
>> >Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with
> XCVR2450
>> on>USRP2
>>
>> >Ya, its failing for me too...set_tx_center_freq is always
> failing
>> (though I>am writing my code in python)..
>> >not able to find the cause...
>>
>> Have you been able to get any of the pre-written scripts (e.g.
>> usrp2_fft.py or usrp_siggen.py) working? I can't even get those
to
> work.
>> I tried usrp_siggen.py in verbose this morning and noticed again
> it was
>> unable to set the Tx frequency. Also, I think the error I had
> mentioned
>> above re usrp2_fft.py would be because the rx frequency couldn't
> be set.
>>
>> I have tried two of the daughtercards on one USRP2, and one of
> those two
>> cards on the other USRP2, and still can't get it to set, though
it
>> worked fine using the same code for the BasicTx and BasicRx.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to implement 64QAM?

Hi, everyone:

recently I have a project which need to use higher modulation scheme, such
as 16QAM or 64 QAM. I noticed that in python/gnuradio/blksimpl, there is no
demodualtion part for higher modulation schemes. Is that means we need to
finish it by ourself?
And i also noticed that from the maillist attached as below, Tom seems
working on the modualtion models. Did he finish this work, and post at some
place i just did not find ?

I really appreciate any help from you guys. Since I am very new to the
python language and dont have confidence to programme the model in such
short time.

====
RE: constellation mapping

by trondeau Mar 06, 2007; 05:44am :: Rate this Message: - Use ratings to
moderate (?)

Reply | Reply to Author | Print | View Threaded | Show Only this Message
> -----Original Message-----
> From: discuss-gnuradio-bounces+trondeau=vt.edu@... [mailto:discuss-
>
> On Sun, Mar 04, 2007 at 06:20:07PM -0500, njm25@... wrote:
>
> > I want to do constellation mapping in pyhton. I have code that does
> > a gr.packed_to_unpacked_bb and then gr.chunks_to_symbols_bc using a
> > constellation of:
> >
> > constellation=array((1+1j,1-1j,-1-1j,-1+1j),Complex)
>
> Use this:
>
> constellation=(1+1j,1-1j,-1-1j,-1+1j)
>
> > My understanding is that this is the constellation mapping for QPSK.
> > I want to do constellation mapping for BPSK and 64-QAM. I don't
> > have a lot of GNU radio experience so I'm not really sure how to do
> > this. Is all I do is change the array (all the possibilities from
> > 4+4j to -4-4j for 64-QAM and 1+0j to -1+0j for BPSK) and the code
> > will do the rest to map the data for the other modulation schemes?
>
> Have you looked at the mpsk code that's in the tree? Most of this
> stuff is already in place. I believe that Tom Rondeau is working on
> QAM too.
... [show rest of quote]

Yep, you can already look in python/gnuradio/blksimpl for DBPSK and DQPSK.
I'm finishing up the tests on the new stuff now and hopefully will get those
checked in to the trunk by the end of today.

This will include D8PSK and a number of square QAM modulations up to M=256.
These are currently disabled until the receivers are finished, but the code
will be there to see how I'm doing it. The modulators have been verified
using our signal analyzer.

Tom
====

Best wishes,

Alan
--
View this message in context: http://old.nabble.com/How-to-implement-64QAM--tp27396489p27396489.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER in bert- example

On Sun, Jan 31, 2010 at 06:52, Brian Padalino <bpadalino@gmail.com> wrote:

>> But from my tests I see that
>> 1 bit error in -> 7 bit errors out
>> 2 consecutive bit errors in -> 2 errors in the output
>> 3 consecutive bit errors in -> 7 errors in the output
>> 4 consecutive bit errors in -> 4 errors in the output
>> ...
>> And so forth up to 7 (Length of the lfsr)
>>
>> The reason I ask is that if I want to change the scrambler and/or the
>> modulation, I assume that this "magic number" will change as well.
>
> If you want a good BER measurement, I wouldn't use the method that you
> describe here.

You are correct. The scrambler introduces three output errors per
input error for single channel errors that are farther apart than the
length of the shift register. This is the case once the shift
register has already achieved self-synchronization and at low channel
error rates. For the purposes of the simple BERT example, this was
sufficient. (The number 3 comes from the number of taps in the
scrambler polynomial.)

Johnathan

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER in bert- example

On Sun, Jan 31, 2010 at 7:36 AM, Mattias Kjellsson <mkje@kth.se> wrote:
> Hi list,
>
> There is a function called 'ber' in receive_path.py in the python bert
> example.
>
> def ber(self):
> return (1.0-self._ber.density())/3.0
>
> From where does the 3 originate? Some lines above, there is this comment:
> # Descramble BERT sequence. A channel error will create 3 incorrect bits
> self._descrambler = gr.descrambler_bb(0x8A, 0x7F, 7) # CCSDS 7-bit
> descrambler
>
> But from my tests I see that
> 1 bit error in -> 7 bit errors out
> 2 consecutive bit errors in -> 2 errors in the output
> 3 consecutive bit errors in -> 7 errors in the output
> 4 consecutive bit errors in -> 4 errors in the output
> ...
> And so forth up to 7 (Length of the lfsr)
>
> The reason I ask is that if I want to change the scrambler and/or the
> modulation, I assume that this "magic number" will change as well.

If you want a good BER measurement, I wouldn't use the method that you
describe here.

Since, as you've noted, the errors propagate through the shift
register and generate more errors than the number of errors at the
input, it seems more like an error generator than an error counter.

Though, on a side note, it is strange you are getting 7 bits in error
when you only have 1 bit in error going in. This really should be
limited to 3 as the comment suggests.

The benefit to this approach is self-synchronization, but you lose out
on an accurate bit error measurement.

Without knowing more about the type of system you are going to be
testing, I can't comment on how I'd change the measurement or
evaluation of the bits produced by your modem. Sorry.

Hope this was helpful - though I somewhat doubt it.

Brian

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Soft-DVB has a Brother. A Receiving Brother. And Fast...

SR-DVB demo video on youtube

http://www.youtube.com/watch?v=S5nGBDCxhmk

regards

vincenzo

[Discuss-gnuradio] BER in bert- example

Hi list,

There is a function called 'ber' in receive_path.py in the python bert
example.

def ber(self):
return (1.0-self._ber.density())/3.0

From where does the 3 originate? Some lines above, there is this comment:
# Descramble BERT sequence. A channel error will create 3 incorrect bits
self._descrambler = gr.descrambler_bb(0x8A, 0x7F, 7) # CCSDS 7-bit
descrambler

But from my tests I see that
1 bit error in -> 7 bit errors out
2 consecutive bit errors in -> 2 errors in the output
3 consecutive bit errors in -> 7 errors in the output
4 consecutive bit errors in -> 4 errors in the output
...
And so forth up to 7 (Length of the lfsr)

The reason I ask is that if I want to change the scrambler and/or the
modulation, I assume that this "magic number" will change as well.

BR
//Mattias

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Questions about synchronization and modulation in benchmark

Hi Adib

Thanks for the reply.

I check it in the net and download it. I don't know about costas loop and clock recovery in detail. may I know how they they estimate frequency offset, and recover it?
as far as I know, they are using gr.quadrature_demod_cf(1) & and subtract it using gr.single_pole_iif_filter_ff(alpha) for frequency offset?is it right?

Tim

On Sun, Jan 31, 2010 at 4:03 PM, adib_sairi <adib_sairi@yahoo.com> wrote:

there is some work from Thomas Schmid which modulate and demodulate O-QPSK
which mean for IEEE802.15.4 standard.. you can search and download the code
online. good luck..

Adib

Timothy Lawrence Sitorus wrote:
>
> HI all,
>
> Please anyone help me.
>
> Is there anyone succeeded to modulate qpsk, even frequency offset occurs?
>
>
> Best Regards,
> Tim
>

> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context: http://old.nabble.com/Questions-about-synchronization-and-modulation-in-benchmark-tp27371719p27390702.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Saturday, January 30, 2010

Re: [Discuss-gnuradio] Questions about synchronization and modulation in benchmark

there is some work from Thomas Schmid which modulate and demodulate O-QPSK
which mean for IEEE802.15.4 standard.. you can search and download the code
online. good luck..

Adib

Timothy Lawrence Sitorus wrote:
>
> HI all,
>
> Please anyone help me.
>
> Is there anyone succeeded to modulate qpsk, even frequency offset occurs?
>
>
> Best Regards,
> Tim
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context: http://old.nabble.com/Questions-about-synchronization-and-modulation-in-benchmark-tp27371719p27390702.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: Questions about synchronization and modulation in benchmark

HI all,

Please anyone help me.

Is there anyone succeeded to modulate qpsk, even frequency offset occurs?

Best Regards,
Tim

Friday, January 29, 2010

Re: [Discuss-gnuradio] ImportError: no module named howto

On Fri, Jan 29, 2010 at 04:21:58PM +0000, patrick mekeze wrote:
> I am a new developper and i have a school project on gnu-radio library
>
> My goal is to make and reverse-engineering on Gnu-Radio library due to aim of meta modeling and code generation.
> First i have downloaded the last version of gnuradio and retrived it on my computer.
> i have succefull built and executed some of gnuradio example from package (gnuradio/gnuradio-example/python/audio) and now i have deceded to write my block.
> but before do it, i first try to execute the giving example qa_howto.py from the package gr-howto-write-a-block/src/python and i got this example:
>
> Traceback (most recent call test):
> File "qa_howto.py", line 24, in <module>
> import howto
> ImportError: no module named howto
>
> could someone what i will do to solve this problem?
> thank for your help

The only way to run qa_howto.py is by running "make check" from the
top directory of gr-howto-write-a-block. It sets up a bunch of
environment variables required to run the QA code without it being
installed.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PS3 - gcell_fft

On Fri, Jan 29, 2010 at 03:31:27PM +0100, Thilo Mönicke wrote:
> Hi,
>
> I tryed to set the fft lenght to 16384... but the gcell fft only
> accepts values to 4096. Its defined in the C-Files, but why?
>
> Do you have any working benchmarks for the ps3?
>
> regards,
> Thilo

Sorry Thilo, I steered you in the wrong direction.

The best gcell related FFT code is on CGRAN:

Project description:

https://www.cgran.org/wiki/GcellizedFFTW

Best code:

svn co https://www.cgran.org/cgran/projects/fftw-gcell/branches/developers/eb/fftw-wip

This code will compute FFT's up to at least 16K points, perhaps 64K (I
don't remember). It's implemented as a modified version of FFTW that
knows about gcell.

To test it, just build and install. By default, let fftw create the
gcell job manager (FFTW will link in the right FFTW spe code. See
fftw-wip/cell/gcell.cc for details.) It's also possible to link this
code into your own SPE executable.

With the modified FFTW library, use the regular gr.fft_vcc block, not
the gcell.fft_vcc block.

Eric

> 2010/1/27 Eric Blossom <eb@comsec.com>:
> > On Wed, Jan 27, 2010 at 11:36:14AM +0100, Thilo Mönicke wrote:
> >> Hi,
> >>
> >> I tried to set up a little Testprogram for the PS3 which should show
> >> the advantage of the Power PC structure. For that, the program should
> >> calculate 10000 FFTs and take the time. Unfortunately this program is
> >> much slower as a same program running at a GPP. With the tool spu-top
> >> I verified that all SPUs are working...
> >>
> >> Do you have any idea how I could speed up my program?
> >
> > Currently, the break even point is higher than 1024 points due to
> > the overhead to get to the SPEs and back.
> >
> > Try 16384 points :-)
> >
> > Eric
> >
> >
> >> Here is my Python-code (only the intresting part...):
> >>
> >> class BenchmarkFFT(gr.top_block):
> >> def __init__(self):
> >>
> >> ph = gcell.program_handle_from_filename("/home/moenicke/gnuradio-3.2.2/gcell/lib/spu/gcell_all")
> >> opts = gcell.jm_options(ph,0)
> >> self.mgr = gcell.job_manager(opts)
> >> gcell.set_singleton(self.mgr)
> >>
> >> gr.top_block.__init__(self)
> >>
> >> fft_len=1024
> >> n_ffts=10000
> >>
> >> src = gr.noise_source_c(gr.GR_GAUSSIAN, 1.0)
> >> head = gr.head(gr.sizeof_gr_complex, fft_len * n_ffts)
> >> s2v = gr.stream_to_vector(gr.sizeof_gr_complex, fft_len)
> >> fft= gcell.fft_vcc(fft_len, True, [])
> >> sink = gr.null_sink(gr.sizeof_gr_complex * fft_len)
> >>
> >> self.connect (src, head, s2v, fft, sink)
> >>
> >> reguards
> >>
> >> Thilo
> >>
> >> @Eric: thank you for your last answer, it was a big help for me ...
> >
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Soft-DVB has a Brother. A Receiving Brother. And Fast...

Yes Dave,

it is absolutely safe.

Actually going from DVB-T to DVB-S (version 1), roughly speaking, only requires removing some OFDM-related blocks, which means it makes the system computationally lighter.. :)

Hi Alexander,

Yes, I absolutely want to share MA-related knowledge with the software radio community, especially with gnuradio community.

At the present moment, papers describing MA technology are undergoing academic review process.

Paper accepted in Karlsruhe (WS10) features a brief section about MA and presentation there will do as well.

If I could just decide, I would provide links to all these contents right now on the list, but I'm not sure I'm allowed to without consequences for my publications.

I will check what I actually can do and possibly prepare some descriptive content for MA that I will post to this list. Can you provide advice on these publication copyright issues?

For sure I will give updates regarding increases of computational efficiency that will be achieved by SR-DVB while applying MA to other sections of the receive chain (currently only Viterbi and OFDM synch have been implemented through MA).

Thanks for your interest.

I will do my best to be clear and detailed ASAP

my best regards

vincenzo

2010/1/29 Alexander Chemeris <alexander.chemeris@gmail.com>

Hi Vincenzo,

That's interesting.
Can you point to some description or this "MAgic" technology? From your
description I'm not sure I understand even on what level it works and what
it actually does :)

On Fri, Jan 29, 2010 at 12:04, Vincenzo Pellegrini <wwvince@gmail.com> wrote:
> Hi GNURadio fellows,
> considering that this list has grown to something highly relevant in
> Software Defined Radio I thought it would have been a good idea to share
> here a few thoughts I've been having since long and as well as a result that
> was just achieved.
>
>
> Since a few months after my first approach to SDR in 2006,
> I thought I picked up two major facts about the technology:
> .:. SDR infinite potential lying for sure in its flexibility but, even more
> relevantly, in its ability to bypass
> the costly HW-level design stage which is embedded in any traditional
> radio design/production process
> .:. Its equally infinite power-inefficiency compared to traditional,
> HW-implemented competitor technologies.
> In fact, ease of development as well as flexibility appear to be
> inversely proportional to power efficiency.
> The latter being in my opinion the reason for which SDR has been growing for
> ages up to now but has never "exploded" as we could expect from a technology
> cutting away a conspicuous part of the design costs of any radio system.
> Actually, flexibility and cost-efficiency, though considerable, do not
> appear to be sufficient motivation for accepting to upscale power
> requirements (at a given computational cost yielded by the implemented
> wireless standard) by a factor which typically is in [100 ; 300].
> Whether right or wrong, by working with these thoughts in mind, during the
> research I'm carrying on at the University of Pisa, Italy while doing my PhD
> here, I developed a novel implementation technique targeted at
> software-implemented Signal Processing over General Purpose CPUs or DSPs
> which we (at DSPCoLa lab, http://dspcola.iet.unipi.it ) call "MA".
> Current research results have shown that MA was able to increase by slightly
> more than one order of magnitude the power efficiency of a traditionally
> implemented (MA-free) SDR.
>
> By applying such "MA" technology to the ETSI DVB-T receiver chain with the
> help of:
> Mario Di Dio (former master thesis student, now PhD Student at DSPCoLa)
> Luca ROSE (former master thesis student at DSPCoLa, now PhD student at
> Supélec Paris)
> we obtained the receiving companion of Soft-DVB: SR-DVB.
> Standing for Software Receiver - DVB,
> SR-DVB is a fully software (all signal processing is done in pure C++ over
> the host computer) ETSI DVB-T receiver capable of running realtime
> while providing 11.612 Mbps throughput
> and absorbing less than 50% of computational resources available over an
> Intel Q9400, 2.66 GHz CPU.
> As long as MA was applied only to the two computationally-heaviest blocks of
> the receive chain (i.e. Viterbi Decoding and OFDM synch), we believe that
> considerable margins for improvement of the presented result do exist. They
> will be explored in the next months.
>
> SR-DVB will be presented in Karlsruhe at WSR 10
> as the article:
> "A Fully Software ETSI DVB-T Receiver Based on the USRP"
> during such presentation also MA technology will be briefly outlined.
> A demo video of our proof-of-concept receiver is available at
> www.legalepellegrini.it/ing/SR-DVB_demo_long.VRO
> as usual, mplayer or VLC wil play this camcorder mpeg2 viedo easily.
>
> Best regards to all writers and readers of the list
> vincenzo
>
>
>
>
> --
> Vincenzo Pellegrini
> http://www.youtube.com/user/wwvince1

> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--

Regards,
Alexander Chemeris.

--
Vincenzo Pellegrini
http://www.youtube.com/user/wwvince1

Re: [Discuss-gnuradio] Soft-DVB has a Brother. A Receiving Brother. And Fast...

Hi Vincenzo,

That's interesting.
Can you point to some description or this "MAgic" technology? From your
description I'm not sure I understand even on what level it works and what
it actually does :)

On Fri, Jan 29, 2010 at 12:04, Vincenzo Pellegrini <wwvince@gmail.com> wrote:
> Hi GNURadio fellows,
> considering that this list has grown to something highly relevant in
> Software Defined Radio I thought it would have been a good idea to share
> here a few thoughts I've been having since long and as well as a result that
> was just achieved.
>
>
> Since a few months after my first approach to SDR in 2006,
> I thought I picked up two major facts about the technology:
> .:. SDR infinite potential lying for sure in its flexibility but, even more
> relevantly, in its ability to bypass
> the costly HW-level design stage which is embedded in any traditional
> radio design/production process
> .:. Its equally infinite power-inefficiency compared to traditional,
> HW-implemented competitor technologies.
> In fact, ease of development as well as flexibility appear to be
> inversely proportional to power efficiency.
> The latter being in my opinion the reason for which SDR has been growing for
> ages up to now but has never "exploded" as we could expect from a technology
> cutting away a conspicuous part of the design costs of any radio system.
> Actually, flexibility and cost-efficiency, though considerable, do not
> appear to be sufficient motivation for accepting to upscale power
> requirements (at a given computational cost yielded by the implemented
> wireless standard) by a factor which typically is in [100 ; 300].
> Whether right or wrong, by working with these thoughts in mind, during the
> research I'm carrying on at the University of Pisa, Italy while doing my PhD
> here, I developed a novel implementation technique targeted at
> software-implemented Signal Processing over General Purpose CPUs or DSPs
> which we (at DSPCoLa lab, http://dspcola.iet.unipi.it ) call "MA".
> Current research results have shown that MA was able to increase by slightly
> more than one order of magnitude the power efficiency of a traditionally
> implemented (MA-free) SDR.
>
> By applying such "MA" technology to the ETSI DVB-T receiver chain with the
> help of:
> Mario Di Dio (former master thesis student, now PhD Student at DSPCoLa)
> Luca ROSE (former master thesis student at DSPCoLa, now PhD student at
> Supélec Paris)
> we obtained the receiving companion of Soft-DVB: SR-DVB.
> Standing for Software Receiver - DVB,
> SR-DVB is a fully software (all signal processing is done in pure C++ over
> the host computer) ETSI DVB-T receiver capable of running realtime
> while providing 11.612 Mbps throughput
> and absorbing less than 50% of computational resources available over an
> Intel Q9400, 2.66 GHz CPU.
> As long as MA was applied only to the two computationally-heaviest blocks of
> the receive chain (i.e. Viterbi Decoding and OFDM synch), we believe that
> considerable margins for improvement of the presented result do exist. They
> will be explored in the next months.
>
> SR-DVB will be presented in Karlsruhe at WSR 10
> as the article:
> "A Fully Software ETSI DVB-T Receiver Based on the USRP"
> during such presentation also MA technology will be briefly outlined.
> A demo video of our proof-of-concept receiver is available at
> www.legalepellegrini.it/ing/SR-DVB_demo_long.VRO
> as usual, mplayer or VLC wil play this camcorder mpeg2 viedo easily.
>
> Best regards to all writers and readers of the list
> vincenzo
>
>
>
>
> --
> Vincenzo Pellegrini
> http://www.youtube.com/user/wwvince1
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
Regards,
Alexander Chemeris.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: Questions about synchronization and modulation in benchmark

Please help me anyone

Tim

On Fri, Jan 29, 2010 at 10:06 PM, Timothy Lawrence Sitorus <timothy.l.sitorus@gmail.com> wrote:

Hello All,

I have problems in demodulating code from benchmark qpsk. please help me with answering my question.

1. Why there are no bpsk, qpsk or 8psk in the modulation option ?there are only dbpsk , dqpsk, d8psk.
2. Is there any different synchronization besides gr_mpsk_receiver_cc?
3.I don't know about costas loop in detail, but in my knowledge, this module using modified Muller for the algorithms and I see that this method is just using 1 sample per symbol in recovering symbol timing with mu as a base for correction? am i right? if yes, may i know why they use just 1 sample per symbol?
3. Is this costas loop just for differential modulation ? I have a problem in decoding the qpsk if frequency offset occurs.
* In the transmitter side , I just took of the diff dec . and in the receiver side, I made diff_phasor as a delay detector and recovered it into qpsk based on preamble.
(it works while i am using bencharmark loopback without frequency offset and time error)

4. if no 3 is yes, please help me in solving this problem. I have no idea.

Best Regards,

Tim

--

Best Regards,

******************************
Timothy Lawrence Sitorus
Komaba Campus Blding, 5th Floor,
Research Center for Advanced Science and Technology,
The University of Tokyo.
4-6-1, Komaba, Meguro-ku, Tokyo 153-8904, Japan.
Tel: +81-3-5452-5368
Fax: +81-3-5452-5369
Mail:tsitora@mlab.t.u-tokyo.ac.jp
Mobile phone: 090-1860-2859
********************************

Re: [Discuss-gnuradio] Fwd: article: "No-knob" radio: the future of Warfighter communications?

On Thu, Jan 28, 2010 at 12:47, Ken N9VV <n9vv@wowway.com> wrote:

> Congratulations to the GNU developers !!

Thanks.

This URL has the (same) story on the Army lab's website, which also
allows comments:

http://armytechnology.armylive.dodlive.mil/index.php/2010/01/27/no-knob-radio-future-warfighter-communications/

Johnathan

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ImportError: no module named howto

Hi Patrick,

You don't say what os or even platform you are using but it sounds like you didn't do a "sudo make install" on the howto stuff.

Or if you did, possibly you installed on ubuntu and the binaries went to /usr/lib but your howto install went to /usr/local/lib.

unfortunately you don't really give enough information to answer your question, I don't think. :-)

-Tom

On Fri, Jan 29, 2010 at 11:21 AM, patrick mekeze <pmekeze@yahoo.fr> wrote:

I am a new developper and i have a school project on gnu-radio library

My goal is to make and reverse-engineering on Gnu-Radio library due to aim of meta modeling and code generation.

First i have downloaded the last version of gnuradio and retrived it on my computer.

i have succefull built and executed some of gnuradio example from package (gnuradio/gnuradio-example/python/audio) and now i have deceded to write my block.

but before do it, i first try to execute the giving example qa_howto.py from the package gr-howto-write-a-block/src/python and i got this example:

Traceback (most recent call test):

File "qa_howto.py", line 24, in <module>

import howto

ImportError: no module named howto

could someone what i will do to solve this problem?

thank for your help

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ImportError: no module named howto

I am a new developper and i have a school project on gnu-radio library

My goal is to make and reverse-engineering on Gnu-Radio library due to aim of meta modeling and code generation.

First i have downloaded the last version of gnuradio and retrived it on my computer.

i have succefull built and executed some of gnuradio example from package (gnuradio/gnuradio-example/python/audio) and now i have deceded to write my block.

but before do it, i first try to execute the giving example qa_howto.py from the package gr-howto-write-a-block/src/python and i got this example:

Traceback (most recent call test):

File "qa_howto.py", line 24, in <module>

import howto

ImportError: no module named howto

could someone what i will do to solve this problem?

thank for your help

Re: [Discuss-gnuradio] PS3 - gcell_fft

Hi,

I tryed to set the fft lenght to 16384... but the gcell fft only
accepts values to 4096. Its defined in the C-Files, but why?

Do you have any working benchmarks for the ps3?

regards,

Thilo

2010/1/27 Eric Blossom <eb@comsec.com>:
> On Wed, Jan 27, 2010 at 11:36:14AM +0100, Thilo Mönicke wrote:
>> Hi,
>>
>> I tried to set up a little Testprogram for the PS3 which should show
>> the advantage of the Power PC structure. For that, the program should
>> calculate 10000 FFTs and take the time. Unfortunately this program is
>> much slower as a same program running at a GPP. With the tool spu-top
>> I verified that all SPUs are working...
>>
>> Do you have any idea how I could speed up my program?
>
> Currently, the break even point is higher than 1024 points due to
> the overhead to get to the SPEs and back.
>
> Try 16384 points :-)
>
> Eric
>
>
>> Here is my Python-code (only the intresting part...):
>>
>> class BenchmarkFFT(gr.top_block):
>> def __init__(self):
>>
>> ph = gcell.program_handle_from_filename("/home/moenicke/gnuradio-3.2.2/gcell/lib/spu/gcell_all")
>> opts = gcell.jm_options(ph,0)
>> self.mgr = gcell.job_manager(opts)
>> gcell.set_singleton(self.mgr)
>>
>> gr.top_block.__init__(self)
>>
>> fft_len=1024
>> n_ffts=10000
>>
>> src = gr.noise_source_c(gr.GR_GAUSSIAN, 1.0)
>> head = gr.head(gr.sizeof_gr_complex, fft_len * n_ffts)
>> s2v = gr.stream_to_vector(gr.sizeof_gr_complex, fft_len)
>> fft= gcell.fft_vcc(fft_len, True, [])
>> sink = gr.null_sink(gr.sizeof_gr_complex * fft_len)
>>
>> self.connect (src, head, s2v, fft, sink)
>>
>> reguards
>>
>> Thilo
>>
>> @Eric: thank you for your last answer, it was a big help for me ...
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Questions about synchronization and modulation in benchmark

Hello All,

I have problems in demodulating code from benchmark qpsk. please help me with answering my question.

1. Why there are no bpsk, qpsk or 8psk in the modulation option ?there are only dbpsk , dqpsk, d8psk.
2. Is there any different synchronization besides gr_mpsk_receiver_cc?
3.I don't know about costas loop in detail, but in my knowledge, this module using modified Muller for the algorithms and I see that this method is just using 1 sample per symbol in recovering symbol timing with mu as a base for correction? am i right? if yes, may i know why they use just 1 sample per symbol?
3. Is this costas loop just for differential modulation ? I have a problem in decoding the qpsk if frequency offset occurs.
* In the transmitter side , I just took of the diff dec . and in the receiver side, I made diff_phasor as a delay detector and recovered it into qpsk based on preamble.
(it works while i am using bencharmark loopback without frequency offset and time error)

4. if no 3 is yes, please help me in solving this problem. I have no idea.

Best Regards,

Tim

Re: [Discuss-gnuradio] Soft-DVB has a Brother. A Receiving Brother. And Fast...

Wow this is exciting! Folks we are on the verge of a paradime shift in RF communications.

I'm not clear on the dvb standards, but is it safe to assume dvb-s would need just a few tweaks on the dvb-t code or no?

Sent from my iPhone

On Jan 29, 2010, at 4:04 AM, Vincenzo Pellegrini <wwvince@gmail.com> wrote:

Hi GNURadio fellows,
considering that this list has grown to something highly relevant in Software Defined Radio I thought it would have been a good idea to share here a few thoughts I've been having since long and as well as a result that was just achieved.

Since a few months after my first approach to SDR in 2006,
I thought I picked up two major facts about the technology:

.:. SDR infinite potential lying for sure in its flexibility but, even more relevantly, in its ability to bypass

the costly HW-level design stage which is embedded in any traditional radio design/production process

.:. Its equally infinite power-inefficiency compared to traditional, HW-implemented competitor technologies.

In fact, ease of development as well as flexibility appear to be inversely proportional to power efficiency.

The latter being in my opinion the reason for which SDR has been growing for ages up to now but has never "exploded" as we could expect from a technology cutting away a conspicuous part of the design costs of any radio system.

Actually, flexibility and cost-efficiency, though considerable, do not appear to be sufficient motivation for accepting to upscale power requirements (at a given computational cost yielded by the implemented wireless standard) by a factor which typically is in [100 ; 300].

Whether right or wrong, by working with these thoughts in mind, during the research I'm carrying on at the University of Pisa, Italy while doing my PhD here, I developed a novel implementation technique targeted at software-implemented Signal Processing over General Purpose CPUs or DSPs which we (at DSPCoLa lab, http://dspcola.iet.unipi.it ) call "MA".

Current research results have shown that MA was able to increase by slightly more than one order of magnitude the power efficiency of a traditionally implemented (MA-free) SDR.

By applying such "MA" technology to the ETSI DVB-T receiver chain with the help of:

Mario Di Dio (former master thesis student, now PhD Student at DSPCoLa)
Luca ROSE (former master thesis student at DSPCoLa, now PhD student at Supélec Paris)

we obtained the receiving companion of Soft-DVB: SR-DVB.

Standing for Software Receiver - DVB,
SR-DVB is a fully software (all signal processing is done in pure C++ over the host computer) ETSI DVB-T receiver capable of running realtime

while providing 11.612 Mbps throughput

and absorbing less than 50% of computational resources available over an Intel Q9400, 2.66 GHz CPU.

As long as MA was applied only to the two computationally-heaviest blocks of the receive chain (i.e. Viterbi Decoding and OFDM synch), we believe that considerable margins for improvement of the presented result do exist. They will be explored in the next months.

SR-DVB will be presented in Karlsruhe at WSR 10
as the article:
"A Fully Software ETSI DVB-T Receiver Based on the USRP"

during such presentation also MA technology will be briefly outlined.

A demo video of our proof-of-concept receiver is available at

www.legalepellegrini.it/ing/SR-DVB_demo_long.VRO

as usual, mplayer or VLC wil play this camcorder mpeg2 viedo easily.

Best regards to all writers and readers of the list

vincenzo

--
Vincenzo Pellegrini

http://www.youtube.com/user/wwvince1

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP I and USB Hubs

Hi,

for practical reasons (read: out of laziness), I was wondering if the
USRP works just as well over a USB hub as without, and if there are hubs
known to work better than others?
According to the archives, I've seen recommendations not to use one, but
no real trouble. Are there any experiences?

Thanks,
Martin
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

[Discuss-gnuradio] Soft-DVB has a Brother. A Receiving Brother. And Fast...

Hi GNURadio fellows,

considering that this list has grown to something highly relevant in Software Defined Radio I thought it would have been a good idea to share here a few thoughts I've been having since long and as well as a result that was just achieved.

Since a few months after my first approach to SDR in 2006,

I thought I picked up two major facts about the technology:

.:. SDR infinite potential lying for sure in its flexibility but, even more relevantly, in its ability to bypass

the costly HW-level design stage which is embedded in any traditional radio design/production process

.:. Its equally infinite power-inefficiency compared to traditional, HW-implemented competitor technologies.

In fact, ease of development as well as flexibility appear to be inversely proportional to power efficiency.

The latter being in my opinion the reason for which SDR has been growing for ages up to now but has never "exploded" as we could expect from a technology cutting away a conspicuous part of the design costs of any radio system.

Actually, flexibility and cost-efficiency, though considerable, do not appear to be sufficient motivation for accepting to upscale power requirements (at a given computational cost yielded by the implemented wireless standard) by a factor which typically is in [100 ; 300].

Whether right or wrong, by working with these thoughts in mind, during the research I'm carrying on at the University of Pisa, Italy while doing my PhD here, I developed a novel implementation technique targeted at software-implemented Signal Processing over General Purpose CPUs or DSPs which we (at DSPCoLa lab, http://dspcola.iet.unipi.it ) call "MA".

Current research results have shown that MA was able to increase by slightly more than one order of magnitude the power efficiency of a traditionally implemented (MA-free) SDR.

By applying such "MA" technology to the ETSI DVB-T receiver chain with the help of:

Mario Di Dio (former master thesis student, now PhD Student at DSPCoLa)

Luca ROSE (former master thesis student at DSPCoLa, now PhD student at Supélec Paris)

we obtained the receiving companion of Soft-DVB: SR-DVB.

Standing for Software Receiver - DVB,

SR-DVB is a fully software (all signal processing is done in pure C++ over the host computer) ETSI DVB-T receiver capable of running realtime

while providing 11.612 Mbps throughput

and absorbing less than 50% of computational resources available over an Intel Q9400, 2.66 GHz CPU.

As long as MA was applied only to the two computationally-heaviest blocks of the receive chain (i.e. Viterbi Decoding and OFDM synch), we believe that considerable margins for improvement of the presented result do exist. They will be explored in the next months.

SR-DVB will be presented in Karlsruhe at WSR 10

as the article:

"A Fully Software ETSI DVB-T Receiver Based on the USRP"

during such presentation also MA technology will be briefly outlined.

A demo video of our proof-of-concept receiver is available at

www.legalepellegrini.it/ing/SR-DVB_demo_long.VRO

as usual, mplayer or VLC wil play this camcorder mpeg2 viedo easily.

Best regards to all writers and readers of the list

vincenzo

Vincenzo Pellegrini

http://www.youtube.com/user/wwvince1

Thursday, January 28, 2010

Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2

Hey Ian,

How did the problem get fixed? I mean what frequency you are setting with the "-f" option?

Regards,

Manav

On Thu, Jan 28, 2010 at 10:17 PM, Ian Holland <Ian.Holland@rlmgroup.com.au> wrote:

Thanks Josh

This partially fixed the problem, in the sense that samples are now
displayed on the fft window when running usrp2_fft.py, and it no longer
says "channel 0 not receiving". However, it still fails to set the
frequency of the receiver. Also, when I run usrp_siggen.py, I still get
the same problem that the Tx frequency can't be set. In verbose mode,
the output of usrp_siggen.py is as below. Any ideas on what else could
be wrong?

Regards

Ian.

USRP interpolation rate: 16
USRP IF bandwidth: 6.25MHz
Set TX gain to: 15.0
Using auto-calculated mid-point frequency
Failed to set freq.
(...etc...)

>Your firmware and fpga images on the sd card are probably out of sync.
>You can find images here: http://gnuradio.org/releases/usrp2-bin/trunk/

>and here are instructions on how to burn:
>http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ

>-Josh

On 01/28/2010 06:14 PM, Ian Holland wrote:
> Hi Matt
>
> I have tried usrp2_fft.py -f 2.4G and also usrp2_fft.py -f 5.7G as you
> suggest below. In both cases, the fft window opens but no trace is
> displayed, and I see the following output in the terminal:
>
> usrp2: channel 0 not receiving
> usrp2::rx_sample() failed
>
> I only recently received my USRP2s and XCVR2450s, which were shipped
at
> the end of December. Are there any known issues with the firmware on
the
> SD cards at this time, or do you have any other idea why I can't seem
to
> tune frequencies on these cards?
>
> Thanks
>
> Ian.
>
> -----Original Message-----
> From: Matt Ettus [mailto:matt@ettus.com]
> Sent: Friday, 29 January 2010 12:35 PM
> To: Manav Seth
> Cc: Ian Holland; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450
on
> USRP2
>
>
>
> The -f argument to usrp2_fft.py is the frequency. By putting "-f
1000"
> you are telling the system to try to tune the xcvr2450 to 1 kHz. The
> specified range is 2.4-2.5 GHz and 4.9 to 5.9 GHz. 1 kHz is WAY
outside
>
> of that range. I would suggest you try something like:
>
> usrp2_fft.py -f 5.7G
>
> Matt
>
> On 01/28/2010 05:35 PM, Manav Seth wrote:
>> Actually no...its always returning false...
>> when I use usrp2_fft.py with -f 1000 then output does come but still
> it
>> is unable to set the initial frequency though it did receive.
>>
>> I am still trying to figure out the problem...
>>
>> On Thu, Jan 28, 2010 at 3:43 PM, Ian Holland
>> <Ian.Holland@rlmgroup.com.au<mailto:Ian.Holland@rlmgroup.com.au>>
> wrote:
>>
>> On Wed, Jan 27, 2010 at 8:52 PM, Ian Holland
>>
<Ian.Holland@rlmgroup.com.au<mailto:Ian.Holland@rlmgroup.com.au>>
>> wrote:
>> Hi All
>>
>> I have been trying to set the Tx and Rx frequencies when using
an
>> XCVR2450 with a USRP2, but it seems these keep failing. A
snippet
> of my
>> source code is below for setting the Tx frequency.
>> The output of this portion of code is "Failed to tune Tx", and
the
>> frequencies are all 0, with spectrum_inverted being false.
>> I have also tried to use usrp2_fft.py, and this fails saying
> nothing is
>> received on channel 0.
>> Does anyone know what the problem could be?
>>
>> Thanks
>>
>> Ian.
>>
>> /* try tuning Tx to a test frequency */
>> double Fc = 2400000000.0;
>> usrp2::tune_result TxTuneResult;
>> bool successTx = device->set_tx_center_freq(Fc,
>> &TxTuneResult);
>> if(successTx) {
>> cout<< "Tx Tune
Successful:\n";
>> cout<< " Baseband Frequency: "<<
>> TxTuneResult.baseband_freq<< "\n";
>> cout<< " DxC Frequency: "<<
>> TxTuneResult.dxc_freq<< "\n";
>> cout<< " Residual Frequency: "<<
>> TxTuneResult.residual_freq<< "\n";
>> cout<< " Spectrum Inverted: "<<
>> (TxTuneResult.spectrum_inverted ? "true" : "false")<< "\n";
>> }
>> else {
>> cout<< "Failed to tune Tx.\n";
>> cout<< " Baseband Frequency: "<<
>> TxTuneResult.baseband_freq<< "\n";
>> cout<< " DxC Frequency: "<<
>> TxTuneResult.dxc_freq<< "\n";
>> cout<< " Residual Frequency: "<<
>> TxTuneResult.residual_freq<< "\n";
>> cout<< " Spectrum Inverted: "<<
>> (TxTuneResult.spectrum_inverted ? "true" : "false")<< "\n";
>> }
>> cout<< "\n";
>>
>> _______________________________________________
>>
>> >From: Manav Seth [mailto:smartymanav@gmail.com
>> <mailto:smartymanav@gmail.com>]
>> >Sent: Thursday, 28 January 2010 3:29 PM
>> >To: Ian Holland
>> >Cc: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
>> >Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with
> XCVR2450
>> on>USRP2
>>
>> >Ya, its failing for me too...set_tx_center_freq is always
> failing
>> (though I>am writing my code in python)..
>> >not able to find the cause...
>>
>> Have you been able to get any of the pre-written scripts (e.g.
>> usrp2_fft.py or usrp_siggen.py) working? I can't even get those
to
> work.
>> I tried usrp_siggen.py in verbose this morning and noticed again
> it was
>> unable to set the Tx frequency. Also, I think the error I had
> mentioned
>> above re usrp2_fft.py would be because the rx frequency couldn't
> be set.
>>
>> I have tried two of the daughtercards on one USRP2, and one of
> those two
>> cards on the other USRP2, and still can't get it to set, though
it
>> worked fine using the same code for the BasicTx and BasicRx.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2

It could be failing to lock. You may want to watch the debug port on the
usrp2. If the lock detect is failing, it will print out on the serial
console. attach a 3.3v level serial port

On 01/28/2010 10:09 PM, Ian Holland wrote:
> Hi Josh
>
>> The xcvr has a high band and a low band, which means there is a gap in
>> the tunable frequency range for the xcvr. Therefore, the
>> "auto-calculated mid-point frequency" is an invalid frequency for the
>> xcvr. Pick a frequency in the high band or low band range:
>
>> #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9)
>> #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9)
>> #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9)
>> #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9)
>
> Thanks - I will keep that in mind when using usrp_siggen.py in future.
>
> However, I have tried 2.4G with the source code from my original post
> (relevant code snippet for Tx tuning just below this paragraph, for
> which successTx is 0 and all frequency properties in TxTuneResult are
> 0), and also with usrp2_fft.py -f 2.4G, after burning the latest images.
> I still face the same problem that neither the Tx nor the Rx will tune.
>
> /* try tuning Tx to a test frequency */
> double Fc = 2400000000.0;
> usrp2::tune_result TxTuneResult;
> bool successTx = device->set_tx_center_freq(Fc,&TxTuneResult);

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2

Hi Josh

>The xcvr has a high band and a low band, which means there is a gap in
>the tunable frequency range for the xcvr. Therefore, the
>"auto-calculated mid-point frequency" is an invalid frequency for the
>xcvr. Pick a frequency in the high band or low band range:

>#define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9)
>#define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9)
>#define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9)
>#define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9)

Thanks - I will keep that in mind when using usrp_siggen.py in future.

However, I have tried 2.4G with the source code from my original post
(relevant code snippet for Tx tuning just below this paragraph, for
which successTx is 0 and all frequency properties in TxTuneResult are
0), and also with usrp2_fft.py -f 2.4G, after burning the latest images.
I still face the same problem that neither the Tx nor the Rx will tune.

/* try tuning Tx to a test frequency */
double Fc = 2400000000.0;
usrp2::tune_result TxTuneResult;
bool successTx = device->set_tx_center_freq(Fc,&TxTuneResult);

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2

On 01/28/2010 09:17 PM, Ian Holland wrote:
> Thanks Josh
>
> This partially fixed the problem, in the sense that samples are now
> displayed on the fft window when running usrp2_fft.py, and it no longer
> says "channel 0 not receiving". However, it still fails to set the
> frequency of the receiver. Also, when I run usrp_siggen.py, I still get
> the same problem that the Tx frequency can't be set. In verbose mode,
> the output of usrp_siggen.py is as below. Any ideas on what else could
> be wrong?
>
> Regards
>
> Ian.
>
> USRP interpolation rate: 16
> USRP IF bandwidth: 6.25MHz
> Set TX gain to: 15.0
> Using auto-calculated mid-point frequency

The xcvr has a high band and a low band, which means there is a gap in
the tunable frequency range for the xcvr. Therefore, the
"auto-calculated mid-point frequency" is an invalid frequency for the
xcvr. Pick a frequency in the high band or low band range:

#define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9)
#define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9)
#define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9)
#define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9)

> Failed to set freq.
> (...etc...)
>
>
>
>> Your firmware and fpga images on the sd card are probably out of sync.
>> You can find images here: http://gnuradio.org/releases/usrp2-bin/trunk/
>
>> and here are instructions on how to burn:
>> http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ
>
>> -Josh
>
> On 01/28/2010 06:14 PM, Ian Holland wrote:
>> Hi Matt
>>
>> I have tried usrp2_fft.py -f 2.4G and also usrp2_fft.py -f 5.7G as you
>> suggest below. In both cases, the fft window opens but no trace is
>> displayed, and I see the following output in the terminal:
>>
>> usrp2: channel 0 not receiving
>> usrp2::rx_sample() failed
>>
>> I only recently received my USRP2s and XCVR2450s, which were shipped
> at
>> the end of December. Are there any known issues with the firmware on
> the
>> SD cards at this time, or do you have any other idea why I can't seem
> to
>> tune frequencies on these cards?
>>
>> Thanks
>>
>> Ian.
>>
>> -----Original Message-----
>> From: Matt Ettus [mailto:matt@ettus.com]
>> Sent: Friday, 29 January 2010 12:35 PM
>> To: Manav Seth
>> Cc: Ian Holland; discuss-gnuradio@gnu.org
>> Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450
> on
>> USRP2
>>
>>
>>
>> The -f argument to usrp2_fft.py is the frequency. By putting "-f
> 1000"
>> you are telling the system to try to tune the xcvr2450 to 1 kHz. The
>> specified range is 2.4-2.5 GHz and 4.9 to 5.9 GHz. 1 kHz is WAY
> outside
>>
>> of that range. I would suggest you try something like:
>>
>> usrp2_fft.py -f 5.7G
>>
>> Matt
>>
>> On 01/28/2010 05:35 PM, Manav Seth wrote:
>>> Actually no...its always returning false...
>>> when I use usrp2_fft.py with -f 1000 then output does come but still
>> it
>>> is unable to set the initial frequency though it did receive.
>>>
>>> I am still trying to figure out the problem...
>>>
>>> On Thu, Jan 28, 2010 at 3:43 PM, Ian Holland
>>> <Ian.Holland@rlmgroup.com.au<mailto:Ian.Holland@rlmgroup.com.au>>
>> wrote:
>>>
>>> On Wed, Jan 27, 2010 at 8:52 PM, Ian Holland
>>>
> <Ian.Holland@rlmgroup.com.au<mailto:Ian.Holland@rlmgroup.com.au>>
>>> wrote:
>>> Hi All
>>>
>>> I have been trying to set the Tx and Rx frequencies when using
> an
>>> XCVR2450 with a USRP2, but it seems these keep failing. A
> snippet
>> of my
>>> source code is below for setting the Tx frequency.
>>> The output of this portion of code is "Failed to tune Tx", and
> the
>>> frequencies are all 0, with spectrum_inverted being false.
>>> I have also tried to use usrp2_fft.py, and this fails saying
>> nothing is
>>> received on channel 0.
>>> Does anyone know what the problem could be?
>>>
>>> Thanks
>>>
>>> Ian.
>>>
>>> /* try tuning Tx to a test frequency */
>>> double Fc = 2400000000.0;
>>> usrp2::tune_result TxTuneResult;
>>> bool successTx = device->set_tx_center_freq(Fc,
>>> &TxTuneResult);
>>> if(successTx) {
>>> cout<< "Tx Tune
> Successful:\n";
>>> cout<< " Baseband Frequency:"<<
>>> TxTuneResult.baseband_freq<< "\n";
>>> cout<< " DxC Frequency:"<<
>>> TxTuneResult.dxc_freq<< "\n";
>>> cout<< " Residual Frequency:"<<
>>> TxTuneResult.residual_freq<< "\n";
>>> cout<< " Spectrum Inverted:"<<
>>> (TxTuneResult.spectrum_inverted ? "true" : "false")<< "\n";
>>> }
>>> else {
>>> cout<< "Failed to tune Tx.\n";
>>> cout<< " Baseband Frequency:"<<
>>> TxTuneResult.baseband_freq<< "\n";
>>> cout<< " DxC Frequency:"<<
>>> TxTuneResult.dxc_freq<< "\n";
>>> cout<< " Residual Frequency:"<<
>>> TxTuneResult.residual_freq<< "\n";
>>> cout<< " Spectrum Inverted:"<<
>>> (TxTuneResult.spectrum_inverted ? "true" : "false")<< "\n";
>>> }
>>> cout<< "\n";
>>>
>>> _______________________________________________
>>>
>>> >From: Manav Seth [mailto:smartymanav@gmail.com
>>> <mailto:smartymanav@gmail.com>]
>>> >Sent: Thursday, 28 January 2010 3:29 PM
>>> >To: Ian Holland
>>> >Cc: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
>>> >Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with
>> XCVR2450
>>> on>USRP2
>>>
>>> >Ya, its failing for me too...set_tx_center_freq is always
>> failing
>>> (though I>am writing my code in python)..
>>> >not able to find the cause...
>>>
>>> Have you been able to get any of the pre-written scripts (e.g.
>>> usrp2_fft.py or usrp_siggen.py) working? I can't even get those
> to
>> work.
>>> I tried usrp_siggen.py in verbose this morning and noticed again
>> it was
>>> unable to set the Tx frequency. Also, I think the error I had
>> mentioned
>>> above re usrp2_fft.py would be because the rx frequency couldn't
>> be set.
>>>
>>> I have tried two of the daughtercards on one USRP2, and one of
>> those two
>>> cards on the other USRP2, and still can't get it to set, though
> it
>>> worked fine using the same code for the BasicTx and BasicRx.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2

Thanks Josh

This partially fixed the problem, in the sense that samples are now
displayed on the fft window when running usrp2_fft.py, and it no longer
says "channel 0 not receiving". However, it still fails to set the
frequency of the receiver. Also, when I run usrp_siggen.py, I still get
the same problem that the Tx frequency can't be set. In verbose mode,
the output of usrp_siggen.py is as below. Any ideas on what else could
be wrong?

Regards

Ian.

USRP interpolation rate: 16
USRP IF bandwidth: 6.25MHz
Set TX gain to: 15.0
Using auto-calculated mid-point frequency
Failed to set freq.
(...etc...)

>Your firmware and fpga images on the sd card are probably out of sync.
>You can find images here: http://gnuradio.org/releases/usrp2-bin/trunk/

>and here are instructions on how to burn:
>http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ

>-Josh

On 01/28/2010 06:14 PM, Ian Holland wrote:
> Hi Matt
>
> I have tried usrp2_fft.py -f 2.4G and also usrp2_fft.py -f 5.7G as you
> suggest below. In both cases, the fft window opens but no trace is
> displayed, and I see the following output in the terminal:
>
> usrp2: channel 0 not receiving
> usrp2::rx_sample() failed
>
> I only recently received my USRP2s and XCVR2450s, which were shipped
at
> the end of December. Are there any known issues with the firmware on
the
> SD cards at this time, or do you have any other idea why I can't seem
to
> tune frequencies on these cards?
>
> Thanks
>
> Ian.
>
> -----Original Message-----
> From: Matt Ettus [mailto:matt@ettus.com]
> Sent: Friday, 29 January 2010 12:35 PM
> To: Manav Seth
> Cc: Ian Holland; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450
on
> USRP2
>
>
>
> The -f argument to usrp2_fft.py is the frequency. By putting "-f
1000"
> you are telling the system to try to tune the xcvr2450 to 1 kHz. The
> specified range is 2.4-2.5 GHz and 4.9 to 5.9 GHz. 1 kHz is WAY
outside
>
> of that range. I would suggest you try something like:
>
> usrp2_fft.py -f 5.7G
>
> Matt
>
> On 01/28/2010 05:35 PM, Manav Seth wrote:
>> Actually no...its always returning false...
>> when I use usrp2_fft.py with -f 1000 then output does come but still
> it
>> is unable to set the initial frequency though it did receive.
>>
>> I am still trying to figure out the problem...
>>
>> On Thu, Jan 28, 2010 at 3:43 PM, Ian Holland
>> <Ian.Holland@rlmgroup.com.au<mailto:Ian.Holland@rlmgroup.com.au>>
> wrote:
>>
>> On Wed, Jan 27, 2010 at 8:52 PM, Ian Holland
>>
<Ian.Holland@rlmgroup.com.au<mailto:Ian.Holland@rlmgroup.com.au>>
>> wrote:
>> Hi All
>>
>> I have been trying to set the Tx and Rx frequencies when using
an
>> XCVR2450 with a USRP2, but it seems these keep failing. A
snippet
> of my
>> source code is below for setting the Tx frequency.
>> The output of this portion of code is "Failed to tune Tx", and
the
>> frequencies are all 0, with spectrum_inverted being false.
>> I have also tried to use usrp2_fft.py, and this fails saying
> nothing is
>> received on channel 0.
>> Does anyone know what the problem could be?
>>
>> Thanks
>>
>> Ian.
>>
>> /* try tuning Tx to a test frequency */
>> double Fc = 2400000000.0;
>> usrp2::tune_result TxTuneResult;
>> bool successTx = device->set_tx_center_freq(Fc,
>> &TxTuneResult);
>> if(successTx) {
>> cout<< "Tx Tune
Successful:\n";
>> cout<< " Baseband Frequency: "<<
>> TxTuneResult.baseband_freq<< "\n";
>> cout<< " DxC Frequency: "<<
>> TxTuneResult.dxc_freq<< "\n";
>> cout<< " Residual Frequency: "<<
>> TxTuneResult.residual_freq<< "\n";
>> cout<< " Spectrum Inverted: "<<
>> (TxTuneResult.spectrum_inverted ? "true" : "false")<< "\n";
>> }
>> else {
>> cout<< "Failed to tune Tx.\n";
>> cout<< " Baseband Frequency: "<<
>> TxTuneResult.baseband_freq<< "\n";
>> cout<< " DxC Frequency: "<<
>> TxTuneResult.dxc_freq<< "\n";
>> cout<< " Residual Frequency: "<<
>> TxTuneResult.residual_freq<< "\n";
>> cout<< " Spectrum Inverted: "<<
>> (TxTuneResult.spectrum_inverted ? "true" : "false")<< "\n";
>> }
>> cout<< "\n";
>>
>> _______________________________________________
>>
>> >From: Manav Seth [mailto:smartymanav@gmail.com
>> <mailto:smartymanav@gmail.com>]
>> >Sent: Thursday, 28 January 2010 3:29 PM
>> >To: Ian Holland
>> >Cc: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
>> >Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with
> XCVR2450
>> on>USRP2
>>
>> >Ya, its failing for me too...set_tx_center_freq is always
> failing
>> (though I>am writing my code in python)..
>> >not able to find the cause...
>>
>> Have you been able to get any of the pre-written scripts (e.g.
>> usrp2_fft.py or usrp_siggen.py) working? I can't even get those
to
> work.
>> I tried usrp_siggen.py in verbose this morning and noticed again
> it was
>> unable to set the Tx frequency. Also, I think the error I had
> mentioned
>> above re usrp2_fft.py would be because the rx frequency couldn't
> be set.
>>
>> I have tried two of the daughtercards on one USRP2, and one of
> those two
>> cards on the other USRP2, and still can't get it to set, though
it
>> worked fine using the same code for the BasicTx and BasicRx.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio