Re: [Discuss-gnuradio] Issue with Virtual Sink/Source

[Richard Clarke]

Hi,

I'm having the same issue as Khalid. I just updated my GNU Radio source
based installation on two different machines. On one of the machines I
previously had a source installation of gnuradio 3.7.4. This machine runs
Linux Mint 17.1, the other machine runs Ubuntu 14.04. A flow graph
utilising virtual sources and sinks that ran fine under gnuradio and
gnuradio-companion 3.7.4 now throws up the same error as Khalid has pointed
out, on both my Linux Mint and Ubuntu machines.

Anyone else seeing this behaviour? Any ideas?

Thanks

Cheers
Richard

On 6 January 2015 at 05:57, khalid.el-darymli 
wrote:

> Hi,
>
> We recently bought a new PC with some powerful specs. GNU Radio was built
> from the source and it seems to be installed fine. However, when I try to
> use the virtual sink and source blocks in my flow graph, I am getting the
> following error:
>
> Traceback (most recent call last):
>   File "./test_skh.py", line 595, in 
> tb = test_skh()
>   File "./test_skh.py", line 486, in __init__
> self.connect((self.virtual_source_0, 0),
> (self.blocks_multiply_conjugate_cc_0, 0))
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line
> 93, in __getattr__
> return getattr(self._impl, name)
> *AttributeError: 'top_block_sptr' object has no attribute
> 'virtual_source_0'*
>
>
> Once I replace the virtual blocks with direct connections, things work
> just fine. What is the cause for this problem and how to fix it?
>
> Please note that on an older machine, GNU Radio was installed around a
> month ago following the same procedure followed here, and the virtual
> sink/source blocks work just fine.
>
> Thank you.
>
> Best regards,
> Khalid
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
*SCOTT ADAMS: Normal people believe that if it ain't broke, don't fix it.
Engineers believe that if it ain't broke, it doesn't have enough features
yet.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Rayleigh fading simulator

[Richard Clarke]

Hi Nasi,

when I checked the fading models supplied in GNU Radio 3.7 the other week
they seemed to be generating nasty glitches in their output. You could
instead take a look at 'my' custom block for doing simple single path
configurable doppler Rayleigh fading. The output of this has been
statistically validated against the theoretical Rayleigh distribution. I
can provide further details of the validations that have been done if
required. There is a version of the block for both GNURadio 3.6 and 3.7
API's. This block works fine when instantiated singly, however if you try
and build a multipath fading model out of it by instantiating more than one
of these blocks (with delays) at the python level then the whole thing
tends to seg fault, for as yet undetermined reasons.

You are welcome to give it a try however.

Here is the link to the GNU Radio 3.7 version of the block,
https://github.com/hawk2050/gr-rccBlocks

Feedback welcome

Cheers
Richard


On 3 March 2014 06:25, Nasi  wrote:

> Martin,
>
> it is so simple, I try to explain again:
>
> my question is how you add Doppler to the channel (the code)?
>
> Different people add it in a different way like using FIR or IIR filters.
> So, I am wondering if you used IIR filter or FIR. If you know of course,
> how you coded it?
>
>
>
> Воскресенье, 2 марта 2014, 15:26 +01:00 от Martin Braun <
> martin.br...@ettus.com>:
>
>   On 03/01/2014 04:35 PM, Nasi wrote:
> > Helo all,
> >
> > I need your help for simulation of the Rayleigh fading.
> > I know that I can use GNURADIO channel models, but I need to know how
> > they simulated.
> > For example I am looking into the 'fading_model_impl.cc' in channel
> > models of GNURADIO.
> > Can someone tell me how this is simulated?
>
> Can you specify what you want to do? I don't understand the question.
> If you connect this block to your signal, it will "simulate" the channel.
>
> > I heard some people also developed it on their own, but I am not sure if
> > that is available and supported by you.
>
> Developed their own what? Channels?
> You can configure these channels to different types of scenarios.
>
> M
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> --
> NE
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
*SCOTT ADAMS: Normal people believe that if it ain't broke, don't fix it.
Engineers believe that if it ain't broke, it doesn't have enough features
yet.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New Product Announcements from Ettus Research

[Richard Clarke]

Hi Matt,

just wondering what the PPM spec is of the onboard TCXO? Will the datasheet
be available soon?

Thanks

Regards
Richard

On 4 October 2011 10:05, Matt Ettus  wrote:

>
> =
>
> New Product Announcements from Ettus Research
>
> =
>
> We are very excited to announce the immediate availability of the
> latest low cost Software Radio product from Ettus Research, the
> USRP(tm) B100.  The B100 has the following features:
>
> - USB 2.0 interface
> - Xilinx Spartan 3A-1400 FPGA
> - Compatibility with our entire daughterboard family
> - Fully supported by UHD drivers
> - Dual 64 MS/s 12-bit ADCs
> - Dual 128 MS/s 14-bit DACs
> - Onboard TCXO for precise frequency control
> - 10 MHz and 1 PPS inputs for external references
> - Flexible clocking from 10 MHz to 64 MHz
> - 8 MHz of RF bandwidth with 16 bit samples
> - 16 MHz of RF bandwidth with 8 bit samples
>
>
> The price is $650 each, and the B100 is in stock and ready to ship.
>
> =
>
> The USRP E110 has a larger FPGA (Spartan 3A-DSP 3400) than
> the E100, but is otherwise the same.  This is perfect for those who
> wish to offload DSP operations from the main ARM processor.
>
> Both the E100 and E110 are now fully compatible with the GPSDO.
>
> The price of the USRP E110 is $1500 and the E100 is $1300.
> Both the E100 and E110 are in stock and ready to ship.
>
> =
>
> As always, you can purchase all of our products through:
>
> http://www.ettus.com/order
>
> and you can contact sa...@ettus.com if you have any further
> questions.
>
> Thanks,
> Matt Ettus
> President, Ettus Research LLC
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
*SCOTT ADAMS: Normal people believe that if it ain't broke, don't fix it.
Engineers believe that if it ain't broke, it doesn't have enough features
yet.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio-companion GUI sinks don't scale to laptop screen resolution

[Richard Clarke]

Hi Alex,

yes, thanks for that info. That is the solution that I settled on in the
interim, it just means that applications are not as portable as I would
like, e.g building an application on a desktop PC with a larger screen and
then transferring to a laptop to be used at a presentation somewhere.
However, I can work around this as it's not a common scenario, for me
anyway.

Cheers
Richard

On 21 July 2011 19:46, Alex DEKKER  wrote:

> On Thu, 21 Jul 2011 11:01:13 +1200, Richard Clarke wrote:
>
>  If for example I have a wx scope gui and an fft gui stacked one above
>> the other so I can see them simultaneously, the lower plot is missing
>> half of the lower portion off the bottom of the screen, i.e it doesnt
>>
>> scale itself to fit within the confines of the visible screen.
>>
>
> It may not do it dynamically, but did you know you can enter dimensions in
> the Window Size field for the scope and waterfall sink? I assume your screen
> doesn't change size too often, so it should at least get it to a point where
> it's usable for you.
>
> alexd
>
> __**_
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>



-- 
*SCOTT ADAMS: Normal people believe that if it ain't broke, don't fix it.
Engineers believe that if it ain't broke, it doesn't have enough features
yet.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gnuradio-companion GUI sinks don't scale to laptop screen resolution

[Richard Clarke]

Hi All,

does anyone know if there is a setting or configuration file I need to
modify to get gnuradio-companion to scale GUI sinks correctly for my laptop
screen resolution?
If for example I have a wx scope gui and an fft gui stacked one above the
other so I can see them simultaneously, the lower plot is missing half of
the lower portion off the bottom of the screen, i.e it doesn't scale itself
to fit within the confines of the visible screen. If I specify the Grid
Position of the two scopes so that they are next to each (left,right) I
still lose a portion off the right of my screen. Is it possible to have
these wx gui objects dynamically scale?

I'm running the latest git 3.4 version of GNU Radio.

Thanks very much.

Regards
Richard

-- 
*SCOTT ADAMS: Normal people believe that if it ain't broke, don't fix it.
Engineers believe that if it ain't broke, it doesn't have enough features
yet.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] AFC (Automatic Frequency Control) FM demo python and GRC scripts

[Richard Clarke]

Very, very useful, thanks for sharing Martin.

Cheers
Richard

On 17 March 2010 14:40, Martin DvH  wrote:

> Hi all,
>
> I wrote two gnuradio AFC (Automatic Frequency Control) demos
>
> This AFC technique can come in handy when your tuning is critical and
> there is a frequency offset or doppler shift to be expected.
> (Like when trying to receive NOAA weather satelites which can have a
> substancial doppler shift. I am also working on an updated gr-noaa
> receive script which uses this AFC. )
>
> There is a broadcast FM demo and a NOAA weathersatellite narrowband FM
> simulation demo.
>
> You can discuss and give feedback on the gnuradio AFC demo's here:
> http://www.gnuradio.eu/cms/nl/node/203
> (But feedback on the gnuradio mailinglist is also OK of course)
>
> You can read about and download the gnuradio AFC demo's here:
> http://www.olifantasia.com/projects/gnuradio/mdvh/AFC
>
> Here follows the README:
>
> Gnuradio AFC demo's
>
> This directory contains gnuradio GRC and python example scripts for
> using AFC in an FM receiver.
>
> There is not (yet) a AFC gnuradio block.
> So these examples implement the AFC by lowpass filtering the FM
> demodulator output and putting the result in a variable sink.
> The variable sink then sets the center frequency of the frequency
> translating channel filter.
> This compensates any frequency offset or doppler drift.
>
> To limit the performance penalty of calling python code from the
> samplestream, the code is only called once a second.
>
> The critical settings of this feedback loop are:
> AFC_gain (float)
> AFC_IIR_alpha (float)
> AFC_update_rate (float value: seconds between updates)
>
> If you want to use this for a different FM signal type also make sure
> you set the right channel_bandwidth and max_dev (=Maximum FM frequency
> deviation in Hertz)
>
> Have fun
>
> 17 Mar 2010
> Martin Dudok van Heel
>
> Olifantasia
>
>
>
>
>
> ___
> 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] Git HEAD build error - build environment issue?

[Richard Clarke]

OK I think I have it. I modified the LD_LIBRARY_PATH to remove reference to
my currently installed version of GNU Radio and now the build appears to be
proceeding. Thanks for the tip.

Cheers
Richard

On 23 February 2010 11:34, Richard Clarke  wrote:

>
>
>> I believe I've seen the same error message when I tried to build from
>> git while 3.2.2 was still installed. Removing 3.2.2 from the linker
>> path solved the problem for me.
>>
>> Alex
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
> Hi Alex,
>
> interesting you should say that. I do indeed have 3.2.2 installed (though I
> use the symlink method to support multiple version installs). However the
> same is true of the other PC (where the build succeeded) , although it's
> current working installed copy of gnuradio is a git HEAD as of 8 Feb.
> However that machine had 3.2.3svn version installed prior to the 8th Feb Git
> HEAD version being compiled and installed. I'm not terribly experienced at
> managing the build tools under Linux, so when you talk about the Linker
> path, how do I go about modifying that?
>
> Thanks very much.
>
> Cheers
> Richard
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Git HEAD build error - build environment issue?

[Richard Clarke]

>
> I believe I've seen the same error message when I tried to build from
> git while 3.2.2 was still installed. Removing 3.2.2 from the linker
> path solved the problem for me.
>
> Alex
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

Hi Alex,

interesting you should say that. I do indeed have 3.2.2 installed (though I
use the symlink method to support multiple version installs). However the
same is true of the other PC (where the build succeeded) , although it's
current working installed copy of gnuradio is a git HEAD as of 8 Feb.
However that machine had 3.2.3svn version installed prior to the 8th Feb Git
HEAD version being compiled and installed. I'm not terribly experienced at
managing the build tools under Linux, so when you talk about the Linker
path, how do I go about modifying that?

Thanks very much.

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

Re: [Discuss-gnuradio] Git HEAD build error - build environment issue?

[Richard Clarke]

On 23 February 2010 11:00, Johnathan Corgan
wrote:

> On Mon, Feb 22, 2010 at 13:48, Richard Clarke  wrote:
>
> > I've just built the head of the Git repo on two different machines. On
> one
> > of them it builds OK, however on my laptop I get the error shown below. I
> > had installed all dependencies for Karmic (or I believe I have) however
> this
> > must be related to my build environment in some way I guess. Does anyone
> > have any clues?
>
> For some reason, the linker cannot find libgruel.so when trying to
> link libgnuradio-core.so.
>
> Could you post the output of your ./configure run, the part that shows
> which modules will get built and which wont?
>
> Johnathan
>

Hi Johnathan,

the part of interest from the configure run is shown below. Everything
appeared to be in order.
Thanks for your help.

Richard

config.status: executing depfiles commands
*
The following components were skipped either because you asked not
to build them or they didn't pass configuration checks:

usrp2-firmware

These components will not be built.


*
The following GNU Radio components have been successfully configured:

config
gruel
omnithread
gnuradio-core
mblock
usrp
usrp2
vrt
gr-usrp
gr-usrp2
gr-msdd6000
gr-audio-alsa
gr-audio-oss
gr-atsc
gr-cvsd-vocoder
gr-gpio
gr-gsm-fr-vocoder
gr-noaa
gr-pager
gr-radar-mono
gr-radio-astronomy
gr-trellis
gr-video-sdl
gr-wxgui
gr-qtgui
gr-sounder
gr-utils
gnuradio-examples
grc
docs

You my now run the make command to build these components.

*
The following components were skipped either because you asked not
to build them or they didn't pass configuration checks:

gcell
gr-gcell
gr-audio-jack
gr-audio-osx
gr-audio-portaudio
gr-audio-windows
gr-comedi

These components will not be built.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Git HEAD build error - build environment issue?

[Richard Clarke]

Hi,

I've just built the head of the Git repo on two different machines. On one
of them it builds OK, however on my laptop I get the error shown below. I
had installed all dependencies for Karmic (or I believe I have) however this
must be related to my build environment in some way I guess. Does anyone
have any clues?

Thanks
Richard

./.libs/libgnuradio-core.so: undefined reference to
`gruel::msg_accepter::~msg_accepter()'
./.libs/libgnuradio-core.so: undefined reference to
`pmt::intrusive_ptr_release(pmt::pmt_base*)'
./.libs/libgnuradio-core.so: undefined reference to `typeinfo for
gruel::msg_accepter'
./.libs/libgnuradio-core.so: undefined reference to
`pmt::intrusive_ptr_add_ref(pmt::pmt_base*)'
collect2: ld returned 1 exit status
make[5]: *** [gnuradio-config-info] Error 1
make[5]: Leaving directory
`/home/richard/gnuradio/source/git_gnuradio-trunk/gnuradio/gnuradio-core/src/lib'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/home/richard/gnuradio/source/git_gnuradio-trunk/gnuradio/gnuradio-core/src/lib'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/richard/gnuradio/source/git_gnuradio-trunk/gnuradio/gnuradio-core/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/richard/gnuradio/source/git_gnuradio-trunk/gnuradio/gnuradio-core'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/richard/gnuradio/source/git_gnuradio-trunk/gnuradio'
make: *** [all] Error 2
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRC - wrapping a GNU Radio block that uses message_sink

[Richard Clarke]

Hi,

I have a 3rd party GNU Radio block of signal processing code that I would
like to wrap for use within GRC. This block uses a message sink (i.e a
pointer to a gnu radio message queue is passed into the block which appears
to then utilise the queue for inserting 'send frequency correction' values
to another process. I have read that GRC currently supports users creating
block wrappers for blocks with message queue IO. In the xml file I write, is
the message queue a second 'sink', i.e in addition to the standard float
stream of samples it outputs, or should it be handled in the parameter
section of the xml code? I've searched all existing standard blocks and
haven't found an example to work from. Does anyone have an example they
could share?

Or have I also got my source and sink perspectives confused and this block
should instead be a msg source? Even so, my questions above remain.

Many thanks.

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

Re: [Discuss-gnuradio] GRC and the Notebook feature - keep getting notebook id error

[Richard Clarke]

Ah huh! That is great, thanks very much!

Cheers
Richard

On 8 February 2010 13:34, Josh Blum  wrote:

> dont use the parenthesis
>
> in the fftsink block, enter my_notebook0, 0
>
> -Josh
>
>
> On 02/07/2010 02:49 PM, Richard Clarke wrote:
>
>> Hi All,
>>
>> so far I've found very little reference to this new and potentially very
>> useful feature. I'm trying to use the notebook feature of GRC 3.2.3svn to
>> allow stacking of multiple WX GUI sink elements (scopes, FFT, etc) on
>> different tabs of a Notebook. I have dragged a Notebook element into my
>> block diagram and given it the ID "my_notebook0". I have also tried to
>> enter
>> info into the Notebook field for my two GUI sinks, using the format
>> (my_notebook0, 0) to indicate that it should be placed in "my_notebook0"
>> on
>> tab 0. However the GRC dialogue box for the GUI Sink (Properties: FFT
>> Sink)
>> just highlights the field name "Notebook" in red and keeps telling me that
>> there is an   "Error: Notebook id "(my_notebook0" is not an existing
>> notebook id"
>>
>> Can someone who has this working let me know what I'm missing?
>>
>> Thanks very much.
>>
>> Cheers
>> Richard
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRC and the Notebook feature - keep getting notebook id error

[Richard Clarke]

Hi All,

so far I've found very little reference to this new and potentially very
useful feature. I'm trying to use the notebook feature of GRC 3.2.3svn to
allow stacking of multiple WX GUI sink elements (scopes, FFT, etc) on
different tabs of a Notebook. I have dragged a Notebook element into my
block diagram and given it the ID "my_notebook0". I have also tried to enter
info into the Notebook field for my two GUI sinks, using the format
(my_notebook0, 0) to indicate that it should be placed in "my_notebook0" on
tab 0. However the GRC dialogue box for the GUI Sink (Properties: FFT Sink)
just highlights the field name "Notebook" in red and keeps telling me that
there is an   "Error: Notebook id "(my_notebook0" is not an existing
notebook id"

Can someone who has this working let me know what I'm missing?

Thanks very much.

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

Re: [Discuss-gnuradio] gnuradio Python on ubuntu 9.10 install problems

[Richard Clarke]

I had the exact same problem. Have you got fort77 installed? This seems to
be a new dependency for Ubuntu 9.10. That solved my problem. Double check
the Ubuntu 9.10 install instructions for all the dependencies as there are a
couple of subtle differences from 9.04. The instructions only went up in the
last 2 or 3 days.

Cheers
Richard

2009/11/15 dave k 

> checking for python... /usr/bin/python
> checking for python version... 2.6
> checking for python platform... linux2
> checking for python script directory...
> ${prefix}/lib/python2.6/dist-packages
> checking for python extension module directory...
> ${exec_prefix}/lib/python2.6/dist-packages
> checking for Python include path... /usr/include/python2.6
> checking Python.h usability... no
> checking Python.h presence... no
> checking for Python.h... no
> configure: error: cannot find usable Python headers
> da...@laptop:~/gnuradio$
>
> but
>
> da...@laptop:~/gnuradio$ ls -la /usr/include/python2.6 | grep Python.h
> -rw-r--r--  1 root root  4384 2009-10-19 23:40 Python.h
>
> any ideas? i think i missed something but not sure
>
>
>
>
>
> ___
> 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] UDP source : can't receive broadcast UDP packets

[Richard Clarke]

Hi,

I was hoping that someone with more knowledge of the GNU Radio UDP
source block might be able to explain why it doesn't seem to receive
UDP packets that have been sent with a broadcast destination address?
If the UDP packets are targeted explicitly at the GNU Radio PC's IP
address then there is no problem. However when I broadcast the UDP
packets instead, the GNU Radio UDP source doesn't spit them out into
my flow graph. I know that they are being transmitted correctly by my
source of UDP packets as I can receive them (with broadcast address)
correctly using the standard Python socket module. Any input
appreciated.

Thanks

Regards
Richard


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

[Discuss-gnuradio] UDP source : can't receive broadcast UDP packets : SOLVED

[Richard Clarke]

OK I've answered my own question. It was a lack of familiarity on my
part with how to configure the UDP source. When wanting to receive a
broadcast UDP stream instead of binding to the local IP address of the
particular network interface being used, it is necessary to bind to
IP_ADDR_ANY, namely 0.0.0.0!

Cheers
Richard


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

Re: [Discuss-gnuradio] udp source - endianness anomaly?

[Richard Clarke]

Aha, guess I should have paid closer attention to the GNU Radio source. That
explains things then. Guess I'll implement a custom byte swapping block, as
I'd rather the PC do it than the AVR32. Thanks Josh.

Cheers
Richard

2009/10/12 Josh Blum 

>
> http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/io/gr_udp_source.cc
>
> The udp source is just memcopying bytes from the udp socket to a output
> vector, it has no concept of what the data is and therefore cant be
> byteswapping it.
>
> This may facilitate the need for a htonx block and a ntohx block for our gr
> short and int types, but the udp blocks are simple as can be; that being a
> good thing.
>
> -Josh
>
> Richard Clarke wrote:
>
>> No indeed, that's what I'm saying. The AVR32 platform is sending out
>> everything in network byte order but the GNU Radio udp source doesn't
>> appear
>> to be interpreting it from network byte order (big endian) into the host
>> byte order (little endian) correctly. My current work around to this is to
>> artificially over ride the byte ordering of the transmitted payload data
>> at
>> the transmitting AVR32 end, to compensate for the apparent problem at the
>> GNU Radio host end. I'm sure if there was really a problem with the code
>> at
>> the GNU Radio end it would have been picked up long ago, so my assumption
>> is
>> that I've missed something obvious, or I need to look more suspiciously at
>> the LWIP code (v1.3.0). However, any ideas are welcomed.
>>
>> Richard
>>
>> 2009/10/12 David I. Emery 
>>
>>  On Mon, Oct 12, 2009 at 11:16:11AM +1300, Richard Clarke wrote:
>>>
>>>> Hi All,
>>>>
>>>> I was wondering if anyone has had any issues with the interpretation of
>>>> shorts by the GNU Radio udp source function, when the shorts are
>>>> transmitted  from a big endian based platform? In my situation I am
>>>> transmitting UDP packets comprised of 16 bit samples from an AVR32 (big
>>>> endian) which utilises the LWIP open source TCP/IP stack. On my GNU
>>>> Radio
>>>> destination PC (Intel Pentium D CPU, little endian) I construct a simple
>>>> flowgraph (using GRC/GNU Radio v3.2.1) with a UDP source set to
>>>> interpret
>>>> incoming data as shorts, into the short to float block and then straight
>>>> into the GUI scope. I'm receiving the UDP packets OK which I assume
>>>> means
>>>> that all the protocol header info is being interpreted with the correct
>>>> endianness, but the waveform displayed in the scope is corrupt, until
>>>>
>>> that
>>>
>>>> is, I manually re-order the LSB and MSB of the transmitted samples at
>>>> the
>>>> AVR32 end. Normally the lower level network code would take care of byte
>>>> reordering as required to match network byte order to the relevant host
>>>>
>>> byte
>>>
>>>> order, however this doesn't appear to be happening correctly on the GNU
>>>> Radio side. I must be missing something simple here, can anyone shed
>>>> some
>>>> light?
>>>>
>>>> Is there a good reason to have packets in something other than
>>> network byte order (to match the IP headers) ?
>>>
>>>
>>> --
>>>  Dave Emery N1PRE/AE, d...@dieconsulting.com  DIE Consulting, Weston,
>>> Mass
>>> 02493
>>> "An empty zombie mind with a forlorn barely readable weatherbeaten
>>> 'For Rent' sign still vainly flapping outside on the weed encrusted pole
>>> -
>>> in
>>> celebration of what could have been, but wasn't and is not to be now
>>> either."
>>>
>>>
>>>
>>
>> 
>>
>> ___
>> 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] udp source - endianness anomaly?

[Richard Clarke]

No indeed, that's what I'm saying. The AVR32 platform is sending out
everything in network byte order but the GNU Radio udp source doesn't appear
to be interpreting it from network byte order (big endian) into the host
byte order (little endian) correctly. My current work around to this is to
artificially over ride the byte ordering of the transmitted payload data at
the transmitting AVR32 end, to compensate for the apparent problem at the
GNU Radio host end. I'm sure if there was really a problem with the code at
the GNU Radio end it would have been picked up long ago, so my assumption is
that I've missed something obvious, or I need to look more suspiciously at
the LWIP code (v1.3.0). However, any ideas are welcomed.

Richard

2009/10/12 David I. Emery 

> On Mon, Oct 12, 2009 at 11:16:11AM +1300, Richard Clarke wrote:
> > Hi All,
> >
> > I was wondering if anyone has had any issues with the interpretation of
> > shorts by the GNU Radio udp source function, when the shorts are
> > transmitted  from a big endian based platform? In my situation I am
> > transmitting UDP packets comprised of 16 bit samples from an AVR32 (big
> > endian) which utilises the LWIP open source TCP/IP stack. On my GNU Radio
> > destination PC (Intel Pentium D CPU, little endian) I construct a simple
> > flowgraph (using GRC/GNU Radio v3.2.1) with a UDP source set to interpret
> > incoming data as shorts, into the short to float block and then straight
> > into the GUI scope. I'm receiving the UDP packets OK which I assume means
> > that all the protocol header info is being interpreted with the correct
> > endianness, but the waveform displayed in the scope is corrupt, until
> that
> > is, I manually re-order the LSB and MSB of the transmitted samples at the
> > AVR32 end. Normally the lower level network code would take care of byte
> > reordering as required to match network byte order to the relevant host
> byte
> > order, however this doesn't appear to be happening correctly on the GNU
> > Radio side. I must be missing something simple here, can anyone shed some
> > light?
> >
>
> Is there a good reason to have packets in something other than
> network byte order (to match the IP headers) ?
>
>
> --
>  Dave Emery N1PRE/AE, d...@dieconsulting.com  DIE Consulting, Weston, Mass
> 02493
> "An empty zombie mind with a forlorn barely readable weatherbeaten
> 'For Rent' sign still vainly flapping outside on the weed encrusted pole -
> in
> celebration of what could have been, but wasn't and is not to be now
> either."
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] udp source - endianness anomaly?

[Richard Clarke]

Hi All,

I was wondering if anyone has had any issues with the interpretation of
shorts by the GNU Radio udp source function, when the shorts are
transmitted  from a big endian based platform? In my situation I am
transmitting UDP packets comprised of 16 bit samples from an AVR32 (big
endian) which utilises the LWIP open source TCP/IP stack. On my GNU Radio
destination PC (Intel Pentium D CPU, little endian) I construct a simple
flowgraph (using GRC/GNU Radio v3.2.1) with a UDP source set to interpret
incoming data as shorts, into the short to float block and then straight
into the GUI scope. I'm receiving the UDP packets OK which I assume means
that all the protocol header info is being interpreted with the correct
endianness, but the waveform displayed in the scope is corrupt, until that
is, I manually re-order the LSB and MSB of the transmitted samples at the
AVR32 end. Normally the lower level network code would take care of byte
reordering as required to match network byte order to the relevant host byte
order, however this doesn't appear to be happening correctly on the GNU
Radio side. I must be missing something simple here, can anyone shed some
light?

Thanks

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

Re: [Discuss-gnuradio] length of the signal in USRP_FFT display

[Richard Clarke]

I believe that what you want to do is the same as what I was trying to
achieve with the scope graphical sink, although I was using GRC as my front
end.  Josh Blum replied to my post on April 20th. The subject title of the
original post was "GRC graphical sink buffer size - how to increase?". I
believe the same advice may apply to your situation. Use version 3.2rc2 of
GNU Radio and activate the open GL mode for the graphicals sinks. See
http://gnuradio.org/trac/wiki/CompGrWxgui#GLSinks for more detail.

I followed that advice and it has worked for me. Now, if only the buffer
size for the graphical sinks could be made more dynamic, i.e selected
automatically based on the timescale selected for the particular scope, or
on a flow graph by flow graph basis.

Cheers
Richard

2009/4/23 Bruhtesfa Ebrahim 

> Hi all,
>
>
> I am trying to modify usrp_fft.py(oscilloscope mode) to display a longer
> duration of decimated data in real time. I think in the default
> oscilloscope 5msec of data is displayed(whatever the decimation rate and
> time/div is) and these length of data is updated in real time.
>
> What I want is to decrease the decimation rate to 1KS/sec(64MS/sec
> decimated by 128 in FPGA and then by 500 using decimating lowpass
> filter) and display 5sec of data and to update this 5sec of data slowly
> in real time.
>
> How can I modify the 5msec default length to 5sec?
>
>
> Bruhtesfa
> --
> Posted via http://www.ruby-forum.com/.
>
>
> ___
> 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] GRC filter tap evaluations - difference between current version and v 0.7

[Richard Clarke]

Hi All,

With version 0.7 of GRC I could enter the taps of a filter in the following
format [-23, 4, 245, 1235, 245, 4, -23]/32768 in the relevant GRC block
window  (taps field) and GRC would do the division calculation for each tap,
i.e the tap vector automatically became [-7.019e-4,1.22e-4, 7.47e-3,
3.76e-2, 7.47e-3, 1.22e-4, -7.019e-4].

Trying to do the same thing in the current version of GRC that is included
with GNU Radio 3.2rc2 results in a warning message that the tap vector
cannot be evaluated. Does anyone know how to achieve the same thing as
demonstrated above for version 0.7?
A small thing I know but most coefficients of filters that I have come as
fixed point 16 bit integers (-32768<=coeff<=32767) and doing a copy/paste is
more convenient than doing the extra calculation and then formatting the
resultant floating point vector into a copy and pasteable form for entry
into the GRC blocks.

Thanks very much.

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

Re: [Discuss-gnuradio] anyone implement the Raleighfadingmodel/multi-path?

[Richard Clarke]

Hi George,

that code is still available if you'd like me to FTP host it again.

Cheers
Richard

George Nychis wrote:


Richard Clarke wrote:
I've established a temporary (60 day) FTP user account on our company 
FTP server to host the GNU Radio Rayleigh Fading code as it currently 
stands. I've placed the raw code that's relevant to this module 
there. It's not immediately ready to build however that won't take 
long for anyone familiar with integrating user modules into GNU 
Radio. There is some other code relevant to the way we were intending 
to use the fading simulator (i.e in a client/server model across a 
network) that may be of interest to some but is not particularly 
relevant to the actual fading module itself so you can ignore that if 
you wish.


FTP details: ftp://ftp.tait.co.nz
user: gnuradio
password: gnuradio01



Hi Richard (and all),

Did anybody grab this code before the temporary FTP user account 
terminated?  I did a while back but have since lost it.  If someone 
has it, can they register an account at CGRAN and upload it?  All it 
entails is registering an account and adding the files to an SVN 
repository. (https://www.cgran.org)


I can worry about the project creation if no one else has time, but I 
think this code would be valuable.


Thanks!
George



===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

Re: [Discuss-gnuradio] VM Make Check problem : createfilemapping isnotavailable

[Richard Clarke]

Hi All,

just an update to this issue. I have managed to get the GNU Radio 
Virtual Machine talking to the USRP, at least the usrp_fft.py is 
working. The 'createfilemapping' was a red herring as Eric had mentioned 
in his reply. The real problem was that I was trying to run the VM using 
VM Server version 1.06 which is too old to support the USB2.0 interface. 
I changed to the latest VM Player (2.04) which does support USB2.0 and 
things started to work, although there may still be some issues lurking 
as the usrp_benchmark_usb.py tes hung when trying to transfer at 4MB/sec.


Cheers
Richard

Richard Clarke wrote:

Bumped

Hi All,

I have been attempting to use a GNU Radio 3.1.2 Virtual Machine (guest 
OS is Open Suse 10.2) kindly provided by Chiara De Dominicis, with the 
USRP. Initial communications with the USRP were established, enough 
for firmware download to the USRP. However when attempting to run any 
script that makes use of the USRP the following error is thrown up 
after a few seconds before the whole VM crashes into oblivion.


Terminal message output: gr_check_counting: enter_SEARCHING at 
offset0  (0x)
 gr_vmcircbuf_createfilemapping: 
createfilemapping is not available


Now, I've also created my own Ubuntu 8.04 VM with GNURadio 3.1.2 built 
from source (svn trunk) and installed. I got as far as the 'make 
check'. All tests passed EXCEPT one relating to 
gr_vmcircbuf_createfilemapping: The specific messages are:


Testing gr_vmcircbuf_createfilemapping_factory...
gr_vmcircbuf_createfilemapping: createfilemapping is not available
.gr_vmcircbuf_createfilemapping: createfilemapping: Doesn't work

from here on all other tests pass OK. The same kind of error occurs 
when just trying to run the dial_tone.py example script.


So, there is a point of common failure between the 2 VM's. Does anyone 
have a clue as to what might be the cause for this failure and what if 
anything can be done to rectify it?
If there is any more info I can provide that may help with a diagnosis 
then please let m know and I'll do my best to obtain it.


Thanks for any assistance.

Cheers
Richard

===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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



===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

[Discuss-gnuradio] VM Make Check problem : createfilemapping is not available

[Richard Clarke]

Bumped

Hi All,

I have been attempting to use a GNU Radio 3.1.2 Virtual Machine (guest 
OS is Open Suse 10.2) kindly provided by Chiara De Dominicis, with the 
USRP. Initial communications with the USRP were established, enough for 
firmware download to the USRP. However when attempting to run any script 
that makes use of the USRP the following error is thrown up after a few 
seconds before the whole VM crashes into oblivion.


Terminal message output: gr_check_counting: enter_SEARCHING at offset
0  (0x)
 gr_vmcircbuf_createfilemapping: 
createfilemapping is not available


Now, I've also created my own Ubuntu 8.04 VM with GNURadio 3.1.2 built 
from source (svn trunk) and installed. I got as far as the 'make check'. 
All tests passed EXCEPT one relating to gr_vmcircbuf_createfilemapping: 
The specific messages are:


Testing gr_vmcircbuf_createfilemapping_factory...
gr_vmcircbuf_createfilemapping: createfilemapping is not available
.gr_vmcircbuf_createfilemapping: createfilemapping: Doesn't work

from here on all other tests pass OK. The same kind of error occurs when 
just trying to run the dial_tone.py example script.


So, there is a point of common failure between the 2 VM's. Does anyone 
have a clue as to what might be the cause for this failure and what if 
anything can be done to rectify it?
If there is any more info I can provide that may help with a diagnosis 
then please let m know and I'll do my best to obtain it.


Thanks for any assistance.

Cheers
Richard

===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

[Discuss-gnuradio] VM Make Check problem : createfilemapping is not available

[Richard Clarke]

Hi All,

I have been attempting to use a GNU Radio 3.1.2 Virtual Machine (guest 
OS is Open Suse 10.2) kindly provided by Chiara De Dominicis, with the 
USRP. Initial communications with the USRP were established, enough for 
firmware download to the USRP. However when attempting to run any script 
that makes use of the USRP the following error is thrown up after a few 
seconds before the whole VM crashes into oblivion.


Terminal message output: gr_check_counting: enter_SEARCHING at offset
0  (0x)
  gr_vmcircbuf_createfilemapping: 
createfilemapping is not available


Now, I've also created my own Ubuntu 8.04 VM with GNURadio 3.1.2 built 
from source (svn trunk) and installed. I got as far as the 'make check'. 
All tests passed EXCEPT one relating to gr_vmcircbuf_createfilemapping: 
The specific messages are:


Testing gr_vmcircbuf_createfilemapping_factory...
gr_vmcircbuf_createfilemapping: createfilemapping is not available
.gr_vmcircbuf_createfilemapping: createfilemapping: Doesn't work

from here on all other tests pass OK.

So, there is a point of common failure between the 2 VM's. Does anyone 
have a clue as to what might be the cause for this failure and what if 
anything can be done to rectify it?
If there is any more info I can provide that may help with a diagnosis 
then please let m know and I'll do my best to obtain it.


Thanks for any assistance.

Cheers
Richard



===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

Re: [Discuss-gnuradio] GNURadio on VmWare: success!

[Richard Clarke]

Has anyone downloaded  Chiara's VMware GNU Radio image? Did it work for 
you? When I unzip it I get a report of a CRC fail error, and the VM 
machine is reported as corrupt by VMware Server. Is it just my copy or 
is the source file broken?


Thanks

Cheers
Richard

Chris Albertson wrote:

On Tue, Jun 17, 2008 at 7:28 AM, Chiara De Dominicis <[EMAIL PROTECTED]> wrote:
  

Hi everybody,
I found a host for the image. You can download it from:
http://www.ing.unibs.it/~wsnlab/SDR/GNURadio312SuSE102_VMWare.zip
or you can go here:
http://www.ing.unibs.it/~wsnlab/



One other place you might want to host this is on the vmware.com site.
 They have a section for "appliances" and I think this counts as one.
If you put if on  their site, I think your work as well as GNURadio
itself will see a lot more exposure and use.

t
  


===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

Re: [Discuss-gnuradio] GNURadio on VmWare: success!

[Richard Clarke]

Hi Chiara,

well done! Just wanted to say I'd definitely be interested in obtaining 
the VmWare image you've created. As you say though, 2GB is pretty big. 
If you don't find a host for the image within the next few days I may be 
able to arrange a temporary FTP location where you can upload to.


Cheers
Richard

Chiara De Dominicis wrote:

Hi everybody,

I installed GNURadio 3.1.2 on SuSE 10.2 in a virtual machine for 
VmWare 6.0.

The installation is perfectly working also with the USRP.
My system is a Centrino Duo T2300 with 2.5GB RAM.

I think it is really working since I've been using it for 2 months, now...

If someone is interested in a clean image of the vm, please tell me 
where to upload it since it is quite huge (2 GB zipped)


Bye
Chiara




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


===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

Re: [Discuss-gnuradio] RFX transceiver board receive VCO offsetautomated calibration

[Richard Clarke]

Hi Johnathan,

thank you for your response. My applications is rather simple. I am not 
performing any receiver (digital or analog demod) type functionality 
where such a realtime tracking of the received carrier frequency would 
need to be a part of the overall design. Rather I am receiving a 
modulated RF carrier on one frequency and then retransmitting on another 
(cross band repeater), or retransmitting at complex baseband to be used 
as an input vector modulation source for an external RF signal 
generator/Fading simulator. I don't want the receive offset due to 
RFX400/USRP oscillator/clock tolerances to cause the retransmitted 
signal to be offset by an amount that could put it outside the fine 
adjustment range of the RF modem receiver (3rd party device) under test. 
At this stage my proposed calibration of the RFX400/USRP doesn't need to 
happen continuously, just once at the start of a test.


Cheers
Richard

Johnathan Corgan wrote:

On 2/27/08, Richard Clarke <[EMAIL PROTECTED]> wrote:

  

 Before I go ahead and try to implement an auto calibration routine for
 the Rx frequency offset of the receive subsystem on the RFX400/USRP, I
 was wondering if anyone else had already implemented something similar,
 or had any pointers for me.



While what you describe is well-intentioned, it doesn't solve the real issue.

  

Basically what I want to do is create a
 calibration routine that will determine the frequency offset between the
 RFX400/USRP receive subsystem (nominally already set to equal the
 frequency from a transmit source (e.g sig gen) and the transmit source,
 and then nudge the tune frequency to null that offset. I find that my
 RFX400 receiver after time to stabilise is around 3.2KHz in error, which
 is well within it's spec I know, however I want to automatically
 determine this offset and null it out.



Do you want to null it out once, based on a your signal generator
input, and store that value somewhere?  How would you use this value
in the future?

  

I guess the actual fine frequency
 adjustment will actually be occurring in the DDC, would that be correct?



If that is how you were to implement it.  If all you are doing is
applying a fixed correction based on this calibration technique you've
described, then it's easier to just tune the daughterboard to the
corrected frequency.  You're correct that you will see the "beat
frequency" in the I or Q channel equal to the frequency offset between
the transmitter and receiver.

However, I don't think this addresses the bigger issue, which is that
receiver frequency and time base offset will always exist, and must be
corrected in real-time if you are using a modulation technique that is
sensitive to these offsets.  Even temperature differences in the
frequency reference in the USRP can cause many kilohertz drift,
especially if you are operating at high carrier frequencies, like
2-3GHz.

There are many techniques for receiver frequency and phase
synchronization.  They generally involve a block to measure the
frequency/phase error, a loop filter to turn this error into an
appropriate control value, and an NCO to apply the actual fine
frequency/phase correction to the incoming signal.  These would be
designed to work with the properties of the actual modulation you'd be
receiving.

  


===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

[Discuss-gnuradio] RFX transceiver board receive VCO offset automated calibration

[Richard Clarke]

Hi All,

Before I go ahead and try to implement an auto calibration routine for 
the Rx frequency offset of the receive subsystem on the RFX400/USRP, I 
was wondering if anyone else had already implemented something similar, 
or had any pointers for me. Basically what I want to do is create a 
calibration routine that will determine the frequency offset between the 
RFX400/USRP receive subsystem (nominally already set to equal the 
frequency from a transmit source (e.g sig gen) and the transmit source, 
and then nudge the tune frequency to null that offset. I find that my 
RFX400 receiver after time to stabilise is around 3.2KHz in error, which 
is well within it's spec I know, however I want to automatically 
determine this offset and null it out. I guess the actual fine frequency 
adjustment will actually be occurring in the DDC, would that be correct?


One way to measure the frequency offset is to look at either the I or Q 
waveform of the (unmodulated) downconverted RF signal. When an offset is 
present between Tx source carrier and Rx subsystem the in-phase or 
quadrature signal is a sinusoidal waveform with a frequency 
corresponding to the magnitude of the offset involved. Use this to then 
fine tune the RFX400/USRP.


So, has anyone done something similar before? Do you have any code you'd 
be willing to share?


Thanks very much.

Cheers
Richard

===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

Re: [Discuss-gnuradio] USRP underrunswhenattemptingsimultaneousreceive and transmit

[Richard Clarke]

Hi Firas,

thank you for posting the link to your repeater code. I have that 
running on my platform now to see if I still have issues with USRP under 
runs. I modified it slightly to accomodate the Flex400 board I'm using. 
It is working, though not the GUI side of things, a Gtk error is 
flagged, "Gtk-CRITICAL **: gtk_window_resize: assertion 'width > 0' 
failed". Not too important for my application but thought I'd mention 
it. Apart from at the very start of the repeater code, so far I do not 
appear to be getting USRP under runs. I'm not entirely sure yet as to 
the difference between what I've been doing and what your code is doing 
that might explain the different USRP data transfer behaviour.


Cheers
Richard



===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

Re: [Discuss-gnuradio] USRP underruns when attemptingsimultaneousreceive and transmit

[Richard Clarke]

OK thanks Eric. I should have mentioned I was using Ubuntu 7.10. My 
application was effectively just passing the samples from the USRP Rx to 
the USRP Tx via the PC, no actual demod/remod going on.


I'll try your suggestions regarding fusb buffering parameters and see if 
that makes a difference.


Thanks again.

Cheers
Richard


===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

[Discuss-gnuradio] USRP underruns when attempting simultaneous receive and transmit

[Richard Clarke]

Hi All,

summary: If I try and receive and transmit data from and to the USRP 
simultaneously at the same data rate (no matter what it is, even as low 
as 2MB/s each way) I always get usrp underruns.


Background
*
I have a simple cross band repeater type example running under Gnuradio 
3.1.1. Basically I have configured an RFX400 to receive an FM type 
modulated signal on one frequency (452.75MHz) and retransmit that same 
signal either as complex baseband to an LFTX daughterboard, or an RF 
signal at another frequency (440MHz) by the RFX400. Currently this 
involves simultaneous reception and transmission of data across the 
USB2.0 interface. I've typically been using usrp_decim values of 128 
(i.e500Ks/s, complex = 2MB/s), and usrp_inter of 256, again giving a 
nominal data rate to the usrp of 2MB/s.


I have verified the USB2.0 simplex performance of my PC (Pentium D 
2.8GHz, 1GB RAM) by running standard gnuradio scripts such as 
usrp_fft.py for testing the data throughput to the PC. I was able to set 
the decimation rate of the fft scope to 8 (giving 8MS/s, complex, I 
assume => 32MB/s) without any usrp over runs reported.Decimation value 
below 8 start giving usrp over runs, as expected.


On the PC to USRP side: I've used usrp_siggen.py to generate a sine wave 
on the PC and output it from the LFTX daughterboard. I kep reducing the 
usrp interpolation rate until I started to see under runs reported. This 
happened at an a value of 12, at 14 it was OK. I was expecting 16 would 
be my lower limit (128MS/s / 16 = 8MS/s = 32MB/s over usb2.0) but it 
would appear my PC USB controller is slightly better at sending data 
than receiving.


Anyway, to get to the point. If I try and receive and transmit data 
simultaneously at the same data rate (no matter what it is, even 2MB/s) 
I always get usrp underruns.


Questions
***
1) Do others see the same thing?
2) Is this because any buffering that's going at the PC end is 
insufficient to smooth out any slight differences in actual receive and 
transmit data rates, leading to the occasional starving of the USRP's 
usb receive buffers?
3) If I configure my application to receive samples from the usrp at a 
lower rate than I retransmit them (using the rational resampler to 
interpolate) this significantly reduces any under run's reported. Is 
this the generally used method to get around this particular issue?
4) Is it possible to configure the USRP to directly pass samples from 
the receive to the transmit, bypassing the PC altogether? Could be 
useful to me as a basic RF passband to complex baseband, cutting out PC 
latencies.


Thanks in advance for your responses.

Cheers
Richard


===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

Re: [Discuss-gnuradio] anyone implement the Raleigh fadingmodel/multi-path?

[Richard Clarke]

I've established a temporary (60 day) FTP user account on our company 
FTP server to host the GNU Radio Rayleigh Fading code as it currently 
stands. I've placed the raw code that's relevant to this module there. 
It's not immediately ready to build however that won't take long for 
anyone familiar with integrating user modules into GNU Radio. There is 
some other code relevant to the way we were intending to use the fading 
simulator (i.e in a client/server model across a network) that may be of 
interest to some but is not particularly relevant to the actual fading 
module itself so you can ignore that if you wish.


FTP details: ftp://ftp.tait.co.nz
user: gnuradio
password: gnuradio01


The top level python files 'filesrc_fade_transmit.py' and 
'nbfm_tx_rx.py' are examples of how the fading module might be used. 
The  file 'multipath_rayleigh_channel_cc.py' is the python level module 
I mentioned earlier that handles doing multiple delayed paths, hopefully 
independently faded, but thats something that can be double checked.


Anyway, feel free to grab the code and have a rummage through to 
familiarise yourself. If you have any questions or problems accessing 
the files let me know. I'll do my best to help however bear in mind I 
haven't worked on this directly myself. It was done as part of a summer 
internship a year or so ago and I'm only now getting around to trying to 
use it. I can however get in touch with the student (Jonas Hodel) if 
required.


I will be on leave for a week from this Friday (NZ time) but will be 
back online Monday 11th Feb.


Good luck!

Cheers
Richard

George Nychis wrote:

Hi Richard,

This would be great!  I have great use for this, and I'm sure many 
others would too.  Did he generate any documentation showing his 
evaluation of his implementation, and any details of it?  (like a 
final research paper).


Could you make this code publicly available to the list so that we can 
review its implementation and discuss integrating it in to the code 
base?  We could work on integrating the multiple paths in to the C++ 
block and making it flexible.


If you host it for us, it won't undergo just one set of eyes, but many 
sets of eyes on the list :)  But make sure to link to it, rather than 
send an attachment because of list restrictions.  Then we can put it 
in a features branch within the SVN repository to work on it if needed.


Thank you!
George


Richard Clarke wrote:

Hi George,

I have had a Summer student doing some work on this (a year ago now). 
He implemented a GNU Radio module that can do Rayleigh channel 
simulation. He based it on a particular paper (I'd have to look it 
up) for the implementation. He verified the statistical performance 
of his implementation against the Matlab Rayleigh channel model and 
against theory and found it to be a close match. I'm not entirely 
convinced of the delayed multiple path aspects of the 
design/implementation but haven't had time to look into it further. 
In fact as it stands I believe the GNU Radio module (at C++ level) 
only handles a single flat fading path and doing multiple delayed 
paths is done at the python module level and which invokes multiple 
instances of the Flat fading Rayleigh C++ GNU Radio module.


I'd welcome another set of eyes and someone more experienced than I 
am with GNU Radio to help finish off this potentially very useful 
addition to the GNU Radio code base.


Cheers
Richard




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



===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===






===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



__

Re: [Discuss-gnuradio] anyone implement the Raleigh fadingmodel/multi-path?

[Richard Clarke]

OK, I'll look at gathering up all relevant code and documentation and 
see what hosting options I have at this end. When I've got this sorted 
I'll post a link to the location of the files. In the  meantime a little 
additional detail, taken from some of the comments in one of the header 
files.
It will be great to progress this module such that multiple delayed 
paths can be implemented at the C++ level without requiring python to 
handle the delays.


*--
/*

This class implements a flat Rayleigh Fading Simulator based on Christos 
Komninakis work referred to in his paper "A Fast and Accurate Rayleigh 
Fading Simulator" (http://www.ee.ucla.edu/~chkomn/). Some analysis has 
been carried out by myself confirming that his algorithm is similar to 
the Rayleigh model available within Matlab "rayleighchan()".



Inputs

- seed: the random channel seed (e.g. -115).
- fdT: Discrete Doppler Rate (small positive fraction, e.g. 0.001 - 
0.2), where fd is the Doppler fade frequency and 1/T is the sample rate 
of the channel. Note that the current implementation only supports 
rational fractions of 0.2. To accommodate other values the IIR filter 
needs to re-designed using Matlab (please reefer to the paper mentioned 
above for details).
- pwr: the square root power of the resulting fading waveform (e.g. pwr 
= 5 would produce a fading waveform with an output power of 25).
- flag_indep: Determines whether individual blocks processed by the 
channel should be treated as independent blocks or as one continuous 
block. 1 if blocks are independent, 0 if continuous across blocks.


  
Jonas Hodel

01/02/07
  
*/   
*---


Cheers
Richard
(Please note: I have no control over the signature attached to the 
bottom of this email, sorry! ;-)


George Nychis wrote:

Hi Richard,

This would be great!  I have great use for this, and I'm sure many 
others would too.  Did he generate any documentation showing his 
evaluation of his implementation, and any details of it?  (like a 
final research paper).


Could you make this code publicly available to the list so that we can 
review its implementation and discuss integrating it in to the code 
base?  We could work on integrating the multiple paths in to the C++ 
block and making it flexible.


If you host it for us, it won't undergo just one set of eyes, but many 
sets of eyes on the list :)  But make sure to link to it, rather than 
send an attachment because of list restrictions.  Then we can put it 
in a features branch within the SVN repository to work on it if needed.


Thank you!
George


Richard Clarke wrote:

Hi George,

I have had a Summer student doing some work on this (a year ago now). 
He implemented a GNU Radio module that can do Rayleigh channel 
simulation. He based it on a particular paper (I'd have to look it 
up) for the implementation. He verified the statistical performance 
of his implementation against the Matlab Rayleigh channel model and 
against theory and found it to be a close match. I'm not entirely 
convinced of the delayed multiple path aspects of the 
design/implementation but haven't had time to look into it further. 
In fact as it stands I believe the GNU Radio module (at C++ level) 
only handles a single flat fading path and doing multiple delayed 
paths is done at the python module level and which invokes multiple 
instances of the Flat fading Rayleigh C++ GNU Radio module.


I'd welcome another set of eyes and someone more experienced than I 
am with GNU Radio to help finish off this potentially very useful 
addition to the GNU Radio code base.


Cheers
Richard




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



===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===






===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete al

Re: [Discuss-gnuradio] anyone implement the Raleigh fading model/multi-path?

[Richard Clarke]

Hi George,

I have had a Summer student doing some work on this (a year ago now). He 
implemented a GNU Radio module that can do Rayleigh channel simulation. 
He based it on a particular paper (I'd have to look it up) for the 
implementation. He verified the statistical performance of his 
implementation against the Matlab Rayleigh channel model and against 
theory and found it to be a close match. I'm not entirely convinced of 
the delayed multiple path aspects of the design/implementation but 
haven't had time to look into it further. In fact as it stands I believe 
the GNU Radio module (at C++ level) only handles a single flat fading 
path and doing multiple delayed paths is done at the python module level 
and which invokes multiple instances of the Flat fading Rayleigh C++ GNU 
Radio module.


I'd welcome another set of eyes and someone more experienced than I am 
with GNU Radio to help finish off this potentially very useful addition 
to the GNU Radio code base.


Cheers
Richard




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



===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

Re: [Discuss-gnuradio] xG Technology

[Richard Clarke]

Interesting however have a read of the following old Register article:

http://www.theregister.co.uk/2005/11/09/xmax/

and

http://www.ka9q.net/xmax_schwartz.html

So, this appears to have been doing the rounds since mid 2005 but 
apparently nothing concrete to show 2 years later.


Difficult to find any articles more recent than 2005 on this 'technology'.

Anyone else find anything more concrete or recent regarding this?

Richard



Charles Swiger wrote:

Apologies for general/off topicness, but does anybody have any
comments/opionion about these guys:

http://www.xgtechnology.com/technology.asp

Useful innovation or snake oil?

TIA

--Chuck





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

  


===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

Re: [Discuss-gnuradio] USRP data rates

[Richard Clarke]

Actually I believe 16MHz is only achieved by reducing the sample bit 
depth from 16 to 8, which I've read somewhere can be done.


8 Mega complex samples per second -> 8MHz when the real and imaginary 
parts of the complex sample are each 16 bits wide. (=32Mbytes/sec)
16 Mega complex samples per second -> 16MHz when I/Q are reduced to 8 
bits each (=32Mbytes/sec)


Somebody correct me if I'm wrong but I'm pretty sure that's right.

Cheers
Richard


Lisa Creer wrote:
The USRP sales brochure lists as a feature "Capable of processing 
signals up to 16 MHz wide". I can only figure out how it can process 
signals up to 8 MHz wide. What am I missing?


Since samples sent across the USB are 16-bit signed integers (16-bit I 
and 16-bit Q for complex samples) that makes each complex sample size 
4 bytes. Since the USB max is 32MB/s, we have a limit of 8MS/s which 
translates to an effective bandwidth of 8MHz wide.


I noticed that there is another method besides usrp.source_c() to 
retrieve data from the USRP, it is usrp.source_s(). Is this returning  
an even smaller sample that would somehow get us to the 16 MHz wide 
bandwidth? What exactly is this method returning?


Thanks in advance.


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


===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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

Re: [Discuss-gnuradio] Ettus Research announcements Nov 2006

[Richard Clarke]

Yes, I would have to agree with Berndt on this. The casing is a good 
idea but I think it would be better to keep it as an option rather than 
forcing it on people and increasing the price of the USRP. It is not 
essential to the operation of the USRP, just nice to have.


Cheers
Richard

Berndt Josef Wulf wrote:
I think that the compulsory addition of a housing will deter many people on 
low budget from purchasing a USRP. It has become a pricy commodity.


Just my opinion,

cheerio Berndt

On Monday 13 November 2006 07:13, Matt Ettus wrote:
  



USRP Update, Nov 12th, 2006



In this issue --

1>   USRP-announce Mailing List
2>   Enclosure [Finally] Available!
3>   SDR06 Conference

==

Mailing List Changes
-


There is a new USRP-announce mailing list.  This list will only be used for
announcements, about once or twice a month, and users cannot post to it. 
It will only be used for announcements about the USRP family of products.


If interested, you can subscribe to it here:

http://aeinet.com/mailman/listinfo/usrp-announce



USRP Enclosure Now Available!
-

We are pleased to announce the availability of the new USRP Enclosure.
This oft-requested item is made out of black anodized aluminum, and
includes a fan and 2 RF cables.

The enclosure, which measures 8.25" by 6.5" by 2" (210mm by 167mm by
54mm) has front-panel cutouts for the power, USB, and 5 SMA bulkhead
connectors.  The enclosure comes with 2 SMA cables, male on one side to
connect to daughterboards inside the box, and female bulkhead to mount
to the box on the other side.  More cables are available for those
needing more than 2 RF connections to the outside of the box.

The only restriction the enclosure places on usage is that only one TVRX
board may be used at a time.  Other daughterboards are not affected.

Going forward, all USRPs ordered will come with the enclosure, fan, 2
cables, and appropriate hardware.  The price of the USRP has been
adjusted to reflect this.

For those who already own USRPs, you can purchase the
enclosure/fan/cables/hardware package separately for $125.

Pictures of the enclosure are here:

   http://gnuradio.org/enclosure.jpg
   http://gnuradio.org/enclosure_open.jpg


===

SDR06 Conference and Trade Show
---

Ettus Research will have a booth (#207) at the SDR06 conference and trade
show happening this week in Orlando, from Monday through Thursday.  There
will be live demos of the USRP in action.  We look forward to meeting those
of you who are attending.  If you'd like to arrange a meeting outside of
the tradeshow, you can do so by email ([EMAIL PROTECTED]) or in person at the
booth.

More info on the show can be found here:

   http://sdrforum.org/pages/sdr06/forumMeeting_sdr06_main.asp


===


Thanks for your time,
Matt Ettus





___
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
  


===
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===



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