Tuesday, November 30, 2010

[Discuss-gnuradio] Tesla C2000 series and CUDA and Gnu Radio

Is anyone out there taking another look at CUDA + Gnu Radio?

Some of the couple-of-years-old charts I've looked at suggest that
speedups for some of the
most important transforms we use vary between modest and disappointing.

Cross-over points for things like FFTs are usually up in the atmospheric
levels of FFT sizes before
a CUDA-based transform would win even slightly against a
multi-threaded CPU-based FFTW, for
example. But that was a couple of years ago. Anything new along
those lines?

It seems like the kinds of things that do well on a GPU are ones that
take a small amount of input
data, compute ferociously, and produce modest amounts of output data.
Or schemes that might
consume deluges of input data, but produce output data only
occasionally--a flow that did
a bunch of FFTs and produced averaged mag-squared outputs only "once
in a while" might fare
well on a GPU.

On a related note, has anyone looked at enabling the multi-threaded FFTW
stuff? The cross-over
points there (between FFTW in a single-thread and FFTW in
multiple-threads) seem to be lower-down
on the FFT-size curve.

--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?

On 11/30/2010 07:04 PM, Vladutzzz wrote:
> I am interested in this 2 USRPs approach since I don't have the experience
> and the knowledge to start messing about inside the FPGA firmware code and
> have an extra USRP2.
> How would this go?
> I tried looking up some info about this topic. I've read some bits and
> pieces on a few forums. Most of the info is about having one USRP2 module as
> a transmitter and the other as a receiver.
> I want them both to be receivers(actually half a receiver) and to complete
> each other by receiving half of the 32 MHz band (so each would receive 16
> MHz).
> How would the USRPs be connected to the same computer? (MIMO cable?)
> How will the two 16 MHz bands be attached together to form the 32 MHz one
> (some kind of 2:1 multiplexing - I'm just guessing here)?
> I am aware of the great load exerted upon the system resources, but I'm
> trying to make this work anyway.
> Thanks.
>
> Vlad.
Assuming that you have a big-arsed machine to do this with, here goes:

Assumptions

o phase-coherence between the two isn't an issue (if you're just
doing power measurements, it won't be)
o you have a very-studly computer
o you have two good 1GiGe interfaces

Start out with two single-usrp sources, address them as appropriate for
your two USRP2s.

16MHz isn't an available bandwidth out of the USRP2, so use 16.66667MHz,
and band-limit it to exactly 16MHz with an FIR bandpass filter.
Your two USRP2s will each be tuned to a frequency that is 16MHz away
from each other.

Once you have your two band-limited complex signals, detect them, using
a complex-to-mag-squared on each of them.
Then put the two signals into an adder, and low-pass filter with a
single-pole IIR or FIR low-pass filter. Decimate to taste
after filtering.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] About the directionality of the LP0410 antenna.

On 11/30/2010 10:06 PM, Miok Wah wrote:
> Hi all,
>
> We hope to do some experiments with the LP0410 antenna. Before that, we
> hope to know more about its characteristics:
>
> 1. Is it a directional antenna?
> 2. If so, is there statistics about its directionality (e.g., beamwidth)?
>
> We did not find relevant information in its data sheet. Hope someone who
> knows about this can help.
>
> Thanks!
>
Those antennas are made by Kent electronics:

http://www.wa5vjb.com/

They're log-periodic antennas, so they are directional. Here's an
article on them:

http://www.salsburg.com/Log-Periodic.pdf

The original Dwight Isbell article on the LPDA is also available on the web.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

[Discuss-gnuradio] About the directionality of the LP0410 antenna.

Hi all,

We hope to do some experiments with the LP0410 antenna. Before that, we
hope to know more about its characteristics:

1. Is it a directional antenna?
2. If so, is there statistics about its directionality (e.g., beamwidth)?

We did not find relevant information in its data sheet. Hope someone who
knows about this can help.

Thanks!

--
View this message in context: http://old.nabble.com/About-the-directionality-of-the-LP0410-antenna.-tp30345118p30345118.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] USRP2 + WBX How to use a 32 MHz signal band?

I am interested in this 2 USRPs approach since I don't have the experience
and the knowledge to start messing about inside the FPGA firmware code and
have an extra USRP2.
How would this go?
I tried looking up some info about this topic. I've read some bits and
pieces on a few forums. Most of the info is about having one USRP2 module as
a transmitter and the other as a receiver.
I want them both to be receivers(actually half a receiver) and to complete
each other by receiving half of the 32 MHz band (so each would receive 16
MHz).
How would the USRPs be connected to the same computer? (MIMO cable?)
How will the two 16 MHz bands be attached together to form the 32 MHz one
(some kind of 2:1 multiplexing - I'm just guessing here)?
I am aware of the great load exerted upon the system resources, but I'm
trying to make this work anyway.
Thanks.

Vlad.

Marcus D. Leech wrote:
>
> On 11/29/2010 08:57 PM, Abdalaleem Andy James Potter wrote:
>> You could use 2 USRPs and chop it down the middle?
>>
>> Reconstruct on the computer?
>>
>>
> Yup, although see my previous comments about host-side resources
> required for such wide bandwidths.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> 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/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30338714.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] Windows Build environment -- Cygwin or MinGW?

I'd like to get started building GNURadio for Windows, using the USRP
1, with the goal of writing some custom blocks. Do people prefer
Cygwin or MinGW style installations? Off the cuff, Cygwin looks more
straightforward. Any opinions?

Thanks in advance

Kevin

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

Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?

I am interested in this 2 USRPs approach since I don't have the experience
and the knowledge to start messing about inside the FPGA firmware code and
have an extra USRP2.
How would this go?
I tried looking up some info about this topic. I've read some bits and
pieces on a few forums. Most of the info is about having one USRP2 module as
a transmitter and the other as a receiver.
I want them both to be receivers(actually half a receiver) and to complete
each other by receiving half of the 32 MHz band (so each would receive 16
MHz).
How would the USRPs be connected to the same computer? (MIMO cable?)
How will the two 16 MHz bands be attached together to form the 32 MHz one
(some kind of 2:1 multiplexing - I'm just guessing here)?
I am aware of the great load exerted upon the system resources, but I'm
trying to make this work anyway.
Thanks.

Vlad.

Marcus D. Leech wrote:
>
> On 11/29/2010 08:57 PM, Abdalaleem Andy James Potter wrote:
>> You could use 2 USRPs and chop it down the middle?
>>
>> Reconstruct on the computer?
>>
>>
> Yup, although see my previous comments about host-side resources
> required for such wide bandwidths.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> 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/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30338714.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] USRP2 + WBX How to use a 32 MHz signal band?

I am interested in this 2 USRPs approach since I don't have the experience
and the knowledge to start messing about inside the FPGA firmware code and
have an extra USRP2.
How would this go?
I tried looking up some info about this topic but currently the
ettus.com/... resources seem to be down. I've read some bits and pieces on a
few forums. Most of the info is about having one USRP2 module as a
transmitter and the other as a receiver.
I want them both to be receivers(actually half a receiver) and to complete
each other by receiving half of the 32 MHz band (so each would receive 16
MHz).
How would the USRPs be connected to the same computer?
How will the two 16 MHz bands be attached together to form the 32 MHz one
(some kind of 2:1 multiplexing - I'm just guessing here)?
I am aware of the great load exerted upon the system resources, but I'm
trying to make this work anyway.
Thanks.

Vlad.

Marcus D. Leech wrote:
>
> On 11/29/2010 08:57 PM, Abdalaleem Andy James Potter wrote:
>> You could use 2 USRPs and chop it down the middle?
>>
>> Reconstruct on the computer?
>>
>>
> Yup, although see my previous comments about host-side resources
> required for such wide bandwidths.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> 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/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30338714.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] Discrete Lo Frequency Changes in GRC

Hello all,
 
Another question. I need to have essentially a counter that will control what frequency I transmit out of the USRP2. I need to control the rate at which it changes. Currently I use a ramp function to do this. I see there is a vector source that is also possible solution. Im wondering if there are also other solutions I may not have considered that someone could recommend. If my previous email is accurate I might need to wait something like 2 seconds between counts to do what I want in an automated fashion. This seems difficult to do in a processor efficient manner within GRC being that it is sample based and more of a labview style of coding and not Cish where I could set a sleep timer or some other wait function to delay the count. If I understand things right a possible solution is to decimate a source to achieve this, or just use a lower frequency ramp source. However this still requires a lot of cpu time since the source is still outputing samples at the sample frequency regardless of whether they are being used. And if I need a variable amount of time at each count, or non-equally spaced counts this doesn't provide that.
 
I have considered going into the python code and doing this modification in there. However I have zero experience with python so it might take me a bit to do that. Just fishing for suggestions, any help offered is appreciated.
 
Thanks,
Justin

[Discuss-gnuradio] USRP2 Lo Frequency Change

Hello All,
 
As always thanks for the help.
 
I was doing some timing measurements the other day and was wondering if this seemed reasonable to you all. I did a simple setup in GRC where I had a toggle switch that changed the frequency the usrp used as an LO. I input a constant of 1 into the USRP2 block and then hooked the usrp2 to a highspeed oscilliscope. I used the toggle switch to change the lo frequency back and forth and with the aid of a stopwatch I saw that the change took about 1.2 seconds to take affect. Is 1.2 seconds a reasonable or expected amount of time? Or is this more indicative of something else?
 
Thanks,
Justin

Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?

I am interested in this 2 USRPs approach since I don't have the experience
and the knowledge to start messing about inside the FPGA firmware code and
have an extra USRP2.
How would this go?
I tried looking up some info about this topic but currently the
ettus.com/... resources seem to be down. I've read some bits and pieces on a
few forums. Most of the info is about having one USRP2 module as a
transmitter and the other as a receiver.
I want them both to be receivers(actually half a receiver) and to complete
each other by receiving half of the 32 MHz band (so each would receive 16
MHz).
How would the USRPs be connected to the same computer?
How will the two 16 MHz bands be attached together to form the 32 MHz one
(some kind of 2:1 multiplexing - I'm just guessing here)?
I am aware of the great load exerted upon the system resources, but I'm
trying to make this work anyway.
Thanks.

Vlad.

Marcus D. Leech wrote:
>
> On 11/29/2010 08:57 PM, Abdalaleem Andy James Potter wrote:
>> You could use 2 USRPs and chop it down the middle?
>>
>> Reconstruct on the computer?
>>
>>
> Yup, although see my previous comments about host-side resources
> required for such wide bandwidths.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> 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/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30338714.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] Sample rate vs. symbol time issue & E100 "Flexible Clocking" (more info please)

On 11/29/2010 01:00 PM, bob beckwith wrote:
> I'm currently confronted with a sample rate vs. symbol time issue.
>
> I noticed that the E100 announcement mentioned a "flexible clocking"
> feature to deal with exactly this type of thing. I've been looking on
> the Ettus site for more information, but haven't been able to locate any.
>
> Is there any more info to be had here?

Unfortunately, we have not really documented this yet. There are a lot
of possibilities, so I will attempt to explain them here.

There are 2 different modes. We'll call them VCO mode and VCXO mode.
You select which mode you are using with 2 jumpers on the board. In
both modes you can lock either to an external reference or to the
onboard 10 MHz TCXO (which has about 1-2 ppm accuracy). The external
reference can be just about any frequency you like, but is typically 10
MHz. In both modes, the maximum master clock rate is 64 MHz.

In VCXO mode, the master clock comes from an on-board VCXO
(voltage-controlled crystal oscillator). In this mode the master clock
frequency for the system is equal to the frequency of the VCXO (or an
integer division thereof). The E100 comes with a 61.44 MHz VCXO (a good
frequency for UMTS), but you can replace it with another frequency
easily since the footprint is an industry standard 5x7 VCXO package.

In VCO mode, the master clock comes from the VCO inside the AD9522-4
clock generator chip. Without getting into too much detail, this allows
you to get a master clock of just about any frequency you would like
below 64 MHz. The limitation is that some frequency choices will have
better phase noise than others. In general, frequencies that are a
multiple of 250 kHz will have very good phase noise. For others you'll
have to do the math to figure out if there are "good factors" you can use.

If you have questions about specific frequencies I can tell you if they
will work well. Otherwise you can look at the AD9522-4 data sheet.

If you need a frequency which does not work well in VCO mode, your best
bet is to use a VCXO at that frequency. For example, 61.44 MHz does not
work well in VCO mode, and that is why we supply the 61.44 MHz VCXO.

> Also, will the N210 incorporate this feature?

No, the N210 clocking uses a VCXO at 100 MHz. You can replace that VCXO
with some other frequencies, but that involves soldering. We are
looking at putting a resampler in the FPGA, but that is some time off.

> And on a different but related front, sample rate wise it looks like the
> Crystek CVHD-950-122.880 would be a good candidate for use as a
> replacement oscillator on the USRP2. Has anyone had any luck with this
> part? Any timing issues I should be aware of? It looks as though the
> clock generator chip shouldn't have a problem with it.


That VCXO should be fine, but you may have trouble meeting FPGA timing
on the USRP2, unless you divide it by 2. It will be a little easier on
the N210.

Matt

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

Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?

I am interested in this 2 USRPs approach since I don't have the experience
and the knowledge to start messing about inside the FPGA firmware code and
have an extra USRP2.
How would this go?
I tried looking up some info about this topic but currently the
ettus.com/... resources seem to be down. I've read some bits and pieces on a
few forums. Most of the info is about having one USRP2 module as a
transmitter and the other as a receiver.
I want them both to be receivers(actually half a receiver) and to complete
each other by receiving half of the 32 MHz band (so each would receive 16
MHz).
How would the USRPs be connected to the same computer?
How will the two 16 MHz bands be attached together to form the 32 MHz one
(some kind of 2:1 multiplexing - I'm just guessing here)?
I am aware of the great load exerted upon the system resources, but I'm
trying to make this work anyway.
Thanks.

Vlad.

Marcus D. Leech wrote:
>
> On 11/29/2010 08:57 PM, Abdalaleem Andy James Potter wrote:
>> You could use 2 USRPs and chop it down the middle?
>>
>> Reconstruct on the computer?
>>
>>
> Yup, although see my previous comments about host-side resources
> required for such wide bandwidths.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> 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/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30338714.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] USRP question for report on gnuradio history

Hello all,

I am writing a report on gnuradio and wanted to include a small portion about the history of the USRP. The only info that I have found is from wikipedia, "The GNU Radio project created the Universal Software Radio Peripheral (USRP) ... the USRP was developed by Matt Ettus." I was slightly surprised that Matt does not have a wikipedia page yet. Was Matt part of the original gnuradio project?

Any good stories, facts, or info on the history of gnuradio (especially the USRP's) would be greatly appreciated.

Have a good day,
Mike

[Discuss-gnuradio] Re:Test-bed application: how to control GUI app and gr_vector_source

Hi Andis Dembovskis:
i tried to run your script, but the program stoped and get following error:

done_part_1
audio_alsa_sink[hw:0,0]: snd_pcm_hw_params failed: Descriptor de
archivo en mal estado
Traceback (most recent call last):
File "programafallido.py", line 56, in <module>
app.tb.start()
File "/usr/lib/python2.6/dist-packages/gnuradio/gr/top_block.py",
line 97, in start
self._tb.start()
File "/usr/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_runtime.py",
line 1455, in start
return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self)
RuntimeError: check topology failed on audio_alsa_sink(1) using
ninputs=1, noutputs=0

do you know how to solve the problem?
thanks in advance.

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

Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?

I am interested in this 2 USRPs approach since I don't have the experience
and the knowledge to start messing about inside the FPGA firmware code and
have an extra USRP2.
How would this go?
I tried looking up some info about this topic but currently gnuradio.com
seems to be down. I've read some bits and pieces on a few forums. Most of
the info is about having one USRP2 module as a transmitter and the other as
a receiver.
I want them both to be receivers(actually half a receiver) and to complete
each other by receiving half of the 32 MHz band (so each would receive 16
MHz).
How would the USRPs be connected to the same computer?
How will the two 16 MHz bands be attached together to form the 32 MHz one
(some kind of 2:1 multiplexing - I'm just guessing here)?
I am aware of the great load exerted upon the system resources, but I'm
trying to make this work anyway.
Thanks.

Vlad.

Marcus D. Leech wrote:
>
> On 11/29/2010 08:57 PM, Abdalaleem Andy James Potter wrote:
>> You could use 2 USRPs and chop it down the middle?
>>
>> Reconstruct on the computer?
>>
>>
> Yup, although see my previous comments about host-side resources
> required for such wide bandwidths.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> 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/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30338714.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] USRP2 + WBX How to use a 32 MHz signal band?

I am interested in this 2 USRPs approach since I don't have the experience
and the knowledge to start messing about inside the FPGA firmware code and
have an extra USRP2.
How would this go?
I tried looking up some info about this topic but currently gnuradio.com
seems to be down. I've read some bits and pieces on a few forums. Most of
the info is about having one USRP2 module as a transmitter and the other as
a receiver.
I want them both to be receivers(actually half a receiver) and to complete
each other by receiving half of the 32 MHz band (so each would receive 16
MHz).
How would the USRPs be connected to the same computer?
How will the two 16 MHz bands be attached together to form the 32 MHz one
(some kind of 2:1 multiplexing - I'm just guessing here)?
I am aware of the great load exerted upon the system resources, but I'm
trying to make this work anyway.
Thanks.

Vlad.

Marcus D. Leech wrote:
>
> On 11/29/2010 08:57 PM, Abdalaleem Andy James Potter wrote:
>> You could use 2 USRPs and chop it down the middle?
>>
>> Reconstruct on the computer?
>>
>>
> Yup, although see my previous comments about host-side resources
> required for such wide bandwidths.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> 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/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30338714.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] USRP2 + WBX How to use a 32 MHz signal band?

I am interested in this 2 USRPs approach since I don't have the experience
and the knowledge to start messing about inside the FPGA firmware code and
have an extra USRP2.
How would this go?
I tried looking up some info about this topic but currently gnuradio.com
seems to be down. I've read some bits and pieces on a few forums. Most of
the info is about having one USRP2 module as a transmitter and the other as
a receiver.
I want them both to be receivers(actually half a receiver) and to complete
each other by receiving half of the 32 MHz band (so each would receive 16
MHz).
How would the USRPs be connected to the same computer?
How will the two 16 MHz bands be attached together to form the 32 MHz one
(some kind of 2:1 multiplexing - I'm just guessing here)?
I am aware of the great load exerted upon the system resources, but I'm
trying to make this work anyway.
Thanks.

Vlad.

Marcus D. Leech wrote:
>
> On 11/29/2010 08:57 PM, Abdalaleem Andy James Potter wrote:
>> You could use 2 USRPs and chop it down the middle?
>>
>> Reconstruct on the computer?
>>
>>
> Yup, although see my previous comments about host-side resources
> required for such wide bandwidths.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> 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/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30338714.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] Full duplex and half duplex doesnot work

How did you resolve your problem? I have the same problem and reading your
post I cannot understand the solution of your one.

Thanks in advance


blwfsoj wrote:
>
> Hi all,
> Before i start telling about my problem, i want to mention that i have
> already read the post named "help: cannot send after transport endpoint
> shutdown" which is very close to my problem but i could not solve it.
>
> I'm trying to transmit from the usrp port A, and then make it receive at
> the same port using "Auto T/R" which i expressed by typing "-v" (isn't it
> correct) after the benchmark.
> but some time it works and most of the times its not (not stable), when
> its not working it shows me the following error:
> .onur@vecon3:~/Documents/abbasi/programmitx.py -f 1200000000 -m dbpsk -v
> --tx-amplitude=0.08 -T A
>>>> gr_fir_ccf: using SSE
>
> Modulator:
> bits per symbol: 1
> Gray code: True
> RRC roll-off factor: 0.35
> Tx amplitude 0.08
> modulation: dbpsk_mod
> bitrate: 100kb/s
> samples/symbol: 2
> USRP Sink: A: Flex 1200 Tx MIMO B
> Requested TX Bitrate: 100k Actual Bitrate: 125k
> Warning: failed to enable realtime scheduling
> ........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................onur@vecon3:~/Documents/abbasi/programmirx.py
> -f 1200000000 -m dbpsk -v
>>>> gr_fir_ccf: using SSE
>
> Demodulator:
> bits per symbol: 1
> Gray code: True
> RRC roll-off factor: 0.35
> Costas Loop alpha: 1.50e-01
> Costas Loop beta: 5.62e-03
> M&M mu: 0.50
> M&M mu gain: 1.00e-01
> M&M omega: 2.00
> M&M omega gain: 2.50e-03
> M&M omega limit: 0.01
>
> Receive Path:
> modulation: dbpsk_demod
> bitrate: 100kb/s
> samples/symbol: 2
> usrp_open_interface:usb_claim_interface: failed interface 2
> could not claim interface 2: Device or resource busy
> usrp_basic_rx: can't open rx interface
> Traceback (most recent call last):
> File "mybenchmark_rx.py", line 112, in <module>
> main()
> File "mybenchmark_rx.py", line 101, in main
> tb = my_top_block(demods[options.modulation], rx_callback, options)
> File "mybenchmark_rx.py", line 45, in __init__
> self.rxpath = usrp_receive_path.usrp_receive_path(demodulator,
> rx_callback, options)
> File
> "/home/onur/Documents/abbasi/programming/examples/digital/usrp_receive_path.py",
> line 68, in __init__
> self._setup_usrp_source(options)
> File
> "/home/onur/Documents/abbasi/programming/examples/digital/usrp_receive_path.py",
> line 73, in _setup_usrp_source
> self.u = usrp_options.create_usrp_source(options)
> File
> "/home/onur/Documents/abbasi/programming/examples/digital/usrp_options.py",
> line 88, in create_usrp_source
> gain=options.rx_gain,
> File
> "/home/onur/Documents/abbasi/programming/examples/digital/generic_usrp.py",
> line 144, in __init__
> _generic_usrp_base.__init__(self, **kwargs)
> File
> "/home/onur/Documents/abbasi/programming/examples/digital/generic_usrp.py",
> line 63, in __init__
> except: raise Exception, 'Failed to automatically setup a usrp
> device.'
> Exception: Failed to automatically setup a usrp device.
> onur@vecon3:~/Documents/abbasi/programming/examples/digital$
>
> ON THE OTHER HAND:
> when i try the full duplex (use a slot from block A as transmitter and
> slot from block B as receiver) it also doesnot work. it will not be able
> to setup the interface.
>
> i appreciate your help,
> regards,
>
>

--
View this message in context: http://old.nabble.com/Full-duplex-and-half-duplex-doesnot-work-tp27226209p30338716.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] USRP2 + WBX How to use a 32 MHz signal band?

I am interested in this 2 USRPs approach since I don't have the experience
and the knowledge to start messing about inside the FPGA firmware code and
have an extra USRP2.
How would this go?
I tried looking up some info about this topic but currently gnuradio.com
seems to be down. I've read some bits and pieces on a few forums. Most of
the info is about having one USRP2 module as a transmitter and the other as
a receiver.
I want them both to be receivers(actually half a receiver) and to complete
each other by receiving half of the 32 MHz band (so each would receive 16
MHz).
How would the USRPs be connected to the same computer?
How will the two 16 MHz bands be attached together to form the 32 MHz one
(some kind of 2:1 multiplexing - I'm just guessing here)?
I am aware of the great load exerted upon the system resources, but I'm
trying to make this work anyway.
Thanks.

Vlad.

Marcus D. Leech wrote:
>
> On 11/29/2010 08:57 PM, Abdalaleem Andy James Potter wrote:
>> You could use 2 USRPs and chop it down the middle?
>>
>> Reconstruct on the computer?
>>
>>
> Yup, although see my previous comments about host-side resources
> required for such wide bandwidths.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> 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/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30338714.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] software-defined GNSS receiver people in Asia

Dear All,
I apologize for bugging people on this mailing list for this but I do
not know an alternative way.

I am looking for people located in Asia doing GNSS stuff with GNU
Radio or other SDR softwares and interested in sharing some Asian
GNSSs (e.g. QZSS) data or implementation. In return I can provide, if
interested, some GALILEO E1/E5 full constellation signal.

Regards
Fabrizio

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

Re: [Discuss-gnuradio] python/digital examples and UHD

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/29/2010 03:47 PM, Tom Rondeau wrote:

Thanks for your reply Tom,

>> Have you used the version 2 digital code, yet (benchmark_tx2,
>> benchmark_rx2, usrp_receive_path2, etc.)? One of the things I did was
>> include better resampling so that you can get any bit rate you want.
>> You still have to go through the process of selecting the USRP's
>> sample rate that's closest to your desired rate, and then the
>> resampling takes care of the rest.

Well in fact that's what I was looking at. I called this the
'automagical' frequency selection in my last mail ;-)

It appears to me you do this by trying all the tuples of (bitrate,
samples_per_symbol,...) and select the one fitting 'best'.

So please don't throw stones at me for asking this question, but from my
understanding the required

desired_samplerate = bitrate x samples_per_symbol / bits_per_symbol (1)


>> What I do with the UHD driver is ask for a sample rate. It will then
>> set its sample rate to whatever the closest rate it can do. You can
>> the read back the actual sample rate of the USRP with get_samp_rate().
>> I then use this value to determine the difference between my desired
>> sample rate and the actual sample rate, which I then plug into the
>> arbitrary resampler.

So what you suggest is basically:

1. set_samp_rate(desired_samplerate) as in (1)

2. tmp = get_samp_rate()

3. and then resample in gnuradio according to tmp / desired_samplerate

or did I get something wrong?

Please don't get me wrong because I ask a lot of questions :-)
I don't ask you guys to do any of my work (like a thesis or the likes).
Just in my opinion having the examples working is really important,
because that's where new people start to look at when trying to figure
out how stuff works.
And nothing is more frustrating than not even managing to get the
examples running.

Best regards and happy hacking,

Moritz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJM9L5tAAoJEOjnDXL6I0uZtNwP/1JDIggYhvBRw6bJQmQzUjKU
mDKrYyqIdFbLDv0+aC62gTn0g+OVpa11yP585pZcF9tZ5A9ZwIqSEpo6iEPXH883
q6+A3GmogTAqtaydf7seG3PkdV/HXZcAkBRtd0QgjMykKbIOG2hlDTJZsv8Ru0Iz
/dOa6ERrxHQSrYY1DLW/e5dMrwBp8SMGdIT3RlwpuKvQyZmA9xj8rcqxNyvfHuNf
3KT5AFCQQbKrmGXiwb9z+09rFTHWga4hdLbfkX+L4ANz/j2eUDxomLgSVcx1vOEb
0Qqn1MJu2vBRceIdyiAItl3gnocWZ62EQMnvIcoDY9F7Mi9sBCWVV18CWVwPv2SU
P+4o5wRvpV5b7nVn6U0Yi47w0/Wfz5UsYbiGMc/scrpSa0wHuYv7BXsjlOOANrmd
RAYz0Xvk6aIq4P4RuuqeIx1AWfw0tLcQaO7BAAvanZqf6qf+HqP+oMmCQZgWzlhL
hgDuL/7YdpUN66c8xSXivCfFZpf/FOkoKMhF1N7BQ1EM349BrgbPdL3VO0I/jEs/
f7nsMML7FkhJdOF5IH/1QgEl+fGGMNvEmqBqfm3w/pYtUkwX4KDnc6GrHimYrk72
QnFuv2ZWURnyNsvp7pYnH27Bu7ssyYa6DZP+Iu047Ev7iK0oMuqaQaWxDibSSL4c
vMqE5g//R0SsNBcTtiZe
=x5g+
-----END PGP SIGNATURE-----

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

Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?

Tom,
You are right, it doesn't make any sense, I was thinking about the reverse method, taking for example just 10 MHz out of a total band of 12.5 by filtering or resampling, but that is totally different since you have extra band and you just eliminate the extra part, but here you can't just make up the difference between 25 and 32 MHz.

Vlad.

--- On Tue, 11/30/10, Tom Rondeau <trondeau1122@gmail.com> wrote:

From: Tom Rondeau <trondeau1122@gmail.com>
Subject: Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?
To: "Vladutzzz" <stoianovici_vlad@yahoo.com>
Cc: Discuss-gnuradio@gnu.org
Date: Tuesday, November 30, 2010, 4:48 AM

On Mon, Nov 29, 2010 at 5:59 PM, Vladutzzz <stoianovici_vlad@yahoo.com> wrote:
>
> What would be the best way to work with a 32 MHz band resulting from USRP2?
> I guess, since the minimum decimation rate is 4 (resulting in a 25 MHz
> signal band), some kind of interpolation will be required or maybe
> resampling?!
> Any ideas on how to proceed?
> Thanks in advance!
>
> Vlad.

I'm not entirely sure what you meant by interpolating or resampling,
but in case you were talking about what I think you were talking
about, that's not going to work. Sure, you can come in at 25 Msps and
resample to 32 Msps, but you won't be getting any more information out
of the signal by doing that. You'll still only have the information in
the original 25 MHz bandwidth, just now sampled at a higher rate
(which doesn't make any difference or, frankly, any sense).

Tom

Re: [Discuss-gnuradio] GRC with two URSP2+DBSRX and UHD

>-----Original Message-----
>From: Thomas Hobiger [mailto:hobiger@nict.go.jp]
>Sent: Tuesday, November 30, 2010 01:04 AM
>To: bobb@sigmatix.com
>Cc: josh@joshknows.com, discuss-gnuradio@gnu.org
>Subject: Re: [Discuss-gnuradio] GRC with two URSP2+DBSRX and UHD
>
>Hi Bob,
>> This is pretty easy to do (but, I can only tell you how to do it in C++)...
>>
>> set_clock_config() in UHD
>>
>Do you have some code snippet to share? Does the C++ version support
>streaming data from a slave device through a host URSP2 before sending
>all data via a single ethernet cable?
>

Thomas,

There is no code that I am aware of that currently does what you want (i.e., sync the U2's *and* conveys data from both devices), however, I believe it is currently being worked on, however I'm willing to be corrected on this.

As I said, sync'ing 2 devices to a single PPS signal is pretty straightforward, however I think you're looking for more than that.

Using the "raw" enet drivers the code is essentially...

usrp2::usrp2::sptr u2 = usrp2::usrp2::make(dev, "");// dev = device path (e.g., "eth1")
u2->config_mimo(mode);
// mode = (usrp2::MC_WE_DONT_LOCK + usrp2::MC_PROVIDE_CLK_TO_MIMO) // drive clock to cable
| (usrp2::MC_WE_LOCK_TO_MIMO) // lock for reference from cable
| (usrp2::MC_WE_LOCK_TO_SMA) // lock to reference provided by front panel

You need to "do the right thing" on both ends of the cable.

For UHD (which we're currently transitioning and am still getting up to speed with), I believe the equivalent code would be something like:

uhd::usrp::simple_usrp::sptr u2 = uhd::usrp::simple_usrp::make(dev);
clock_config_t mode;
mode.ref_source = { REF_AUTO | REF_INT = 'i' | REF_SMA = 's' | REF_MIMO = 'm' }l
mode.pps_source = { PPS_INT | PPS_SMA | PPS_MIMO};
mode.pps_polarity = { PPS_NEG | PPS_POS};
u2->set_clock_config(mode);

As I said, I think what you're actually looking for (clock/pps sync & data over the MIMO cable is "in the works", but I could be mistaken).

Obviously syncing more than 2 usrps requires additional hardware (since without additional hardware you can only connect 2 usrps together).

Hope this helps,

--Bob

>I am implementing our passive radar in C++ but I thought that GRC is
>nice for testing. I learnt yesterday that things are not completely
>available for GRC. But as our project needs to move on I would be highly
>interested if you can sync (PPS and freq.) two (or more) URSP2s via MIMO
>and (!) stream the data via a single gigabit Ethernet cable with the
>current UHD library? This would enable us to place our receivers at
>arbitrary locations without the need of pulse generators and a 10 MHz
>reference.
>
>Regards,
> Thomas
>
>
>
>
>--
>******************************************************************
>Dr. Thomas Hobiger
>Space-Time Measurement Project
>Space-Time Standards Group
>New Generation Network Research Center
>National Institute of Information and Communications Technology
>------------------------------------------------------------------
>4-2-1 Nukui-Kitamachi, Koganei
>184-8795 Tokyo
>Japan
>------------------------------------------------------------------
>email: hobiger@nict.go.jp
>phone: ++81-042-327-7561
>fax: ++81-042-327-6664
>------------------------------------------------------------------
>homepage (priv.): http://www.hobiger.org
>******************************************************************
>
>

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

Monday, November 29, 2010

Re: [Discuss-gnuradio] GRC with two URSP2+DBSRX and UHD

Hi Bob,
> This is pretty easy to do (but, I can only tell you how to do it in C++)...
>
> set_clock_config() in UHD
>
Do you have some code snippet to share? Does the C++ version support
streaming data from a slave device through a host URSP2 before sending
all data via a single ethernet cable?

I am implementing our passive radar in C++ but I thought that GRC is
nice for testing. I learnt yesterday that things are not completely
available for GRC. But as our project needs to move on I would be highly
interested if you can sync (PPS and freq.) two (or more) URSP2s via MIMO
and (!) stream the data via a single gigabit Ethernet cable with the
current UHD library? This would enable us to place our receivers at
arbitrary locations without the need of pulse generators and a 10 MHz
reference.

Regards,
Thomas


--
******************************************************************
Dr. Thomas Hobiger
Space-Time Measurement Project
Space-Time Standards Group
New Generation Network Research Center
National Institute of Information and Communications Technology
------------------------------------------------------------------
4-2-1 Nukui-Kitamachi, Koganei
184-8795 Tokyo
Japan
------------------------------------------------------------------
email: hobiger@nict.go.jp
phone: ++81-042-327-7561
fax: ++81-042-327-6664
------------------------------------------------------------------
homepage (priv.): http://www.hobiger.org
******************************************************************


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

Re: [Discuss-gnuradio] gr-air-modes: problem with uhd and USRP1

Nick,

Got it working on my USRP2 by changing to line 57 to:
self.u = uhd.single_usrp_source("addr=192.168.1.15",
uhd.io_type_t.COMPLEX_FLOAT32)

and line 119 to:
result = self.u.set_center_freq(freq,0)

I'm getting 0 aircraft locations in the KML file but the stdout is as
follows:

(-40) Type 11 (all call reply) from e9fc9f in reply to interrogator 5
(-41) Type 11 (all call reply) from 2c4e09 in reply to interrogator 0

I assume these are Mode-S packets, thus no position info?


--
View this message in context: http://old.nabble.com/gr-air-modes%3A-problem-with-uhd-and-USRP1-tp30326133p30336873.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] USRP2 + WBX How to use a 32 MHz signal band?

On Mon, Nov 29, 2010 at 5:59 PM, Vladutzzz <stoianovici_vlad@yahoo.com> wrote:
>
> What would be the best way to work with a 32 MHz band resulting from USRP2?
> I guess, since the minimum decimation rate is 4 (resulting in a 25 MHz
> signal band), some kind of interpolation will be required or maybe
> resampling?!
> Any ideas on how to proceed?
> Thanks in advance!
>
> Vlad.

I'm not entirely sure what you meant by interpolating or resampling,
but in case you were talking about what I think you were talking
about, that's not going to work. Sure, you can come in at 25 Msps and
resample to 32 Msps, but you won't be getting any more information out
of the signal by doing that. You'll still only have the information in
the original 25 MHz bandwidth, just now sampled at a higher rate
(which doesn't make any difference or, frankly, any sense).

Tom

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

Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?

On 11/29/2010 08:57 PM, Abdalaleem Andy James Potter wrote:
> You could use 2 USRPs and chop it down the middle?
>
> Reconstruct on the computer?
>
>
Yup, although see my previous comments about host-side resources
required for such wide bandwidths.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

[Discuss-gnuradio] Noise Blanker Module?

begin:vcard
fn:Rob Frohne
n:Frohne;Rob
org:Walla Walla University;Engineering
adr:;;100 SW 4th Street;College Place;WA;99324;USA
email;internet:rob.frohne@wallawalla.edu
title:Professor
tel;work:509 527 2075
x-mozilla-html:FALSE
url:http://people.wallawalla.edu/~rob.frohne/
version:2.1
end:vcard

Hi,

Has anyone got a noise blanker module for gnuradio?

Thanks & 73,

Rob
KL7NA

--
Rob Frohne, Ph.D., P.E.
E.F. Cross School of Engineering
Walla Walla University
100 SW 4th Street
College Place, WA 99324
(509) 527-2075 http://people.wallawalla.edu/~rob.frohne

Re: [Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?

>
> What would be the best way to work with a 32 MHz band resulting from USRP2?
> I guess, since the minimum decimation rate is 4 (resulting in a 25 MHz
> signal band), some kind of interpolation will be required or maybe
> resampling?!
> Any ideas on how to proceed?
> Thanks in advance!
>
> Vlad.
>
The maximum bandwidth over the GiGE interface is 25Msps. If you want to
do processing at higher bandwidths, you'll
have to dive into the UHD code and move to smaller samples (8-bits x
2 instead of 16-bits x 2), or do your processing
on the FPGA. Either approach will require modifying significant
swaths of code on the FPGA.

Also, doing anything significant to a datastream arriving at 25Msps on
the host will require a CPU that's up to the task.
My IRA radio astronomy code, which does spectral and radiometry
measurements can just-barely keep up at 12.5Msps
on a 4-core Phenom II running flat-out at 3.2GHz.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

[Discuss-gnuradio] USRP2 + WBX How to use a 32 MHz signal band?

What would be the best way to work with a 32 MHz band resulting from USRP2?
I guess, since the minimum decimation rate is 4 (resulting in a 25 MHz
signal band), some kind of interpolation will be required or maybe
resampling?!
Any ideas on how to proceed?
Thanks in advance!

Vlad.
--
View this message in context: http://old.nabble.com/USRP2-%2B-WBX-How-to-use-a-32-MHz-signal-band--tp30335430p30335430.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] Bandpower measurment USRP2

Thanks Marcus.
You did manage to tie up several loose ends, and I really appreciate it!
All the best.

Vlad.


Marcus D. Leech wrote:
>
> On 11/28/2010 06:53 PM, Vladutzzz wrote:
>> Marcus,
>> First of all thank you for your reply!
>> I have some questions about your very much appreciated explanations:
>> After using the complex-to-mag-squared block, should I consider the
>> coefficients as being in W or mW (should I use 10*log10 or 30 + 10*log10
>> to
>> get the power value in dBm)?
>> What is the function of the single-pole-iir_filter? What does it actualy
>> do?
>> I'm asking this so I will know how to calculate its parameters. Does it
>> give
>> the frequency bin based signal band, a more rounded appearance?
>> Again thank you for your help!
>> I hope other people will also find this useful.
>>
>> Vlad.
>>
>>
> You expressed a desire to measure power over a finite bandwidth (at
> least, that's what I think
> you were asking).
>
> The values after the complex-to-mag-squared block are *unscaled* total
> power estimates over
> the input bandwidth. The IIR filter is used to smooth the result--in
> a hardware power detector,
> it would be a simple R-C network, here we use a simple single-pole
> IIR filter, although you could
> use a simple FIR low-pass as well, but the single-pole IIR is cheap,
> and has adequate
> behaviour for total-power detection--it's what I use in radiometry.
>
> In order to convert to your favourite units (like dBm), you'll have to
> take some
> *experimental measurements*, and scale the output values
> accordingly. Please re-read
> my original reply, I'm not going to repeat it here.
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> 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/Bandpower-measurment-USRP2-tp30323488p30335394.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] Sample rate vs. symbol time issue & E100 "Flexible Clocking" (more info please)

I'm currently confronted with a sample rate vs. symbol time issue.

I noticed that the E100 announcement mentioned a "flexible clocking" feature to deal with exactly this type of thing. I've been looking on the Ettus site for more information, but haven't been able to locate any. 

Is there any more info to be had here?

Also, will the N210 incorporate this feature?

And on a different but related front, sample rate wise it looks like the Crystek CVHD-950-122.880 would be a good candidate for use as a replacement oscillator on the USRP2. Has anyone had any luck with this part? Any timing issues I should be aware of? It looks as though the clock generator chip shouldn't have a problem with it.

Thanks much,

  --Bob


Re: [Discuss-gnuradio] help -- how to implement transmitting periodic on/off tones

Yes, LO leakage, more specifically DC imbalance in the I and Q channels; I
assume you are using a daughter board with an IQ modulator? This is
supposedly corrected for in the firmware, however, probably not done over
temperature. You can probably tweak it by adding/subtracting a few LSB of
DC offset to your I and Q samples. It's an iterative approach, tweaking
until you minimize it. Won't be able to do better than what's spec'd in the
data sheet though. I have never been able to get less than -60 dBc; not on
URSP hardware but my own stuff. It's really only a problem in really
wide-band modulation (e.g. spread spectrum) where your leakage poke above
the modulation, or with tons of averaging and you are trying to hide your
signal. Of course it's a problem for you, but best bet to blank off the
buffer (or switch the T/R switch) to improve isolation.
--
View this message in context: http://old.nabble.com/help----how-to-implement-transmitting-periodic-on-off-tones-tp30328518p30334344.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] help -- how to implement transmitting periodic on/off tones

On 11/29/2010 01:35 PM, Steven Clark wrote:


One would think something like this would work, but I've noticed that even if you're sending 0's to your usrp sink, the transmitter still puts out some amount of power (plenty strong enough to be detectable via a spec-an). This power goes away if you disable the transmitter via software. Does anybody know anything about this phenomenon?

-Steven
 
Slight LO leakage out of the mixer?




--  Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org

Re: [Discuss-gnuradio] help -- how to implement transmitting periodic on/off tones


Think of the on/off part as a control stream consisting of 1's and
0's.  Generate the control stream, and multiple the control stream by
the carrier stream.

Don't try to start and stop the graph or anything like that from
python.

You can probably generate the control stream with a
gr.vector_source_f([<my-pattern>], True) followed by a dumb
interpolator that will just replicate values.

 my_pattern = [1, 1, 0, 0, 1, 0, ... ]
 interp_factor = 1000   # scale the pattern up in time to match signal

 ctrl_pattern = gr.vector_source_f(my_pattern, True)
 ctrl_interp = gr.interp_fir_filter_fff(interp_factor, interp_factor*[1.0])

 signal = <generate carrier>

 mult = gr.multiple_ff()

 sink = <something-downstream>


 tb.connect(ctrl_pattern, ctrl_interp, (mult, 0))
 tb.connect(signal, (mult, 1))
 tb.connect(mult, sink)



One would think something like this would work, but I've noticed that even if you're sending 0's to your usrp sink, the transmitter still puts out some amount of power (plenty strong enough to be detectable via a spec-an). This power goes away if you disable the transmitter via software. Does anybody know anything about this phenomenon?

-Steven

Re: [Discuss-gnuradio] help -- how to implement transmitting periodic on/off tones

On Mon, Nov 29, 2010 at 12:42:38AM -0800, Steve Mcmahon wrote:
> Hello:

> I have a USRP2 board and a WBX daughterboard. I am trying to
> implement a scheme where a single-tone sine wave (at frequencies
> between 1 kHz and 10 kHz) is transmitted
> intermittently. Specifically, time is divided into intervals,
> defined by the user on the command line, typically of values such as
> 200 ms or 500 ms or 1s. When invoked, the flow graph (the Python
> script) would transmit nothing (all zeros) during the first time
> interval, then transmit the tone during the second time interval,
> then transmit nothing (all zeros) during the third and fourth and
> fifth time intervals, then transmit the tone during the sixth time
> interval, then transmit nothing (all zeros) during the seventh time
> interval, and then stop and end.

> How in the world could I implement this? I feel like it'd be hard to
> do, but maybe it's actually easy. Would I need to use a timer in
> Python to set what gets transmitted at the start of each interval
> duration? Any help would be very much appreciated, as I am still
> somewhat new to GNU Radio and Python. Thanks for your help,
> everyone.

Think of the on/off part as a control stream consisting of 1's and
0's. Generate the control stream, and multiple the control stream by
the carrier stream.

Don't try to start and stop the graph or anything like that from
python.

You can probably generate the control stream with a
gr.vector_source_f([<my-pattern>], True) followed by a dumb
interpolator that will just replicate values.

my_pattern = [1, 1, 0, 0, 1, 0, ... ]
interp_factor = 1000 # scale the pattern up in time to match signal

ctrl_pattern = gr.vector_source_f(my_pattern, True)
ctrl_interp = gr.interp_fir_filter_fff(interp_factor, interp_factor*[1.0])

signal = <generate carrier>

mult = gr.multiple_ff()

sink = <something-downstream>


tb.connect(ctrl_pattern, ctrl_interp, (mult, 0))
tb.connect(signal, (mult, 1))
tb.connect(mult, sink)

Eric

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

Re: [Discuss-gnuradio] TPB scheduler fills block buffers

On Mon, Nov 29, 2010 at 08:42:14AM +0100, antonb wrote:
> Hi,
>
> I am writing an application for which I want to keep the latency to a
> minimum, and this involves trying to keep the buffers between the blocks as
> empty as possible. Basically, I have a source block with an element size of
> 512 bytes that accepts data through a public member function. If there is
> no data to transmit it will produce one empty packet to keep the USRP busy.
> The scheduler keeps asking for 64 items and I give it one. This goes on
> until its write buffer is full. The processing latency (from the source
> block to the USRP) of the first items is a few ms, but this grows to well
> over a second due to the large amounts of buffered data.
>
> Looking at the behavior of the single threaded scheduler, it seems it is
> trying to keep the latency low by only requesting data from source blocks
> when the other blocks fail to produce anything. However, the thread per
> block scheduler does not seem to care about whether a block is a source
> block or not. Is there any way I can configure it to do this? Is there any
> other approach for solving this problem?
>
> Thankful for any help,
> Anton Blad

Hi Anton,

There's been some discussion about this over the past few months.
Probably the easiest way to fix this problem is to limit the usable
size of the buffers in the processing chain. This is a relatively
small change, that would allow an application developer to control the
worst case amount of buffering that is used in the graph. By default,
we allocate buffers on the order of 32KiB, then double that size so
that we can double buffer under the TPB scheduler. (Optimizing for
throughput.)

The current implementation requires that the physical size of the
buffers be a multiple of the page size. The fix I'm proposing leaves
that constraint in place (it's hard to remove for a variety of
reasons), but allows the specification of a limit on the total number
of samples allowed in the buffer. Thus, if want low latency, you
could specify a limit of 512 bytes (or less for that matter), and the
total buffering would be drastically reduced from what's currently
used.

I won't have time to look at this until after the new year, but if
you're interested in looking at it, the primary place to look is
gnuradio-core/src/lib/runtime/gr_buffer.{h,cc}. Basically you'd want
to limit the amount of space that it reports is available for writing
to min(<whats-physically-available>, <your-limit>)

Eric

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

[Discuss-gnuradio] Thread deadlock in GNU Radio?

Eric,

In my experiments, I had one transmitter and one receiver, which used
tunnel.py for communicating with each other. Occasionally, I got the
problem that one radio stopped receiving, but could still transmit. I
used TX and RX printings to observe this behavior. In the receiving
path, there is one thread to put received packets into a queue and
another thread to read out the packets from this queue. Is it possible
that these two threads can get deadlocked?

Once the above behavior happened, I used oprifile to see what's still
running, here is the data:


CPU: Core 2, speed 1600 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a
unit mask of 0x00 (Unhalted core cycles) count 50000
samples % image name app name
symbol name
505795 36.8303 /no-vmlinux /no-vmlinux
/no-vmlinux
91821 6.6861 /lib/libgcc_s.so.1 /lib/libgcc_s.so.1
/lib/libgcc_s.so.1
63582 4.6298 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gr_block_executor::run_one_iteration()
62849 4.5765 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0 gr_fast_atan2f(float,
float)
52437 3.8183 /lib/tls/i686/cmov/libm-2.11.1.so
/lib/tls/i686/cmov/libm-2.11.1.so /lib/tls/i686/cmov/libm-2.11.1.so
41528 3.0239 /lib/tls/i686/cmov/libpthread-2.11.1.so
/lib/tls/i686/cmov/libpthread-2.11.1.so pthread_mutex_lock
40215 2.9283 /usr/lib/libfftw3f.so.3.2.4
/usr/lib/libfftw3f.so.3.2.4 /usr/lib/libfftw3f.so.3.2.4
32285 2.3509 /lib/tls/i686/cmov/libpthread-2.11.1.so
/lib/tls/i686/cmov/libpthread-2.11.1.so __pthread_mutex_unlock_usercnt
27639 2.0126 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0 ccomplex_dotprod_sse
25218 1.8363 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gr_clock_recovery_mm_ff::general_work(int, std::vector<int,
std::allocator<int> >&, std::vector<void const*, std::allocator<void
const*> >&, std::vector<void*, std::allocator<void*> >&)
24609 1.7919 /lib/tls/i686/cmov/libc-2.11.1.so
/lib/tls/i686/cmov/libc-2.11.1.so /lib/tls/i686/cmov/libc-2.11.1.so
23391 1.7033 /usr/bin/python2.6 /usr/bin/python2.6
/usr/bin/python2.6
22216 1.6177 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gr_fir_ccc_simd::filter(std::complex<float> const*)
19529 1.4220 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gri_fft_filter_ccc_generic::filter(int, std::complex<float> const*,
std::complex<float>*)
19382 1.4113 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
min_available_space(gr_block_detail*, int)
17852 1.2999 [vdso] (tgid:2135 range:0x5bd000-0x5be000)
/usr/bin/python2.6 [vdso] (tgid:2135 range:0x5bd000-0x5be000)
17703 1.2891 /lib/tls/i686/cmov/libpthread-2.11.1.so
/lib/tls/i686/cmov/libpthread-2.11.1.so pthread_cond_signal@@GLIBC_2.3.2
17030 1.2401 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gr_freq_xlating_fir_filter_ccc::work(int, std::vector<void const*,
std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&)
15846 1.1539 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gr_tpb_detail::notify_downstream(gr_block_detail*)
15706 1.1437 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gr_tpb_detail::notify_upstream(gr_block_detail*)
15387 1.1204 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0 float_dotprod_sse
14412 1.0494 /usr/bin/oprofiled /usr/bin/oprofiled
/usr/bin/oprofiled
12486 0.9092 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gr_keep_one_in_n::general_work(int, std::vector<int, std::allocator<int>
>&, std::vector<void const*, std::allocator<void const*> >&,
std::vector<void*, std::allocator<void*> >&)
12119 0.8825 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gr_quadrature_demod_cf::work(int, std::vector<void const*,
std::allocator<void const*> >&, std::vector<void*, std::allocator<void*> >&)
11792 0.8587 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gr_count_bits32(unsigned int)
10476 0.7628 /usr/lib/libboost_thread.so.1.40.0
/usr/lib/libboost_thread.so.1.40.0 /usr/lib/libboost_thread.so.1.40.0
9285 0.6761 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr<gr_block>)
9073 0.6607 /lib/tls/i686/cmov/libpthread-2.11.1.so
/lib/tls/i686/cmov/libpthread-2.11.1.so pthread_cond_wait@@GLIBC_2.3.2
8443 0.6148 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
gri_mmse_fir_interpolator::interpolate(float const*, float) const
7698 0.5605 /usr/local/lib/libusrp2-3.3.1git.so.0.0.0
/usr/local/lib/libusrp2-3.3.1git.so.0.0.0
usrp2::copy_u2_16sc_to_host_32fc(unsigned int, unsigned int const*,
std::complex<float>*)
7512 0.5470 /usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0
/usr/local/lib/libgnuradio-core-3.3.1git.so.0.0.0 __i686.get_pc_thunk.bx


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

Re: [Discuss-gnuradio] USRP FPGA code

Are you behind a firewall blocking git? You may want to try the http mirror:

http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Get-the-source

-Josh

On 11/29/2010 08:14 AM, Euripedes Rocha Filho wrote:
> Hi, I was trying to get the code from ettus git repository, but without
> success.
>
> Is anyone else having trouble with this? And where I can get the code?
>
>
> Euripedes
>
>
>
>
> _______________________________________________
> 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] SDR conference GNU Radio meeting

Hi everyone,

Just a reminder about the meetup we will be having at the SDR
Technical Conference in Crystal City on Wednesday night starting at
7:30.

You can find the conference program here:
http://conference.wirelessinnovation.org/mc/page.do?sitePageId=119381&orgId=s1

Importantly, the location of the meetup will be in Potomac Rooms V&VI.
They are located on the bottom floor of the Crystal City Hyatt where
the rest of the conference is going on. Exhibits will (likely) be on
the next floor up from here, which is where many of us attending the
conference will be coming down from.

Thanks, and I look forward to seeing many of you soon!

Tom

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

Re: [Discuss-gnuradio] python/digital examples and UHD

On Mon, Nov 29, 2010 at 4:02 AM, Moritz Fischer
<fischer@int.uni-karlsruhe.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi list,
>
> over the weekend I spend some time trying to update the demos to work
> with the UHD, I just started playing with git, so if you see something
> stupid let me know ;-)
>
> I put what I got on (in the uhd-examples branch):
>
> git@github.com:mfischer/gnuradio-mfischer.git
>
> However the part where it 'automagically' picks rx/tx bitrates is not
> really working as I have no idea how to detect what device I'm talking
> to. Also please note that as I don't have the right values for bitrates
> and samples_per_symbol don't be surprised if the examples crash ;-)
>
> The old generic_usrp.py had ranges for the possible decimation /
> interpolation factors as we don't have this in UHD I'm a bit confused on
> how to continue.
>
> I started to add a function
>
> samp_rate_range_t get_rx_samp_rate_range()
>
> to UHDs single_usrp_sink / multi_usrp_sink which internally would ask
> the corresponding _dev for the right ranges, depending on what device
> you're talking to. I still have to figure out the ranges part though.
>
> git@github.com:mfischer/uhd-mfischer.git
>
> As I don't really have insight into the longtime plan for UHD,
> I'm not sure whether that's the way to go though...
>
> Can someone give me any hints whether this actually makes sense?
>
> Happy hacking,
>
> - -Moritz

Thanks, Moritz. I'll try to take a look at this sometime.

Have you used the version 2 digital code, yet (benchmark_tx2,
benchmark_rx2, usrp_receive_path2, etc.)? One of the things I did was
include better resampling so that you can get any bit rate you want.
You still have to go through the process of selecting the USRP's
sample rate that's closest to your desired rate, and then the
resampling takes care of the rest.

What I do with the UHD driver is ask for a sample rate. It will then
set its sample rate to whatever the closest rate it can do. You can
the read back the actual sample rate of the USRP with get_samp_rate().
I then use this value to determine the difference between my desired
sample rate and the actual sample rate, which I then plug into the
arbitrary resampler.

Tom

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJM82xBAAoJEOjnDXL6I0uZ4icQAJt3+Z82fs2LGRZ+4ndKVat0
> DMPzRW1EN3T4EKIyAY9N4/weLwXvT5vuyKc+2i/mlPzhjS+ssJKfsnbLJNfNgK0Q
> Notdvyv1ItNZtrD2/l5MpM/dyR0dwVpLJnmF6jrH0zOX0yiBdah80/YAz5ISrxtm
> nKNmo0DJ/hZqWPQkklYbMrDirdLACPTzRwqh+JVJHBOOiVnoyXbmxakY2Ta1Ea+d
> 4BpOOV4h5daGQeC+9BKODY/aNtkemCvHBZdC3FQA/8IxnoRnJWTohT4Dyxc+Ypgo
> AKOaYUGk1uPuJ1JrCP1883umBBm5Pf4x4Obe0yJ8s3RXWuWB80f40Kx/Qbc4CXnG
> e3rXN50E4lF76JZm4bJqzlextQ28bXRVkeCM+AeaM/nTECRHaY2QhQhAWCA2iFCC
> /amJjdQpm8fiDk1gx1hpXWeQk2eyvx3Uy4Oe9L5JgiVMFBD+4yvwqIqGcRwIxo/i
> ladOfOTiJ9d0tcYXZ9Injg4QDAtHwtmFO8nF8WVnzvPlPHiGQaOwpgtJu7aPJRt/
> +96HR/lT7VFCGmawJbsig4jbXgSQ0oxsRkJ6A+IxjCDN56wtABiyIdbu0575BU7w
> I/SjuIZ6xe9H+NFs/ZYmb5ImMiZFq2fV3Tn3ljZJrcaf1IMRQ+a2yoSgo4In5O7C
> +7H/Ru9tHCRR5J52m587
> =AHQt
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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] USRP FPGA code

Hi, I was trying to get the code from ettus git repository, but without success.

Is anyone else having trouble with this? And where I can get the code?


Euripedes

[Discuss-gnuradio] python/digital examples and UHD

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi list,

over the weekend I spend some time trying to update the demos to work
with the UHD, I just started playing with git, so if you see something
stupid let me know ;-)

I put what I got on (in the uhd-examples branch):

git@github.com:mfischer/gnuradio-mfischer.git

However the part where it 'automagically' picks rx/tx bitrates is not
really working as I have no idea how to detect what device I'm talking
to. Also please note that as I don't have the right values for bitrates
and samples_per_symbol don't be surprised if the examples crash ;-)

The old generic_usrp.py had ranges for the possible decimation /
interpolation factors as we don't have this in UHD I'm a bit confused on
how to continue.

I started to add a function

samp_rate_range_t get_rx_samp_rate_range()

to UHDs single_usrp_sink / multi_usrp_sink which internally would ask
the corresponding _dev for the right ranges, depending on what device
you're talking to. I still have to figure out the ranges part though.

git@github.com:mfischer/uhd-mfischer.git

As I don't really have insight into the longtime plan for UHD,
I'm not sure whether that's the way to go though...

Can someone give me any hints whether this actually makes sense?

Happy hacking,

- -Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJM82xBAAoJEOjnDXL6I0uZ4icQAJt3+Z82fs2LGRZ+4ndKVat0
DMPzRW1EN3T4EKIyAY9N4/weLwXvT5vuyKc+2i/mlPzhjS+ssJKfsnbLJNfNgK0Q
Notdvyv1ItNZtrD2/l5MpM/dyR0dwVpLJnmF6jrH0zOX0yiBdah80/YAz5ISrxtm
nKNmo0DJ/hZqWPQkklYbMrDirdLACPTzRwqh+JVJHBOOiVnoyXbmxakY2Ta1Ea+d
4BpOOV4h5daGQeC+9BKODY/aNtkemCvHBZdC3FQA/8IxnoRnJWTohT4Dyxc+Ypgo
AKOaYUGk1uPuJ1JrCP1883umBBm5Pf4x4Obe0yJ8s3RXWuWB80f40Kx/Qbc4CXnG
e3rXN50E4lF76JZm4bJqzlextQ28bXRVkeCM+AeaM/nTECRHaY2QhQhAWCA2iFCC
/amJjdQpm8fiDk1gx1hpXWeQk2eyvx3Uy4Oe9L5JgiVMFBD+4yvwqIqGcRwIxo/i
ladOfOTiJ9d0tcYXZ9Injg4QDAtHwtmFO8nF8WVnzvPlPHiGQaOwpgtJu7aPJRt/
+96HR/lT7VFCGmawJbsig4jbXgSQ0oxsRkJ6A+IxjCDN56wtABiyIdbu0575BU7w
I/SjuIZ6xe9H+NFs/ZYmb5ImMiZFq2fV3Tn3ljZJrcaf1IMRQ+a2yoSgo4In5O7C
+7H/Ru9tHCRR5J52m587
=AHQt
-----END PGP SIGNATURE-----

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

Re: [Discuss-gnuradio] Getting started and documentation beyond dialtone.py ?

On 11/29/2010 03:24 AM, Martin Braun wrote:
>
> FWIW, a lot of people think GNU Radio is hard. Personally, I find the
> hardest bit is understanding signal processing. And no tool in the world
> can make that simple. If you really know how the DSP works, getting GNU
> Radio to do thy biddings is usually fairly straightforward.
>
> Good luck!
> MB
>
>
My experience, on this list and elsewhere is that there's a perception
that SDR environments
will allow you to build a software-based radio with only the very thinnest
(or non-existent) understanding of:

o programming (whether it's Python or C++ or whatever)
o real-time systems
o RF systems in the analog world
o signal processing

I think a significant number of people get into Gnu Radio having come
from perhaps an intro course in
signal processing perhaps using Matlab or similar, and expect GnuRadio
to be a pretty-similar
experience, only with real hardware "on the ends".

They get "bitten" by the fact that at the end of the day, your signal
has to interact with the real analog
world, and they have no experience to offer guidance once the "rubber
hits the road". Simple
lab-practice concepts like the use of attenuators between a
transmitter and a receiver when you're
hard-wiring them, is not something that the purely Matlab-like world
prepares you for. When you
think of a radio *purely* as a set of abstract mathematical
operations, you can often lose sight of
the fact that there's this ugly physical universe out there as well,
and many folks encountering Gnu Radio
for the first time are also encountering a lot of different "ugly
realities" for the first time as well.

My ten cents worth...

--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

[Discuss-gnuradio] help -- how to implement transmitting periodic on/off tones

Hello:

I have a USRP2 board and a WBX daughterboard. I am trying to implement a scheme where a single-tone sine wave (at frequencies between 1 kHz and 10 kHz) is transmitted intermittently. Specifically, time is divided into intervals, defined by the user on the command line, typically of values such as 200 ms or 500 ms or 1s. When invoked, the flow graph (the Python script) would transmit nothing (all zeros) during the first time interval, then transmit the tone during the second time interval, then transmit nothing (all zeros) during the third and fourth and fifth time intervals, then transmit the tone during the sixth time interval, then transmit nothing (all zeros) during the seventh time interval, and then stop and end.

How in the world could I implement this? I feel like it'd be hard to do, but maybe it's actually easy. Would I need to use a timer in Python to set what gets transmitted at the start of each interval duration? Any help would be very much appreciated, as I am still somewhat new to GNU Radio and Python. Thanks for your help, everyone.

Steve McMahon


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

Re: [Discuss-gnuradio] Getting started and documentation beyond dialtone.py ?

I guess I can throw in a couple of pennies here...

Here at KIT we have a couple of students hacking GR-related projects,
and most of them get something running within reasonable time, provided
they've had some kind of previous programming experience.
Here's some of the advice I give them:

On Fri, Nov 26, 2010 at 01:02:19PM -0800, madengr wrote:
> 1) I'd like to get started with coding flow-graphs in Python. Is there any
> documentation that describes the Python libraries, mainly arguments to the
> functions and the algorithm details? I'm browsing through the doxygen
> documentation but it's kind of overwhelming since it's geared toward C++ and
> doesn't cover how it functions.

I guess you've read:
http://gnuradio.org/redmine/wiki/gnuradio/TutorialsWritePythonApplications

It's a wee bit old, but not wrong. However, it doesn't cover GRC.
It's good you've got GRC running, because it's a super-useful tool,
even once you're an expert, because you can just prototype stuff very quickly.

What it does explain is how to use the C++ docs for your Python dev.
Since most of the signal processing is done in C++, this is most of what
you need.
However, to understand the algorithms, quite often you simply have to
jump to the source. Don't let that discourage you: I found the GNU Radio
code simple to read most of the time.

> 2) What IDE is good for Python, specifically for use with gnuradio? I have
> dabbled a few hours with Wing IDE and I like it so far. I want something
> with a class browser and auto completion. However, I figured it would help
> (e.g. auto-completion) with the arguments to the gnuradio functions, but it
> gives no hints.

I wouldn't know how to do that, I also use very standard tools (in my
case, vim & console). Also very useful:

- ipython, an interactive python shell, where I can quickly try small
hacks
- a running browser with the autogenerated docs (that's why I haven't
tried autocompletion)
- gr_modtool.py, which helps add blocks to out-of-tree modules

> 3) I saw there was an actual gnuradio book, but looks like it was never
> published. I'd be willing to buy this in PDF or ebook format; is it
> avaiable?
>
> Anyway, for now I'm looking at the *.py that GRC generates and learning from
> that. Also looking at the examples in source tree. I'm just wondering if
> there is more documentation. Maybe it's just dive in and sink or swim; of
> course that's probably the best way to learn. I figure modifying the
> example programs to work with the UHD will teach me allot.

FWIW, a lot of people think GNU Radio is hard. Personally, I find the
hardest bit is understanding signal processing. And no tool in the world
can make that simple. If you really know how the DSP works, getting GNU
Radio to do thy biddings is usually fairly straightforward.

Good luck!
MB

--
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

Sunday, November 28, 2010

[Discuss-gnuradio] TPB scheduler fills block buffers

Hi,

I am writing an application for which I want to keep the latency to a
minimum, and this involves trying to keep the buffers between the blocks as
empty as possible. Basically, I have a source block with an element size of
512 bytes that accepts data through a public member function. If there is
no data to transmit it will produce one empty packet to keep the USRP busy.
The scheduler keeps asking for 64 items and I give it one. This goes on
until its write buffer is full. The processing latency (from the source
block to the USRP) of the first items is a few ms, but this grows to well
over a second due to the large amounts of buffered data.

Looking at the behavior of the single threaded scheduler, it seems it is
trying to keep the latency low by only requesting data from source blocks
when the other blocks fail to produce anything. However, the thread per
block scheduler does not seem to care about whether a block is a source
block or not. Is there any way I can configure it to do this? Is there any
other approach for solving this problem?

Thankful for any help,
Anton Blad

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