Re: [Discuss-gnuradio] Filterbank stuff

[Frank Brickle]

On Thu, Feb 12, 2009 at 11:15 PM, Bob McGwier  wrote:


> WSJT uses portaudio directly and that can talk to jack through its
> portaudio host if jack has been compiled with that support in it.


Ideally, yes. However, unless some of the WSJT code has been rewritten,
despite appearances, you're limited to using the WSJT default sample rate.
Sample rate choices made in the audio subsystem aren't actually propagated
correctly through the entire DSP chain.

This causes problems with JACK in a number of situations, depending on which
driver (ALSA, FFADO, etc.) JACK itself is using.

Frank

-- 
...we ain't going to hell, we're going to the rebel side of heaven. --
Langhorne Slim
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Measuring SNR

[Swapna Raj]

I am sorry if my previous mail was confusing. I am trying to switch toa
different Rx  freq depending on a control information. Even though I exit
from rx_callback and try to call a new script for Rx using os.system I get
an error message saying
USB _claim_interface :failed interface 2
Device or resource busy
can't open rx_interface
can't open usrp1.

I closed /disconnected the flowgraph before attempting to open a new script.
How can I ensure that the rx_path is clear?

Thank you
Swapna

On Thu, Feb 12, 2009 at 9:19 PM, Swapna Raj  wrote:

> Eric,
>
> Thank You.
> os.system() worked. I can now switch between different scripts while in
> transmitting mode.
>
> To all,
> While receiving data (using a modification of benchmark_rx.py) I need to
> receive at a different frequency depending on some control information .
>
> I get an error message while attempting to do this using os.system().It
> says *
>
> cannot connect to usb interface, cannot connect to usrp1*.
> I tried the following and it doesn't work
>
> 1.I tried using flowgraph.disconnect and flowgraph.close() before calling
> the second script.
> 2.I tried calling os.system() after exiting rx_callback and main() but it
> still can't connect to the source.
> 3.I also tried changing frequency instead of calling a separate script
> inside rx_callback()
>
>
> How can I ensure that the receive path is completely disconnected and
> usrp_source is available?
>
> thanks ,
> Swapna
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filterbank stuff

[Bob McGwier]

WSJT uses portaudio directly and that can talk to jack through its 
portaudio host if jack has been compiled with that support in it.


Bob


Frank Brickle wrote:
On Thu, Feb 12, 2009 at 7:59 PM, Marcus D. Leech > wrote:
 


I'm looking into this for a friend who wants to use his USRP2 for EME.
I'll see if I can do something JT65-like (or exactly that!)
 in Gnu Radio.


You should be able to just use it via portaudio on top of JACK, 
talking to the USRP through GNU Radio. There may be some sample rate 
issues that need to be solved in GNU Radio -- last time I looked, WSJT 
only pretended to handle variable sample rates.


Frank


--
...we ain't going to hell, we're going to the rebel side of heaven. -- 
Langhorne Slim





--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.



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

Re: [Discuss-gnuradio] Measuring SNR

[Swapna Raj]

Eric,

Thank You.
os.system() worked. I can now switch between different scripts while in
transmitting mode.

To all,
While receiving data (using a modification of benchmark_rx.py) I need to
receive at a different frequency depending on some control information .

I get an error message while attempting to do this using os.system().It says
*

cannot connect to usb interface, cannot connect to usrp1*.
I tried the following and it doesn't work

1.I tried using flowgraph.disconnect and flowgraph.close() before calling
the second script.
2.I tried calling os.system() after exiting rx_callback and main() but it
still can't connect to the source.
3.I also tried changing frequency instead of calling a separate script
inside rx_callback()


How can I ensure that the receive path is completely disconnected and
usrp_source is available?

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

Re: [Discuss-gnuradio] Filterbank stuff

[Frank Brickle]

On Thu, Feb 12, 2009 at 7:59 PM, Marcus D. Leech  wrote:


> I'm looking into this for a friend who wants to use his USRP2 for EME.
> I'll see if I can do something JT65-like (or exactly that!)
>  in Gnu Radio.


You should be able to just use it via portaudio on top of JACK, talking to
the USRP through GNU Radio. There may be some sample rate issues that need
to be solved in GNU Radio -- last time I looked, WSJT only pretended to
handle variable sample rates.

Frank


-- 
...we ain't going to hell, we're going to the rebel side of heaven. --
Langhorne Slim
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Filterbank stuff

[Marcus D. Leech]

Bob McGwier wrote:
> PLEASE do yourself a favor and look at WSJT by Joe Taylor.  This guy
> has years and years and years of experience doing this.  He has
> studied the problem absolutely to the n-th degree.  His system is
> really beautifully done.  And,  you know he isn't a nut case because
> he won the Nobel prize for physics proving observational evidence for
> General Relativity by discovering and observing certain types of radio
> emission pulsars.  The only thing that has ever caused me to doubt his
> sanity was his taking the job of Dean of Faculty at Princeton for
> seven years!
>
> http://www.physics.princeton.edu/pulsar/K1JT/
>
> Bob
>
Thanks Bob.

I'd actually looked at JT65 a few years back, and had forgotten about
it.  Doh!

I'm looking into this for a friend who wants to use his USRP2 for EME. 
I'll see if I can do something JT65-like (or exactly that!)
  in Gnu Radio.


-- 
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] Filterbank stuff

[Bob McGwier]

Marcus D. Leech wrote:

I'm toying with some insane ideas for EME (Moonbounce) for a friend of mine.

I'm toying with taking a modulated baseband from a QAM16 modulator, and
replicating it across several spectral pickets
  over a wide band, then on reception doing "something" with these
redundant copies to improve SNR/BER.

I'm currently thinking Analysis Filterbank/Synthesis Filterbank to take
the baseband signals, and spread them across
  a wider spectrum, with replication.

Ignoring whether this approach is sane or not is the filterbank the
right block to use to take multiple narrow baseband signals and
  "map" them onto a wider baseband?

  
PLEASE do yourself a favor and look at WSJT by Joe Taylor.  This guy has 
years and years and years of experience doing this.  He has studied the 
problem absolutely to the n-th degree.  His system is really beautifully 
done.  And,  you know he isn't a nut case because he won the Nobel prize 
for physics proving observational evidence for General Relativity by 
discovering and observing certain types of radio emission pulsars.  The 
only thing that has ever caused me to doubt his sanity was his taking 
the job of Dean of Faculty at Princeton for seven years!


http://www.physics.princeton.edu/pulsar/K1JT/

Bob

--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio 
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,

NJQRP, QRP ARCI, QCWA, FRC.
"It is human nature to think wisely and act in
an absurd fashion.", Anatole France.



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

Re: [Discuss-gnuradio] Filterbank stuff

[Johnathan Corgan]

On Thu, Feb 12, 2009 at 3:31 PM, Marcus D. Leech  wrote:

> I'm currently thinking Analysis Filterbank/Synthesis Filterbank to take
> the baseband signals, and spread them across
>  a wider spectrum, with replication.

Aside from what Matt says regarding QAM and OFDM, if you truly want to
exactly replicate the baseband signal, and not apply some form of
coding across each of them to make them different, why not just zero
stuff your baseband up to the wider sample rate?

On the sanity of the original idea, though, I agree with Matt--OFDM
gets you the protection against frequency selective fading I think
you're going for here.

Another thought is to use spread spectrum, similar to GPS, which would
trade off bit rate for bandwidth.

Johnathan


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

Re: [Discuss-gnuradio] Filterbank stuff

[Matt Ettus]

Marcus D. Leech wrote:

I'm toying with some insane ideas for EME (Moonbounce) for a friend of mine.

I'm toying with taking a modulated baseband from a QAM16 modulator, and
replicating it across several spectral pickets
  over a wide band, then on reception doing "something" with these
redundant copies to improve SNR/BER.

I'm currently thinking Analysis Filterbank/Synthesis Filterbank to take
the baseband signals, and spread them across
  a wider spectrum, with replication.

Ignoring whether this approach is sane or not is the filterbank the
right block to use to take multiple narrow baseband signals and
  "map" them onto a wider baseband?




The filterbank is the way to do what you are asking.  But the overall 
idea is not sane :)  QAM-16 makes no sense on such a weak signal.  The 
purpose of QAM16 is to get more bits per second per hertz.  What you 
want is more bits per second per watt.  In any case, if you just do 
OFDM, then you don't need to worry about filterbanks.



I would suggest looking up and reading the paper that Phil Karn (KA9Q) 
wrote a long time ago, called EME-2000.


Matt



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

[Discuss-gnuradio] Filterbank stuff

[Marcus D. Leech]

I'm toying with some insane ideas for EME (Moonbounce) for a friend of mine.

I'm toying with taking a modulated baseband from a QAM16 modulator, and
replicating it across several spectral pickets
  over a wide band, then on reception doing "something" with these
redundant copies to improve SNR/BER.

I'm currently thinking Analysis Filterbank/Synthesis Filterbank to take
the baseband signals, and spread them across
  a wider spectrum, with replication.

Ignoring whether this approach is sane or not is the filterbank the
right block to use to take multiple narrow baseband signals and
  "map" them onto a wider baseband?

-- 
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] Connecting and disconnecting a usrp

[Kieran Brownlees]

Hey all,

I have a quick question about connecting and disconnecting a usrp within 
the same python run.
My test program creates a top block, within the top block it attempts to 
create a usrp.source_c(0), it then deletes the source goes to sleep and 
waits for a KeyboardInterrupt, when this is detected it attempts to 
create the usrp source again.


The behaviour I am trying to understand is when I start this program 
with my usrp not powered on I get the message "Unable to find USRP #0" 
as expected. But if I then power on the usrp and hit ctrl-c I still get 
the message "Unable to find USRP #0". So my question is: Is it not 
possible to connect / disconnect a usrp within the same python run? 
(There is a firmware error if you have the usrp connected to start with, 
create / destroy a source, disconnect it, reconnect it and then attempt 
to create a new source)


Thank you,
Kieran

===
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] gnuradio mentioned in cnet article on phone snooping

[ematlis]

Gnuradio was recently mentioned in this article on the technology of phone 
snooping:


http://news.cnet.com/8301-13739_3-10159055-46.html




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

Re: [Discuss-gnuradio] Re: Frequency dependent problem after syncronizing , Please help!

[Johnathan Corgan]

On Thu, Feb 12, 2009 at 1:20 PM, Bruhtesfa Ebrahim  wrote:

> What makes it strange is the dependence on gain.when the linear gain in
> the spectrum panel(usrp_fft.py)is set to 0,the signal at the center(the
> DC)is 5dB higher than the noise level.When I increase the gain, the
> difference between the DC and noise level keeps decreasing and finally
> the DC level is equal to the noise level.
> Specifically, for a linear gain >=20, the signal around DC is not
> visible(it is equal to the noise level).

Actually, what you're now describing is more like not receiving any
signal at all--the small line at DC is residual DC offset from the
ADC, and the noise is simply that, noise that gets amplified according
to the gain setting.  At a certain point the noise power exceeds the
small DC offset.

Johnathan


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

Re: [Discuss-gnuradio] Re: some usrp modules are missing

[Josh Blum]

The usrp_diagnostics script was renamed usrp_probe.

Part of this confusion may have come from the freedesktop menu item: If 
you have installed the menu items for grc, run the following to remove 
the old "usrp diagnostics" menu item:

sudo xdg-desktop-menu uninstall gnuradio-usrp_diagnostics.desktop

Then run the following to install the current grc freedesktop stuff:
sudo grc_setup_freedesktop install

The wiki is updated to reflect this:
http://gnuradio.org/trac/wiki/GNURadioCompanion#Installation
http://gnuradio.org/trac/wiki/GNURadioCompanion#Execution

-josh


usrp_diagnostics was an installed script by the grc module, which I felt
was poorly named, so I asked Josh to rename it to usrp_probe.

Johnathan



___
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] Re: Frequency dependent problem after syncronizing , Please help!

[Bruhtesfa Ebrahim]

Johnathan Corgan wrote:
> On Thu, Feb 12, 2009 at 5:43 AM, Bruhtesfa Ebrahim 
>  wrote:

> It sounds like, since you have perfect synchronization between
> transmitter and receiver, that what you have after downconversion in
> the daughterboard is DC + noise.  That is, the transmitted carrier
> (plus noise and multipath from the channel) is being mixed with a
> synchronized local oscillator, resulting in only the noise components
> being left in the complex baseband signal GNU Radio is receiving.
> There will also be a DC component based on the path delay and
> wavelength causing a phase shift between the transmitted carrier phase
> and and the receiver LO phase.
> 
> Johnathan



Thank you Johnathan!

What makes it strange is the dependence on gain.when the linear gain in 
the spectrum panel(usrp_fft.py)is set to 0,the signal at the center(the 
DC)is 5dB higher than the noise level.When I increase the gain, the 
difference between the DC and noise level keeps decreasing and finally 
the DC level is equal to the noise level.
Specifically, for a linear gain >=20, the signal around DC is not 
visible(it is equal to the noise level).

is this gain dependence normal?

Bruhtesfa
-- 
Posted via http://www.ruby-forum.com/.


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

Re: [Discuss-gnuradio] Make fails in gr-how-to-write-a-block

[Johnathan Corgan]

On Thu, Feb 12, 2009 at 2:03 AM, Emil Molin  wrote:

>> > after doing ./bootstrap and then ./configure
>> >
>> > make gives the following message:
>> >
>> > libtool: Version mismatch error.  This is libtool 2.2.6, but the
>> > libtool: definition of this LT_INIT comes from an older release.
>> > libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
>> > libtool: and run autoconf again.
>> > make[3]: *** [howto.lo] Error 63
>> > make[2]: *** [check] Error 2
>> > make[1]: *** [check-recursive] Error 1

Can you give us the details on your OS, GNU Radio version, installed
libtool and automake verions?

Thanks.

Johnathan


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

Re: [Discuss-gnuradio] CCSDS 27 Encode/Decode

[Johnathan Corgan]

On Thu, 2009-02-12 at 14:29 -0500, Marcus D. Leech wrote:

> I'm looking at building a quick prototype narrowband QAM16 transceiver
> with error-correction.  I'm looking at the CCSDS 27
>   blocks, and the encode *looks* to me like it takes bytes in, and bytes
> out.
> 
> But the decoder is different.

Yes, the encoder takes packed bits (bytes) and outputs unpacked bits
(bytes, with LSBs carrying the interleaved G0 and G1 code bits). So one
byte in creates 16 bytes out.

The decoder takes floating point soft symbols in the range of 0-255, and
outputs packed bits.  It consumes 16 bytes of demodulator output data
and outputs 1 byte of packed bits.

There reason for these very specific types is that these blocks do
nothing but wrap GNU Radio blocks around a version of Phil Karn's libfec
library R1/2, K=7 encoder and Viterbi decoder, which only consume and
produce these types.  The one place I successfully used these was in a
non-packetized, continuously transmitting, BPSK satellite downlink.
These blocks aren't suitable for packetized transmission as they don't
provide any means of resetting the Viterbi decoder at the start of each
packet.

I recommend you look at CMU's SPIRAL project for machine generated
Viterbi decoders that might be easier to wrap and/or call directly to do
what you need.  I wasn't aware of this when I did the above, but my the
next generation of that project will use it.

Johnathan






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

[Discuss-gnuradio] CCSDS 27 Encode/Decode

[Marcus D. Leech]

I'm looking at building a quick prototype narrowband QAM16 transceiver
with error-correction.  I'm looking at the CCSDS 27
  blocks, and the encode *looks* to me like it takes bytes in, and bytes
out.

But the decoder is different.

Can somebody "clue me up" about how to use them?

-- 
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] CGRAN downtime

[George Nychis]

Frank Brickle wrote:



Definitely.



Done.

PS. the trac wiki is having some issues using mod_python, it's 
segfaulting on me and I'm trying to fix this now.  So, to all using the 
trac wiki on CGRAN, hang in there.


- George


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

Re: [Discuss-gnuradio] how to generate a periodic pulse

[Karthik]

On Mon, Feb 9, 2009 at 2:11 AM, Bruhtesfa Ebrahim wrote:

> Hey all,
>
> I want to generate a periodic rectangular pulse(of low duty cycle) from
> one USRP and receive it using another USRP operating simultaneously.
>
> So, is there some built in function to generate such a pulse?
> Also,what filter do i need to apply before connecting the pulse source
> to Usrp sink?
>
> Thanks!
>
> Bruhtesfa
> --
> Posted via http://www.ruby-forum.com/.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

You can write your own block if you aren't able to find something that you
can plug in from gnuradio. There is a source gr.sig_source_x which generates
square pulses, which you can modify to suit your requirements. The actual
period of the waveform coming out of the USRP will depend on the length of
the sequence and what your interpolation setting is. However, that is
something that you can work out.

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

Re: [Discuss-gnuradio] how to generate a periodic pulse

[yufeng wang]

Hey, Bruhtesfa,

This is Yufeng.  I have a more simpler question on Python, do you know
which codes can I use to generate a fixed length of random 0 and 1s,
and how to modulate them in PSK, do you have any idea about this?
Thanks!



On Mon, Feb 9, 2009 at 5:11 AM, Bruhtesfa Ebrahim  wrote:
> Hey all,
>
> I want to generate a periodic rectangular pulse(of low duty cycle) from
> one USRP and receive it using another USRP operating simultaneously.
>
> So, is there some built in function to generate such a pulse?
> Also,what filter do i need to apply before connecting the pulse source
> to Usrp sink?
>
> Thanks!
>
> Bruhtesfa
> --
> Posted via http://www.ruby-forum.com/.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Best wishes,

Yufeng


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

Re: [Discuss-gnuradio] Frequency dependent problem after syncronizing , Please help!

[Johnathan Corgan]

On Thu, Feb 12, 2009 at 5:43 AM, Bruhtesfa Ebrahim  wrote:

> I syncronized my USRPs(one is v4.3 and the other v4.5) by using the USRP
> clocking notes on http://www.gnuradio.org/trac/wiki/USRPClockingNotes,
> to make them frequency and phase syncronized.

Ok.

> ...Then,I run usrp_fft.py on the master USRP.I
> see that the master USRP receives the 5GHz transmission from signal
> generator without problem, but when i change the center frequency to
> 4.96GHz to receive from the slave, I got a weird signal.The signal is
> not stable, the noise(whole spectrum) level decreases and increases very
> fast and it has only a very small peak at the center frequency.Moreover,
> the spectrum changes very much with gain.)

It sounds like, since you have perfect synchronization between
transmitter and receiver, that what you have after downconversion in
the daughterboard is DC + noise.  That is, the transmitted carrier
(plus noise and multipath from the channel) is being mixed with a
synchronized local oscillator, resulting in only the noise components
being left in the complex baseband signal GNU Radio is receiving.
There will also be a DC component based on the path delay and
wavelength causing a phase shift between the transmitted carrier phase
and and the receiver LO phase.

Johnathan


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

Re: [Discuss-gnuradio] USRP2 PPS and REF

[Douglas Geiger]

Johnathan Corgan wrote:
> On Tue, Feb 10, 2009 at 1:26 PM, Douglas Geiger
>  wrote:
> 
>> Ok, looking at the frames in wireshark, looking for the timestamps that
>> were sent to the copy handler, it looks like only the frames from 30:80
>> are being used, and they're being used twice (i.e. u2b->rx_samples(0,
>> handlerb.get()) got the same samples that u2a->rx_samples(0,
>> handlera.get()) got).
> 
> Thanks for the info and update, this really helps narrow it down.  We
> may have a bug in our GbE driver packet filter, where the source mac
> address is being set to the wrong USRP2.  Unfortunately, both Eric and
> I are out of the office at the moment, but we'll look at this tonight.

In an effort to try to help solve this:
 The packet filter (the used in make_ethertype_inbound at least) looks
like it just sorts filters in packets with the correct ethertype, and
filters out any of those from 'our' (i.e. the host PC) mac address.
Unless I'm not following the code correctly - is there somewhere else
which looks for the target USRP2's mac address in receive packets?
 Doug

-- 
Doug Geiger
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
douglas.gei...@okstate.edu
doug.gei...@ieee.org


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

Re: [Discuss-gnuradio] Measuring SNR

[Eric Blossom]

On Thu, Feb 12, 2009 at 08:57:11AM -0600, Swapna Raj wrote:
> Hi,
> 
> My second question is more related to Python programming. I need to run a
> series of scripts one after the other in my work.Though these scripts work
> fine independently. I get an error when I use os.popen(). In most cases I do
> not want the control to return back to the calling script.Could any one
> suggest what is the best way to do this, or atleast a reference?

Try

   os.system("ls -l")

Eric


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

Re: [Discuss-gnuradio] Re: some usrp modules are missing

[Johnathan Corgan]

On Thu, 2009-02-12 at 08:34 -0800, Eric Blossom wrote:
> On Thu, Feb 12, 2009 at 10:18:55AM +, feldmaus wrote:

> > As i read, the  Tool is now called
> > .
>
> I have no idea what you're talking about :-)

usrp_diagnostics was an installed script by the grc module, which I felt
was poorly named, so I asked Josh to rename it to usrp_probe.

Johnathan



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

Re: [Discuss-gnuradio] Re: some usrp modules are missing

[Eric Blossom]

On Thu, Feb 12, 2009 at 10:18:55AM +, feldmaus wrote:
> Markus Feldmann  gmx.de> writes:
> > 
> > the  is missing.
> 
> As i read, the  Tool is now called
> .
> 
> Regards Markus

I have no idea what you're talking about :-)

Have you tried

 ./configure --help

It lists all the modules that exist.

Eric


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

Re: [Discuss-gnuradio] usrp_siggen.py underruns

[Eric Blossom]

On Thu, Feb 12, 2009 at 11:07:43AM +0100, Dominik Auras wrote:
> Hi!
>
>> Yes, there are lots of ways to do this.  In this particular case,
>> you're going to want to keep track of the worst case and average run
>> times. 
>
> Hm run times may not be the appropriate performance measure in my case.  
> The transmitter is of course designed to run continuously (until I  
> interrupt him). What about interarrival times? I once had the idea to  
> record every buffer update with a timestamp, the difference in the  
> number of samples and the current processor the task is running on. Do  
> you think that these samples may help to reveal the reason for the  
> underruns in my transmitter code?

> Will a big buffer in the USRP1 probably change the behavior? Am I right  
> that with setting fusb_nblocks etc., the buffer size changes?

You can try that, though on Linux the defaults are pretty big already.

> I have just confirmed that the Gaussian PRNG can't send at a bandwidth  
> of near 8 MHz with the USRP2. That was definitely a bad example.

...

> I will try to perform some measurements in the next week. Are there any  
> gnuradio blocks, gnuradio utils available to find the average and worst  
> cases? Oprofile will sample the whole application, not only the link  
> between my last block and the USRP1 sink.
> For your interest, I was measuring the throughput with a modified  
> gr.throttle block. Instead of delaying the stream, I compute the  
> momentaneous rate/throughput and average with a simple IIR (the rate  
> estimate).

I wouldn't try to use gr.throttle for this.  I suggest running your
flow graph with a known amount of known input and throw the output
into a null sink.  Then time the wall and cpu times.

  $ time 

or you could insert a gr.head(...) immediately before the null sink
which will stop the graph after it's copied N samples into the null
sink.  In either case, you're got a graph that will process a known
amount of input and then exit.

You can get time measurements that avoid most of the setup overhead by
just measuring fg.run().  Check the python docs for functions that
measure wall and cpu time.

If your code can't on the average generate the required amount of
output in the required time, then you've got some work to do.  If you
think you've got a case where the average and the worst cases vary
widely, I suspect that the easiest way to go after that is to think
about it!  You wrote the code, right?  You know the expected and worst
case complexity for each block, right?  If not, spend some time with
Knuth, then think about it some more...

Eric


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

[Discuss-gnuradio] Measuring SNR

[Swapna Raj]

Hi,

I am trying to implement a particular channel coding technique as part of my
work(Master's Thesis). I need to test this technique in a fading channel.
But since I have no control over the channel I cannot quantify channel
condition.I need SNR to analyze the performance of the coding technique.The
only solution i thought was to inject noise at source and ensure that
transmission.But this is more like a simulation. I would like to know if
there are better ways to do this.


My second question is more related to Python programming. I need to run a
series of scripts one after the other in my work.Though these scripts work
fine independently. I get an error when I use os.popen(). In most cases I do
not want the control to return back to the calling script.Could any one
suggest what is the best way to do this, or atleast a reference?


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

[Discuss-gnuradio] Frequency dependent problem after syncronizing , Please help!

[Bruhtesfa Ebrahim]

Hey all,

I syncronized my USRPs(one is v4.3 and the other v4.5) by using the USRP
clocking notes on http://www.gnuradio.org/trac/wiki/USRPClockingNotes,
to make them frequency and phase syncronized.

I want to use one as TX and other as RX, with XCVR daugherboards on
them.
But, what I got afre syncronizing is a wierd signal with very small peak
at the center frequency;moreover its whole spectrum level and shape
changes randomly with time . I checked that these problem is not a
reception problem; rather it is a problem created when the master and
slave are set at the same frequency. I check this by making the
following experiment.

(I transmit a carrier @4.96GHz from the slave USRP and a carrier @5GHz
from a signal generator.I verify that both transmissions are working
using a spectrum analyser.Then,I run usrp_fft.py on the master USRP.I
see that the master USRP receives the 5GHz transmission from signal
generator without problem, but when i change the center frequency to
4.96GHz to receive from the slave, I got a weird signal.The signal is
not stable, the noise(whole spectrum) level decreases and increases very
fast and it has only a very small peak at the center frequency.Moreover,
the spectrum changes very much with gain.)

I also tried the reverse(using master as transmitter and slave as
receiver) and also changing the carrier frequencies.But, these weird
behavior remains.

So,anyone having similar problems before? please could you help me with
this issue?

Thanks for your help!

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] Re: Usrp2 and Agere ET131x compatibility

[Yc Park]

Tha's weired. Apparently Ubuntu 8.10 kernel includes Agere driver since 
my laptop perfectly works ever since I installed Ubuntu 8.10.

But when I try the "fund_usrps" while monitoring the network packet,
nothing goes out though eth0 (Agere ET131).

Unfortunately, my laptop does only has a PCMCIA slot, and
my desktop does not have GigE, either.

Well, maybe I can buy a low cost GigE card with a PCI interface for the 
laptop,
but the thing is that I'd like to work on my laptop...



Matt Ettus wrote:
> OK, we got the driver to compile, and spent some time trying to get the
> card to talk to the USRP2.  If you try enough times, it sort of runs,
> but with a lot of noise.  It has the same behavior when running through
> an ethernet switch.  It turns out that the card and/or driver has some
> weird sort of data corruption which puts errors in nearly every received
> packet.  We also got a lot of syslog messages which were warnings from
> the driver.
> 
> When I tried to connect the card to my router and do normal TCP/IP over
> it, it can't even get an IP address from DHCP successfully.
> 
> Basically, I think that the kernel drivers are simply not working, so
> there's no hope of getting these cards to connect to a USRP2 properly if
> they can't connect to anything else either.  The fact that this driver
> has not been included in the main line kernel even though the chipset
> has been out for a long time (its no longer even owned by Agere -- it
> was bought by LSI) tells me that there are much deeper problems.
> 
> There are much better supported interfaces available.  If you are using
> a laptop with this chip in it, I would suggest buying an ExpressCard
> (next generation of PCMCIA) GigE card with a Marvell chip in it.  They
> should be less than $50.
> 
> Matt

-- 
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] Re: some usrp modules are missing

[feldmaus]

Markus Feldmann  gmx.de> writes:
> 
> the  is missing.

As i read, the  Tool is now called
.

Regards Markus




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

Re: [Discuss-gnuradio] usrp_siggen.py underruns

[Dominik Auras]

Hi!

Thanks for your answer.
And thanks Frank Brickle, too!


Uhh, 12.5 MS/s is 50MB/s (16-bit I&Q across the wire).

Sorry, my fault.


Yes, there are lots of ways to do this.  In this particular case,
you're going to want to keep track of the worst case and average run
times. 
Hm run times may not be the appropriate performance measure in my case. 
The transmitter is of course designed to run continuously (until I 
interrupt him). What about interarrival times? I once had the idea to 
record every buffer update with a timestamp, the difference in the 
number of samples and the current processor the task is running on. Do 
you think that these samples may help to reveal the reason for the 
underruns in my transmitter code?



Are you really trying to use the Gaussian PRNG?  If so you'll have to
fix it.  If you look at the code for it, you'll see that it samples a
distribution until it gets something it likes.  The worst case time
can be huge.  The difference between the USRP1 and the USRP2 is the
amount of buffering available in the Tx path in the kernel and on the
board.
No. Just for the case someone tries to reproduce the odd behavior, 
usrp_siggen is widely available. You may understand that I can't hand 
out my transmitter code. I could strip it down to the relevant parts, 
that reproduce the behavior, but since I don't know what could be the 
reason, this becomes an undirected search. Simply I hoped that the 
underruns of the Gaussian PRNG are caused by the same problem.


Will a big buffer in the USRP1 probably change the behavior? Am I right 
that with setting fusb_nblocks etc., the buffer size changes?


I have just confirmed that the Gaussian PRNG can't send at a bandwidth 
of near 8 MHz with the USRP2. That was definitely a bad example.


I will try to perform some measurements in the next week. Are there any 
gnuradio blocks, gnuradio utils available to find the average and worst 
cases? Oprofile will sample the whole application, not only the link 
between my last block and the USRP1 sink.
For your interest, I was measuring the throughput with a modified 
gr.throttle block. Instead of delaying the stream, I compute the 
momentaneous rate/throughput and average with a simple IIR (the rate 
estimate).


Thank you for your help.

Best regards
Dominik


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

Re: [Discuss-gnuradio] Make fails in gr-how-to-write-a-block

[Emil Molin]

2009/2/11 Eric Blossom 

> On Wed, Feb 11, 2009 at 03:45:54PM +0100, Emil Molin wrote:
> > So i want to learn how to write a block but it fails to install
> apparently.
> >
> > after doing ./bootstrap and then ./configure
> >
> > make gives the following message:
> >
> > libtool: Version mismatch error.  This is libtool 2.2.6, but the
> > libtool: definition of this LT_INIT comes from an older release.
> > libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
> > libtool: and run autoconf again.
> > make[3]: *** [howto.lo] Error 63
> > make[2]: *** [check] Error 2
> > make[1]: *** [check-recursive] Error 1
> >
> > well it seems i should recreate aclocal.m4 with macros from libtool 2.2.6
> > problem is i dont know how.
>
>   $ rm aclocal.m4
>  $ ./bootstrap && ./configure ...
>
> Eric


Seemed simple but i get the same error message after another ./bootstrap and
./configure during the ./bootstrap it warns me about alot of things:

../../lib/autoconf/specific.m4:386: AC_USE_SYSTEM_EXTENSIONS is expanded
from...
../../lib/autoconf/specific.m4:459: AC_MINIX is expanded from...
config/lf_cc.m4:33: LF_CONFIGURE_CC is expanded from...
configure.ac:28: the top level
configure.ac:28: warning: AC_RUN_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
configure.ac:28: warning: LTVERSION_VERSION is m4_require'd but not
m4_defun'd
config/libtool.m4:67: LT_INIT is expanded from...
configure.ac:28: warning: LTOBSOLETE_VERSION is m4_require'd but not
m4_defun'd

 this over and over, ./configure goes thru just fine without anything
happening but make still refuses due to the same error.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio