Monday, January 31, 2011

Re: [Discuss-gnuradio] Increasing ALSA Sampling Rate

> On 1/31/2011 4:22 PM, Marcus D. Leech wrote:
>>
>> audio_alsa_source[hw:2,1]: get_period_size failed: Invalid argument
>>
>> I think the clue is in the above.
>>
>> It looks like the device-specific driver for this hardware doesn't
>> contain the "PERIOD_SIZE" parameter
>> in the configuration description for the hardware, and Gnu Radio
>> uses that information for buffer
>> planning purposes (using it for set_output_multiple() ). Not
>> clear whether there's a fix or not, and
>> whether the fix belongs in Alsa or Gnu Radio.
>>
>
> Would this keep Gnu Radio from using the card at 1792000 but still
> allow 896000?
>
> Using this in config.conf
> [audio_alsa]
> verbose = true
>
> And setting samp_rate to 896000
>
> GRC returns this-
> PCM name: hw:1,1
> Access types:
> MMAP_INTERLEAVED YES
> MMAP_NONINTERLEAVED NO
> MMAP_COMPLEX NO
> RW_INTERLEAVED YES
> RW_NONINTERLEAVED NO
> Formats:
> S8 YES
> S16_LE YES
> Number of channels
> min channels: 1
> max channels: 1
> 1 channels YES
> Sample Rates:
> min rate: 119466 (dir = 1)
> max rate: 1792000 (dir = 0)
> 8000 NO
> 16000 NO
> 22050 NO
> 32000 NO
> 44100 NO
> 48000 NO
> 96000 NO
> 192000 NO
>
> So I would think that Gnu Radio should know about the higher rate??
> The flowgraph does execute at 896000.
>
> But, if I set samp_rate to 1792000, I get the get_period_size failed:
> Invalid argument error.
>
> Just trying to understand this stuff- still in the steep part of the
> learning curve.
>
> George
>
>
I suspect the answer lies in the bt87x kernel driver for Alsa and not in
Gnu Radio per se. Could be wrong, I haven't looked
that deeply into the audio-alsa code.

--
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] Increasing ALSA Sampling Rate

On 1/31/2011 4:22 PM, Marcus D. Leech wrote:
>
> audio_alsa_source[hw:2,1]: get_period_size failed: Invalid argument
>
> I think the clue is in the above.
>
> It looks like the device-specific driver for this hardware doesn't contain the "PERIOD_SIZE" parameter
> in the configuration description for the hardware, and Gnu Radio uses that information for buffer
> planning purposes (using it for set_output_multiple() ). Not clear whether there's a fix or not, and
> whether the fix belongs in Alsa or Gnu Radio.
>

Would this keep Gnu Radio from using the card at 1792000 but still allow
896000?

Using this in config.conf
[audio_alsa]
verbose = true

And setting samp_rate to 896000

GRC returns this-
PCM name: hw:1,1
Access types:
MMAP_INTERLEAVED YES
MMAP_NONINTERLEAVED NO
MMAP_COMPLEX NO
RW_INTERLEAVED YES
RW_NONINTERLEAVED NO
Formats:
S8 YES
S16_LE YES
Number of channels
min channels: 1
max channels: 1
1 channels YES
Sample Rates:
min rate: 119466 (dir = 1)
max rate: 1792000 (dir = 0)
8000 NO
16000 NO
22050 NO
32000 NO
44100 NO
48000 NO
96000 NO
192000 NO

So I would think that Gnu Radio should know about the higher rate?? The
flowgraph does execute at 896000.

But, if I set samp_rate to 1792000, I get the get_period_size failed:
Invalid argument error.

Just trying to understand this stuff- still in the steep part of the
learning curve.

George

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

[Discuss-gnuradio] Frequency & time offset problem at low SNR region

Dear all,

I've been trying to implement a system that operates over a wide range of signal-to-noise-ratio (SNR) (e.g. -5dB ~ 30dB).

For the first step, I tried to measure bit-error-rate (BER) of QPSK at various SNRs.
I used a pn sequence to implement channel compensation and accurately measure instantaneous SNR.

At high SNR region (>10dB), everything is fine. Good SNR and good BER.

However, at low SNR region (<10dB), mpsk_receiver(Costas & MM) fails to fix the freq and time offset.
Therefore, nothing can be done in low SNR region.

Is there any way to measure SNR and BER at low SNR region?

(FYI, I'm using USRP1 and WBX with Ubuntu 10.04) 

- Minsuk Kang 

Re: [Discuss-gnuradio] Increasing ALSA Sampling Rate

On 01/31/2011 01:10 PM, George S. Williams wrote:
> Hey, Tom,
>
> Thanks for the reply. I'm not sure that it's entirely an ALSA problem.
>
> Both my aplay and snd-bt88x are patched to allow 1792000. If I do-
> arecord -D hw:1,1 -r 1792000 -f S16_LE -t wav -d 5 test0.wav
>
>

audio_alsa_source[hw:2,1]: get_period_size failed: Invalid argument

I think the clue is in the above.

It looks like the device-specific driver for this hardware doesn't contain the "PERIOD_SIZE" parameter
in the configuration description for the hardware, and Gnu Radio uses that information for buffer
planning purposes (using it for set_output_multiple() ). Not clear whether there's a fix or not, and
whether the fix belongs in Alsa or Gnu Radio.

>
>


--
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] Increasing ALSA Sampling Rate

On Mon, Jan 31, 2011 at 1:10 PM, George S. Williams <ra@websterling.com> wrote:
> Hey, Tom,
>
> Thanks for the reply. I'm not sure that it's entirely an ALSA problem.
>
> Both my aplay and snd-bt88x are patched to allow 1792000. If I do-
> arecord -D hw:1,1 -r 1792000 -f S16_LE -t wav -d 5 test0.wav
>
> I get-
> Recording WAVE 'test0.wav' : Signed 16 bit Little Endian, Rate 1792000 Hz,
> Mono
>
> And- soxi reports-
> Input File     : 'test0.wav'
> Channels       : 1
> Sample Rate    : 1.792e+06
> Precision      : 16-bit
> Duration       : 00:00:05.00 = 8960000 samples ~ 375 CDDA sectors
> Sample Encoding: 16-bit Signed Integer PCM
>
> So it looks to me like ALSA recorded at 1792000.
>
> Wish I knew more about ALSA and gnuradio- probably will before it's over.
>
> George

Ok, gotcha. Then I'll reword what I said; it must be a problem with
how we are using ALSA :)

Like I said, though, this is not my area of expertise, so I'm hoping
someone else with more knowledge of the ALSA API can help out.

Tom

> On 1/31/2011 10:30 AM, Tom Rondeau wrote:
>>
>> On Thu, Jan 27, 2011 at 11:38 AM, George S. Williams<ra@websterling.com>
>>  wrote:
>>>
>>> Is it possible to increase the maximum sampling rate for audio_alsa?
>>>
>>> I am experimenting with using a modified TV tuner card as an ADC. The
>>> card
>>> uses a Bt878a chipset. arecord can record from the card at 1972000 rate
>>> and
>>> GRC shows the maximum rate as 1972000, but GNUradio can only sample at
>>> 896000.
>>>
>>> Running GNUradio at 1972000 rate gives the following error-
>>>
>>>
>>> audio_alsa_source[hw:2,1]: get_period_size failed: Invalid argument
>>> Traceback (most recent call last):
>>>  File "/root/top_block.py", line 81, in<module>
>>>    tb = top_block()
>>>  File "/root/top_block.py", line 49, in __init__
>>>    self.audio_source_0 = audio.source(samp_rate, "hw:2,1", True)
>>>  File "/usr/local/lib/python2.6/site-packages/gnuradio/audio_alsa.py",
>>> line
>>> 241, in source
>>>    return _audio_alsa.source(*args, **kwargs)
>>> RuntimeError: audio_alsa_source
>>>
>>>
>>> Is there some setting change that can enable the 1792000 rate?
>>>
>>> Thanks,
>>> George
>>
>>
>> George,
>> It appears that this error is occurring in the ALSA asound library
>> itself (see line 205 of gr-audio-alsa/src/audio_alsa_source.cc). I
>> haven't spent much time looking around the alsa implementation, so I
>> can't say for certain, but this appears to be a problem with ALSA, not
>> GNU Radio.
>>
>> Hopefully, someone else with much more knowledge about ALSA and it's
>> capabilities can tell you better.
>>
>> Tom
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.872 / Virus Database: 271.1.1/3414 - Release Date: 01/31/11
>> 02:34:00
>>
>
>
> _______________________________________________
> 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] USRP2 transmission issues

>
> Hy Matt, I know the Nyquist theorem :-D , but here the problem is not as
> simple as that. The problem is that changing the interpolation, the
> bandwidth of the signal sent by USRP2 and displayed on spectrum analyzer
> does not change. Not only that, the displayed signal is not stable at all.
>
> I tried everything but the result is always the same. Please help me. :-(
>
> Bye!!

What command are you using? What command line options? What software
versions? What OS?

Matt

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

Re: [Discuss-gnuradio] USRP E100 problem installing python-lxml

Achilleas -

Have you updated your repo trees?:

-----------------
# opkg update
-----------------

My repos show python-lxml packages:

-----------------
usrp-e1xx:/home/bhilburn/# opkg list | grep python-lxml
python-lxml - 2.2.6-r0.9 - Powerful and Pythonic XML processing
library combining libxml2/libxslt with the ElementTree API.
python-lxml-dbg - 2.2.6-r0.9 - Powerful and Pythonic XML processing
library combining libxml2/libxslt with the ElementTree API.
python-lxml-dev - 2.2.6-r0.9 - Powerful and Pythonic XML processing
library combining libxml2/libxslt with the ElementTree API.
-----------------

Also, for the future, you should probably direct these kinds of
questions to the USRP users list, since this doesn't really have
anything to do with GNU Radio =)

http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Cheers,
Ben


On Mon, Jan 31, 2011 at 11:46 AM, Achilleas Anastasopoulos
<anastas@umich.edu> wrote:
>
> # opkg install python-lxml
>
> says the package does not exist...
>
> are we supposed to build it from source?
>
> thanks
> Achilleas
>
> _______________________________________________
> 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] N210 firmware

On Mon, 2011-01-31 at 17:49 +0000, Philip Apus wrote:
> Hi,
>
> I have N210 and latest UHD (downloaded 20110129) from GIT.
> I have downloaded firmware from:
> http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/UHD-images-002.20110122035832.cd5631f-Linux.zip
>
> But I get:
>
> user@user-desktop:~/gnuradio/uhd/host/utils$ uhd_find_devices
> linux; GNU C++ version 4.4.5; Boost_104000;
> UHD_002.20110127203211.8a62a20
> Warning:
> Ignoring discovered device
> Expected protocol compatibility number 8, but got 7:
> The firmware build is not compatible with the host code build.
> Warning:
> Ignoring discovered device
> Expected protocol compatibility number 8, but got 7:
> The firmware build is not compatible with the host code build.
> No UHD Devices Found
>

Have you updated the firmware and FPGA images with the image burner? Did
the image burner indicate a successful upgrade? The error message you're
seeing indicates it's still running the older firmware and FPGA images.

--n

> Thanks,
> Philip
>
>
>
> _______________________________________________
> 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] N210 firmware

Hi,

I have N210 and latest UHD (downloaded 20110129) from GIT.
I have downloaded firmware from:
http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/UHD-images-002.20110122035832.cd5631f-Linux.zip

But I get:

user@user-desktop:~/gnuradio/uhd/host/utils$ uhd_find_devices
linux; GNU C++ version 4.4.5; Boost_104000; UHD_002.20110127203211.8a62a20
Warning:
    Ignoring discovered device
    Expected protocol compatibility number 8, but got 7:
    The firmware build is not compatible with the host code build.
Warning:
    Ignoring discovered device
    Expected protocol compatibility number 8, but got 7:
    The firmware build is not compatible with the host code build.
No UHD Devices Found

Thanks,
Philip


Just to confirm, you did use:

usrp_n2xx_net_burner.py

To load the new images into the N210, and reboot the N210?



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


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

Re: [Discuss-gnuradio] Increasing ALSA Sampling Rate

Hey, Tom,

Thanks for the reply. I'm not sure that it's entirely an ALSA problem.

Both my aplay and snd-bt88x are patched to allow 1792000. If I do-
arecord -D hw:1,1 -r 1792000 -f S16_LE -t wav -d 5 test0.wav

I get-
Recording WAVE 'test0.wav' : Signed 16 bit Little Endian, Rate 1792000
Hz, Mono

And- soxi reports-
Input File : 'test0.wav'
Channels : 1
Sample Rate : 1.792e+06
Precision : 16-bit
Duration : 00:00:05.00 = 8960000 samples ~ 375 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM

So it looks to me like ALSA recorded at 1792000.

Wish I knew more about ALSA and gnuradio- probably will before it's over.

George

On 1/31/2011 10:30 AM, Tom Rondeau wrote:
> On Thu, Jan 27, 2011 at 11:38 AM, George S. Williams<ra@websterling.com> wrote:
>> Is it possible to increase the maximum sampling rate for audio_alsa?
>>
>> I am experimenting with using a modified TV tuner card as an ADC. The card
>> uses a Bt878a chipset. arecord can record from the card at 1972000 rate and
>> GRC shows the maximum rate as 1972000, but GNUradio can only sample at
>> 896000.
>>
>> Running GNUradio at 1972000 rate gives the following error-
>>
>>
>> audio_alsa_source[hw:2,1]: get_period_size failed: Invalid argument
>> Traceback (most recent call last):
>> File "/root/top_block.py", line 81, in<module>
>> tb = top_block()
>> File "/root/top_block.py", line 49, in __init__
>> self.audio_source_0 = audio.source(samp_rate, "hw:2,1", True)
>> File "/usr/local/lib/python2.6/site-packages/gnuradio/audio_alsa.py", line
>> 241, in source
>> return _audio_alsa.source(*args, **kwargs)
>> RuntimeError: audio_alsa_source
>>
>>
>> Is there some setting change that can enable the 1792000 rate?
>>
>> Thanks,
>> George
>
>
> George,
> It appears that this error is occurring in the ALSA asound library
> itself (see line 205 of gr-audio-alsa/src/audio_alsa_source.cc). I
> haven't spent much time looking around the alsa implementation, so I
> can't say for certain, but this appears to be a problem with ALSA, not
> GNU Radio.
>
> Hopefully, someone else with much more knowledge about ALSA and it's
> capabilities can tell you better.
>
> Tom
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.872 / Virus Database: 271.1.1/3414 - Release Date: 01/31/11 02:34:00
>


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

[Discuss-gnuradio] N210 firmware

Hi,

I have N210 and latest UHD (downloaded 20110129) from GIT.
I have downloaded firmware from:
http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/UHD-images-002.20110122035832.cd5631f-Linux.zip

But I get:

user@user-desktop:~/gnuradio/uhd/host/utils$ uhd_find_devices
linux; GNU C++ version 4.4.5; Boost_104000; UHD_002.20110127203211.8a62a20
Warning:
    Ignoring discovered device
    Expected protocol compatibility number 8, but got 7:
    The firmware build is not compatible with the host code build.
Warning:
    Ignoring discovered device
    Expected protocol compatibility number 8, but got 7:
    The firmware build is not compatible with the host code build.
No UHD Devices Found

Thanks,
Philip


Re: [Discuss-gnuradio] USRP2 transmission issues

On 01/31/2011 11:51 AM, nyquist82 wrote:
> I do not understand what you mean by "proper" bandwidth. And what are these
> "proper" USRP2 `s bandwidth? Thanks anyway for your reply.
>
The allowable bandwidths for the USRP2 are in the range 100Msps /
([4...512]). The
FPGA *do not do* fractional interpolation/decimation. The rate that
is presented to the
USRP2 must be an integer fraction of the basic DAC/ADC rate.

It's also vastly preferable that the interpolation rate be even, and
it's better if it's
a multiple of 4.


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

On 1/31/11 11:51 AM, nyquist82 wrote:
>
> I do not understand what you mean by "proper" bandwidth. And what are these
> "proper" USRP2 `s bandwidth? Thanks anyway for your reply.

The USRP2 runs at 100 Msamples/sec. There is no integer decimation
factor that will yield exactly 8 Msamples/sec for an 8 MHz bandwidth.

100 / 12 = 8.33333...

100 / 13 = 7.69230769


@(^.^)@ Ed

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

Re: [Discuss-gnuradio] USRP2 transmission issues

I do not understand what you mean by "proper" bandwidth. And what are these
"proper" USRP2 `s bandwidth? Thanks anyway for your reply.

Marcus D. Leech wrote:
>
> On 01/31/2011 09:35 AM, nyquist82 wrote:
>>
>> Hy Matt, I know the Nyquist theorem :-D , but here the problem is not as
>> simple as that. The problem is that changing the interpolation, the
>> bandwidth of the signal sent by USRP2 and displayed on spectrum analyzer
>> does not change. Not only that, the displayed signal is not stable at
>> all.
>>
>> I tried everything but the result is always the same. Please help me. :-(
>>
>> Bye!!
>>
> You said that your recording is at 8MHz bandwidth (8Msps complex). Since
> 8Msps isn't a "proper" bandwidth for the USRP2, you'll have to up-sample
> to a proper (10MHz) rate before you send it to the USRP2, and select
> the appropriate interpolation ratio. You'd have to specify an
> interpolation
> value of 10.
>
>
>
>
>
> --
> 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-transmission-issues-tp30776517p30808373.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 E100 problem installing python-lxml

# opkg install python-lxml

says the package does not exist...

are we supposed to build it from source?

thanks
Achilleas

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

Re: [Discuss-gnuradio] Increasing ALSA Sampling Rate

On Thu, Jan 27, 2011 at 11:38 AM, George S. Williams <ra@websterling.com> wrote:
> Is it possible to increase the maximum sampling rate for audio_alsa?
>
> I am experimenting with using a modified TV tuner card as an ADC. The card
> uses a Bt878a chipset. arecord can record from the card at 1972000 rate and
> GRC shows the maximum rate as 1972000, but GNUradio can only sample at
> 896000.
>
> Running GNUradio at 1972000 rate gives the following error-
>
>
> audio_alsa_source[hw:2,1]: get_period_size failed: Invalid argument
> Traceback (most recent call last):
>  File "/root/top_block.py", line 81, in <module>
>    tb = top_block()
>  File "/root/top_block.py", line 49, in __init__
>    self.audio_source_0 = audio.source(samp_rate, "hw:2,1", True)
>  File "/usr/local/lib/python2.6/site-packages/gnuradio/audio_alsa.py", line
> 241, in source
>    return _audio_alsa.source(*args, **kwargs)
> RuntimeError: audio_alsa_source
>
>
> Is there some setting change that can enable the 1792000 rate?
>
> Thanks,
> George


George,
It appears that this error is occurring in the ALSA asound library
itself (see line 205 of gr-audio-alsa/src/audio_alsa_source.cc). I
haven't spent much time looking around the alsa implementation, so I
can't say for certain, but this appears to be a problem with ALSA, not
GNU Radio.

Hopefully, someone else with much more knowledge about ALSA and it's
capabilities can tell you better.

Tom

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

Re: [Discuss-gnuradio] USRP2 transmission issues

On 01/31/2011 09:35 AM, nyquist82 wrote:
>
> Hy Matt, I know the Nyquist theorem :-D , but here the problem is not as
> simple as that. The problem is that changing the interpolation, the
> bandwidth of the signal sent by USRP2 and displayed on spectrum analyzer
> does not change. Not only that, the displayed signal is not stable at all.
>
> I tried everything but the result is always the same. Please help me. :-(
>
> Bye!!
>
You said that your recording is at 8MHz bandwidth (8Msps complex). Since
8Msps isn't a "proper" bandwidth for the USRP2, you'll have to up-sample
to a proper (10MHz) rate before you send it to the USRP2, and select
the appropriate interpolation ratio. You'd have to specify an
interpolation
value of 10.

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

Matt Ettus wrote:
>
> On 01/27/2011 03:44 AM, nyquist82 wrote:
>>
>> Hi!! I am trying to transmit a complex signal with the USRP2+WBX system.
>> First I tried transmitting from file, an 8MHz band recorded with the
>> USRP2,
>> by connecting the "from file" block to the USRP2 transmitter, with and
>> appropriate interpolation.
>> When visualizing the output on a spectrum analyzer I can see that the
>> USRP2
>> is transmitting a very narrow bell-shaped signal band and on the sides
>> what
>> seem to be harmonics of the center signal.
>> Changing the interpolation on the usrp2 seems to affect the bandwidth of
>> the
>> central signal (the smaller the interpolation the larger the bandwidth).
>> Any ideas on where I'm going wrong?
>
> Dear nyquist82,
>
> You are not setting the proper sampling rate. Changing the
> interpolation rate changes the sampling rate and thus the bandwidth.
> This relationship was first proved by your namesake many years ago.
>
> Matt
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

Hy Matt, I know the Nyquist theorem :-D , but here the problem is not as
simple as that. The problem is that changing the interpolation, the
bandwidth of the signal sent by USRP2 and displayed on spectrum analyzer
does not change. Not only that, the displayed signal is not stable at all.

I tried everything but the result is always the same. Please help me. :-(

Bye!!
--
View this message in context: http://old.nabble.com/USRP2-transmission-issues-tp30776517p30807112.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

Sunday, January 30, 2011

[Discuss-gnuradio] why in low_pass cutoff_freq is CENTER of transition band whereas in low_pass_2 cutoff_freq is BEGINNING of transition band

The  low_pass and  low_pass_2 logic are almost the same. I can't see any different usage of cutoff_freq
in this two function. So why the parameter cutoff_freq have different meaning in this two function.

Thanks!

Re: [Discuss-gnuradio] question about xlating filter and resample filter

Thanks Tom.


On Mon, Jan 31, 2011 at 1:04 AM, Tom Rondeau <trondeau1122@gmail.com> wrote:
On Sat, Jan 29, 2011 at 10:23 PM, James Jordan
<james.jordan.fun@gmail.com> wrote:
> Hi all, I use xlating filter get baseband data from a wide band signal, but
> the xlating result sample
> rate is not what I want, so I need to use resample to convert the signal to
> the sample rate what I
> want. I find gr_rational_resampler_base_ccc also need a filter(tap). I
> already filter the baseband signal
> so how should I set the resampler filter(tap)?
>
> Thanks!


The easiest thing to do is use blks2.rational_resampler_ccc(I, D).
This is a  wrapper around gr.rational_resampler_base_ccc, but if you
don't pass it the taps and just the interpolation and decimation
values, it will design a filter for you that is the width of the
passband.

If you are using the git code (master or next), you can also use
blks2.pfb_arb_resampler(rate) where the rate is the real number
resampling rate you want. It, too, will automatically generate the
filter for you if you don't specify one.

Tom

Re: [Discuss-gnuradio] Is it possible to make sub-micro seconds level timing control?

> In UHD, is it possible to give a nano second level timing control in
> timed_tx samples
> sample?

It is possible to specify times to the precision of the FPGA clock. See
http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html


> I think that is possible due to the restriction from OS,


Timed transmission is supported by the FPGA for all USRP models with the
exception of USRP1 classic:
http://www.ettus.com/uhd_docs/manual/html/usrp1.html#missing-and-emulated-features


-josh

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

[Discuss-gnuradio] Is it possible to make sub-micro seconds level timing control?

Hello,

I have a quick question.

In UHD, is it possible to give a nano second level timing control in timed_tx samples sample?
I think that is possible due to the restriction from OS, 
but I saw some consistent difference in the transmission when I gave timed delay as

1.000000100, 1.000000200, and 1.000000210



Re: [Discuss-gnuradio] TPB Scheduler - Block Scheduling Rate

Michael -

I greatly appreciate the response, and yes, your post was helpful.

Hopefully I'll come back with some good news before too long =)

Cheers,
Ben


On Fri, Jan 28, 2011 at 10:07 PM, Michael Dickens <mlk@alum.mit.edu> wrote:
> On Jan 28, 2011, at 2:23 PM, Ben Hilburn wrote:
>> As I understand it, there is code in the GNURadio scheduler stuff that
>> manages block scheduling, to some degree.
>>
>> I'm aware of the kernel's role in switching between the threads
>> themselves, but I was under the impression that block scheduling, was
>> at least in some part, influenced by GNU Radio.
>>
>> If this is incorrect though, someone please correct me!
>
> Yes, this is true, Ben.  The OS handles the basics of thread execution, but the TPB scheduler does handle "when" a block's "general_work" method is actually called.  See gnuradio-core/src/lib/runtime, files "gr_tpb_thread_body.cc" (which for the most part is a simple loop calling the block executor and neighbor blocks when things change) and "gr_block_executor.cc" (which is where the meat of what you're looking for it, I believe).  For the latter, you can set ENABLE_LOGGING to 1, which should give you an idea of what the "decision process" is.
>
> I think the general idea goes roughly like this: When data in a given buffer changes (whether through generated or consumed items), each block that is associated with that buffer checks to see if there is "enough" input data and output buffer space for a "reasonable sized" computation.  If not, then go back and wait for buffers to change; if so, then do the computation (call "general_work").  You'll need to look through the code to determine what "enough" and "reasonable sized" mean -- looking at the debug log might help as well.
>
> It's been a long time since I've thought about these algorithms, so hopefully the above is reasonably correct.  And, I hope this helps! - MLD
>
>

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

Re: [Discuss-gnuradio] question about xlating filter and resample filter

On Sat, Jan 29, 2011 at 10:23 PM, James Jordan
<james.jordan.fun@gmail.com> wrote:
> Hi all, I use xlating filter get baseband data from a wide band signal, but
> the xlating result sample
> rate is not what I want, so I need to use resample to convert the signal to
> the sample rate what I
> want. I find gr_rational_resampler_base_ccc also need a filter(tap). I
> already filter the baseband signal
> so how should I set the resampler filter(tap)?
>
> Thanks!


The easiest thing to do is use blks2.rational_resampler_ccc(I, D).
This is a wrapper around gr.rational_resampler_base_ccc, but if you
don't pass it the taps and just the interpolation and decimation
values, it will design a filter for you that is the width of the
passband.

If you are using the git code (master or next), you can also use
blks2.pfb_arb_resampler(rate) where the rate is the real number
resampling rate you want. It, too, will automatically generate the
filter for you if you don't specify one.

Tom

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

Saturday, January 29, 2011

[Discuss-gnuradio] question about xlating filter and resample filter

Hi all, I use xlating filter get baseband data from a wide band signal, but the xlating result sample
rate is not what I want, so I need to use resample to convert the signal to the sample rate what I
want. I find gr_rational_resampler_base_ccc also need a filter(tap). I already filter the baseband signal
so how should I set the resampler filter(tap)?

Thanks!

Re: [Discuss-gnuradio] UHD graph for simple FFT

Hi Marcus,

The file is unavailable.

Nick

On Fri, Jan 28, 2011 at 4:30 PM, Marcus D. Leech <mleech@ripnet.com> wrote:
Here's a simple UHD FFT flow-graph that is reasonably dynamically-configurable:

http://www.srbac.org/files/uhd_fft.grc

Cheers

Yeah, because I'm a goofy guy who can't type :-)

http://www.sbrac.org/files/uhd_fft.grc


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

Re: [Discuss-gnuradio] UHD graph for simple FFT

Hi Marcus,

The file is unavailable.

Nick

On Fri, Jan 28, 2011 at 4:30 PM, Marcus D. Leech <mleech@ripnet.com> wrote:
Here's a simple UHD FFT flow-graph that is reasonably dynamically-configurable:

http://www.srbac.org/files/uhd_fft.grc

Cheers

--
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] SDR Radio Telescope Receiver

Hi Jeff,

I'm interested to learn about Joe's hydraulic antenna pointing system.
Do you know how he handles the feedback, ie what kind of sensors
is he using to "know" the antenna position?

At the moment we're trying to use Pololu Jrk as a low cost motor control
with feedback
http://www.pololu.com/catalog/product/1393
and
http://www.pololu.com/catalog/product/1392

Patrik

----- Original Message -----
From: "Jeff Kelly" <jkelly@bellatlantic.net>
To: <Discuss-gnuradio@gnu.org>
Sent: Saturday, January 29, 2011 20:39
Subject: Re: [Discuss-gnuradio] SDR Radio Telescope Receiver


>I have been working with Joe K5SO on the OpenHPSDR project
> using two Mercury receivers for diversity reception. I mention
> Joe because he is using his system for Radio Astronomy:
> Perhaps there would something on his site.
>
> http://www.k5so.com/
>
> Jeff
> K2SDR
>
>
> -----Original Message-----
> From: Marcus D. Leech Sent: Saturday, January 29, 2011 12:52 PM To: Phil
> Behnke ; Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] SDR
> Radio Telescope Receiver
> On 01/29/2011 12:37 PM, Phil Behnke wrote:
>> Thanks for the tips! I'm definitely going to investigate hooking the
>> ADC directly to the FX2. Looks like there are some inexpensive dev
>> boards for the FX2 on ebay, although I have no idea how good they are.
>> I figure I will try to develop the receiver to always grab 1MHz worth
>> of bandwidth, and then give the user finer filtering abilities by
>> using digital filters on the PC side.
>>
> That's probably a reasonable approach. The FX2 is actually a
> fairly-capable chip. It's used in the
> USRP1 from Ettus Research, which can "pump" upto 16Msps(complex,
> 8-bit) over USB-2.0,
> so 1Msps should be more than doable.
>
> You have to make certain that your I and Q lines are low-pass filtered,
> fairly stiffly, prior to sampling.
> If you're sampling at 1Msps, the I and Q lines need to be low-pass
> filtered to 500KHz. There's a nice
> passive-filter designer on-line at:
>
> http://www.wa4dsy.net/filter/filterdesign.html
>
> I've used it for other radio astronomy projects in the past
>
> Other things to keep in mind:
>
> o you'll need enough low-noise gain ahead of the down-converter to
> make up for the
> *terrible* noise figure that's typical of mixers and ADCs. At
> HF, in radio astronomy, you'll
> probably need about 50dB.
>
> o You'll need a good bandpass filter at RF. Again, the
> above-mentioned site should help here. A
> good approach is to use a amp-filter/amp-filter/amp-filter
> topology, which gives you distributed gain
> and filtering, and makes the individual filter stages
> manageable. If you designed your bandpass
> RF filter for an Fc of 20Mhz, and bandwidth of 5Mhz or so, it'll
> improve your usable dynamic
> range, and prevent driving your gain stages into compression,
> due to "other muck" that your
> antenna will inevitably "see".
>
>
>
>
>
> --
> 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 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] SDR Radio Telescope Receiver

On 01/29/2011 01:24 PM, Phil Behnke wrote:
Thanks again, Marcus!  Do you suggest breaking the signal up into I and Q via analog mixing and having two ADCs (one for I and one for Q)?  I was thinking about mixing down to DC and sampling with a single ADC, and then breaking the signal up into I and Q digitally on the PC side.  I've been looking at the Mercury SDR ( http://openhpsdr.org/wiki/index.php?title=MERCURY) and that seems like what they do, only they have a digital down converter in the FPGA which beaks the signal into I and Q.

-Phil
If you want to convert to I and Q in an FPGA, you need to use a conventional IF architecture that brings
  it into the range of the ADC sampling rate.  If you convert to DC in "real" mode, you lose
  phase information and have the problem of "folding" about DC.

Use an analog approach to generating I & Q.  The simplest is to use a so-called 2XLO approach, in
  which you generate a 50%-duty-cycle square wave at exactly twice the desired Fc, feed that to
  a pair of D flip-flops to produce two signals at exactly half the frequency, and exactly 90 degrees
  out-of-phase with respect to each other.  Then use a pair of mixers to produce the converted
  I & Q signals.  Use a dual-channel ADC, like the AD9288 -- only $8.00 apiece for 40Msps, and
  you can likely find cheaper dual-channel ADCs for only 1 or 2Msps.  The FX2 FIFO is 16-bits wide,
  so if you use a dual-channel 8-bit ADC, you don't have to play any interleaving games into
  the FX2.

Here's an article on a 2XLO approach here, see figure 4:

rfdesign.com/mag/606RFDF3.pdf

Since your input frequency would be around 40MHz, you could use pretty-ordinary CMOS gates
  and flip-flops to do this--nothing exotic like ECL logic required.


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

Re: [Discuss-gnuradio] SDR Radio Telescope Receiver

I have been working with Joe K5SO on the OpenHPSDR project
using two Mercury receivers for diversity reception. I mention
Joe because he is using his system for Radio Astronomy:
Perhaps there would something on his site.

http://www.k5so.com/

Jeff
K2SDR


-----Original Message-----
From: Marcus D. Leech
Sent: Saturday, January 29, 2011 12:52 PM
To: Phil Behnke ; Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] SDR Radio Telescope Receiver

On 01/29/2011 12:37 PM, Phil Behnke wrote:
> Thanks for the tips! I'm definitely going to investigate hooking the
> ADC directly to the FX2. Looks like there are some inexpensive dev
> boards for the FX2 on ebay, although I have no idea how good they are.
> I figure I will try to develop the receiver to always grab 1MHz worth
> of bandwidth, and then give the user finer filtering abilities by
> using digital filters on the PC side.
>
That's probably a reasonable approach. The FX2 is actually a
fairly-capable chip. It's used in the
USRP1 from Ettus Research, which can "pump" upto 16Msps(complex,
8-bit) over USB-2.0,
so 1Msps should be more than doable.

You have to make certain that your I and Q lines are low-pass filtered,
fairly stiffly, prior to sampling.
If you're sampling at 1Msps, the I and Q lines need to be low-pass
filtered to 500KHz. There's a nice
passive-filter designer on-line at:

http://www.wa4dsy.net/filter/filterdesign.html

I've used it for other radio astronomy projects in the past

Other things to keep in mind:

o you'll need enough low-noise gain ahead of the down-converter to
make up for the
*terrible* noise figure that's typical of mixers and ADCs. At
HF, in radio astronomy, you'll
probably need about 50dB.

o You'll need a good bandpass filter at RF. Again, the
above-mentioned site should help here. A
good approach is to use a amp-filter/amp-filter/amp-filter
topology, which gives you distributed gain
and filtering, and makes the individual filter stages
manageable. If you designed your bandpass
RF filter for an Fc of 20Mhz, and bandwidth of 5Mhz or so, it'll
improve your usable dynamic
range, and prevent driving your gain stages into compression,
due to "other muck" that your
antenna will inevitably "see".

--
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 mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] SDR Radio Telescope Receiver

On 01/29/2011 12:37 PM, Phil Behnke wrote:
> Thanks for the tips! I'm definitely going to investigate hooking the
> ADC directly to the FX2. Looks like there are some inexpensive dev
> boards for the FX2 on ebay, although I have no idea how good they are.
> I figure I will try to develop the receiver to always grab 1MHz worth
> of bandwidth, and then give the user finer filtering abilities by
> using digital filters on the PC side.
>
Don't know whether you've seen these:

http://www.knjn.com/ShopBoards_USB2.html

$79.95 for the low-end board, which includes and FX2, and a small
Cyclone FPGA. Pretty good
value.

--
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] SDR Radio Telescope Receiver

On 01/29/2011 12:37 PM, Phil Behnke wrote:
> Thanks for the tips! I'm definitely going to investigate hooking the
> ADC directly to the FX2. Looks like there are some inexpensive dev
> boards for the FX2 on ebay, although I have no idea how good they are.
> I figure I will try to develop the receiver to always grab 1MHz worth
> of bandwidth, and then give the user finer filtering abilities by
> using digital filters on the PC side.
>
That's probably a reasonable approach. The FX2 is actually a
fairly-capable chip. It's used in the
USRP1 from Ettus Research, which can "pump" upto 16Msps(complex,
8-bit) over USB-2.0,
so 1Msps should be more than doable.

You have to make certain that your I and Q lines are low-pass filtered,
fairly stiffly, prior to sampling.
If you're sampling at 1Msps, the I and Q lines need to be low-pass
filtered to 500KHz. There's a nice
passive-filter designer on-line at:

http://www.wa4dsy.net/filter/filterdesign.html

I've used it for other radio astronomy projects in the past

Other things to keep in mind:

o you'll need enough low-noise gain ahead of the down-converter to
make up for the
*terrible* noise figure that's typical of mixers and ADCs. At
HF, in radio astronomy, you'll
probably need about 50dB.

o You'll need a good bandpass filter at RF. Again, the
above-mentioned site should help here. A
good approach is to use a amp-filter/amp-filter/amp-filter
topology, which gives you distributed gain
and filtering, and makes the individual filter stages
manageable. If you designed your bandpass
RF filter for an Fc of 20Mhz, and bandwidth of 5Mhz or so, it'll
improve your usable dynamic
range, and prevent driving your gain stages into compression,
due to "other muck" that your
antenna will inevitably "see".

--
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] LD_LIBRARY_PATH root question

Aha, thanks!

Lots to learn....

Patrik

----- Original Message -----
From: "Tom Rondeau" <trondeau1122@gmail.com>
To: "Patrik Tast" <patrik@poes-weather.com>; "GNURadio Discussion List"
<discuss-gnuradio@gnu.org>
Sent: Saturday, January 29, 2011 17:28
Subject: Re: [Discuss-gnuradio] LD_LIBRARY_PATH root question


On Fri, Jan 28, 2011 at 8:41 AM, Patrik Tast <patrik@poes-weather.com>
wrote:
> Hi All,
>
> I use fedora 9-13.
> I've setup the USERNAME/.bashrc to point at python and other shared
> libraries, all works fine as USERNAME.
>
> My question is: If I login as USERNAME, then in terminal su root and start
> a GR py it will fail due to it can't find some libraries (boost).
> I must always do an export first
>
> Where do I declare LD_LIBRARY_PATH properly for root (or any user) access
> at
> startup?
> At the moment I've declared paths in /root/.bash_profile, but when
> rebooted
> it complains and an export is needed to shared library path:s inorder to
> run
> GR
>
> Patrik

If you have to su, you can pass it the -p (or -m) flag and that will
preserve your environment (see man su; there's a restriction on PATH
when doing this).

You should also be able to edit /etc/bash.bashrc (might be different
in Fedora, but something similar should be there) to make common
environments shared among all users.

Tom


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

Re: [Discuss-gnuradio] LD_LIBRARY_PATH root question

On Fri, Jan 28, 2011 at 8:41 AM, Patrik Tast <patrik@poes-weather.com> wrote:
> Hi All,
>
> I use fedora 9-13.
> I've setup the USERNAME/.bashrc to point at python and other shared
> libraries, all works fine as USERNAME.
>
> My question is: If I login as USERNAME, then in terminal su root  and start
> a GR py it will fail due to it can't find some libraries (boost).
> I must always do an export first
>
> Where do I declare LD_LIBRARY_PATH properly for root (or any user) access at
> startup?
> At the moment I've declared paths in /root/.bash_profile, but when rebooted
> it complains and an export is needed to shared library path:s inorder to run
> GR
>
> Patrik

If you have to su, you can pass it the -p (or -m) flag and that will
preserve your environment (see man su; there's a restriction on PATH
when doing this).

You should also be able to edit /etc/bash.bashrc (might be different
in Fedora, but something similar should be there) to make common
environments shared among all users.

Tom

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

Re: [Discuss-gnuradio] SDR Radio Telescope Receiver

> Hi Marcus:
> FX2 dev kit at $475 ????????
> hardly inexpensive to get started, unless there's a cheaper one out there.
> Limited free dev software too, cost more for more than 4k code size???
> Don
>
When I investigated it a couple of years ago, cheaper dev kits were
available.

Also, you can use the SDCC open-source compiler to generate code for it. No
need to buy an expensive commercial devkit for it. The USRP1
firmware was
done with SDCC, and it works fine.


--
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] Spectrum distortion in wideband OFDM samples

Sorry for my last post on this thread which contained nothing new
(mistake). A new comment on thread from my side at the bottom.


On Fri, 2011-01-28 at 15:10 -0800, Matt Ettus wrote:
> On 01/28/2011 02:44 PM, Per Zetterberg wrote:
> > On Fri, 2011-01-28 at 02:09 -0500, Sangho Oh wrote:
> >> Hello, I am transmitting 20Mhz OFDM symbols using UHD code.
> >> When I checked the PSD of the received samples using UHD
> >> (rx_samples_to_file)
> >> I found there is a significant difference in PSD between the
> >> transmitted and received signal.
> >>
> >>
> >> Reception decimation is 4 and I used re-sampled data (4/5) for OFDM
> >> demodulation.
> >> Here is the figure showing the PDS difference.
> >>
> >>
> >> http://i1181.photobucket.com/albums/x423/notilas/untitled.jpg
> >>
> >>
> >> Someone guessed that this is a natural thing related to the low pass
> >> filter in RF parts of Gnuradio.
> >> However, I would like to ask valuable comments from radio experts.
> >>
> >
> >
> > The spectrum looks very strange so I would guess saturation or
> > something.
>
>
> Yes, it does look very saturated. Remember, OFDM has a very high peak
> to average ratio.
>
>
> >
> > However, I have had some experiences I would like to discuss. I have
> > experimented with OFDM waveforms on USRP1, USRP2 and also another
> > home-brewed testbed. What I generally find is that an oversampling of a
> > factor of two is required. Thus with 25MHz sample-rate I can squeeze in
> > a maximum 12.5MHz signal. I can use more but at the expense of much
> > worse performance. I think the main problem is nonlinearities. The
> > nonlinearities causes intermods. If the sampling frequency is less than
> > twice the bandwidth, 3rd order intermods will fold into the desired
> > signal.
>
> Intermod is not affected by sample rate because intermod only happens on
> analog signals (assuming you don't have digital clipping), and the
> signals are only converted to/from analog at the maximum sample rate.
>

I forgot that original the sample-rate is higher. But if the digital
filtering in the FPGA is insufficient (not enough attenuation of
sidebands) the problem persists - because the intermods (which
originates from the analog side) will get folded into the desired at the
final decimation.


BR/
Per

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

RE: [Discuss-gnuradio] Spectrum distortion in wideband OFDM samples

________________________________________
From: Matt Ettus [matt@ettus.com]
Sent: Saturday, January 29, 2011 12:10 AM
To: Per Zetterberg
Cc: Sangho Oh; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Spectrum distortion in wideband OFDM samples

On 01/28/2011 02:44 PM, Per Zetterberg wrote:
> On Fri, 2011-01-28 at 02:09 -0500, Sangho Oh wrote:
>> Hello, I am transmitting 20Mhz OFDM symbols using UHD code.
>> When I checked the PSD of the received samples using UHD
>> (rx_samples_to_file)
>> I found there is a significant difference in PSD between the
>> transmitted and received signal.
>>
>>
>> Reception decimation is 4 and I used re-sampled data (4/5) for OFDM
>> demodulation.
>> Here is the figure showing the PDS difference.
>>
>>
>> http://i1181.photobucket.com/albums/x423/notilas/untitled.jpg
>>
>>
>> Someone guessed that this is a natural thing related to the low pass
>> filter in RF parts of Gnuradio.
>> However, I would like to ask valuable comments from radio experts.
>>
>
>
> The spectrum looks very strange so I would guess saturation or
> something.


Yes, it does look very saturated. Remember, OFDM has a very high peak
to average ratio.


>
> However, I have had some experiences I would like to discuss. I have
> experimented with OFDM waveforms on USRP1, USRP2 and also another
> home-brewed testbed. What I generally find is that an oversampling of a
> factor of two is required. Thus with 25MHz sample-rate I can squeeze in
> a maximum 12.5MHz signal. I can use more but at the expense of much
> worse performance. I think the main problem is nonlinearities. The
> nonlinearities causes intermods. If the sampling frequency is less than
> twice the bandwidth, 3rd order intermods will fold into the desired
> signal.

Intermod is not affected by sample rate because intermod only happens on
analog signals (assuming you don't have digital clipping), and the
signals are only converted to/from analog at the maximum sample rate.

What you may be seeing is aliasing, which will be noticeable when you
try to make your signal wider than 75% of the sample rate.

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

Friday, January 28, 2011

Re: [Discuss-gnuradio] TPB Scheduler - Block Scheduling Rate

On Jan 28, 2011, at 2:23 PM, Ben Hilburn wrote:
> As I understand it, there is code in the GNURadio scheduler stuff that
> manages block scheduling, to some degree.
>
> I'm aware of the kernel's role in switching between the threads
> themselves, but I was under the impression that block scheduling, was
> at least in some part, influenced by GNU Radio.
>
> If this is incorrect though, someone please correct me!

Yes, this is true, Ben. The OS handles the basics of thread execution, but the TPB scheduler does handle "when" a block's "general_work" method is actually called. See gnuradio-core/src/lib/runtime, files "gr_tpb_thread_body.cc" (which for the most part is a simple loop calling the block executor and neighbor blocks when things change) and "gr_block_executor.cc" (which is where the meat of what you're looking for it, I believe). For the latter, you can set ENABLE_LOGGING to 1, which should give you an idea of what the "decision process" is.

I think the general idea goes roughly like this: When data in a given buffer changes (whether through generated or consumed items), each block that is associated with that buffer checks to see if there is "enough" input data and output buffer space for a "reasonable sized" computation. If not, then go back and wait for buffers to change; if so, then do the computation (call "general_work"). You'll need to look through the code to determine what "enough" and "reasonable sized" mean -- looking at the debug log might help as well.

It's been a long time since I've thought about these algorithms, so hopefully the above is reasonably correct. And, I hope this helps! - MLD


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

Re: [Discuss-gnuradio] TI vs Freescale DSP for open-source development

Don-

> Hi Jeff: interesting reply. I remember when TI and MOT did exactly the
> opposite. TI had the 9900 processor series that was much better than
> anything on the market, and essentially blew it off. MOT had the
> 6800/68000 series, that became moderately successful. The most crippled
> processor of the time, the Intel, won the day. Now the TI processors
> thrive, MOT is in the dumper, and Intel is king of the heap. A real riot
> to watch history as it happens, huh? Think also of the lovely alpha chip,
> and the downfall of mighty DEC. sigh.

Yes things look much different years after the heat of the battle. Clarity is gained in small increments.

I know some of the TI execs from the early 1980s (in fact one works with me, he was Gen Mgr of Consumer Products at
the time). The general conclusion is that TI guys learned a hard lesson with the 9900 and applied it well over time.
They never ventured forth again without solid development tools and other supporting software. But on the other hand
they took nearly 10 years to support Linux after major players started embracing it... oh well.

-Jeff


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

Re: [Discuss-gnuradio] SDR Radio Telescope Receiver

> Hello All,
>
> I'm currently an undergraduate engineering student at Grand Valley
> State University. For my senior design project, I'm working on
> designing a SDR-based radio telescope to compliment the NASA RadioJove
> project (a direct conversion receiver for use in radio astronomy).
>
> In a nutshell, the receiver must be able to receive an AM signal with
> a center frequency of 20.1MHz and a bandwidth of 1MHz. On the
> software side of things, we need to be able to plot signal strength as
> a function of time and frequency in real time. We are planning to use
> analog mixing to get an IF centered around 500kHz and 1MHz bandwidth.
> The IF would then be sampled that with a 14-bit ADC clocked around
> 4MHz. The output of the ADC would then be sent to some kind of
> controller (ie. FPGA, microcontroller, etc) which would do a little
> bit of digital down converting to get the signal into its I and Q
> centered around DC and send it over USB to the host PC.
>
> While I am not completely against using an FPGA in the design of our
> receiver, I would really like to use a fast microcontroller, PSoC, or
> similar device as I have much more experience programming in C than I
> do in HDL. Has anyone hear of a SDR receiver with 1MHz bandwidth
> using a microcontroller? I was thinking along the lines of using a
> ARM Cortex M3 chip with high clock frequency (~80MHz), DMA, and
> external ADC clocked around 4MHz, but I'm not sure if the ARM chip
> would be fast enough to down convert all that data and send it over
> USB quickly enough. If anyone has links to resources where this kind
> of thing has been done that would be awesome.
>
> I'm very new to SDR development so any input would be greatly appreciated.
>
> Thanks!
> Phil
A few comments:

check out the gr-radio-astronomy sub-tree. It's old, but should still
function.

What you might consider doing, if you're committed to building your own
hardware, is a direct-conversion receiver, perhaps with a fixed
LO at 20.1MHz, and then sample with a 1MSps ADC, feeding an FX2 for
USB-2.0. No need for an FPGA, provided you never want to
change sample rates before the signal gets to the host PC.

The FX2 uController/USB-2.0 interface is very common, very inexpensive
hardware, and has a nice FIFO interface that's easy to interface
to ADC hardware.

Another thing to keep in mind, is that your *usable* bandwidth around
20.1MHz is likely to only be a few 10s of KHz, due to lots of
interference down there. So your 1MHz bandwidth may be utterly wasted.

For narrowband stuff, you might consider something like the SoftRock
series of direct-conversion receivers, or the UHFSDR.
The UHFSDR tunes from DC to 700MHz, and gives a 96KHz
bandpass--perfect for audio. Combine the UHFSDR with the SDR-Widget,
and you have a pretty-complete narrowband platform.


--
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] TI vs Freescale DSP for open-source development

Hi Jeff: interesting reply. I remember when TI and MOT did exactly the
opposite. TI had the 9900 processor series that was much better than
anything on the market, and essentially blew it off. MOT had the
6800/68000 series, that became moderately successful. The most crippled
processor of the time, the Intel, won the day. Now the TI processors
thrive, MOT is in the dumper, and Intel is king of the heap. A real riot
to watch history as it happens, huh? Think also of the lovely alpha chip,
and the downfall of mighty DEC. sigh.
Don


--
"Neither the voice of authority nor the weight of reason and argument are
as significant as experiment, for thence comes quiet to the mind."
R. Bacon
"If you don't know what it is, don't poke it."
Ghost in the Shell


Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com


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

Re: [Discuss-gnuradio] Spectrum distortion in wideband OFDM samples

On 01/28/2011 02:44 PM, Per Zetterberg wrote:
> On Fri, 2011-01-28 at 02:09 -0500, Sangho Oh wrote:
>> Hello, I am transmitting 20Mhz OFDM symbols using UHD code.
>> When I checked the PSD of the received samples using UHD
>> (rx_samples_to_file)
>> I found there is a significant difference in PSD between the
>> transmitted and received signal.
>>
>>
>> Reception decimation is 4 and I used re-sampled data (4/5) for OFDM
>> demodulation.
>> Here is the figure showing the PDS difference.
>>
>>
>> http://i1181.photobucket.com/albums/x423/notilas/untitled.jpg
>>
>>
>> Someone guessed that this is a natural thing related to the low pass
>> filter in RF parts of Gnuradio.
>> However, I would like to ask valuable comments from radio experts.
>>
>
>
> The spectrum looks very strange so I would guess saturation or
> something.


Yes, it does look very saturated. Remember, OFDM has a very high peak
to average ratio.


>
> However, I have had some experiences I would like to discuss. I have
> experimented with OFDM waveforms on USRP1, USRP2 and also another
> home-brewed testbed. What I generally find is that an oversampling of a
> factor of two is required. Thus with 25MHz sample-rate I can squeeze in
> a maximum 12.5MHz signal. I can use more but at the expense of much
> worse performance. I think the main problem is nonlinearities. The
> nonlinearities causes intermods. If the sampling frequency is less than
> twice the bandwidth, 3rd order intermods will fold into the desired
> signal.

Intermod is not affected by sample rate because intermod only happens on
analog signals (assuming you don't have digital clipping), and the
signals are only converted to/from analog at the maximum sample rate.

What you may be seeing is aliasing, which will be noticeable when you
try to make your signal wider than 75% of the sample rate.

Matt

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

Re: [Discuss-gnuradio] Spectrum distortion in wideband OFDM samples

On Fri, 2011-01-28 at 02:09 -0500, Sangho Oh wrote:
> Hello, I am transmitting 20Mhz OFDM symbols using UHD code.
> When I checked the PSD of the received samples using UHD
> (rx_samples_to_file)
> I found there is a significant difference in PSD between the
> transmitted and received signal.
>
>
> Reception decimation is 4 and I used re-sampled data (4/5) for OFDM
> demodulation.
> Here is the figure showing the PDS difference.
>
>
> http://i1181.photobucket.com/albums/x423/notilas/untitled.jpg
>
>
> Someone guessed that this is a natural thing related to the low pass
> filter in RF parts of Gnuradio.
> However, I would like to ask valuable comments from radio experts.
>


The spectrum looks very strange so I would guess saturation or
something.

However, I have had some experiences I would like to discuss. I have
experimented with OFDM waveforms on USRP1, USRP2 and also another
home-brewed testbed. What I generally find is that an oversampling of a
factor of two is required. Thus with 25MHz sample-rate I can squeeze in
a maximum 12.5MHz signal. I can use more but at the expense of much
worse performance. I think the main problem is nonlinearities. The
nonlinearities causes intermods. If the sampling frequency is less than
twice the bandwidth, 3rd order intermods will fold into the desired
signal.

Another observation is that, given that I have the luxury of two times
oversampling (or more), it is better to use an fft on all the samples
and null (don't use) some of the subcarriers, than do up/downsampling
after/before the fft. I don't why, but I guess that it would not be very
hard to prove it with maths.

I wish I had a reference on these issues (conference, journal-paper or
book). Most papers are ignoring all these practical issues ....


BR/
Per

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

[Discuss-gnuradio] SDR Radio Telescope Receiver

Hello All,

I'm currently an undergraduate engineering student at Grand Valley State University.  For my senior design project, I'm working on designing a SDR-based radio telescope to compliment the NASA RadioJove project (a direct conversion receiver for use in radio astronomy).

In a nutshell, the receiver must be able to receive an AM signal with a center frequency of 20.1MHz and a bandwidth of 1MHz.  On the software side of things, we need to be able to plot signal strength as a function of time and frequency in real time.  We are planning to use analog mixing to get an IF centered around 500kHz and 1MHz bandwidth.  The IF would then be sampled that with a 14-bit ADC clocked around 4MHz.  The output of the ADC would then be sent to some kind of controller (ie. FPGA, microcontroller, etc) which would do a little bit of digital down converting to get the signal into its I and Q centered around DC and send it over USB to the host PC.

While I am not completely against using an FPGA in the design of our receiver, I would really like to use a fast microcontroller, PSoC, or similar device as I have much more experience programming in C than I do in HDL.  Has anyone hear of a SDR receiver with 1MHz bandwidth using a microcontroller?  I was thinking along the lines of using a ARM Cortex M3 chip with high clock frequency (~80MHz), DMA, and external ADC clocked around 4MHz, but I'm not sure if the ARM chip would be fast enough to down convert all that data and send it over USB quickly enough.  If anyone has links to resources where this kind of thing has been done that would be awesome.

I'm very new to SDR development so any input would be greatly appreciated.

Thanks!
Phil

Re: [Discuss-gnuradio] TI vs Freescale DSP for open-source development

Alexander-

> okay here are my 2 cents
>
> 2- TI actually offers all the tools you need to develop for their DSP for free, I can vouch for the C64x+ DSP since
> that's what I have experience using. You can download and look at the supported DSP for the free download from
> http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/
>
>
> The biggest issue you might run into with the free software is the ability to use a JTAG, if you want to use a JTAG
> you have to use Code Composer period. Though I've read about people using the free demo version of Code Composer
> (CCS) 4.0 with a very cheap JTAG ( < $150) to debug their DSP code. I think TI restricts the type of DSPs and JTAGs
> you can use with the free CCS I know that the JTAG I use (XDS560) is not supported.
>
> 3- TI support for open source is surprisingly decent. I've posted many questions on their support forums and TI
> engineers have always gotten back to me with alot of good information and continued asnwering as posted more follow up
> questions.
>
> 4- The learning tool has a bit of a learning curve that's for sure. I have posted a github link on the listserv
> yesterday which includes new custom blocks for GNU Radio using the C64x+ DSP. You might find the guide helpful in
> shedding some light about developing with TI tools.
>
> 6- I've been using TI software as an open source developer for almost 1.5 years now and I think they've managed to
> find a great balance between being a for profit company and a supplier of tools for the open source community. I
> don't have experience with freescale but my experience with TI has been a positive one.

We are a heavy TI device user and have been for years. Al Fayez's comments are pretty much accurate.

I would add a few additional comments for MSC8x5x vs. C667x; i.e. high performance multicore CPUs (the vendors are
moving away from the term "DSPs" nowadays, hehe). My comments apply *only* to these high-end multicore devices.

My two major concerns with Freescale are a) peer support and b) product roadmap. First, there simply are not enough
users. For example there is a motoroladsp Yahoo Group (there are several TI DSP Yahoo groups, C6x, C5x, etc) but in
the last several years activity on the mot group has slowly died off. There are still knowledgeable Mot/Freescale DSP
guys on comp.dsp, but mostly in audio/acoustic related areas.

Second, product roadmap. Before they were Freescale, Mot used to have a strong, competitive product portfolio in DSP.
In 1998 they started a downhill slide when their CEO re-organized his own DSP guys into an "internal resource
matrix", essentially deciding there wasn't actually a DSP market. Obviously TI thought otherwise and became "a DSP
company" and we all know the rest of that story. (As a side note, that CEO was Hector Ruiz, the same guy who later
presided over AMD during its decline and is now subject to an SEC investigation). In 2004, Mot DSPs became Freescale
and enjoyed a resurgence with Starcore based devices. Starcore technology has always looked quite promising, but in
my opinion, in day-to-day execution Freescale has not been able to match TI. Now TI has out the C667x series, which
leaps beyond MSC815x/MSC825x.

Not to mention that TI's multicore CPUs benefit indirectly, both in terms of technical advances, and in terms of
customer support, from what TI is doing in smart phones, tablets, high-performance ARM, etc.

-Jeff

> -----Original Message-----
> From: Alexander Chemeris <alexander.chemeris@gmail.com>
> To: Gnuradio-discuss <discuss-gnuradio@gnu.org>
> Sent: Fri, Jan 28, 2011 10:24 am
> Subject: [Discuss-gnuradio] TI vs Freescale DSP for open-source development
>
>
> Hello all,
>
> We're working on an open-source WiMAX receiver/scanner and we're
> looking into using a high-performance DSP to process data from USRP.
> Right now we implement this processing in FPGA, but we want to
> experiment with DSPs too. I know there are skilled people here and I'm
> looking forward to hear their opinion.
>
> Note, that this project is not meant for starving students or
> occasional hobbyists. It is for high-profile hobbyists, targeted
> researchers and for small companies. So please refrain from comments
> like "no way, this is too expensive for 90% of community". Though we
> would appreciate comments on how to make it cheaper.
>
> So, I'm looking for the community advise about pros and cons of
> different DSPs. Particularly I'm interested in comparing Freescale
> MSC815x/MSC825x [1][2][3] and TI TMS320C667x [4][5] DSPs/SoCs from the
> perspective of open-source development. But if you know any other good
> high-profile DSPs - please propose them too. So far, as I read it we
> have following comparison:
>
> 1) Price.
> It used to be that Freescale is cheaper, but right now I see that
> "pricing for the MSC8156 starts at $192 in 10,000 unit quantities"
> [6], while TMX320C6670CYP is priced 160.00 USD | 1ku [7]. So they're
> barely the same with TI slightly winning. I'm not sure how much will
> new MSC8157 cost.
>
> 2) Development tools price
> Both Freescale CodeWarrior and TI Code Composer seem to be at the same
> line with about $2K per single license (correct me if I'm wrong - I
> may have missed something easily).
>
> Big minus here is that neither Freescale nor TI offer open/free
> compilers for their DSPs, which is a big roadblock for open-source
> development.
>
> 3) Support for open-source technologies.
> Well, both Freescale and TI declare themselves as more or less
> open-source supporters (which is weird while they have expensive
> development tools). Both offers BSPs for Linux for GPP part of SoCs
> and free/open OSes for DSP cores (SmartDSP for Freescale, SYS/BIOS for
> TI). I would appreciate if someone could comment on maturity of those
> and their usability (bug-ness level).
>
> Other then that I don't see any evidence of their support for
> open-source for their DSPs.
>
> 4) Quality/simplicity
> I have no experience with those DSPs yet, so I would very much
> appreciate comments about development tools quality / easy to use,
> code generation quality, DSP architecture simplicity for a programmer
> and (important!) documentation quality.
>
> 5) Chips availability
> I'm a software guy, so again I seek for an insight about availability
> of Freescale and TI DSPs. How hard is it to source them? Especially
> outside of US?
>
> 6) Any other concerns?
> Please share your opinion - I should have missed something important.
> It's hard to keep everything in mind.
>
> PS As I told, we're working on an open-source WiMAX receiver right
> now. If you're a skilled engineer and you're willing to participate -
> drop me a few lines with your experience description. We need more
> skilled hands to get up and running faster. And I should say this
> project is a *lot* of fun.
> PPS Please don't mail me if you just want to look into the code out of
> curiosity or don't have enough skills or enough time to help. We'll
> announce the project publicly when we have a (somehow) working
> prototype. Right now we just have a bunch of Matlab proof-of-concept
> code and we've started to port it to FPGA.
>
> Thank you if you get that far! Sorry for the long e-mail :)
>
> 1. http://www.freescale.com/webapp/sps/site/homepage.jsp?code=STARCORE_HOME
> 2. http://www.bdti.com/InsideDSP/2010/12/16/Freescale
> 3. http://www.bdti.com/InsideDSP/2010/05/20/Freescale
> 4. http://focus.ti.com/dsp/docs/dspcontent.tsp?contentId=77428&DCMP=nysh_101109&HQS=Other+PR+c66multicore-tcipr-lp
> 5. http://www.bdti.com/InsideDSP/2010/11/18/Ti
> 6. http://www.eetimes.com/electronics-products/processors/4108765/Freescale-reboots-base-station-DSPs-leapfrogs-TI
> 7. http://focus.ti.com/docs/prod/folders/print/tms320c6670.html
>
> --
> Regards,
> Alexander Chemeris.
> http://www.fairwaves.ru
>
> _______________________________________________
> 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] USRP2 transmission issues

On 01/27/2011 03:44 AM, nyquist82 wrote:
>
> Hi!! I am trying to transmit a complex signal with the USRP2+WBX system.
> First I tried transmitting from file, an 8MHz band recorded with the USRP2,
> by connecting the "from file" block to the USRP2 transmitter, with and
> appropriate interpolation.
> When visualizing the output on a spectrum analyzer I can see that the USRP2
> is transmitting a very narrow bell-shaped signal band and on the sides what
> seem to be harmonics of the center signal.
> Changing the interpolation on the usrp2 seems to affect the bandwidth of the
> central signal (the smaller the interpolation the larger the bandwidth).
> Any ideas on where I'm going wrong?

Dear nyquist82,

You are not setting the proper sampling rate. Changing the
interpolation rate changes the sampling rate and thus the bandwidth.
This relationship was first proved by your namesake many years ago.

Matt

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

[Discuss-gnuradio] UHD graph for simple FFT

Here's a simple UHD FFT flow-graph that is reasonably
dynamically-configurable:

http://www.srbac.org/files/uhd_fft.grc

Cheers

--
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] Quick-and-dirty GNU Radio (Geeko powered!)

Hello,

When you build GNU Radio for the first time successfully (after twenty
times calling ./configure, until you have all the dependencies), you get
a sense of pleasure. Maybe, this initial overhead is desired, as it
prevents the community from noobs without the iron will of getting GNU
Radio running. Personally, I don't think it's that difficult.

GNU Radio itself provides an Ubuntu repository, but it doesn't seem to
be maintaned (last modified in Oct 2009). So some time ago, I started to
package GNU Radio for my own system.

I've used the openSUSE Build Service [1] for almost a year, and -- after
some initial overhead -- it has been working like a charm for me. But as
I won't use GNU Radio for the next term, I can't keep the repository
updated any longer. You can find the repository under [2] and you are
invited to clone, branch, and maintain that repo.

A few notes:
- The package "gnuradio" is used to build the latest stable release
(gnuradio-3.3.0) and the "next" release. The sources are fetched and the
spec-files are updated by the script gnuradio-next_update.sh. But as
there are a few patches to get an package according to the openSUSE
packaging guidelines, you can't always update the package with the
following steps. Sometimes, you have to adapt the patches:
1) sh gnuradio-next_update.sh
2) osc rm gnuradio-next-<old>.tar.bz2
3) osc add gnuradio-next-<new>.tar.bz2
4) osc vc # Edit the changelog
5) osc ci -m 'update'
- Both, gnuradio and gnuradio-next, have their files in the gnuradio
repository. The gnuradio-next package is only a link onto the gnuradio
package, so that the OBS uses the gnuradio-next.spec instead of the
gnuradio.spec.
- When I startet the packaging process, OBS didn't provide the feature
to create a tar-ball from a git repository. This feature was implemented
in the meanwhile. Nevertheless, the gnuradio-next_update.sh,
gnuradio_update.sh and libuhd_update.sh scripts are more flexible, as
they extract some information from the meta information located in the
git repository.
- The last build I've used _productively_ (with USRP2) was based on an
checkout from October or November.
- I've just updated to the current HEAD and resolved some building
errors (I had to adapt the patch-file for the package gnuradio-next, and
meanwhile, libuhd.so changed to libuhd.so.002, so that package needed a
rename, too).
- I haven't minded new features implemented since October or November
(e.g. VOLK compiled successfully, but I didn't test it).

If you have already an openSUSE 11.3 installation and you just want to
play with GNU Radio, just add the download repository to zypper / yast:
# zypper ar -f
http://download.opensuse.org/repositories/home:/chkpnt:/gnuradio/openSUSE_11.3/home:chkpnt:gnuradio.repo
# zypper in gnuradio-next
You'll need gnuradio-next-devel, too, if you want to compile your own
blocks against GNU Radio. I've tested the packages with a clean
installation within a VM and it worked for me. Nevertheless, I want to
mention that the last time I used the packages productively (with USRP2)
was two / three months ago.

With SUSE Studio it is very simple to build an appliance based on RPMs
[3]. I've composed a GNU Radio appliance that can be found in the SUSE
Gallery [4]. There is a Live-CD / USB-Stick, if you just want to try out
GNU Radio on a new system. And there is a VMware-Appliance, if you want
to use GNU Radio in parallel to your existing operating system. I have
used this VMware approach since UHD works fine, as I have mainly worked
under Windows (had very disappointing experience with Xilinx ISE 10
under openSUSE... maybe, ISE 12 is running better...). To download, you
have to sign in (OpenID like Google is supported). Nevertheless, as I
don't know how long SUSE Gallery stores the appliances, they are
mirrored on [5], too.

Cheers, and have fun,
Gregor


[1] http://build.opensuse.org
[2] https://build.opensuse.org/project/show?project=home:chkpnt:gnuradio
[3] http://www.susestudio.com
[4] http://susegallery.com/a/MjwCkX/gnu-radio--2
[5] http://www.dschung.de/gnuradio/


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