Re: [Discuss-gnuradio] help with add a new block to GNURadio

[intermilan]

hi Tom:

  Thank you for your reply.
  At the beginning, I want to tell you 
about the function of my block.I want to use this block to correlate the
 received signal(spread signal) and local PN code,after I have a the max
 value of the correlate value,I should use the local PN code to despread
 the received demodulated signal and get the original data. So my input 
number and output number may not be strictly 1:1. And the value of d_len
 is the length of PN code,it may be 7,31,etc. So it can be too large.
 And in the block,it firstly test the in[0]...in[d_len-1],then 
in[d_len]...in[2*d_len-1] in while loop,  and after I get the max 
correlate value(which means the value of  sum is lager than the 
threshold), then go to the for loop to despread the spread signal.and in
 that loop,the in pointer should be incremented until the program end.

  The input of the block is 0 means the inputs themselves are 0,and 
after several bytes it will back to the correct value as the output value
 of the last block.And as you suggested,I use gr_sync_block instead of 
the gr_block,but it work worse than before.The input still will become 
to 0 and will never back the correct value. In my opinion,it may be the problem 
of the in pointer,after the block work for a while ,the value in this pointer 
become to 0,and then it back the value of the output of the last block.
  I hope I make myself clearly.So what do you think about this problem and 
how to fix it.
  Thank you again.

Inter

From: trondeau1...@gmail.com
Date: Tue, 31 May 2011 13:54:44 -0400
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] help with add a new block to GNURadio

2011/5/31 intermilan 







Hi:
I recently add a new block to the GNURadio and GRC.The function of the 
block is to correlate the received spread signal and the local PN code.
I think my block can work well,but there is one thing I do not know how to 
fix.Sometimes the input of my block is 0 and then it will back to the normal.


But I saw the  output data from the last block ,they are correct.Did anyone 
have situation  before? and how did it happen? In the accessory are the code 
of my block. 
   thank you in advance.
  



I haven't looked over the code too closely, but a few comments. First, because 
you are consuming and returning the same number of items, you can just make 
this a gr_sync_block instead of a gr_block, which means you don't have to worry 
about the forecast function and it simplifies the interface.


On the other hand, since you need at least d_len to make a decision, you'll 
have to either deal with it by holding state or by forcing the scheduler to 
give you the correct number of samples, minimum (set_output_multiple can be 
useful for things like this if d_len is not too large).


Also, you are not initializing sum to anything in the work function, so the 
initial test in the while loop might trigger incorrectly.
You are also incrementing the in pointer during the for loop, but it looks like 
you want to remain there until the sum is greater than your threshold. I would 
think that you would want to test in[0] to in[d_len-1] in one loop, then in[1] 
to in[d_len], and so on. Here, you are going to skip an entire d_len of inputs.


I'm not sure what you mean by the input of your block is 0. Does this mean the 
number of input items is 0 or that the inputs themselves are 0?
Hope this helps some.


Tom


___
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] Reintallation of GNU Radio software to work with UHD & USRP2

[Marcus D. Leech]

On 05/31/2011 08:07 PM, hafiz zimran wrote:

Thanks for help.
 I have installed C++ Compiler and followed the instructions as given in
http://www.ettus.com/uhd_docs/manual/html/build.html
Now I have connected usrp2 to PC ( Ubuntu 10.04, gnuradio-3.2.2) and 
run the command sudo uhd_find_devices and getting the error "command 
not found".
Wether I have to reinstall GNU Radio again to work with UHD or some 
extension of  GNURadio

Waiting for response
Zimran Rafique


You don't have UHD installed, almost for sure.  Unless you are "wedded" 
to gnuradio-3.2.2 for some reason, then I would do a "start over".


My advice would be to use the "build-gnuradio" script:

http://www.sbrac.org/files/build-gnuradio

Which will do a number of useful things:


   o install all the necessary pre-requisites, using "apt-get" or 
"yum", depending on system
   o remove any binary installs of Gnu Radio that may be present and 
that will interfere with upgrading to a installed-from-source version

   o download build and install the latest UHD
   o download build and install the latest Gnu Radio, configured to 
support UHD
   o download the latest firmware/fpga images and place them in the 
/usr/local/share/uhd/images  directory


Once this is complete, you'll need to burn new firmware/fpga images into 
the SD card for your USRP2, which will involve using the
  /usr/local/share/uhd/utils/usrp2_card_burner_gui.py  program to burn 
new images into your SD card.  You'll need an SD card reader/writer.

  They're now so cheap that my local dollar store carries them.


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

[Discuss-gnuradio] Reintallation of GNU Radio software to work with UHD & USRP2

[hafiz zimran]

Thanks for help.
 I have installed C++ Compiler and followed the instructions as given in 
http://www.ettus.com/uhd_docs/manual/html/build.html
Now I have connected usrp2 to PC ( Ubuntu 10.04, gnuradio-3.2.2) and run the 
command sudo uhd_find_devices and getting the error "command not found".
Wether I have to reinstall GNU Radio again to work with UHD or some extension 
of  GNURadio
Waiting for response
Zimran Rafique___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Signal coming from the USRP to the computer

[John Andrews]

Yes Patrick, I agree with your explanation. That was succinct and easy to
understand. Thanks.

On Tue, May 31, 2011 at 4:55 PM, Patrick Sisterhen  wrote:

> John,
>
> Typo in my equations, should have been:
>
> y_q = (x_i * sin(phi)) - (x_q * cos(phi))
>
> Patrick Sisterhen
> National Instruments
>
>
>
> From:John Andrews 
> To:Patrick Sisterhen 
> Cc:discuss-gnuradio@gnu.org
> Date:05/31/2011 02:08 PM
> Subject:Re: [Discuss-gnuradio] Signal coming from the USRP to the
> computer
> --
>
>
>
> Thanks Patrick. I was concerned with the received signal path. Suppose, I
> have the receiver tuned to, let's say, GPS signal. What will the received
> signal look like. Considering the GPS message signal is m(t), then what
> would equation would best describe the received signal.
>
> If 'f_c' is the carrier frequency then the signal coming over the USB bus
> on to the computer for baseband processing will be,
> inphase(t) = m(t) cos(phi)
> quadrature(t) = m(t)sin(phi)
>
> where, 'phi' is the instantaneous offset. Remember, phi here is a broad
> term which includes all kinds of offsets(frequency, phase etc).
>
> On Tue, May 31, 2011 at 11:47 AM, Patrick Sisterhen <*
> patrick.sister...@ni.com* > wrote:
> I think a little more detailed precise answer to John's question might
> help:
>
> John Andrews wrote:
>
> > each complex sample that enters the
> > USB bus is the following,
> >
> > x[i] = (inphase_component) + j (quadrature_component), and
> > x[i] = m(t)cos( 2*pi*FREQ_OFFSET*t + PHI ) + jm(t)sin( 2*pi*FREQ_OFFSET*t
> +
> > PHI ), where m(t), is the actual message signal, FREQ_OFFSET is the
> > frequency offset, and PHI is the phase.
> >
> > Is that correct?
>
> I think you're confusing the baseband and passband signals a little, and
> the equations aren't quite right.
>
> The complex-baseband signal (your message) is the data that is transferred
> across the USB channel.
> x[i] = (in-phase) + j*(quadrature)
>= (x_i) + j*(x_q)
>
> These are samples of your message signal, after modulation (mapping to a
> complex QAM-constellation, for example), coding, pulse-shaping, etc.
>
> The signal is up/down converted on the USRP device such that the
> transmitted RF signal is
>
> r(t) = x_i*cos(2*pi*f_c) - (x_q)*sin(2*pi*f_c)
>
> (where f_c is your RF carrier frequency, and I'm ignoring phase offsets and
> noise)
>
> Notice the subtraction there (which comes from the trig identities) and
> that all the terms are real (it's a real passband signal).
>
> Hope that helps a little.
>
> Patrick Sisterhen
> National Instruments
> ___
> 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] about RFX2200 duaghter board

[Matt Ettus]

On 05/30/2011 01:22 AM, Songsong Gee wrote:
> I have question on RFX2200
> What frequency range does RFX2200 support?
> 
> I mean, I know it supports 2.0-2.4 GHz. but,
> For RFX2400, it supports 2.3-2.9 GHz if bypassing is applied, basically
> 2.4-2.483 GHz is supported without bypassing.
> Thus, if I did not take bypassing, what frequency range I can use?

The RFX2200 is already bypassed, so you will get the full 2.0 to 2.4 GHz
range (really 2.45 GHz).

Matt


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

Re: [Discuss-gnuradio] Signal coming from the USRP to the computer

[Patrick Sisterhen]

John,

A phase difference (phi) between the frequency of the transmit carrier 
(f_c) and the receiver local oscillator (f_r) will be exhibited as a 
rotation of your received symbols in the complex plain.

I think that's what you mean to imply in your equations, but to get a 
little more precise:

Let x_i and x_q be the in-phase and quadrature components of your baseband 
message at the transmitter.
Let y_i and y_q be the same for the baseband message at the receiver 
(after downconversion with an oscillator with a phase offset).

y_i = (x_i * cos(phi)) + (x_q * sin(phi))
y_q = (x_i * cos(phi)) - (x_q * cos(phi))

If phi is 0, you recover the original in-phase and quadrature components. 
Otherwise, it works like a rotation by phi.

If the receiver local oscillator has a frequency offset from the 
transmitter oscillator (f_c != f_r), the received symbols will 
continuously rotate over time.

(I may have reversed the sign in those equations... it depends on the 
implementation of the downconverter, but you can detect and correct for it 
in the same way.)

Patrick Sisterhen
National Instruments



From:   John Andrews 
To: Patrick Sisterhen 
Cc: discuss-gnuradio@gnu.org
Date:   05/31/2011 02:08 PM
Subject:Re: [Discuss-gnuradio] Signal coming from the USRP to the 
computer



Thanks Patrick. I was concerned with the received signal path. Suppose, I 
have the receiver tuned to, let's say, GPS signal. What will the received 
signal look like. Considering the GPS message signal is m(t), then what 
would equation would best describe the received signal. 

If 'f_c' is the carrier frequency then the signal coming over the USB bus 
on to the computer for baseband processing will be,
inphase(t) = m(t) cos(phi)
quadrature(t) = m(t)sin(phi)

where, 'phi' is the instantaneous offset. Remember, phi here is a broad 
term which includes all kinds of offsets(frequency, phase etc).

On Tue, May 31, 2011 at 11:47 AM, Patrick Sisterhen <
patrick.sister...@ni.com> wrote:
I think a little more detailed precise answer to John's question might 
help: 

John Andrews wrote: 

> each complex sample that enters the
> USB bus is the following,
> 
> x[i] = (inphase_component) + j (quadrature_component), and
> x[i] = m(t)cos( 2*pi*FREQ_OFFSET*t + PHI ) + jm(t)sin( 
2*pi*FREQ_OFFSET*t +
> PHI ), where m(t), is the actual message signal, FREQ_OFFSET is the
> frequency offset, and PHI is the phase.
> 
> Is that correct? 

I think you're confusing the baseband and passband signals a little, and 
the equations aren't quite right. 

The complex-baseband signal (your message) is the data that is transferred 
across the USB channel. 
x[i] = (in-phase) + j*(quadrature) 
   = (x_i) + j*(x_q) 

These are samples of your message signal, after modulation (mapping to a 
complex QAM-constellation, for example), coding, pulse-shaping, etc. 

The signal is up/down converted on the USRP device such that the 
transmitted RF signal is 

r(t) = x_i*cos(2*pi*f_c) - (x_q)*sin(2*pi*f_c) 

(where f_c is your RF carrier frequency, and I'm ignoring phase offsets 
and noise) 

Notice the subtraction there (which comes from the trig identities) and 
that all the terms are real (it's a real passband signal). 

Hope that helps a little.

Patrick Sisterhen
National Instruments
___
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] Problem with new signal processing block

[Tom Rondeau]

On Tue, May 31, 2011 at 5:02 PM, Felipe Fideles  wrote:

> Hello,
>
> I got this error when I did the last make check comand, trying to test a
> new signal processing block:
>
>  File "/usr/lib/python2.6/unittest.
> py", line 457, in run
>for test in self._tests:
>
> TypeError: in method 'delete_gr_basic_block_sptr', argument 1 of type
> 'boost::shared_ptr< gr_basic_block > *'
>
> Does anyone know how to fix it?
>
> Thanks,
> --
> Felipe Fideles
> Electrical Engineering Undergraduate
> Universidade Federal de Campina Grande - Brazil
>

That's unfamiliar to me, but strikes me as a syntax error in your code.
You're probably going to have to provide more details.

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

Re: [Discuss-gnuradio] Issue with MMSE interp. filter (broken?)

[Tom Rondeau]

On Tue, May 31, 2011 at 4:56 PM, Colby Boyer  wrote:

>
>
> On Tue, May 31, 2011 at 1:46 PM, Tom Rondeau wrote:
>
>> On Tue, May 31, 2011 at 4:37 PM, Colby Boyer wrote:
>>
>>> Related. It seems that this delay is not taking in account for the MM
>>> clock recovery block? It some cases, this delay will not matter (2 or 4
>>> samples per symbol), but for other rates it will.
>>>
>>> --Colby
>>
>>
>>
>> That's an excellent point. Any chance for a patch? :)
>>
>> Tom
>>
>>
>>
>>
>>>  On Tue, May 31, 2011 at 1:29 PM, Tom Rondeau wrote:
>>>
 On Tue, May 31, 2011 at 4:25 PM, Colby Boyer wrote:

>
>
> On Tue, May 31, 2011 at 5:59 AM, Tom Rondeau 
> wrote:
>
>> On Tue, May 31, 2011 at 2:13 AM, Colby Boyer 
>> wrote:
>>
>>> Hi All,
>>>
>>> Recently I've been using the MMSE interp filter. I found that when I
>>> shift a signal by a fractional amount of 0 (or anything really), the 
>>> signal
>>> goes way off! I would expect SOME difference, but not this much...
>>>
>>> Some example output.
>>>
>>> Mu:0 In:(-1.67869,0.480381) Out:(0.0418351,-0.16734)
>>>
>>> Mu:0 In:(-1.23772,-0.104519) Out:(0.16003,-0.115883)
>>>
>>> Mu:0 In:(-1.7598,-0.0618457) Out:(0.0986395,-0.33428)
>>>
>>> On the imgur links are two Re-Im scatter plots of a bpsk signal, one
>>> with the fractional shift of 0 and the other with a fractional shift of 
>>> 0.1
>>> The points with 'x' are the resampled points and points with 'o' is the
>>> original signal. As you can see, the mmse fractional interp more or less
>>> destroys the signal! Unless I'm using it wrong!?
>>>
>>> Any comments?
>>>
>>> imgur: http://imgur.com/a/w98SX top picture is 0 delay, bottom is
>>> 0.1 delay.
>>>
>>> Thanks!
>>> Colby
>>
>>
>>
>> Colby,
>> This block has been around for years without any changes, and I and
>> others have been successfully using it in various projects, so my guess 
>> is
>> that you have some misconception about what it's doing or what the
>> parameters are.
>>
>> You can see how it's used to simulate a timing offset in
>> gnuradio-core/src/lib/hier/gr_channel_model.cc where it's used inside of 
>> the
>> gr_fractional_interpolator_cc block. We also use it in the
>> gr_clock_recovery_mm_XX and gr_mpsk_receiver_cc.
>>
>> Tom
>>
>>
>
> Hi Tom,
>
> I looked at the issue again and I was not taking in account the group
> delay of the interp filter (its 5 taps into the future or 3 in the past), 
> so
> I was sampling a few taps out of phase! After a time shift, it passes the
> sanity check of '0.0' delay. Thanks for the response!
>
> --Colby
>

 Excellent, glad that worked out. I was pretty sure it works, but you
 never know... good to have extra confirmation.

 Tom




>>>
>>
> Sure thing, perhaps later this week? I can submit all my patches at once
> (this fix, gardner algorithm, multi-order loopfilter).
>
> --Colby
>

Excellent, thanks!

So this gets into the question of how to best submit work to the project.
There's some work being done now to help convey this information. I'll take
the time now to comment on what you are proposing here.

There are two main ways to best contribute code. The simplest is the patch
and the more complex is creating a branch on a git server somewhere that I
can then pull in and merge with our code.

In this case, I would rather get the submissions done as three different git
branches. The fix for the clock recovery loop _could_ be easily done as a
patch, but if we're going all out on the other two items, it'll just make
things simpler to do it all in the same way.

The thing to do is start a github (or your-favorite-git-service-here) repo
that is based on either my branch on github or the git master on
gnuradio.org. The one from gnuradio.org will of course always be more
up-to-date, but it sounds like there are nice visualization tools on github
that would be more usable if you branched from me directly. I'll leave that
up to you for now.

We tend to like to see branches solve one particular problem. So you would
have three branches here: one for the MM fix, one for the gardner loop, and
one for the loopfilter work. I can then merge in the branches individually.
This will help keep me organized, and each branch can be independently
audited and tested.

Just a note on the form of the branches, too. The MM fix and Gardner loop
branch should be easy submissions because one is a simple internal fix and
the other is a new block. This easily fits into the current API of the
blocks and doesn't break anything. I'm not sure how you plan on implementing
the work in the loopfilter branch, but if possible, make sure there is no
change to the API of any blocks using it. Also, in this case, we shouldn't
be changing the behavior of any

Re: [Discuss-gnuradio] Signal coming from the USRP to the computer

[Patrick Sisterhen]

John,

Typo in my equations, should have been:

y_q = (x_i * sin(phi)) - (x_q * cos(phi))

Patrick Sisterhen
National Instruments



From:   John Andrews 
To: Patrick Sisterhen 
Cc: discuss-gnuradio@gnu.org
Date:   05/31/2011 02:08 PM
Subject:Re: [Discuss-gnuradio] Signal coming from the USRP to the 
computer



Thanks Patrick. I was concerned with the received signal path. Suppose, I 
have the receiver tuned to, let's say, GPS signal. What will the received 
signal look like. Considering the GPS message signal is m(t), then what 
would equation would best describe the received signal. 

If 'f_c' is the carrier frequency then the signal coming over the USB bus 
on to the computer for baseband processing will be,
inphase(t) = m(t) cos(phi)
quadrature(t) = m(t)sin(phi)

where, 'phi' is the instantaneous offset. Remember, phi here is a broad 
term which includes all kinds of offsets(frequency, phase etc).

On Tue, May 31, 2011 at 11:47 AM, Patrick Sisterhen <
patrick.sister...@ni.com> wrote:
I think a little more detailed precise answer to John's question might 
help: 

John Andrews wrote: 

> each complex sample that enters the
> USB bus is the following,
> 
> x[i] = (inphase_component) + j (quadrature_component), and
> x[i] = m(t)cos( 2*pi*FREQ_OFFSET*t + PHI ) + jm(t)sin( 
2*pi*FREQ_OFFSET*t +
> PHI ), where m(t), is the actual message signal, FREQ_OFFSET is the
> frequency offset, and PHI is the phase.
> 
> Is that correct? 

I think you're confusing the baseband and passband signals a little, and 
the equations aren't quite right. 

The complex-baseband signal (your message) is the data that is transferred 
across the USB channel. 
x[i] = (in-phase) + j*(quadrature) 
   = (x_i) + j*(x_q) 

These are samples of your message signal, after modulation (mapping to a 
complex QAM-constellation, for example), coding, pulse-shaping, etc. 

The signal is up/down converted on the USRP device such that the 
transmitted RF signal is 

r(t) = x_i*cos(2*pi*f_c) - (x_q)*sin(2*pi*f_c) 

(where f_c is your RF carrier frequency, and I'm ignoring phase offsets 
and noise) 

Notice the subtraction there (which comes from the trig identities) and 
that all the terms are real (it's a real passband signal). 

Hope that helps a little.

Patrick Sisterhen
National Instruments
___
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] gfortran-4.2.1 build 5666.3 for Xcode 4.0.2 on Mac OS X 10.6.7

[Michael Dickens]

On May 31, 2011, at 3:03 PM, Elvis Dowson wrote:
> a. gcc-llvm-4.2 supplied with Xcode-4.0.2 package (paid version) appears to 
> build all the libraries, just like the standard gcc-4.0.1 from the older 
> Xcode-3.2.x series.

TTBOMK, and, really, this is kinda off list-topic by now:

Before XCode 4, Apple has -never- provided fortran as part of their standard 
XCode GCC install.  Apple's GCC 4.0.1 and 4.2.1, as found in XCode for OSX 10.5 
and 10.6, do not.  I don't have XCode 4 yet, so I cannot comment on what is 
included with it.

GCC is under the GPL, so Apple is required to release their source changes in 
some way.  Thus, since GCC is capable of building fortran, Apple's GCC variant 
should be as well with the correct tweaks.  I'm not a GCC hacker, but I'm sure 
there are folks out there who could figure out what to do.

Apple is moving away from stock GCC, towards LLVM / Clang etc..  LLVM provides 
interfaces for the major languages including fortran, though of course Apple 
can provide whatever interfaces it choose to.

I'm sure there are others, but this'll have to do for now :) - MLD


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

[Discuss-gnuradio] Problem with new signal processing block

[Felipe Fideles]

Hello,

I got this error when I did the last make check comand, trying to test a new
signal processing block:

 File "/usr/lib/python2.6/unittest.
py", line 457, in run
   for test in self._tests:

TypeError: in method 'delete_gr_basic_block_sptr', argument 1 of type
'boost::shared_ptr< gr_basic_block > *'

Does anyone know how to fix it?

Thanks,
--
Felipe Fideles
Electrical Engineering Undergraduate
Universidade Federal de Campina Grande - Brazil
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with MMSE interp. filter (broken?)

[Colby Boyer]

On Tue, May 31, 2011 at 1:46 PM, Tom Rondeau  wrote:

> On Tue, May 31, 2011 at 4:37 PM, Colby Boyer wrote:
>
>> Related. It seems that this delay is not taking in account for the MM
>> clock recovery block? It some cases, this delay will not matter (2 or 4
>> samples per symbol), but for other rates it will.
>>
>> --Colby
>
>
>
> That's an excellent point. Any chance for a patch? :)
>
> Tom
>
>
>
>
>>  On Tue, May 31, 2011 at 1:29 PM, Tom Rondeau wrote:
>>
>>> On Tue, May 31, 2011 at 4:25 PM, Colby Boyer wrote:
>>>


 On Tue, May 31, 2011 at 5:59 AM, Tom Rondeau wrote:

> On Tue, May 31, 2011 at 2:13 AM, Colby Boyer wrote:
>
>> Hi All,
>>
>> Recently I've been using the MMSE interp filter. I found that when I
>> shift a signal by a fractional amount of 0 (or anything really), the 
>> signal
>> goes way off! I would expect SOME difference, but not this much...
>>
>> Some example output.
>>
>> Mu:0 In:(-1.67869,0.480381) Out:(0.0418351,-0.16734)
>>
>> Mu:0 In:(-1.23772,-0.104519) Out:(0.16003,-0.115883)
>>
>> Mu:0 In:(-1.7598,-0.0618457) Out:(0.0986395,-0.33428)
>>
>> On the imgur links are two Re-Im scatter plots of a bpsk signal, one
>> with the fractional shift of 0 and the other with a fractional shift of 
>> 0.1
>> The points with 'x' are the resampled points and points with 'o' is the
>> original signal. As you can see, the mmse fractional interp more or less
>> destroys the signal! Unless I'm using it wrong!?
>>
>> Any comments?
>>
>> imgur: http://imgur.com/a/w98SX top picture is 0 delay, bottom is 0.1
>> delay.
>>
>> Thanks!
>> Colby
>
>
>
> Colby,
> This block has been around for years without any changes, and I and
> others have been successfully using it in various projects, so my guess is
> that you have some misconception about what it's doing or what the
> parameters are.
>
> You can see how it's used to simulate a timing offset in
> gnuradio-core/src/lib/hier/gr_channel_model.cc where it's used inside of 
> the
> gr_fractional_interpolator_cc block. We also use it in the
> gr_clock_recovery_mm_XX and gr_mpsk_receiver_cc.
>
> Tom
>
>

 Hi Tom,

 I looked at the issue again and I was not taking in account the group
 delay of the interp filter (its 5 taps into the future or 3 in the past), 
 so
 I was sampling a few taps out of phase! After a time shift, it passes the
 sanity check of '0.0' delay. Thanks for the response!

 --Colby

>>>
>>> Excellent, glad that worked out. I was pretty sure it works, but you
>>> never know... good to have extra confirmation.
>>>
>>> Tom
>>>
>>>
>>>
>>>
>>
>
Sure thing, perhaps later this week? I can submit all my patches at once
(this fix, gardner algorithm, multi-order loopfilter).

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

Re: [Discuss-gnuradio] Issue with MMSE interp. filter (broken?)

[Tom Rondeau]

On Tue, May 31, 2011 at 4:37 PM, Colby Boyer  wrote:

> Related. It seems that this delay is not taking in account for the MM clock
> recovery block? It some cases, this delay will not matter (2 or 4 samples
> per symbol), but for other rates it will.
>
> --Colby



That's an excellent point. Any chance for a patch? :)

Tom




>  On Tue, May 31, 2011 at 1:29 PM, Tom Rondeau wrote:
>
>> On Tue, May 31, 2011 at 4:25 PM, Colby Boyer wrote:
>>
>>>
>>>
>>> On Tue, May 31, 2011 at 5:59 AM, Tom Rondeau wrote:
>>>
 On Tue, May 31, 2011 at 2:13 AM, Colby Boyer wrote:

> Hi All,
>
> Recently I've been using the MMSE interp filter. I found that when I
> shift a signal by a fractional amount of 0 (or anything really), the 
> signal
> goes way off! I would expect SOME difference, but not this much...
>
> Some example output.
>
> Mu:0 In:(-1.67869,0.480381) Out:(0.0418351,-0.16734)
>
> Mu:0 In:(-1.23772,-0.104519) Out:(0.16003,-0.115883)
>
> Mu:0 In:(-1.7598,-0.0618457) Out:(0.0986395,-0.33428)
>
> On the imgur links are two Re-Im scatter plots of a bpsk signal, one
> with the fractional shift of 0 and the other with a fractional shift of 
> 0.1
> The points with 'x' are the resampled points and points with 'o' is the
> original signal. As you can see, the mmse fractional interp more or less
> destroys the signal! Unless I'm using it wrong!?
>
> Any comments?
>
> imgur: http://imgur.com/a/w98SX top picture is 0 delay, bottom is 0.1
> delay.
>
> Thanks!
> Colby



 Colby,
 This block has been around for years without any changes, and I and
 others have been successfully using it in various projects, so my guess is
 that you have some misconception about what it's doing or what the
 parameters are.

 You can see how it's used to simulate a timing offset in
 gnuradio-core/src/lib/hier/gr_channel_model.cc where it's used inside of 
 the
 gr_fractional_interpolator_cc block. We also use it in the
 gr_clock_recovery_mm_XX and gr_mpsk_receiver_cc.

 Tom


>>>
>>> Hi Tom,
>>>
>>> I looked at the issue again and I was not taking in account the group
>>> delay of the interp filter (its 5 taps into the future or 3 in the past), so
>>> I was sampling a few taps out of phase! After a time shift, it passes the
>>> sanity check of '0.0' delay. Thanks for the response!
>>>
>>> --Colby
>>>
>>
>> Excellent, glad that worked out. I was pretty sure it works, but you never
>> know... good to have extra confirmation.
>>
>> Tom
>>
>>
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with MMSE interp. filter (broken?)

[Colby Boyer]

Related. It seems that this delay is not taking in account for the MM clock
recovery block? It some cases, this delay will not matter (2 or 4 samples
per symbol), but for other rates it will.

--Colby

On Tue, May 31, 2011 at 1:29 PM, Tom Rondeau  wrote:

> On Tue, May 31, 2011 at 4:25 PM, Colby Boyer wrote:
>
>>
>>
>> On Tue, May 31, 2011 at 5:59 AM, Tom Rondeau wrote:
>>
>>> On Tue, May 31, 2011 at 2:13 AM, Colby Boyer wrote:
>>>
 Hi All,

 Recently I've been using the MMSE interp filter. I found that when I
 shift a signal by a fractional amount of 0 (or anything really), the signal
 goes way off! I would expect SOME difference, but not this much...

 Some example output.

 Mu:0 In:(-1.67869,0.480381) Out:(0.0418351,-0.16734)

 Mu:0 In:(-1.23772,-0.104519) Out:(0.16003,-0.115883)

 Mu:0 In:(-1.7598,-0.0618457) Out:(0.0986395,-0.33428)

 On the imgur links are two Re-Im scatter plots of a bpsk signal, one
 with the fractional shift of 0 and the other with a fractional shift of 0.1
 The points with 'x' are the resampled points and points with 'o' is the
 original signal. As you can see, the mmse fractional interp more or less
 destroys the signal! Unless I'm using it wrong!?

 Any comments?

 imgur: http://imgur.com/a/w98SX top picture is 0 delay, bottom is 0.1
 delay.

 Thanks!
 Colby
>>>
>>>
>>>
>>> Colby,
>>> This block has been around for years without any changes, and I and
>>> others have been successfully using it in various projects, so my guess is
>>> that you have some misconception about what it's doing or what the
>>> parameters are.
>>>
>>> You can see how it's used to simulate a timing offset in
>>> gnuradio-core/src/lib/hier/gr_channel_model.cc where it's used inside of the
>>> gr_fractional_interpolator_cc block. We also use it in the
>>> gr_clock_recovery_mm_XX and gr_mpsk_receiver_cc.
>>>
>>> Tom
>>>
>>>
>>
>> Hi Tom,
>>
>> I looked at the issue again and I was not taking in account the group
>> delay of the interp filter (its 5 taps into the future or 3 in the past), so
>> I was sampling a few taps out of phase! After a time shift, it passes the
>> sanity check of '0.0' delay. Thanks for the response!
>>
>> --Colby
>>
>
> Excellent, glad that worked out. I was pretty sure it works, but you never
> know... good to have extra confirmation.
>
> Tom
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with MMSE interp. filter (broken?)

[Tom Rondeau]

On Tue, May 31, 2011 at 4:25 PM, Colby Boyer  wrote:

>
>
> On Tue, May 31, 2011 at 5:59 AM, Tom Rondeau wrote:
>
>> On Tue, May 31, 2011 at 2:13 AM, Colby Boyer wrote:
>>
>>> Hi All,
>>>
>>> Recently I've been using the MMSE interp filter. I found that when I
>>> shift a signal by a fractional amount of 0 (or anything really), the signal
>>> goes way off! I would expect SOME difference, but not this much...
>>>
>>> Some example output.
>>>
>>> Mu:0 In:(-1.67869,0.480381) Out:(0.0418351,-0.16734)
>>>
>>> Mu:0 In:(-1.23772,-0.104519) Out:(0.16003,-0.115883)
>>>
>>> Mu:0 In:(-1.7598,-0.0618457) Out:(0.0986395,-0.33428)
>>>
>>> On the imgur links are two Re-Im scatter plots of a bpsk signal, one with
>>> the fractional shift of 0 and the other with a fractional shift of 0.1 The
>>> points with 'x' are the resampled points and points with 'o' is the original
>>> signal. As you can see, the mmse fractional interp more or less destroys the
>>> signal! Unless I'm using it wrong!?
>>>
>>> Any comments?
>>>
>>> imgur: http://imgur.com/a/w98SX top picture is 0 delay, bottom is 0.1
>>> delay.
>>>
>>> Thanks!
>>> Colby
>>
>>
>>
>> Colby,
>> This block has been around for years without any changes, and I and others
>> have been successfully using it in various projects, so my guess is that you
>> have some misconception about what it's doing or what the parameters are.
>>
>> You can see how it's used to simulate a timing offset in
>> gnuradio-core/src/lib/hier/gr_channel_model.cc where it's used inside of the
>> gr_fractional_interpolator_cc block. We also use it in the
>> gr_clock_recovery_mm_XX and gr_mpsk_receiver_cc.
>>
>> Tom
>>
>>
>
> Hi Tom,
>
> I looked at the issue again and I was not taking in account the group delay
> of the interp filter (its 5 taps into the future or 3 in the past), so I was
> sampling a few taps out of phase! After a time shift, it passes the sanity
> check of '0.0' delay. Thanks for the response!
>
> --Colby
>

Excellent, glad that worked out. I was pretty sure it works, but you never
know... good to have extra confirmation.

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

Re: [Discuss-gnuradio] Issue with MMSE interp. filter (broken?)

[Colby Boyer]

On Tue, May 31, 2011 at 5:59 AM, Tom Rondeau  wrote:

> On Tue, May 31, 2011 at 2:13 AM, Colby Boyer wrote:
>
>> Hi All,
>>
>> Recently I've been using the MMSE interp filter. I found that when I shift
>> a signal by a fractional amount of 0 (or anything really), the signal goes
>> way off! I would expect SOME difference, but not this much...
>>
>> Some example output.
>>
>> Mu:0 In:(-1.67869,0.480381) Out:(0.0418351,-0.16734)
>>
>> Mu:0 In:(-1.23772,-0.104519) Out:(0.16003,-0.115883)
>>
>> Mu:0 In:(-1.7598,-0.0618457) Out:(0.0986395,-0.33428)
>>
>> On the imgur links are two Re-Im scatter plots of a bpsk signal, one with
>> the fractional shift of 0 and the other with a fractional shift of 0.1 The
>> points with 'x' are the resampled points and points with 'o' is the original
>> signal. As you can see, the mmse fractional interp more or less destroys the
>> signal! Unless I'm using it wrong!?
>>
>> Any comments?
>>
>> imgur: http://imgur.com/a/w98SX top picture is 0 delay, bottom is 0.1
>> delay.
>>
>> Thanks!
>> Colby
>
>
>
> Colby,
> This block has been around for years without any changes, and I and others
> have been successfully using it in various projects, so my guess is that you
> have some misconception about what it's doing or what the parameters are.
>
> You can see how it's used to simulate a timing offset in
> gnuradio-core/src/lib/hier/gr_channel_model.cc where it's used inside of the
> gr_fractional_interpolator_cc block. We also use it in the
> gr_clock_recovery_mm_XX and gr_mpsk_receiver_cc.
>
> Tom
>
>

Hi Tom,

I looked at the issue again and I was not taking in account the group delay
of the interp filter (its 5 taps into the future or 3 in the past), so I was
sampling a few taps out of phase! After a time shift, it passes the sanity
check of '0.0' delay. Thanks for the response!

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

Re: [Discuss-gnuradio] gfortran-4.2.1 build 5666.3 for Xcode 4.0.2 on Mac OS X 10.6.7

[Michael Dickens]

2 comments:

1: Apple's GCC variant does not provide a fortran option (at all); maybe it can 
be hacked on, but I don't know of a project that's done that.  You're better 
off getting the vanilla GCC & compiling it with fortran enabled, or go with a 
fortran-specific project instead.

2: IIRC numpy requires fortran for the purpose of putting that name in place 
for 'f2c'-like purposes -- none of the internal numpy code is actually written 
in fortran and the fortran compiler is never invoked during configuration, 
building, or installation of numpy.  It is invoked is you do a "test" or 
"check", but you can safely ignore those errors.  Once upon a time, the 
MacPorts' py27-numpy port fixed the fortran version via a patch to the numpy 
source (maybe it still does) -- you should be able to do a similar trick to 
convince numpy that it doesn't even need fortran, if that's even necessary.  Of 
course, if you really -do- need fortran for some real purpose (e.g., compiling 
a project that's written with fortran code), then you're better off with 
vanilla GCC.


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

Re: [Discuss-gnuradio] Signal coming from the USRP to the computer

[John Andrews]

Thanks Patrick. I was concerned with the received signal path. Suppose, I
have the receiver tuned to, let's say, GPS signal. What will the received
signal look like. Considering the GPS message signal is m(t), then what
would equation would best describe the received signal.

If 'f_c' is the carrier frequency then the signal coming over the USB bus on
to the computer for baseband processing will be,
inphase(t) = m(t) cos(phi)
quadrature(t) = m(t)sin(phi)

where, 'phi' is the instantaneous offset. Remember, phi here is a broad term
which includes all kinds of offsets(frequency, phase etc).

On Tue, May 31, 2011 at 11:47 AM, Patrick Sisterhen <
patrick.sister...@ni.com> wrote:

> I think a little more detailed precise answer to John's question might
> help:
>
> John Andrews wrote:
>
> > each complex sample that enters the
> > USB bus is the following,
> >
> > x[i] = (inphase_component) + j (quadrature_component), and
> > x[i] = m(t)cos( 2*pi*FREQ_OFFSET*t + PHI ) + jm(t)sin( 2*pi*FREQ_OFFSET*t
> +
> > PHI ), where m(t), is the actual message signal, FREQ_OFFSET is the
> > frequency offset, and PHI is the phase.
> >
> > Is that correct?
>
> I think you're confusing the baseband and passband signals a little, and
> the equations aren't quite right.
>
> The complex-baseband signal (your message) is the data that is transferred
> across the USB channel.
> x[i] = (in-phase) + j*(quadrature)
>= (x_i) + j*(x_q)
>
> These are samples of your message signal, after modulation (mapping to a
> complex QAM-constellation, for example), coding, pulse-shaping, etc.
>
> The signal is up/down converted on the USRP device such that the
> transmitted RF signal is
>
> r(t) = x_i*cos(2*pi*f_c) - (x_q)*sin(2*pi*f_c)
>
> (where f_c is your RF carrier frequency, and I'm ignoring phase offsets and
> noise)
>
> Notice the subtraction there (which comes from the trig identities) and
> that all the terms are real (it's a real passband signal).
>
> Hope that helps a little.
>
> Patrick Sisterhen
> National Instruments
> ___
> 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] gfortran-4.2.1 build 5666.3 for Xcode 4.0.2 on Mac OS X 10.6.7

[Elvis Dowson]

Hi,
   Here are my observations so far.

a. gcc-llvm-4.2 supplied with Xcode-4.0.2 package (paid version) appears to 
build all the libraries, just like the standard gcc-4.0.1 from the older 
Xcode-3.2.x series.

b. Xcode-4.0.2 has gcc-4.2.1 build 5666.3. There is no binary package for 
gfortran-4.2.1-5666.3. The closest available is gfortran-4.2.1-5664, which 
according some posts is as good as 5666, and you can install the older binary 
and get gfortran and gcc-4.2.1 to work without problems.

http://r.research.att.com/gfortran-42-5664.pkg

Perhaps in a while, the folks at research.att.com will release an updated 
binary package for gfortran-4.2.1-5666.3 to match the gcc-4.2.1-5666.3 release 
that comes with Xcode-4.0.2.

c. For the moment, perhaps it is better to stick to Xcode-3.2.6, if you just 
want the gcc compiler for building gnuradio, but don't want to take advantage 
of the newer Xcode-4.0.2 integrated IDE and its newer features.

http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20792

I still haven't finished the manual build of gnuradio library dependencies. 
Right now, I'm down to the last leg, installing and patching GTK+ OS X 
libraries for gnuradio companion. 

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

Re: [Discuss-gnuradio] 802.15.4 performance analysis: pin Oscilloscope on IF

[Tom Rondeau]

On Sat, May 28, 2011 at 1:31 PM, Colby Boyer  wrote:

> On Sat, May 28, 2011 at 6:50 AM, Tom Rondeau 
> wrote:
> > On Wed, May 25, 2011 at 3:16 PM, Marius  wrote:
> >>
> >> Hi!
> >>
> >> - To my background there's to say - before you read this - I'm just a
> >> software-dev. I have little expertise when it comes to hardware.
> >>
> >> I  support the development of a real-time application that uses
> >> 802.15.4 on an AT86230RF Chip. That RF chip is IEEE 802.15.4-2003
> >> compliant.
> >> It has got a data-rate of 250 kBit/s. Let's say I want to send 10
> >> Byte. 2 Bytes CRC are added, and 6 Bytes from the Physical Layer
> >> (Preambel + Length Field + Delimeter).
> >> So I send 144 Bits (12 Byte PSDU are 12 *8 and 48 Bytes Physical Layer
> >> due 6 * 8). Theoretically I get 0,576 ms per transmission using 250
> >> Kbit/s: 1/250k*144*10^3.
> >>
> >> Now... I use my USRP with an XCVR, start the sender, and record some
> >> transmissions into cfiles. I plot the Q channel, and calculate the
> >> transmission lengh: like how many samples do I see with a high
> >> amplitude relative to the sample-rate. That's when the RF chip is
> >> active. I get 3,45 ms.
> >>
> >> So the difference between what I theoretically can assume as TX time,
> >> and what I see in reality is abnormally high.
> >>
> >> My questions:
> >> 1.) Can I use an Oscilloscope to find out whether there's signal on
> >> IF. The Oscilloscope operates on something like 100 MHz, so I want the
> >> down-scaled frequency.
> >> I read that the RF frontend down-scales to the ADC. I can pin-point
> >> the microcontroller with the chip. Can I also pin-point the USRP2 with
> >> the XCVR (or RFX)? I could correlate the state-changes of the RF Chip
> >> that way.
> >>
> >> 2.) I suspect the differences result from state-changes on the RF chip
> >> (PLL_ON -> TX). Is anybody aware of a similar performance analysis on
> >> Zigbee for real-time applications? As I stated out I'm not a
> >> hardware-expert.
> >>
> >> 3.) I use the Gnuradio Companion, and record from the USRP2 directly
> >> into a cfile. Is there any way to apply a filter to be able to
> >> automatically detect the start and end point of a high-amplitude that
> >> represents sending activity? I tried to use the integrator to lower
> >> the amplitude (I'm not interested in demodulation at this point, just
> >> tx start and end). But that doesn't work very well.
> >>
> >> I hope my terminology isn't too crude ;)
> >>
> >> Best,
> >> Marius
> >
> >
> > Marius,
> > While I _think_ there is a way to do what you are asking in 1 and 2, I
> > really can't remember right now, nor am I at a spot where I can looking
> into
> > it. I'm also trying to think if that's really your best bet for learning
> > what you are looking for, but at least it will be educational :)
> > As for 3., that's a bit difficult. You can do all sorts of things to
> detect
> > if you have a signal or not. The most agnostic way is to use a power
> > detector with a threshold level. We have a squelch block for this.
> > Since you know the signal you are looking for, though, you can get a more
> > tuned algorithm for signal detection. You should be able to create a
> matched
> > filter and detect if there is anything in the output. That should be
> (unless
> > I'm not thinking clearly right now) the ML approach to detecting if you
> have
> > a signal.
> > Tom
>
>
> I took a quick look at the 15.4 standard, your best bet for finding a
> 802.151.4 frame is to search for the preamble of each packet. As Tom
> mentioned, the maximum likelihood (ML) detector for this is a matched
> filter. Which in math terms is the magnitude of the correlation
> (sliding inner product)  between the known preamble sequence and your
> received signal. The point with the largest magnitude is the start of
> the 15.4 frame.
>
> Since 15.4 works off of a spread spectrum system, this magnitude peak
> should be very well defined and look like a large spike (pretty sure
> this is correct, Tom?). If there is no frame, the correlation should
> just appear as random noise.
>

Yes, I think that's correct. If you are critically sampled, then it should
look like a large spike when you get the hit.

Tom



> I suggest that you download the standard from IEEE and figure out the
> preamble sequence.
>
> --Colby
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Signal coming from the USRP to the computer

[Patrick Sisterhen]

I think a little more detailed precise answer to John's question might 
help:

John Andrews wrote:

> each complex sample that enters the
> USB bus is the following,
> 
> x[i] = (inphase_component) + j (quadrature_component), and
> x[i] = m(t)cos( 2*pi*FREQ_OFFSET*t + PHI ) + jm(t)sin( 
2*pi*FREQ_OFFSET*t +
> PHI ), where m(t), is the actual message signal, FREQ_OFFSET is the
> frequency offset, and PHI is the phase.
> 
> Is that correct?

I think you're confusing the baseband and passband signals a little, and 
the equations aren't quite right.

The complex-baseband signal (your message) is the data that is transferred 
across the USB channel.
x[i] = (in-phase) + j*(quadrature)
   = (x_i) + j*(x_q)

These are samples of your message signal, after modulation (mapping to a 
complex QAM-constellation, for example), coding, pulse-shaping, etc.

The signal is up/down converted on the USRP device such that the 
transmitted RF signal is

r(t) = x_i*cos(2*pi*f_c) - (x_q)*sin(2*pi*f_c)

(where f_c is your RF carrier frequency, and I'm ignoring phase offsets 
and noise)

Notice the subtraction there (which comes from the trig identities) and 
that all the terms are real (it's a real passband signal).

Hope that helps a little.

Patrick Sisterhen
National Instruments___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RFC: A generic 'Loop Filter' for PLL type blocks (Work with Freq and Time synch)

[Tom Rondeau]

On Tue, May 31, 2011 at 11:17 AM, Colby Boyer  wrote:

> I've taken a look at Gardner's text earlier and he does mention 3rd order
> PLLs. Also, I found the text with the chapter by Harris. Good reference.
>
> Thanks.


Yes, there is the 3rd order loop. It's honestly been so long since I've
looked at one, though, that I can't remember what they are used for. Which
is not to say that they aren't useful.

Tom


On Tue, May 31, 2011 at 6:16 AM, Tom Rondeau  wrote:
>
>> On Sat, May 28, 2011 at 2:29 AM, Colby Boyer wrote:
>>
>>> Hi All,
>>>
>>> Recently, I've gone down the road of timing synchronization and ended
>>> up learning basics for PLLs and such. So far in GNURadio, it seems
>>> that the loop filters used in the existing GNURadio synch blocks are
>>> only first order. From what I understand, increasing the filter order
>>> of the PLL can help it to lock in the presence of noise, for both
>>> timing and frequency. Any else care to comment on the performance
>>> gains for higher orders?
>>>
>>> I propose to come up with a block that can cascade a series of
>>> integrators and gains to form a loop filter. The total order and gains
>>> of the filter can perhaps be defined in the block constructor. The
>>> idea is make the block generic enough so that you can drop it in with
>>> an outside NCO and phase error detector.
>>>
>>> Thoughts, questions or concerns?
>>>
>>> Colby
>>
>>
>>
>> Colby,
>> You're general thought about having an implementation for these loops
>> could work well, since we repeat them frequently in various blocks.
>>
>> I will point out, though, that the PLLs are (I'm pretty sure) second order
>> loops since they have the two accumulator stages in them. These of course
>> look different than the types of circuits you normally see for PLLs, like in
>> Gardner's book. But if you can get it, fred harris has a paper called "Let's
>> assume the system is synchronized" that gives a great overview of the
>> various synchronization problems. It also contains many block diagrams for
>> these different systems, including a block diagram for a digital PLL. You
>> can pretty much trace the code in these PLL blocks to his diagrams.
>>
>> Tom
>>
>>
>>>
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help: CIR measurement problems using usrp_sounder.py

[Rickard Radio]

Have someone experience or other knowledge about the "usrp_sounder.py"
CIR-channel sounder, FPGA-based tool ?
It should be a very valuable and usable Gnu-Radio communications tool if it
works !?!?

I appreciate any comments or ideas to my issues with it as described below.

/ Rickard


On Sat, May 28, 2011 at 2:09 AM, Rickard Radio wrote:

> Dear all,
>
> I have been trying using the usrp_sounder.py script for measuring the
> channel impulse response (CIR), but without success.
>
> Q: - Have anyone succeeded? Does the FPGA-based script work as advertised?
>
> Here is what I got:
> Firstly, making a "loopback" test worked great
> > usrp_sounder.py   -g 50 -f 2.45e9 -d 12 -t -r -l -v  -F loopback.log
>
> followed by plotting the recorded CIR-values in Matlab:
> >> loopback = read_complex_binary('loopback.log',inf);
> >> plot(abs(loopback))
>
> This results in a nice looking "impulse-train", i.e., one strong impulse
> followed by near zero correlation values until the next PN-sequence frame
> (4095 values per 12-bit PN-period).
> So far, so good!
>
> However, when I try to send from one USRP with RFX2400 and receive with
> another (same setup) I do not get a representative output (I believe!).
> Distance between USRPs is about 10m, and placed in different rooms (with
> wooden walls).
> Rx> usrp_sounder.py -g 50 -f 2.45e9 -r -v  -F CIRtest.log
> Tx> usrp_sounder.py  -f 2.45e9 -t -v
>
> In this case I only see when plotting a continuous almost "random" sequence
> with relatively low but uniform max-amplitude, but no distinctive strong
> correlation peaks at all ?!?
> I do not understand why!?  Although the USRP to USRP distance is relatively
> short  (~10m) I would then expect a similar CIR-response as in the loopback
> test. That is, my expectation was not just one but a few relatively strong
> impulses, the rest of the long PN-period filled with much weaker background
> correlation noise. But I don't get any strong correlation-peaks at all !
> Not a single one that is well above the uniform bg correlation noise.
> Q: - Can anyone explain this result??
>
> It can not depend on a too weak received signal, since I tested to monitor
> it using the "ursp_fft.py" with the same UHDgain (= 50). In this case I can
> clearly see the broadband PN-signal in the frequency domain, well above the
> noise-floor (some 15-20 dB). Furthermore,  by turning on and off the
> PN-sequence transmitter during CIR-recording, I can also clearly notice a
> corresponding variation in the received signal strength when plotting in
> Matlab afterwards - but not a single distinctive peak at all !?!? Again just
> the uniform background correlation noise! Hmmm, why this then?!
>
> Q: - Have anyone had success with the "usrp_sounder.py" script?
> Q: - Does it work as advertised, or what can my problem be?
>
> I know it doesn't contain synchronization, so the CIR's should "roll"
> between PN-periods, but that is not the problem here, since I get no peaks?!
>
> Help me get nice strong peaks, please!
>
> Glad for any advice!
>
> / Rickard
>
>
> Below a summary of how I used the "ursp_sounder.py" script:
>
> Loopback:
> > usrp_sounder.py   -g 50 -f 2.45e9 -d 12 -t -r -l -v  -F loopback.log
> Using PN code degree of 12 length 4095
> Logging impulse records to file:  loopback.log
> Using smoothing alpha of 1.0
> Setting PN code degree to 12
> Enabling digital loopback.
> Enabling transmitter.
> gr_buffer::allocate_buffer: warning: tried to allocate
>4 items of size 32760. Due to alignment requirements
>512 were allocated.  If this isn't OK, consider padding
>your structure to a power-of-two bytes.
>On this platform, our allocation granularity is 4096 bytes.
> gr_buffer::allocate_buffer: warning: tried to allocate
>4 items of size 32760. Due to alignment requirements
>512 were allocated.  If this isn't OK, consider padding
>your structure to a power-of-two bytes.
>On this platform, our allocation granularity is 4096 bytes.
> Enter CTRL-C to stop.
>
> Q: -- Is it normal behaviour with the buffer-allocation warning above (I
> get it all the time when receiving, depending on the PN code length) ?
>
> Receiver:
> Rx > usrp_sounder.py -g 50 -f 2.45e9 -r -v  -F CIRtest.log
> Using PN code degree of 12 length 4095
> Sounding frequency range is 2.434G to 2.466G
> Logging impulse records to file:  CIRtest.log
> Using Flex 2400 Rx MIMO B for sounder receiver.
> Setting receiver gain to 50.0
> Using smoothing alpha of 1.0
> Setting receiver frequency to 2.45G
> Setting PN code degree to 12
> Disabling digital loopback.
> gr_buffer::allocate_buffer: warning: tried to allocate
>4 items of size 32760. Due to alignment requirements
>512 were allocated.  If this isn't OK, consider padding
>your structure to a power-of-two bytes.
>On this platform, our allocation granularity is 4096 bytes.
> gr_buffer::allocate_buffer: warning: tried to allocate
>4 items of size 32760. Due to alignment requirements
>512 were alloc

Re: [Discuss-gnuradio] gfortran-4.2.1 build 5666.3 for Xcode 4.0.2 on Mac OS X 10.6.7

[Tom Rondeau]

On Sat, May 28, 2011 at 5:19 PM, Elvis Dowson  wrote:

> Hi Alex,
>
> On May 29, 2011, at 1:04 AM, Alexandru Csete wrote:
> >
> > Can you see which package requires fortran?
> > It sounds like a false dependency and if there actually is something
> > that requires fortran it might not be important.
> >
> > I looked through my config.log file but the only place where I see
> > reference to fortran is where gcc reports that it has been compiled
> > with fortran support.
>
> The package that requires fortran is numpy.
>
>
> http://sourceforge.net/projects/numpy/files/NumPy/1.6.0/numpy-1.6.0.tar.gz/download
>
> A while back, I got gnuradio-3.3 to compile using gcc-4.0.1 using Xcode
> 3.2. Now I'm trying to refresh the build, for gnuradio-3.4.0. I've got most
> of the core dependent libraries installed. Just got stuck at the gfortran
> support.
>
> I tried to build the apple gcc-5666.3 compile with fortran only support,
> using the following configure options, but got the following error, even
> though gmp is installed.
>
> $ cd gcc-5666.3
> $ mkdir -p build/obj build/install
> $ ../../configure --disable-checking --enable-werror
> --prefix=/Users/elvis/Tool/gcc-5666.3/build/install
> --enable-languages=fortran --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
> --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10-
> --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
> --with-gmp=/usr/local
>
> checking host system type... x86_64-apple-darwin10
> checking target system type... i686-apple-darwin10
> checking build system type... i686-apple-darwin10
> checking for a BSD compatible install... /usr/bin/install -c
> checking whether ln works... yes
> checking whether ln -s works... yes
> checking for x86_64-apple-darwin10-gnatbind... no
> checking for gnatbind... no
> checking whether compiler driver understands Ada... no
> checking how to compare bootstrapped objects... cmp --ignore-initial=16
> $$f1 $$f2
> checking for correct version of gmp.h... no
> configure: error:
> The following requested languages could not be built: fortran
> Recognised languages are: c,c++,objc,obj-c++
>
>
> Elvis Dowson



I have to say that I find this very strange.  Can any of our OSX gurus out
there comment, perhaps?

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

Re: [Discuss-gnuradio] help with add a new block to GNURadio

[Tom Rondeau]

2011/5/31 intermilan 

>  Hi:
> I recently add a new block to the GNURadio and GRC.The function of the
> block is to correlate the received spread signal and the local PN code.
> I think my block can work well,but there is one thing I do not know how to
> fix.Sometimes the input of my block is 0 and then it will back to the
> normal.
> But I saw the  output data from the last block ,they are correct.Did anyone
> have situation  before? and how did it happen? In the accessory are the code
>
> of my block.
>thank you in advance.
>


I haven't looked over the code too closely, but a few comments. First,
because you are consuming and returning the same number of items, you can
just make this a gr_sync_block instead of a gr_block, which means you don't
have to worry about the forecast function and it simplifies the interface.

On the other hand, since you need at least d_len to make a decision, you'll
have to either deal with it by holding state or by forcing the scheduler to
give you the correct number of samples, minimum (set_output_multiple can be
useful for things like this if d_len is not too large).

Also, you are not initializing sum to anything in the work function, so the
initial test in the while loop might trigger incorrectly.

You are also incrementing the in pointer during the for loop, but it looks
like you want to remain there until the sum is greater than your threshold.
I would think that you would want to test in[0] to in[d_len-1] in one loop,
then in[1] to in[d_len], and so on. Here, you are going to skip an entire
d_len of inputs.

I'm not sure what you mean by the input of your block is 0. Does this mean
the number of input items is 0 or that the inputs themselves are 0?

Hope this helps some.

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

Re: [Discuss-gnuradio] RFC: A generic 'Loop Filter' for PLL type blocks (Work with Freq and Time synch)

[Colby Boyer]

I've taken a look at Gardner's text earlier and he does mention 3rd order
PLLs. Also, I found the text with the chapter by Harris. Good reference.

Thanks.

On Tue, May 31, 2011 at 6:16 AM, Tom Rondeau  wrote:

> On Sat, May 28, 2011 at 2:29 AM, Colby Boyer wrote:
>
>> Hi All,
>>
>> Recently, I've gone down the road of timing synchronization and ended
>> up learning basics for PLLs and such. So far in GNURadio, it seems
>> that the loop filters used in the existing GNURadio synch blocks are
>> only first order. From what I understand, increasing the filter order
>> of the PLL can help it to lock in the presence of noise, for both
>> timing and frequency. Any else care to comment on the performance
>> gains for higher orders?
>>
>> I propose to come up with a block that can cascade a series of
>> integrators and gains to form a loop filter. The total order and gains
>> of the filter can perhaps be defined in the block constructor. The
>> idea is make the block generic enough so that you can drop it in with
>> an outside NCO and phase error detector.
>>
>> Thoughts, questions or concerns?
>>
>> Colby
>
>
>
> Colby,
> You're general thought about having an implementation for these loops could
> work well, since we repeat them frequently in various blocks.
>
> I will point out, though, that the PLLs are (I'm pretty sure) second order
> loops since they have the two accumulator stages in them. These of course
> look different than the types of circuits you normally see for PLLs, like in
> Gardner's book. But if you can get it, fred harris has a paper called "Let's
> assume the system is synchronized" that gives a great overview of the
> various synchronization problems. It also contains many block diagrams for
> these different systems, including a block diagram for a digital PLL. You
> can pretty much trace the code in these PLL blocks to his diagrams.
>
> Tom
>
>
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] super minor UHD Subdev "bug"/feature request

[Josh Blum]

On 05/31/2011 10:08 AM, Brett L. Trotter wrote:
> I have a UHD app I'd like to work with USRP1 and 2- but when I give USRP2:
> self.dut_out.set_subdev_spec("A:A A:B", 0)
> it complains about the A's and I have to specify ":A :B" instead, but
> for USRP1 it needs the A.
> 

Officially, the daughterboard slot is named 0, so 0:A 0:B. Its weird but
better than asking the user to calculate a mux value.

I will add an app note to the usrp2/Nseries docs.

-josh

> It would be a nice simplification if the USRP2 allowed A:whatever since
> it technically has a side A and just no B.
> 
> 
> I'm about to look in the .h files right now, but is there a quick way,
> given a self.usrp = uhd.usrp_source() to call self.usrp.is_usrp2() or
> something?
> 
> ___
> 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] fusb: (rd status -2) No such file or directory

[Johannes Schmitz]

I found that our gnuradio is based on a version from git from "Thu Feb
11 08:18:46 2010"
But there are some patches and changes from our side so it is not so
easy for us to just jump to the newest version
Today I compiled the newest version from git to see what happens with
the example code and I don't get the fusb problem anymore.
Does anybody know which patch resolved the issue?

Johannes

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

Re: [Discuss-gnuradio] OFDM on USRP2

[Marcus D. Leech]

On 05/31/2011 10:15 AM, vanITA1082 wrote:

Thanks.

However we are trying to transmit a packet from a usrp n210 to another usrp
n210 and we are searching for examples do to this simple operation.

How is it possible that are not out there? Do you know any source of simple
examples?


Thanks

Vanessa



Dont know what state they're in:

./gnuradio-examples/python/ofdm
./gnuradio-examples/python/ofdm/ofdm_mod_demod_test.py
./gnuradio-examples/python/ofdm/plot_ofdm.m
./gnuradio-examples/python/ofdm/ofdm_sync.m
./gnuradio-examples/python/ofdm/benchmark_ofdm_rx.py
./gnuradio-examples/python/ofdm/benchmark_ofdm_tx.py
./gnuradio-examples/python/ofdm/gr_plot_ofdm.py
./gnuradio-examples/python/ofdm/benchmark_ofdm.py
./gnuradio-examples/python/ofdm/ofdm_sync_pn.m








--
Marcus Leech
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] OFDM on USRP2

[vanITA1082]

Thanks.

However we are trying to transmit a packet from a usrp n210 to another usrp
n210 and we are searching for examples do to this simple operation.

How is it possible that are not out there? Do you know any source of simple
examples?


Thanks

Vanessa


Tom Rondeau wrote:
> 
> On Mon, May 30, 2011 at 5:05 AM, vanITA1082
> wrote:
> 
>>
>> Dear Tom,
>>
>> Do you mind sharing your code for usrp n210 ?
>>
>> I am new on gnuradio and usrp and I am not able to find a python example
>> to
>> perform packet transmission.
>>
>>
>> Thank you
>>
>> Vanessa
>>
> 
> 
> You can find lots of examples from my gr_apps github repo:
> github.com/trondeau/gr_apps
> 
> For direct cloning:
> git://github.com/trondeau/gr_apps.git
> 
> Note, some of these are just basic utilities while others are more
> "works-in-progress" type projects.
> 
> Tom
> 
> 
> 
> 
>> Tom Rondeau wrote:
>> >
>> > On Mon, Jan 17, 2011 at 2:48 PM, Josh Blum  wrote:
>> >>
>> >>
>> >> On 01/17/2011 11:31 AM, Veljko Pejovic wrote:
>> >>> Hi,
>> >>>
>> >>> I updated the OFDM example. You can find it at
>> >>> http://www.cs.ucsb.edu/~veljko/downloads/ofdm_example.tar.gz
>> >>>
>> >>> It supports both USRPs and the UHD driver. I get pretty bad
>> >>> performance with UHD receiver for some reason. Any ideas?
>> >>>
>> >>
>> >> For the UHD performance issue, which model usrp? The following applies
>> >> to usrp2:
>> >>
>> >> Was the bad performance on a transmit + receive application? There was
>> >> an issue where if receive was not keeping up, the transmit flow
>> control
>> >> could be hampered; this is fixed on next branch.
>> >>
>> >> Or was it receive only? And in any case did UHD print and warnings
>> about
>> >> buffer sizes? Because it needs sysctl permission to allocate a large
>> >> enough receive buffer.
>> >>
>> >> -josh
>> >
>> >
>> > I found issues with the UHD code in setting the sample rates. When you
>> > set the sample rate, the best thing to do is ask the UHD device what
>> > the real sample rate it was actually set to. I then use a PFB arb
>> > resampler to adjust to the actual sample rate that I want.
>> >
>> > I was playing around with some FM signals and found that I couldn't
>> > get anything clean out until I did this, even though I was setting
>> > what I thought was a standard sample rate (that is, an integer
>> > decimation of the clock) to my N210. What I asked for and what I set
>> > were only off by a little bit, but it makes a huge difference in
>> > performance for FM signals.
>> >
>> > That said, we should be adjusting for this in the OFDM code, but it's
>> > something to keep in mind.
>> >
>> > Tom
>> >
>> >
>> >>>
>> >>> Cheers,
>> >>>
>> >>>
>> >>> Veljko
>> >>>
>> >>>
>> >>> On Tue, Jan 11, 2011 at 9:26 PM, Guanbo  wrote:
>> 
>>  Hi,
>> 
>>  I was looking for the source codes through the list.
>>  And I got one from Veljko from UCSB, who are very nice to share his
>>  codes,
>>  "ofdm_example.tar.gz"
>>  The codes are attached.
>>  Given the enough gain in TX and RX, you can see the output result at
>>  RX.
>> 
>>  Guanbo
>> 
>> http://old.nabble.com/file/p30650478/ofdm_example.zipofdm_example.zip
>> 
>> 
>>  mrahaim wrote:
>> >
>> >
>> > Hi all,
>> >
>> > Does anyone know of any updated OFDM benchmark code that is
>> modified
>> > to
>> > be run on a USRP2?  I have seen previous posts of this, however the
>> > link to the updated code is no longer available.
>> >
>> > Thanks,
>> >
>> > Michael Rahaim
>> > Graduate Research Assistant
>> > Smart Lighting Engineering Research Center
>> > Boston University
>> > mrah...@bu.edu
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> >
>> 
>>  --
>>  View this message in context:
>>  http://old.nabble.com/OFDM-on-USRP2-tp30638994p30650478.html
>>  Sent from the GnuRadio mailing list archive at Nabble.com.
>> 
>> 
>>  ___
>>  Discuss-gnuradio mailing list
>>  Discuss-gnuradio@gnu.org
>>  http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
>> >>>
>> >>> ___
>> >>> Discuss-gnuradio mailing list
>> >>> Discuss-gnuradio@gnu.org
>> >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>
>> >> ___
>> >> Discuss-gnuradio mailing list
>> >> Discuss-gnuradio@gnu.org
>> >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/OFDM-on-US

[Discuss-gnuradio] super minor UHD Subdev "bug"/feature request

[Brett L. Trotter]

I have a UHD app I'd like to work with USRP1 and 2- but when I give USRP2:
self.dut_out.set_subdev_spec("A:A A:B", 0)
it complains about the A's and I have to specify ":A :B" instead, but
for USRP1 it needs the A.

It would be a nice simplification if the USRP2 allowed A:whatever since
it technically has a side A and just no B.


I'm about to look in the .h files right now, but is there a quick way,
given a self.usrp = uhd.usrp_source() to call self.usrp.is_usrp2() or
something?

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

Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory

[Johannes Schmitz]

> You gotta be more specific. "IBM Notebooks" doesn't tell us what USB
> controller it is. At least give us the output of "lspci".

Actually our two Lab PC seem to have the same USB Controller:

"00:1d.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB
UHCI Controller"

But I tried on another machine which has nvidia MCP61 USB Controller

The IBM Notebook (T61) has a Intel 82801H Controller.

USRP Revision is 4.2 (at least the one I have on my desktop)

-Johannes

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

Re: [Discuss-gnuradio] RFC: A generic 'Loop Filter' for PLL type blocks (Work with Freq and Time synch)

[Tom Rondeau]

On Sat, May 28, 2011 at 2:29 AM, Colby Boyer  wrote:

> Hi All,
>
> Recently, I've gone down the road of timing synchronization and ended
> up learning basics for PLLs and such. So far in GNURadio, it seems
> that the loop filters used in the existing GNURadio synch blocks are
> only first order. From what I understand, increasing the filter order
> of the PLL can help it to lock in the presence of noise, for both
> timing and frequency. Any else care to comment on the performance
> gains for higher orders?
>
> I propose to come up with a block that can cascade a series of
> integrators and gains to form a loop filter. The total order and gains
> of the filter can perhaps be defined in the block constructor. The
> idea is make the block generic enough so that you can drop it in with
> an outside NCO and phase error detector.
>
> Thoughts, questions or concerns?
>
> Colby



Colby,
You're general thought about having an implementation for these loops could
work well, since we repeat them frequently in various blocks.

I will point out, though, that the PLLs are (I'm pretty sure) second order
loops since they have the two accumulator stages in them. These of course
look different than the types of circuits you normally see for PLLs, like in
Gardner's book. But if you can get it, fred harris has a paper called "Let's
assume the system is synchronized" that gives a great overview of the
various synchronization problems. It also contains many block diagrams for
these different systems, including a block diagram for a digital PLL. You
can pretty much trace the code in these PLL blocks to his diagrams.

Tom


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

Re: [Discuss-gnuradio] Issue with MMSE interp. filter (broken?)

[Tom Rondeau]

On Tue, May 31, 2011 at 2:13 AM, Colby Boyer  wrote:

> Hi All,
>
> Recently I've been using the MMSE interp filter. I found that when I shift
> a signal by a fractional amount of 0 (or anything really), the signal goes
> way off! I would expect SOME difference, but not this much...
>
> Some example output.
>
> Mu:0 In:(-1.67869,0.480381) Out:(0.0418351,-0.16734)
>
> Mu:0 In:(-1.23772,-0.104519) Out:(0.16003,-0.115883)
>
> Mu:0 In:(-1.7598,-0.0618457) Out:(0.0986395,-0.33428)
>
> On the imgur links are two Re-Im scatter plots of a bpsk signal, one with
> the fractional shift of 0 and the other with a fractional shift of 0.1 The
> points with 'x' are the resampled points and points with 'o' is the original
> signal. As you can see, the mmse fractional interp more or less destroys the
> signal! Unless I'm using it wrong!?
>
> Any comments?
>
> imgur: http://imgur.com/a/w98SX top picture is 0 delay, bottom is 0.1
> delay.
>
> Thanks!
> Colby



Colby,
This block has been around for years without any changes, and I and others
have been successfully using it in various projects, so my guess is that you
have some misconception about what it's doing or what the parameters are.

You can see how it's used to simulate a timing offset in
gnuradio-core/src/lib/hier/gr_channel_model.cc where it's used inside of the
gr_fractional_interpolator_cc block. We also use it in the
gr_clock_recovery_mm_XX and gr_mpsk_receiver_cc.

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

Re: [Discuss-gnuradio] Latency measurements with Unix-domain sockets

[Alexander Chemeris]

On Tue, May 31, 2011 at 15:24, Andre Puschmann
 wrote:
> On 05/31/2011 10:54 AM, Alexander Chemeris wrote:
>> On Tue, May 31, 2011 at 03:07, Marcus D. Leech  wrote:
>>> I used the following two little programs:
>>> 
>>>
>>> And found no significant difference in peak and average latencies
>>> between them.
>>>
>>> The unixdomain_server takes a single command-line argument which tells
>>> it how many samples
>>>  to average over before producing a printed result.
>>>
>>> So this confirms my earlier assertion that I would be surprised to find
>>> a significant latency difference
>>>  between Unix-domain sockets and FIFOs, since the interior kernel
>>> mechanisms are broadly similar.
>>>  Basically--some chunk of memory is copied from one place to another,
>>> there's some housekeeping, and
>>>  the system-call interface is traversed a couple of times.
>>
>> Let me contradict. Maximum latency is *much* better - less then 80us
>> instead of 3ms.
>>
>> Data attached as usual.  Tests were run with 'chrt 80 ./runtest_sh'
>>
>> PS I test on Core 2 Duo 1.6 GHz with all the GUI stuff running.
>
> Just did both tests on my machine here, Intel Core i5 notebook.
>
> I couldn't find such a high latency (3ms). Indeed, both are performing
> pretty much the same. I would even say that on my box, the pipe
> mechanism does even better in terms of jitter. I didn't calculate mean
> and standard deviation but from the plot it looks like the values are
> closer together.

So this once again means that there is no single answer. :)
We should put together a test which everyone could run and choose.


-- 
Regards,
Alexander Chemeris.

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

Re: [Discuss-gnuradio] 802.11 Interference

[Tom Rondeau]

On Mon, May 30, 2011 at 11:55 AM, Songsong Gee wrote:

> I'm trying to do some experiment on freq. band 2.4-2.483 GHz with RFX2400
> But I could not get what I expected.
>
> My guess is that 802.11 AP and USRP interfere each other, thus it cannot
> work well.
>
> Am I right?
>
> --
> Seokseong Jeon (aka Songsong Gee)
>

Songsong,
It would help a bit to know what your experiments were. The concept of
"interference" is really specific to your applications.

In general, though, yes, you will see interference from 802.11 systems in
the 2.4 GHz ISM band. You will also get interference from Bluetooth devices,
some portable phones, and microwave ovens to name some of the consumer
electronics that operate in those 80 MHz. It's a dirty band to operate in.

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

Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory

[Nick Foster]

On Tue, 2011-05-31 at 11:24 +0200, Johannes Schmitz wrote:
> > Is it conceivable that this particular problem is specific to a particular
> > type of USB host controller, since various folks
> >  have reported "I can't make it break", whereas a couple of folks (Johannes
> > and Brett) are able to make it break.
> 
> We tried with two different PCs and two IBM Notebooks. It happens
> every time. So I am not sure if we can say that it is because of host
> controller type.

You gotta be more specific. "IBM Notebooks" doesn't tell us what USB
controller it is. At least give us the output of "lspci".

> Maybe it is an Ubuntu specific problem.

I'm running an IBM Notebook (a Lenovo x220) on Ubuntu 11.04 x86_64 and
mine works OK on both the legacy and UHD drivers.

--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] Latency measurements with Unix-domain sockets

[Andre Puschmann]

On 05/31/2011 10:54 AM, Alexander Chemeris wrote:
> On Tue, May 31, 2011 at 03:07, Marcus D. Leech  wrote:
>> I used the following two little programs:
>> 
>>
>> And found no significant difference in peak and average latencies
>> between them.
>>
>> The unixdomain_server takes a single command-line argument which tells
>> it how many samples
>>  to average over before producing a printed result.
>>
>> So this confirms my earlier assertion that I would be surprised to find
>> a significant latency difference
>>  between Unix-domain sockets and FIFOs, since the interior kernel
>> mechanisms are broadly similar.
>>  Basically--some chunk of memory is copied from one place to another,
>> there's some housekeeping, and
>>  the system-call interface is traversed a couple of times.
> 
> Let me contradict. Maximum latency is *much* better - less then 80us
> instead of 3ms.
> 
> Data attached as usual.  Tests were run with 'chrt 80 ./runtest_sh'
> 
> PS I test on Core 2 Duo 1.6 GHz with all the GUI stuff running.

Just did both tests on my machine here, Intel Core i5 notebook.

I couldn't find such a high latency (3ms). Indeed, both are performing
pretty much the same. I would even say that on my box, the pipe
mechanism does even better in terms of jitter. I didn't calculate mean
and standard deviation but from the plot it looks like the values are
closer together.

Cheers,
Andre


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

Re: [Discuss-gnuradio] how to trigger dynamic reconfiguration with lock/disconnect

[Johannes Schmitz]

Hello Yang,
Do you have any specific questions?
Better you write some example programs first, then come back with your
exact questions I think.

Johannes

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

Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory

[Johannes Schmitz]

Hello Thomas,

> I'm not able to reproduce this error with the posted examples. Please
> try compiling with the --fusb-tech=libusb1 option and post any error
> output. It may not solve the problem, but debugging with libusb is
> simpler than debugging through the kernel.

Which distribution are you using? Is it Ubuntu as well?
I tried to compile with this option but I am getting the following
error when running configure:

checking for boost >= 1.35... no
configure: error: we could not detect the boost libraries (version
1.35 or higher).
If you are sure you have boost installed, then check your version
number looking in .

boost 1.42 is installed so I don't understand this.

Johannes

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

Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory

[Johannes Schmitz]

> Is it conceivable that this particular problem is specific to a particular
> type of USB host controller, since various folks
>  have reported "I can't make it break", whereas a couple of folks (Johannes
> and Brett) are able to make it break.

We tried with two different PCs and two IBM Notebooks. It happens
every time. So I am not sure if we can say that it is because of host
controller type.
Maybe it is an Ubuntu specific problem.

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

[Discuss-gnuradio] help with add a new block to GNURadio

[intermilan]

Hi:
I recently add a new block to the GNURadio and GRC.The function of the 
block is to correlate the received spread signal and the local PN code.
I think my block can work well,but there is one thing I do not know how to 
fix.Sometimes the input of my block is 0 and then it will back to the normal.
But I saw the  output data from the last block ,they are correct.Did anyone 
have situation  before? and how did it happen? In the accessory are the code 
of my block. 
   thank you in advance.
  /* -*- c++ -*- */
/*
 * Copyright 2004 Free Software Foundation, Inc.
 * 
 * This file is part of GNU Radio
 * 
 * GNU Radio is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3, or (at your option)
 * any later version.
 * 
 * GNU Radio is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with GNU Radio; see the file COPYING.  If not, write to
 * the Free Software Foundation, Inc., 51 Franklin Street,
 * Boston, MA 02110-1301, USA.
 */
#ifndef INCLUDED_PN_CORRELATOR_CC_H
#define INCLUDED_PN_CORRELATOR_CC_H

#include 
#include 
class pn_correlator_cc;

/*
 * We use boost::shared_ptr's instead of raw pointers for all access
 * to gr_blocks (and many other data structures).  The shared_ptr gets
 * us transparent reference counting, which greatly simplifies storage
 * management issues.  This is especially helpful in our hybrid
 * C++ / Python system.
 *
 * See http://www.boost.org/libs/smart_ptr/smart_ptr.htm
 *
 * As a convention, the _sptr suffix indicates a boost::shared_ptr
 */
typedef boost::shared_ptr pn_correlator_cc_sptr;

/*!
 * \brief Return a shared_ptr to a new instance of pn_correlator_cc.
 *
 * To avoid accidental use of raw pointers, pn_correlator_cc's
 * constructor is private.  pn_make_correlator_cc is the public
 * interface for creating new instances.
 */
pn_correlator_cc_sptr pn_make_correlator_cc (int degree, int mask=0, int seed=1);

/*!
 * \brief square a stream of floats.
 * \ingroup block
 *
 * \sa pn_square2_ff for a version that subclasses gr_sync_block.
 */
class pn_correlator_cc : public gr_block
{
private:
  // The friend declaration allows pn_make_correlator_cc to
  // access the private constructor.

  friend pn_correlator_cc_sptr pn_make_correlator_cc (int degree, int mask, int seed);
  intd_len;
  float  d_pn;
  gri_glfsr *d_reference;


  pn_correlator_cc ();  	// private constructor
 protected:
  pn_correlator_cc(int degree, int mask, int seed);

 public:
  void forecast (int noutput_items, gr_vector_int &ninput_items_required);
  ~pn_correlator_cc ();	// public destructor


  // Where all the action really happens

   int general_work (int noutput_items,
 gr_vector_int &ninput_items,
 gr_vector_const_void_star &input_items,
 gr_vector_void_star &output_items);
};

#endif /* INCLUDED_PN_CORRELATOR_CC_H */
/* -*- c++ -*- */
/*
 * Copyright 2004 Free Software Foundation, Inc.
 * 
 * This file is part of GNU Radio
 * 
 * GNU Radio is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3, or (at your option)
 * any later version.
 * 
 * GNU Radio is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with GNU Radio; see the file COPYING.  If not, write to
 * the Free Software Foundation, Inc., 51 Franklin Street,
 * Boston, MA 02110-1301, USA.
 */

/*
 * config.h is generated by configure.  It contains the results
 * of probing for features, options etc.  It should be the first
 * file included in your .cc file.
 */
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include 
#include 

/*
 * Create a new instance of pn_correlator_cc and return
 * a boost shared_ptr.  This is effectively the public constructor.
 */
pn_correlator_cc_sptr 
pn_make_correlator_cc (int degree, int mask, int seed)
{
  return pn_correlator_cc_sptr (new pn_correlator_cc (degree, mask, seed));
}

/*
 * Specify constraints on number of input and output streams.
 * This info is used to construct the input and output signatures
 * (2nd & 3rd args to gr_block's constructor).  The input and
 * output signatures are used by the runtime system to
 * check that a valid number and type of inputs and outputs
 * are connected to this block.  In this case, we accept
 * only 1 input and 1 o