Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion

[Marcus D. Leech]

>
> By default Gnu Radio now schedules each block in its own CPU thread. So
>   
>> there could be
>>   differences in instantaneous latencies down each path.
>>
>> 
> Also- whether a data is processed at the same time in terms of physical
> timeslices in the real world isn't so important, but by definition,
> gnuradio should assure that samples in various block arrive in order to
> the various things- so say in the simplest case you have a vector source
> with [1, 0] in it, and you have two sink blocks connected to it, each
> sink should receive 1,0,1,0 always. Make it more complicated, add a
> const multiplier (*2) in one of the two paths- one sink should receive
> 2,0,2,0... and the other should receive 1,0,1,0. My point is - in-order
> processing and sample order preservation and arrival should be preserved
> or half the DSP in done in gnuradio wouldn't be possible. The Scope sink
> should be grabbing the same number of samples off each of the inputs on
> each work pass, and if one path doesn't have enough available it should
> stop short and not report consuming anything past the smallest available
> number of samples on the inputs, and not render any data seen past the
> shortest available.
>
>   
I'm not sure how the scope sink deals with the "minimum amount of data
available" issue.

But the broader question becomes something like:

   given two (or more) subgraphs where the signals in the subgraphs had
relative phase "foo" at the
   head of those sub-graphs, and the two (or more) subgraphs do
different numbers and types of
   "things" to those signals, is relative phase preserved as seen by a
sink object?

It seems, on reflection, that unless those things *explicitly* modify
phase, then phase should
  naturally be preserved.  This is in stark contrast to the analog
world, where there will be
  minor (or major!) phase-distortions as a result of following different
paths.


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



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

Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion

[Marcus D. Leech]

>
> On 05/26/2011 08:06 PM, Nick Foster wrote:
>   
> The alignment I'm talking about wasn't even relative between RX and TX-
> it was between branches of the RX path such as the real and imaginary
> components of that path when viewed on the scope.
>
>   
So, you're talking about splitting I/Q for the same signal, and joining
them later, and seeing
  phase slip on the scope?

By default Gnu Radio now schedules each block in its own CPU thread.  So
there could be
  differences in instantaneous latencies down each path.




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



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

Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion

[Marcus D. Leech]

>
> USRP1:
> - When we have a very simple flowgraph with a USRP1 sink connected to a
> signal source and a USRP1 source connected to a WX scope- trying to shut
> down the app using the close box causes the USB on the host system to
> freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids
> this problem. This problem exists on many flowgraphs, both GRC generated
> and not- as far as I know it is limited to flowgraphs with both USRP1
> source and sink. This is a serious problem that has hit us on multiple
> platforms and machines and causes unnecessary reboots. It is honestly an
> unacceptable bug.
>
>   
My intuition here is that the "close" box doesn't cause the flow-graph
to do the
  usual "finish the flow-graph" thing.  Which means that the USRP1 is
still streaming, and
  nobody is listening.  For the 'power off' case, the USRP1 resets
itself, and stops streaming
  data, and for ctrl-C, there's built-in logic that causes the
flow-graph to shutdown
  "politely", and send a "please stop streaming" command to the USRP1.
 My suspicion about
  USB freeze-up is that the problem is due to the USB drivers in the
kernel not doing the
  right thing with a deluge of data still arriving when nobody is
actually listening.  Which makes it a
  not-strictly-GnuRadio thing, and more of a USB drivers thing.  Also,
USB is inherently half-duplex,
  which may (somehow) play into scenarios like this--some kind of weird
deadlock problem in the
  kernel USB drivers?




> USRP2 / UHD:
> - With a similar flowgraph to the one above, changing the secs/div
> causes the various traces to change phase relative to one another but
> this doesn't happen when a USRP1 source is substituted. However, I
> believe this is indicative of a deeper problem. We also see with the
> same flowgraph and a slider that controls both the TX and RX frequencies
> simultaneously, the flowgraph gets into a place where it seems to be
> getting data but it no longer represents the state of what's coming in
> and we also see the phase slippage. Long story short, create a flowgraph
> with a UHD (USRP2) sink and source with a siggen at a fixed
> frequency/amplitude, a wx scope, and a slider that sets the TX+RX
> frequencies to the slider value. Direct connect the TX to the RX with an
> SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX
> this seems to give various results. Do the same thing with a USRP1 for
> comparison. To me it seems like UHD is losing data or the various paths
> in the flowgraph get out of whack with eachother. There were no O's or
> U's printed.
>
> We were trying to do a simple VNA in UHD and it just doesn't work as
> expected, but switching it all over to a USRP1 its fine and dandy.
>
>
>   
There's a tremendous amount of buffering inside a Gnu Radio flow-graph,
which can
  easily cause *seconds* of latency.  The buffer-sizing algorithm is
complicated, and the
  buffering at any point in the graph is calculated by whatever is
downstream, including
  decimators.

I've long opined that the buffer-sizing (with its inherent latency)
isn't actually correct all the time,
  but I admit to not having offered any meaningful solutions.  I don't
know whether UHD exacerbates
  this problem or not.

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



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

Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion

[Brett L. Trotter]

On 05/26/2011 08:06 PM, Nick Foster wrote:
> On Thu, 2011-05-26 at 19:29 -0500, Brett L. Trotter wrote:
>> USRP1:
>> - When we have a very simple flowgraph with a USRP1 sink connected to a
>> signal source and a USRP1 source connected to a WX scope- trying to shut
>> down the app using the close box causes the USB on the host system to
>> freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids
>> this problem. This problem exists on many flowgraphs, both GRC generated
>> and not- as far as I know it is limited to flowgraphs with both USRP1
>> source and sink. This is a serious problem that has hit us on multiple
>> platforms and machines and causes unnecessary reboots. It is honestly an
>> unacceptable bug.
> UHD or gr-usrp? What OS? What version of libusb? Do all USB devices
> "freeze" or just the USRP? Does power cycling the USRP un-freeze it?
> This is definitely not something I've seen before.
gr-usrp
Ubuntu x86_64 with libusrp /usr/lib/libusb-0.1.so.4.4.4
RHEL-6 x86-64 with libusrp /usr/lib64/libusb-0.1.so.4.4.4
I believe I've also seen it on FC14 and RHEL5

USB devices continue to function, but it will not recognize new
connection events of any device, the USRP will not reinitialize even if
power cycled and reconnected, even to a different port.


>> USRP2 / UHD:
>> - With a similar flowgraph to the one above, changing the secs/div
>> causes the various traces to change phase relative to one another but
>> this doesn't happen when a USRP1 source is substituted. However, I
>> believe this is indicative of a deeper problem. We also see with the
>> same flowgraph and a slider that controls both the TX and RX frequencies
>> simultaneously, the flowgraph gets into a place where it seems to be
>> getting data but it no longer represents the state of what's coming in
>> and we also see the phase slippage. Long story short, create a flowgraph
>> with a UHD (USRP2) sink and source with a siggen at a fixed
>> frequency/amplitude, a wx scope, and a slider that sets the TX+RX
>> frequencies to the slider value. Direct connect the TX to the RX with an
>> SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX
>> this seems to give various results. Do the same thing with a USRP1 for
>> comparison. To me it seems like UHD is losing data or the various paths
>> in the flowgraph get out of whack with eachother. There were no O's or
>> U's printed.
> If you lose samples somewhere in the chain, which can happen, the TX and
> RX paths will change their relative alignment. Have you tried reducing
> your sample rate, or the refresh rate on the graphical sink? The various
> graphical sinks can be very CPU-intensive. 
>
> It is generally not a great idea to rely on the TX and RX paths staying
> aligned with respect to each other all the time. The fact that the USRP1
> seems to in your test is a bonus, but I wouldn't rely on that going
> forward either.
>
> If you require the TX and RX paths to maintain a fixed relationship, the
> USRP2 with UHD will let you use timed samples to achieve this down to
> 10ns. You could also align your TX and RX paths in your application,
> using known TX waveforms to correlate the RX against. This approach
> probably fits best into your design flow (don't have to code C++ with
> UHD).
>
> --n
The alignment I'm talking about wasn't even relative between RX and TX-
it was between branches of the RX path such as the real and imaginary
components of that path when viewed on the scope.



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

Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion

[Brett L. Trotter]

Replying to self- here's another case on the USRP2/UHD-

TX Path: Sig Source -> UHD (USRP2) Sink

RX Path: UHD (USRP2) Source -> Band Pass Filter -> Scope Sink

It seems that any kind of filter, even with appropriate calculation of
the rate coming out of the filter taking into account decimation will
yield a very delayed signal on the scope sink. The same problem does not
happen on USRP1 when the sinks are swapped out and the sample rates
adjusted appropriately.


On 05/26/2011 07:29 PM, Brett L. Trotter wrote:
> USRP1:
> - When we have a very simple flowgraph with a USRP1 sink connected to a
> signal source and a USRP1 source connected to a WX scope- trying to shut
> down the app using the close box causes the USB on the host system to
> freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids
> this problem. This problem exists on many flowgraphs, both GRC generated
> and not- as far as I know it is limited to flowgraphs with both USRP1
> source and sink. This is a serious problem that has hit us on multiple
> platforms and machines and causes unnecessary reboots. It is honestly an
> unacceptable bug.
>
> USRP2 / UHD:
> - With a similar flowgraph to the one above, changing the secs/div
> causes the various traces to change phase relative to one another but
> this doesn't happen when a USRP1 source is substituted. However, I
> believe this is indicative of a deeper problem. We also see with the
> same flowgraph and a slider that controls both the TX and RX frequencies
> simultaneously, the flowgraph gets into a place where it seems to be
> getting data but it no longer represents the state of what's coming in
> and we also see the phase slippage. Long story short, create a flowgraph
> with a UHD (USRP2) sink and source with a siggen at a fixed
> frequency/amplitude, a wx scope, and a slider that sets the TX+RX
> frequencies to the slider value. Direct connect the TX to the RX with an
> SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX
> this seems to give various results. Do the same thing with a USRP1 for
> comparison. To me it seems like UHD is losing data or the various paths
> in the flowgraph get out of whack with eachother. There were no O's or
> U's printed.
>
> We were trying to do a simple VNA in UHD and it just doesn't work as
> expected, but switching it all over to a USRP1 its fine and dandy.
>
>
>
>
> On a general note- I think there should be two new block sets added:
> 1) A simple source block that provides samples in the appropriate format
> (float, complex, etc depending on the _f / _c etc) which generates as
> fast as possible and counts how many it generates in a second which gets
> output on a float output.
>
> 2) The same thing but a consumer.
>
> The idea being it would help diagnose blocks that end up putting out
> more or less data than they take in and whose decimation/interpolation
> rates aren't apparent. For instance, I have a decimating filter block
> that appears to actually be producing more samples than it takes in,
> causing the data to show up almost 30 seconds later on the scope which
> is set at the source's data rate. I'd love to put the timed consumer and
> timed provider blocks on either side and see how the in/out amounts compare.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

[Discuss-gnuradio] about signal process window design?

[梁初阳]

Hi all:
   When I try to implement some spectrum estimate algorithm encounter a 
problem like this hope some one can help me out ,cause I really don't 
understand how to design
the window in window.py which I have post below or in the attachment.

please help me figure out the midn(fft_size) ?problem 



Thanks all! God bless you!



  File "usrp_welch_rt.py", line 327, in 
    main ()
  File "usrp_welch_rt.py", line 323, in main
    app = stdgui2.stdapp(app_top_block, "USRP Welch", nstatus=1)
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", line 
36, in __init__
    wx.App.__init__ (self, redirect=False)
  File "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
7978, in __init__
    self._BootstrapApp()
  File "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
7552, in _BootstrapApp
    return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", line 
39, in OnInit
    frame = stdframe (self.top_block_maker, self.title, self._nstatus)
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", line 
60, in __init__
    self.panel = stdpanel (self, self, top_block_maker)
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py", line 
81, in __init__
    self.top_block = top_block_maker (frame, self, vbox, sys.argv)
  File "usrp_welch_rt.py", line 136, in __init__
    mywindow1 = window.blackman2(options.fft_size)    
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/window.py", line 102, 
in blackman2
    for index in xrange(midn(fft_size)+1):
NameError: global name 'midn' is not defined





window.py content below:

'''
Routines for designing window functions.
'''

import math
from gnuradio import gr

def izero(x):
    izeroepsilon = 1e-21
    halfx = x/2.0
    accum = u = n = 1
    while 1:
    temp = halfx/n
    n += 1
    temp *= temp
    u *= temp
    accum += u
    if u >= IzeroEPSILON*sum:
    break
    return accum

def midm1(fft_size):
    return (fft_size - 1)/2

def midp1(fft_size):
    return (fft_size+1)/2

def freq(fft_size):
    return 2.0*math.pi/fft_size

def rate(fft_size):
    return 1.0/(fft_size >> 1)

def expn(fft_size):
    math.log(2.0)/(midn(fft_size) + 1.0)
    
def hamming(fft_size):
    window = []
    for index in xrange(fft_size):
    window.append(0.54 - 0.46 * math.cos (2 * math.pi / fft_size * index))  
# Hamming window
    return window

def hanning(fft_size):
    window = []
    for index in xrange(fft_size):
    window.append(0.5 - 0.5 * math.cos (2 * math.pi / fft_size * index))  
#  von Hann window
    return window

def welch(fft_size):
    window = [0 for i in range(fft_size)]
    j = fft_size-1
    for index in xrange(midn(fft_size)+1):
    window[j] = window[index] = (1.0 - math.sqrt((index - midm1(fft_size)) 
/ midp1(fft_size)))
    j -= 1
    return window

def parzen(fft_size):
    window = [0 for i in range(fft_size)]
    j = fft_size-1
    for index in xrange(midn(fft_size)+1):
    window[j] = window[index] = (1.0 - math.abs((index - midm1(fft_size)) / 
midp1(fft_size)))
    j -= 1
    return window

def bartlett(fft_size):
    mfrq = freq(fft_size)
    angle = 0
    window = [0 for i in range(fft_size)]
    j = fft_size-1
    for index in xrange(midn(fft_size)+1):
    window[j] = window[index] = angle
    angle += freq
    j -= 1
    return window
    
def blackman2(fft_size):
    mfrq = freq(fft_size)
    angle = 0
    window = [0 for i in range(fft_size)]
    j = fft_size-1
    for index in xrange(midn(fft_size)+1):
    cx = math.cos(angle)
    window[j] = window[index] = (.34401 + (cx * (-.49755 + (cx * .15844
    angle += freq
    j -= 1
    return window
    
def blackman3(fft_size):
    mfrq = freq(fft_size)
    angle = 0
    window = [0 for i in range(fft_size)]
    j = fft_size-1
    for index in xrange(midn(fft_size)+1):
    cx = math.cos(angle)
    window[j] = window[index] = (.21747 + (cx * (-.45325 + (cx * (.28256 - 
(cx * .04672))
    angle += freq
    j -= 1
    return window
    
def blackman4(fft_size):
    mfrq = freq(fft_size)
    angle = 0
    window = [0 for i in range(fft_size)]
    j = fft_size-1
    for index in xrange(midn(fft_size)+1):
    cx = math.cos(angle)
    window[j] = window[index] = (.084037 + (cx * (-.29145 + (cx * (.375696 
+ (cx * (-.20762 + (cx * .041194
    angle += freq
    j -= 1
    return window
    
def exponential(fft_size):
    expsum = 1.0
    window = [0 for i in range(fft_size)]
    j = fft_size-1
    for index in xrange(midn(fft_size)+1):
  window[j] = window[i] = (expsum - 1.0)
  expsum *= expn(fft_size)
  j -= 1
    return window

def riemann(fft_size):
    sr1 = freq(fft_size)
    window = [0 for i in range(fft_size)]
    j = fft_size-1
    for index in xrange(midn(fft_size)):
    if 

Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion

[Nick Foster]

On Thu, 2011-05-26 at 19:29 -0500, Brett L. Trotter wrote:
> USRP1:
> - When we have a very simple flowgraph with a USRP1 sink connected to a
> signal source and a USRP1 source connected to a WX scope- trying to shut
> down the app using the close box causes the USB on the host system to
> freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids
> this problem. This problem exists on many flowgraphs, both GRC generated
> and not- as far as I know it is limited to flowgraphs with both USRP1
> source and sink. This is a serious problem that has hit us on multiple
> platforms and machines and causes unnecessary reboots. It is honestly an
> unacceptable bug.

UHD or gr-usrp? What OS? What version of libusb? Do all USB devices
"freeze" or just the USRP? Does power cycling the USRP un-freeze it?
This is definitely not something I've seen before.

> 
> USRP2 / UHD:
> - With a similar flowgraph to the one above, changing the secs/div
> causes the various traces to change phase relative to one another but
> this doesn't happen when a USRP1 source is substituted. However, I
> believe this is indicative of a deeper problem. We also see with the
> same flowgraph and a slider that controls both the TX and RX frequencies
> simultaneously, the flowgraph gets into a place where it seems to be
> getting data but it no longer represents the state of what's coming in
> and we also see the phase slippage. Long story short, create a flowgraph
> with a UHD (USRP2) sink and source with a siggen at a fixed
> frequency/amplitude, a wx scope, and a slider that sets the TX+RX
> frequencies to the slider value. Direct connect the TX to the RX with an
> SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX
> this seems to give various results. Do the same thing with a USRP1 for
> comparison. To me it seems like UHD is losing data or the various paths
> in the flowgraph get out of whack with eachother. There were no O's or
> U's printed.

If you lose samples somewhere in the chain, which can happen, the TX and
RX paths will change their relative alignment. Have you tried reducing
your sample rate, or the refresh rate on the graphical sink? The various
graphical sinks can be very CPU-intensive. 

It is generally not a great idea to rely on the TX and RX paths staying
aligned with respect to each other all the time. The fact that the USRP1
seems to in your test is a bonus, but I wouldn't rely on that going
forward either.

If you require the TX and RX paths to maintain a fixed relationship, the
USRP2 with UHD will let you use timed samples to achieve this down to
10ns. You could also align your TX and RX paths in your application,
using known TX waveforms to correlate the RX against. This approach
probably fits best into your design flow (don't have to code C++ with
UHD).

--n

> 
> We were trying to do a simple VNA in UHD and it just doesn't work as
> expected, but switching it all over to a USRP1 its fine and dandy.
> 
> 
> 
> 
> On a general note- I think there should be two new block sets added:
> 1) A simple source block that provides samples in the appropriate format
> (float, complex, etc depending on the _f / _c etc) which generates as
> fast as possible and counts how many it generates in a second which gets
> output on a float output.
> 
> 2) The same thing but a consumer.
> 
> The idea being it would help diagnose blocks that end up putting out
> more or less data than they take in and whose decimation/interpolation
> rates aren't apparent. For instance, I have a decimating filter block
> that appears to actually be producing more samples than it takes in,
> causing the data to show up almost 30 seconds later on the scope which
> is set at the source's data rate. I'd love to put the timed consumer and
> timed provider blocks on either side and see how the in/out amounts compare.

This is a cool idea, but I'm not sure how it could be implemented in
Gnuradio's scheduler. I'll have to think about that one.

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



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

Re: [Discuss-gnuradio] How to speed up spectrum sensing?

[Yang]

Thank you for replying.

I have already tried different fft size (256, 128, 32, etc) but as you said it 
did not change my sensing time. I also change my decimation but no luck too.

I intend to sense a broad band, say, 20M or 40M. But it seems this script costs 
too much time working. Should I retune or not? Because if I do not it only 
sense a very narrow band.
-- 
Yang
Sent with Sparrow
On 2011年5月27日星期五 at 上午4:15, devin kelly wrote: 
> Changing the fft size won't change your sensing time that much unless the 
> machine you're using is really slow or the fft size is outrageous. What fft 
> sizes are you using?
> 
> What will affect your sensing time more is the sampling/decimation rate you 
> sent, the tune delay, and the dwell delay. Be careful when changing the tune 
> delay, if it is too short your data will be corrupted. 
> 
> Look at the usrp_spectrum_sense.py code and try this:
> 
> > $ python usrp_spectrum_sense.py --help 
> 
> Also, since you're only trying to look at a narrow band, 
> usrp_spectrum_sense.py isn't for you. This script is really for looking at 
> different bands and different times, but you really only need to look at one 
> band. Basically, you never need to retune and a lot of that script does is 
> retune. 
> 
> Devin
> 
> On Sat, May 14, 2011 at 8:11 AM, Alexander Chemeris 
>  wrote:
> > On Fri, May 13, 2011 at 14:25, Tom Rondeau  wrote:
> > > On Fri, May 13, 2011 at 11:12 AM, Yang  wrote:
> > >>
> > >> Hi all,
> > >> I am working on the implementation of dynamic spectrum access with
> > >> gnuradio and usrp2. I modified usrp_spectrum_sense for usrp2 to do the
> > >> sensing job. However, I find the sensing speed is intolerably slow, 
> > >> which is
> > >> about 1s for 1MHz.
> > >
> > > Yang,
> > > Considering that the USRP2 can sample 25 MHz, you should be able to 
> > > capture
> > > that bandwidth instantaneously.
> > 
> > Note, that while USRP2 can sample 25MHz, you probably can't receive
> >  that much in your PC. I'm working with USRP N210 and having troubles
> >  with receiving even 16 MSPS.
> > 
> >  --
> >  Regards,
> > Alexander Chemeris.
> > 
> >  ___
> >  Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> 
> 
> -- 
> http://users.wpi.edu/~dkelly/
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion

[Brett L. Trotter]

USRP1:
- When we have a very simple flowgraph with a USRP1 sink connected to a
signal source and a USRP1 source connected to a WX scope- trying to shut
down the app using the close box causes the USB on the host system to
freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids
this problem. This problem exists on many flowgraphs, both GRC generated
and not- as far as I know it is limited to flowgraphs with both USRP1
source and sink. This is a serious problem that has hit us on multiple
platforms and machines and causes unnecessary reboots. It is honestly an
unacceptable bug.

USRP2 / UHD:
- With a similar flowgraph to the one above, changing the secs/div
causes the various traces to change phase relative to one another but
this doesn't happen when a USRP1 source is substituted. However, I
believe this is indicative of a deeper problem. We also see with the
same flowgraph and a slider that controls both the TX and RX frequencies
simultaneously, the flowgraph gets into a place where it seems to be
getting data but it no longer represents the state of what's coming in
and we also see the phase slippage. Long story short, create a flowgraph
with a UHD (USRP2) sink and source with a siggen at a fixed
frequency/amplitude, a wx scope, and a slider that sets the TX+RX
frequencies to the slider value. Direct connect the TX to the RX with an
SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX
this seems to give various results. Do the same thing with a USRP1 for
comparison. To me it seems like UHD is losing data or the various paths
in the flowgraph get out of whack with eachother. There were no O's or
U's printed.

We were trying to do a simple VNA in UHD and it just doesn't work as
expected, but switching it all over to a USRP1 its fine and dandy.




On a general note- I think there should be two new block sets added:
1) A simple source block that provides samples in the appropriate format
(float, complex, etc depending on the _f / _c etc) which generates as
fast as possible and counts how many it generates in a second which gets
output on a float output.

2) The same thing but a consumer.

The idea being it would help diagnose blocks that end up putting out
more or less data than they take in and whose decimation/interpolation
rates aren't apparent. For instance, I have a decimating filter block
that appears to actually be producing more samples than it takes in,
causing the data to show up almost 30 seconds later on the scope which
is set at the source's data rate. I'd love to put the timed consumer and
timed provider blocks on either side and see how the in/out amounts compare.


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

Re: [Discuss-gnuradio] How to speed up spectrum sensing?

[devin kelly]

Changing the fft size won't change your sensing time that much unless the
machine you're using is really slow or the fft size is outrageous.  What fft
sizes are you using?

What will affect your sensing time more is the sampling/decimation rate you
sent, the tune delay, and the dwell delay.  Be careful when changing the
tune delay, if it is too short your data will be corrupted.

Look at the usrp_spectrum_sense.py code and try this:

$ python usrp_spectrum_sense.py --help


Also, since you're only trying to look at a narrow band,
usrp_spectrum_sense.py isn't for you. This script is really for looking at
different bands and different times, but you really only need to look at one
band.  Basically, you never need to retune and a lot of that script does is
retune.

Devin

On Sat, May 14, 2011 at 8:11 AM, Alexander Chemeris <
alexander.cheme...@gmail.com> wrote:

> On Fri, May 13, 2011 at 14:25, Tom Rondeau  wrote:
> > On Fri, May 13, 2011 at 11:12 AM, Yang  wrote:
> >>
> >> Hi all,
> >> I am working on the implementation of dynamic spectrum access with
> >> gnuradio and usrp2. I modified usrp_spectrum_sense for usrp2 to do the
> >> sensing job. However, I find the sensing speed is intolerably slow,
> which is
> >> about 1s for 1MHz.
> >
> > Yang,
> > Considering that the USRP2 can sample 25 MHz, you should be able to
> capture
> > that bandwidth instantaneously.
>
> Note, that while USRP2 can sample 25MHz, you probably can't receive
> that much in your PC. I'm working with USRP N210 and having troubles
> with receiving even 16 MSPS.
>
> --
> Regards,
> Alexander Chemeris.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
http://users.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Store data with usrp_spectrum_sense.py

[devin kelly]

I did a project similar to this. Look at this structure

m = parse_msg(tb.msgq.delete_head())

There is a field called data (I think) that contains the magnitude of the
sweep.  You record m.data to a file (like a csv, hdf5, or binary file).
 Keep in mind that you have to do the equivalent of fftshift.

Hope that helps.

On Sat, May 21, 2011 at 2:04 PM, Miguel Angel Sanz Rodriguez <
mikys...@hotmail.com> wrote:

>  Hi everyone,
> I am new in GNUradio and I want to sense the spectrum of Wifi from 2.4G to
> 2.5 G with a USRP.
> I have been reading through a lot of discussions in the forum but I have
> not been able to store any data using usrp_spectrum_sense.py. I want to
> analyze this data with matlab, but I dont get any suitable file after
> running spectrum sense. I know that I have to modify the script, but I dont
> know how. I am quite bad at programming, so I would appreciate so much a way
> to find the solution(it must be very easy, but I am usless in programming)
> Thanks in advance for your help
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
http://users.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Signal Generator synced to PPS & Reference wave

[Sam Price]

Has anyone made a Signal generator that can be synced to the PPS, and
10MHz input?

-- 
Thank you,

Sam Price
(707) 742-3726

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

Re: [Discuss-gnuradio] Reconfigure example with lock/disconnect/connect/unlock code hangs randomly

[Johannes Schmitz]

There should be another sleep in the reconfigure method to make it working fine.

   def reconfigure(self):
   self.lock()
   self.disconnect(self.h_block_one)
   self.connect(self.h_block_two)
   sleep(0.0001)
   self.unlock()

I am not sure how long we have to sleep in order to fix the problem.

- Johannes

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

[Discuss-gnuradio] Reconfigure example with lock/disconnect/connect/unlock code hangs randomly

[Johannes Schmitz]

Hey guys,
I have written some example code to learn how to dynamically
reconfigure gnuradio based on events generated by probe blocks and a
watcher thread.
First I thought everything is running very well but later I noticed
that the program hangs if you let it run long enough.
If you uncomment the sleep(0.0001) it seems to be working fine but says:

"Exception in thread Thread-1 (most likely raised during interpreter shutdown)"

We are running Ubuntu 10.10 over here.

Can somebody please run the code and confirm this?
Looks like a bug for me.

---

#!/usr/bin/env python

from gnuradio import gr
import gnuradio.gr.gr_threading as _threading
from time import sleep

class h_block_one(gr.hier_block2):
def __init__(self):
gr.hier_block2.__init__(self, "foo",
gr.io_signature(0, 0, 0),
gr.io_signature(0, 0, 0))

vec = range(100)

self.source = gr.vector_source_f(vec,True,1)
self.probe = gr.probe_signal_f()
self.sink = gr.null_sink(gr.sizeof_float)
self.connect(self.source, self.probe)

def level_one(self):
return self.probe.level()


class h_block_two(gr.hier_block2):
def __init__(self):
gr.hier_block2.__init__(self, "bar",
gr.io_signature(0, 0, 0),
gr.io_signature(0, 0, 0))

vec = range(100)

self.source = gr.vector_source_f(vec,True,1)
self.probe = gr.probe_signal_f()
self.sink = gr.null_sink(gr.sizeof_float)
self.connect(self.source, self.probe)

def level_two(self):
return self.probe.level()


class probe_this(gr.top_block):

def __init__(self):
gr.top_block.__init__(self, 'Probe Reconfigure Test')

self.h_block_one = h_block_one()
self.h_block_two = h_block_two()
self.connect(self.h_block_one)

def level_one(self):
return self.h_block_one.level_one()

def level_two(self):
return self.h_block_two.level_two()

def reconfigure(self):
self.lock()
self.disconnect(self.h_block_one)
self.connect(self.h_block_two)
self.unlock()

def conf_back(self):
self.lock()
self.disconnect(self.h_block_two)
self.connect(self.h_block_one)
#sleep(0.0001)
self.unlock()

class _probe_watcher_thread(_threading.Thread):
def __init__(self, level_one, reconfigure, level_two, conf_back):
_threading.Thread.__init__(self)
self.setDaemon(1)
self.level_one = level_one
self.reconfigure = reconfigure
self.level_two = level_two
self.conf_back = conf_back
self.confed = False
self.keep_running = True
self.start()

def run(self):
while self.keep_running:
if self.confed:
if self.level_two() > 50:
self.conf_back()
self.confed = False
print 'reconfiguring'
else:
if self.level_one() > 50:
self.reconfigure()
self.confed = True
print 'reconfiguring back'
#if self.level_one and self.level_two:
#print 'foo', self.level_one()
#print 'bar', self.level_two()

if __name__=="__main__":

def callback(msg):
print 'received:', msg

tb = probe_this()
watcher = 
_probe_watcher_thread(tb.level_one,tb.reconfigure,tb.level_two,tb.conf_back)
tb.start()

sleep(100)

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

Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?

[Marcus D. Leech]

On 26/05/2011 9:55 AM, Michael Dickens wrote:


It would be great if you could share with the list example code snippets of how 
you do the pipes.  For example: Where in an online repository one can find such 
code.

I think that's what Jeff was getting at: that "we" are providing IANAL advice rather than 
code examples.  I, for one, have never actually tried the pipes -- I've just heard that they are 
possible and that using them does not form a "greater work" in the GPL sense. - MLD


___
Actually, my SIDSuite code uses this a little bit, in that data 
recording is handled outside of Gnu Radio.  The basic idea is that there's
  a shell script that sets up the environment (creates the FIFO files, 
starts the external programs in the background, etc), then the
  Gnu Radio flow-graph is called.  The flow-graphs just use "File 
Source" and "File Sink" with buffering turned off--as far as Gnu Radio
  is concerned, it's writing to a file, but in fact, it's a FIFO file 
or "named pipe".


See:

http://www.sbrac.org/files/sidsuite.tar.gz

It doesn't do it as much as other code that I've written, but it gives 
one a flavour for how the pipes are used.


The other "trick" that I use is to use the XMLRPC server stuff that Josh 
put in GRC--it allows you to set flowgraph variables from an

  outside program, which is really great!




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

Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?

[Michael Dickens]

On May 25, 2011, at 6:23 PM, Marcus D. Leech wrote:
> Actually, IANAL is a perfectly-valid response.  IP licensing arrangements are 
> complicated and studded with sinkholes and minefields.

Yes; exactly.  Think of it this way: If we don't put "IANAL, TINLA" then one 
could possibly, if IMHO unreasonably, interpret what we write as legal advice 
and thus we could possibly even be held liable for the advice.  Although 
putting in that text does not entirely protect us, it makes the context clear 
that -this is not legal advice- and should not be interpreted to be so; it is 
just a discussion of legal issues, and may simply be people's opinions that 
wouldn't hold water in a court of law.  It's sort of like the "CONFIDENTIALITY 
NOTICE" many professional organizations require their employees to use when 
sending emails -- it cannot legally be enforced, but without it the 
organization could actually be liable for its contents (IIRC, WIRED did a piece 
on this issue in the last year, and this was their conclusion).  And, no, I'm 
not kidding: in the litigious US society, these non-legally binding annoyances 
are actually necessary to CYOA.

> I've avoided the issue (I hope!) in my proprietary "stuff" that uses Gnu 
> Radio by doing two things:
> 
> o minimizing the "stuff" that I do inside the flow-graph if I can 
> conveniently do it outside
> o speaking to the flowgraph via named pipes and moving the proprietary 
> and user-goop into non Gnu Radio compiled
>code.

That sounds like the correct way to go in order to keep your code separate from 
GNU Radio's, but, of course, TINLA etc. ;)

It would be great if you could share with the list example code snippets of how 
you do the pipes.  For example: Where in an online repository one can find such 
code.

I think that's what Jeff was getting at: that "we" are providing IANAL advice 
rather than code examples.  I, for one, have never actually tried the pipes -- 
I've just heard that they are possible and that using them does not form a 
"greater work" in the GPL sense. - MLD


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

Re: [Discuss-gnuradio] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)

[Tom Rondeau]

On Thu, May 26, 2011 at 12:31 PM, Arturo Rinaldi wrote:

>  Il 26/05/2011 13:05, Robert McGwier ha scritto:
>
> On either my Ubuntu box or my Fedora box,  2.9.0 fails. I used 2.8.0 and
> all is well.
>
> I get it from sdcc sourceforge site and was done in a few minutes.
>
> Bob
> On May 26, 2011 6:15 AM, "Tom Rondeau"  wrote:
> > On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech 
> wrote:
> >
> >> On 05/25/2011 09:01 PM, Arturo Rinaldi wrote:
> >>
> >> i have an issue regarding the SDCC executable in the building of
> gnuradio
> >> 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as :
> >>
> >> *export PATH=/usr/libexec/sdcc:$PATH
> >>
> >> *as written in the build guide but I still get the error in the
> configure
> >> process :
> >>
> >> *USRP requires sdcc. sdcc not found. See http://sdcc.sf.net
> >> Unable to find firmware compiler SDCC.
> >> Not building component usrp.*
> >>
> >> Where am i wrong ? If I launch from terminal
> >>
> >> *$ sdcc -v *
> >>
> >> it returns :
> >>
> >> *$ SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0
> >> #6037 (Apr 13 2011) (Linux)*
> >>
> >> thx in advance. All the others pre-requisites are fully satisfied.
> >>
> >> Regards, Arturo.
> >>
> >> A few points:
> >>
> >> If you're using UHD, you don't need component "USRP".
> >>
> >> Since Fedora 14, they have shipped SDCC version 3.0 which has different
> >> command names, and also
> >> some difference syntax for built-in variable-type intrinsics, so the
> >> USRP1 firmware won't build under
> >> SDCC-3.0 anyway.
> >>
> >> The configure script for Gnu Radio looks for SDCC using the SDCC version
> >> 2.X command names, and
> >> so for a system with SDCC 3.0, this will fail.
> >>
> >> But, once again, if you're using UHD (which I *strongly* recommend), you
> >> don't need the component
> >> "usrp" and "gr-usrp" to be built anyway.
> >>
> >> I haven't upgraded any of my systems to F15 yet, but when I do, expect
> the
> >> famous (almost!)
> >> "build-gnuradio" script to get updated to deal with F15.
> >>
> >> --
> >> Principal Investigator
> >> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
> >>
> >>
> > And if you do really want to get the usrp and gr-usrp components to
> build,
> > you should be able to easily install a 2.9 version of SDCC.
> >
> > Tom
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>  thank you very much to all of you. I'll do my test on my Fedora 15 system
> as soon as possible. I think the best solution is to build 2.9.0-7 from
> source and then install.
>
> @ Bob
>
> never experienced any issue on Ubuntu with sdcc 2.9.0-5. I also remember
> that building from source on a Fedora 14 worked well like described in the
> guide on the gnuradio website.
>
> Best Regards to all,
>
>  Arturo
>


Thanks all. I've built using SDCC 2.9.0 in Ubuntu, which is the native
version in 11.04, with no problems. So I didn't build or install it from
another package. If someone else is having issues with a 2.9 version and can
confirm Bob's problem, let me know.

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

Re: [Discuss-gnuradio] Unexpected energy peak sensing thermal noise and using usrp_spectrum_sense.py

[Marcus D. Leech]

>
> Thank you for answering but I cannot understand what you mean with "The USRP
> is not a measurement receiver". If USRP was not a measurement receiver,
> which is its utility? Moreover, if it is not a measurement receiver what is
> the result memorized in m.data that is the output of usrp_spectrum_sense.py?
> When I use a WiFi antenna I can receive (and measure) the energy of WiFi
> channels. The problem arises without antenna becasue USRP measures a signal
> that cannot exist! Furthermore, such a signal is always at the beginning of
> the sensed bandwidth, so this has not any sense!
>
> Any idea about that? Thank you!
>
>   
You should perhaps do some diagnosis using something other than
spectrum_sense.py.

Try a simple FFT display with your tuner tuned to different frequencies.
 Does an apparent
  spur appear in those cases as well?

A general observation is that essentially-all receivers will experience
spurs in the RF, IF and
  occasionally baseband stages.  These are internally-generated, small,
signals narrowband in
  nature that come from the internal operations of the receiver itself.

A "measurement receiver" is one that has been engineered specifically to
drastically reduce spurs, and
  also to have a *calibrated* (as in laboratory-quality calibrated)
response that is predictable,
  specified, and flat across the entire tunable bandwidth of the
receiver.  Providing that kind of
  functionality requires design and *construction* techniques that are
very, very, expensive.

However, that doesn't mean that the hardware can't be used for
measurement, you just have to
  be aware of things like changes in response at different frequencies,
and calibrate them yourself.

I would suggest that you use a simple FFT display at various frequencies
to help with diagnosis.

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



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

Re: [Discuss-gnuradio] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)

[Arturo Rinaldi]

Il 26/05/2011 13:05, Robert McGwier ha scritto:


On either my Ubuntu box or my Fedora box,  2.9.0 fails. I used 2.8.0 
and all is well.


I get it from sdcc sourceforge site and was done in a few minutes.

Bob

On May 26, 2011 6:15 AM, "Tom Rondeau" > wrote:
> On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech > wrote:

>
>> On 05/25/2011 09:01 PM, Arturo Rinaldi wrote:
>>
>> i have an issue regarding the SDCC executable in the building of 
gnuradio

>> 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as :
>>
>> *export PATH=/usr/libexec/sdcc:$PATH
>>
>> *as written in the build guide but I still get the error in the 
configure

>> process :
>>
>> *USRP requires sdcc. sdcc not found. See http://sdcc.sf.net
>> Unable to find firmware compiler SDCC.
>> Not building component usrp.*
>>
>> Where am i wrong ? If I launch from terminal
>>
>> *$ sdcc -v *
>>
>> it returns :
>>
>> *$ SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0
>> #6037 (Apr 13 2011) (Linux)*
>>
>> thx in advance. All the others pre-requisites are fully satisfied.
>>
>> Regards, Arturo.
>>
>> A few points:
>>
>> If you're using UHD, you don't need component "USRP".
>>
>> Since Fedora 14, they have shipped SDCC version 3.0 which has different
>> command names, and also
>> some difference syntax for built-in variable-type intrinsics, so the
>> USRP1 firmware won't build under
>> SDCC-3.0 anyway.
>>
>> The configure script for Gnu Radio looks for SDCC using the SDCC 
version

>> 2.X command names, and
>> so for a system with SDCC 3.0, this will fail.
>>
>> But, once again, if you're using UHD (which I *strongly* 
recommend), you

>> don't need the component
>> "usrp" and "gr-usrp" to be built anyway.
>>
>> I haven't upgraded any of my systems to F15 yet, but when I do, 
expect the

>> famous (almost!)
>> "build-gnuradio" script to get updated to deal with F15.
>>
>> --
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org 


>>
>>
> And if you do really want to get the usrp and gr-usrp components to 
build,

> you should be able to easily install a 2.9 version of SDCC.
>
> Tom


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
thank you very much to all of you. I'll do my test on my Fedora 15 
system as soon as possible. I think the best solution is to build 
2.9.0-7 from source and then install.


@ Bob

never experienced any issue on Ubuntu with sdcc 2.9.0-5. I also remember 
that building from source on a Fedora 14 worked well like described in 
the guide on the gnuradio website.


Best Regards to all,

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

Re: [Discuss-gnuradio] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)

[Robert McGwier]

On either my Ubuntu box or my Fedora box,  2.9.0 fails. I used 2.8.0 and all
is well.

I get it from sdcc sourceforge site and was done in a few minutes.

Bob
On May 26, 2011 6:15 AM, "Tom Rondeau"  wrote:
> On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech 
wrote:
>
>> On 05/25/2011 09:01 PM, Arturo Rinaldi wrote:
>>
>> i have an issue regarding the SDCC executable in the building of gnuradio
>> 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as :
>>
>> *export PATH=/usr/libexec/sdcc:$PATH
>>
>> *as written in the build guide but I still get the error in the configure
>> process :
>>
>> *USRP requires sdcc. sdcc not found. See http://sdcc.sf.net
>> Unable to find firmware compiler SDCC.
>> Not building component usrp.*
>>
>> Where am i wrong ? If I launch from terminal
>>
>> *$ sdcc -v *
>>
>> it returns :
>>
>> *$ SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0
>> #6037 (Apr 13 2011) (Linux)*
>>
>> thx in advance. All the others pre-requisites are fully satisfied.
>>
>> Regards, Arturo.
>>
>> A few points:
>>
>> If you're using UHD, you don't need component "USRP".
>>
>> Since Fedora 14, they have shipped SDCC version 3.0 which has different
>> command names, and also
>> some difference syntax for built-in variable-type intrinsics, so the
>> USRP1 firmware won't build under
>> SDCC-3.0 anyway.
>>
>> The configure script for Gnu Radio looks for SDCC using the SDCC version
>> 2.X command names, and
>> so for a system with SDCC 3.0, this will fail.
>>
>> But, once again, if you're using UHD (which I *strongly* recommend), you
>> don't need the component
>> "usrp" and "gr-usrp" to be built anyway.
>>
>> I haven't upgraded any of my systems to F15 yet, but when I do, expect
the
>> famous (almost!)
>> "build-gnuradio" script to get updated to deal with F15.
>>
>> --
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
> And if you do really want to get the usrp and gr-usrp components to build,
> you should be able to easily install a 2.9 version of SDCC.
>
> Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to hexdump in gnuradio realtime

[nimsi stouwdam]

Hi,

Thank you for the fast reply. I will try what you suggested.
I will let you know if it worked.

regards
Nimsi

Date: Thu, 26 May 2011 11:12:51 +0200
From: martin.br...@kit.edu
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How to hexdump in gnuradio realtime

On Thu, May 26, 2011 at 07:55:33AM +, nimsi stouwdam wrote:
> Hi guys,
> 
> First of all my apologies for my bad English. I am a Dutch student and for a
> internship I use GNURadio.
> 
> For test purposes I want to show the hexadecimals values of a stream of chars
> realtime (while running).
> I don't want to use 'printf' in the c-code of a block because sometimes it
> messes up the order of printing.
> 
> What I want to use is some kind of terminal what shows the hexadecimals 
> values.
> In GNURadio I saw a block named terminal sink, but I couldn't figure out how 
> to
> use it.
> 
> My question is as follows: Is there any way to show hexadecimal numbers in 
> some
> kind of terminal realtime?
> 
> Hopefully you understand my question and know an answer.
 
I'm not sure... you want to print the hex values of chars, but *not* on
the same output as your regular stdout?
Try this:
 
- Make a new block that converts chars to ASCII-hex (e.g. w/ sprintf)
- Connect that block to a gr_file_sink (or a gr_file_descriptor_sink),
  and write to a file (or a named pipe).
- When the flowgraph is running, open a separate xterm, and in there, do
  a 'tail -f FILENAME' (or 'cat PIPENAME').
 
The file approach will create a massive big text file, but perhaps you
want that.
 
MB
 
-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
 
Dipl.-Ing. Martin Braun
Research Associate
 
Kaiserstraße 12
Building 05.01
76131 Karlsruhe
 
Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu
 
KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
 

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

Re: [Discuss-gnuradio] Tuesday, 24th May sample volcanic ash image

[Tom Rondeau]

Very cool, Patrik, thanks for posting!

Tom


On Wed, May 25, 2011 at 7:10 PM, Patrik Tast wrote:

> Yep,
>
> Patrik
>
> - Original Message - From: "Alexandru Csete" 
> To: 
> Sent: Wednesday, May 25, 2011 19:39
> Subject: Re: [Discuss-gnuradio] Tuesday, 24th May sample volcanic ash image
>
>
>
>  On Wed, May 25, 2011 at 2:21 PM, Patrik Tast 
>> wrote:
>>
>>> Just FYI, to encourage GNURadio users,
>>>
>>> Received using GR USRP1 + TVRX (traditional, no uhd). Satellite Feng Yun
>>> channel-6 HRPT (1km resolution) gray-scale unprocessed image
>>> showing volcanic ash cloud entering Scandinavian airspace on Tuesday 24th
>>> May @ 1350Z
>>>
>>>
>>> http://www.poes-weather.com/downloads/Iceland-Ash-Cloud/Tue-May-24-2011/2011-05-24T164949-FENGYUN-1D-CH-6.jpg
>>>
>>>
>> Amazing! So this is received using gr-noaa package and your GUI?
>>
>> Alex
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building gnuradio 3.3.0 on Fedora 15 (issue with SDCC)

[Tom Rondeau]

On Thu, May 26, 2011 at 3:08 AM, Marcus D. Leech  wrote:

>  On 05/25/2011 09:01 PM, Arturo Rinaldi wrote:
>
> i have an issue regarding the SDCC executable in the building of gnuradio
> 3.3.0 on Fedora 15. I set up the PATH in my *.bashrc* file as :
>
> *export PATH=/usr/libexec/sdcc:$PATH
>
> *as written in the build guide but I still get the error in the configure
> process :
>
> *USRP requires sdcc. sdcc not found. See http://sdcc.sf.net
> Unable to find firmware compiler SDCC.
> Not building component usrp.*
>
> Where am i wrong ? If I launch from terminal
>
> *$ sdcc -v *
>
> it returns :
>
> *$ SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.0
> #6037 (Apr 13 2011) (Linux)*
>
> thx in advance. All the others pre-requisites are fully satisfied.
>
> Regards, Arturo.
>
>A few points:
>
> If you're using UHD, you don't need component "USRP".
>
> Since Fedora 14, they have shipped SDCC version 3.0 which has different
> command names, and also
>   some difference syntax for built-in variable-type intrinsics, so the
> USRP1 firmware won't build under
>   SDCC-3.0 anyway.
>
> The configure script for Gnu Radio looks for SDCC using the SDCC version
> 2.X command names, and
>   so for a system with SDCC 3.0, this will fail.
>
> But, once again, if you're using UHD (which I *strongly* recommend), you
> don't need the component
>   "usrp" and "gr-usrp" to be built anyway.
>
> I haven't upgraded any of my systems to F15 yet, but when I do, expect the
> famous (almost!)
>   "build-gnuradio" script to get updated to deal with F15.
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
And if you do really want to get the usrp and gr-usrp components to build,
you should be able to easily install a 2.9 version  of SDCC.

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

Re: [Discuss-gnuradio] How to hexdump in gnuradio realtime

[Martin Braun]

On Thu, May 26, 2011 at 07:55:33AM +, nimsi stouwdam wrote:
> Hi guys,
> 
> First of all my apologies for my bad English. I am a Dutch student and for a
> internship I use GNURadio.
> 
> For test purposes I want to show the hexadecimals values of a stream of chars
> realtime (while running).
> I don't want to use 'printf' in the c-code of a block because sometimes it
> messes up the order of printing.
> 
> What I want to use is some kind of terminal what shows the hexadecimals 
> values.
> In GNURadio I saw a block named terminal sink, but I couldn't figure out how 
> to
> use it.
> 
> My question is as follows: Is there any way to show hexadecimal numbers in 
> some
> kind of terminal realtime?
> 
> Hopefully you understand my question and know an answer.

I'm not sure... you want to print the hex values of chars, but *not* on
the same output as your regular stdout?
Try this:

- Make a new block that converts chars to ASCII-hex (e.g. w/ sprintf)
- Connect that block to a gr_file_sink (or a gr_file_descriptor_sink),
  and write to a file (or a named pipe).
- When the flowgraph is running, open a separate xterm, and in there, do
  a 'tail -f FILENAME' (or 'cat PIPENAME').

The file approach will create a massive big text file, but perhaps you
want that.

MB

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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

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



pgpio6530DiqJ.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to hexdump in gnuradio realtime

[nimsi stouwdam]

Hi guys,

First of all my apologies for my bad English. I am a Dutch student and for a 
internship I use GNURadio.

For test purposes I want to show the hexadecimals values of a stream of chars 
realtime (while running).
I don't want to use 'printf' in the c-code of a block because sometimes it 
messes up the order of printing.

What I want to use is some kind of terminal what shows the hexadecimals values.
In GNURadio I saw a block named terminal sink, but I couldn't figure out how to 
use it.

My question is as follows: Is there any way to show hexadecimal numbers in some 
kind of terminal realtime?

Hopefully you understand my question and know an answer.

Best regards,
Nimsi
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unexpected energy peak sensing thermal noise and using usrp_spectrum_sense.py

[Lebowski80]

Thank you for answering but I cannot understand what you mean with "The USRP
is not a measurement receiver". If USRP was not a measurement receiver,
which is its utility? Moreover, if it is not a measurement receiver what is
the result memorized in m.data that is the output of usrp_spectrum_sense.py?
When I use a WiFi antenna I can receive (and measure) the energy of WiFi
channels. The problem arises without antenna becasue USRP measures a signal
that cannot exist! Furthermore, such a signal is always at the beginning of
the sensed bandwidth, so this has not any sense!

Any idea about that? Thank you!


Nick Foster-4 wrote:
> 
> On Wed, 2011-05-25 at 08:51 -0700, Lebowski80 wrote:
>> Hello everyone
>> 
>> I’m using an USRP with a XCVR2450 daughter board working at 2.4 - 2.5
>> GHz. I
>> want to find a threshold between thermal noise and signals energy using
>> the
>> script usrp_spectrum_sense.py and sensing from 2.400 GHz to 2.500 GHz. To
>> do
>> that, I replaced the WiFi antenna with a resistor of 50 Ω to measure the
>> noise. I obtained a very strange peak at the beginning of the bandwidth
>> (around 2.405 GHz) and this result was totally unexpected because I
>> supposed
>> to sense only thermal noise without any particular peak. So, I repeated
>> the
>> experiment from 2.420 GHz to 2.500 GHz and I achieved the same peak
>> always
>> at the beginning of the bandwidth (in this case around 2.425 GHz).
>> Therefore, I'm quite sure this is a problem linked to USRP or to the
>> script
>> usrp_spectrum_sense.py, isn’t it? Can someone give me a hint about that
>> please?
> 
> The USRP is not a measurement receiver, and some small spurs are to be
> expected. You can plan for this, or work around it by changing the LO
> offset at a given center frequency using the advanced tuning parameters:
> http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html
> 
> --n
> 
>> 
>> Regards 
>> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Unexpected-energy-peak-sensing-thermal-noise-and-using-usrp_spectrum_sense.py-tp31700266p31705762.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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