Re: [Discuss-gnuradio] [VOLK] volk_profile failures

[West, Nathan]

Hi Sean,

I didn't read all of the debug info, but your symptoms are a result of
ORC doing bad things.

You can either uninstall ORC or upgrade to the latest release (0.4.23). The
commit you really need is this one:
http://cgit.freedesktop.org/gstreamer/orc/commit/?id=acdaac31c648fd10f1bd0a49c4c33b483bb9c35c

If you choose to upgrade ORC let me know how it goes.

Cheers,
Nathan

On Friday, June 5, 2015, Nowlan, Sean  wrote:

>  I compiled GNU Radio 3.7.7.1 natively on an ODROID XU3-Lite with Ubuntu
> 14.04.2 LTS. I ran volk_profile and got a lot of failures for various embedded
> architectures. Any ideas what could be happening? Could it be something
> with the compile flags I chose?
>
>
>  volk_16ic_s32f_deinterleave_32f_x2: fail on arch neon
> volk_16ic_s32f_deinterleave_32f_x2: fail on arch neon
> volk_16ic_s32f_deinterleave_32f_x2: fail on arch u_orc
> volk_16ic_s32f_deinterleave_32f_x2: fail on arch u_orc
> volk_32fc_s32f_magnitude_16i: fail on arch u_orc
> volk_32fc_x2_multiply_32fc: fail on arch a_generic
> volk_32fc_x2_multiply_32fc: fail on arch a_generic
> volk_32fc_x2_multiply_32fc: fail on arch a_generic
> volk_32fc_x2_multiply_32fc: fail on arch neon
> volk_32fc_x2_multiply_32fc: fail on arch neon
> volk_32fc_x2_multiply_32fc: fail on arch neon
> volk_32fc_x2_multiply_32fc: fail on arch neon_opttests
> volk_32fc_x2_multiply_32fc: fail on arch neon_opttests
> volk_32fc_x2_multiply_32fc: fail on arch neon_opttests
> volk_32fc_x2_multiply_32fc: fail on arch neonasm
> volk_32fc_x2_multiply_32fc: fail on arch neonasm
>  volk_32fc_x2_multiply_32fc: fail on arch neonasm
> volk_32fc_x2_multiply_32fc: fail on arch u_orc
> volk_32fc_x2_multiply_32fc: fail on arch u_orc
> volk_32fc_x2_multiply_32fc: fail on arch u_orc
> volk_32f_sqrt_32f: fail on arch neon
> volk_32f_x3_sum_of_poly_32f: fail on arch a_neon
> volk_32f_x3_sum_of_poly_32f: fail on arch neonvert
> volk_32fc_s32fc_multiply_32fc: fail on arch neon
>
>  The full output of volk_profile is here:
> 
> https://gist.github.com/nowls/37c78d89342053bae0ea
>  Resulting volk_config: https://gist.github.com/nowls/5894fbce1b29325b8f58
>
>  Some relevant configuration info taken from CMakeCache.txt (gcc/g++
> version and C/CXX/ASM flags):
>
>  CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++-4.9
> CMAKE_CXX_COMPILER_WITH_PATH:FILEPATH=/usr/bin/g++-4.9
> CMAKE_CXX_FLAGS:STRING=-mcpu=cortex-a15.cortex-a7
> -mtune=cortex-a15.cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard
> -funsafe-math-optimizations
> CMAKE_CXX_FLAGS_DEBUG:STRING=-g
> CMAKE_CXX_FLAGS_DEBUGPARANOID:STRING=-Wall -Wextra -g -O0
> CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
> CMAKE_CXX_FLAGS_NOOPTWITHASM:STRING=-Wall -save-temps -g -O0
> CMAKE_CXX_FLAGS_O2WITHASM:STRING=-Wall -save-temps -g -O2
> CMAKE_CXX_FLAGS_O3WITHASM:STRING=-Wall -save-temps -g -O3
> CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
> CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
> CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-4.9
> CMAKE_C_COMPILER_WITH_PATH:FILEPATH=/usr/bin/gcc-4.9
> CMAKE_C_FLAGS:STRING=-mcpu=cortex-a15.cortex-a7
> -mtune=cortex-a15.cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard
> -funsafe-math-optimizations
> CMAKE_C_FLAGS_DEBUG:STRING=-g
> CMAKE_C_FLAGS_DEBUGPARANOID:STRING=-Wall -Wextra -g -O0
> CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
> CMAKE_C_FLAGS_NOOPTWITHASM:STRING=-Wall -save-temps -g -O0
> CMAKE_C_FLAGS_O2WITHASM:STRING=-Wall -save-temps -g -O2
> CMAKE_C_FLAGS_O3WITHASM:STRING=-Wall -save-temps -g -O3
> CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
> CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
> CMAKE_ASM_FLAGS:STRING=-mcpu=cortex-a15.cortex-a7
> -mtune=cortex-a15.cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard
> -funsafe-math-optimizations
> CMAKE_ASM_FLAGS_DEBUG:STRING=-g
> CMAKE_ASM_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
> CMAKE_ASM_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
> CMAKE_ASM_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
>
>
>  Sean Nowlan
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [VOLK] volk_profile failures

[Nowlan, Sean]

I compiled GNU Radio 3.7.7.1 natively on an ODROID XU3-Lite with Ubuntu 14.04.2 
LTS. I ran volk_profile and got a lot of failures for various embedded 
architectures. Any ideas what could be happening? Could it be something with 
the compile flags I chose?


volk_16ic_s32f_deinterleave_32f_x2: fail on arch neon
volk_16ic_s32f_deinterleave_32f_x2: fail on arch neon
volk_16ic_s32f_deinterleave_32f_x2: fail on arch u_orc
volk_16ic_s32f_deinterleave_32f_x2: fail on arch u_orc
volk_32fc_s32f_magnitude_16i: fail on arch u_orc
volk_32fc_x2_multiply_32fc: fail on arch a_generic
volk_32fc_x2_multiply_32fc: fail on arch a_generic
volk_32fc_x2_multiply_32fc: fail on arch a_generic
volk_32fc_x2_multiply_32fc: fail on arch neon
volk_32fc_x2_multiply_32fc: fail on arch neon
volk_32fc_x2_multiply_32fc: fail on arch neon
volk_32fc_x2_multiply_32fc: fail on arch neon_opttests
volk_32fc_x2_multiply_32fc: fail on arch neon_opttests
volk_32fc_x2_multiply_32fc: fail on arch neon_opttests
volk_32fc_x2_multiply_32fc: fail on arch neonasm
volk_32fc_x2_multiply_32fc: fail on arch neonasm
volk_32fc_x2_multiply_32fc: fail on arch neonasm
volk_32fc_x2_multiply_32fc: fail on arch u_orc
volk_32fc_x2_multiply_32fc: fail on arch u_orc
volk_32fc_x2_multiply_32fc: fail on arch u_orc
volk_32f_sqrt_32f: fail on arch neon
volk_32f_x3_sum_of_poly_32f: fail on arch a_neon
volk_32f_x3_sum_of_poly_32f: fail on arch neonvert
volk_32fc_s32fc_multiply_32fc: fail on arch neon

The full output of volk_profile is here: 
 
https://gist.github.com/nowls/37c78d89342053bae0ea
Resulting volk_config: https://gist.github.com/nowls/5894fbce1b29325b8f58

Some relevant configuration info taken from CMakeCache.txt (gcc/g++ version and 
C/CXX/ASM flags):

CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++-4.9
CMAKE_CXX_COMPILER_WITH_PATH:FILEPATH=/usr/bin/g++-4.9
CMAKE_CXX_FLAGS:STRING=-mcpu=cortex-a15.cortex-a7 -mtune=cortex-a15.cortex-a7 
-mfpu=neon-vfpv4 -mfloat-abi=hard -funsafe-math-optimizations
CMAKE_CXX_FLAGS_DEBUG:STRING=-g
CMAKE_CXX_FLAGS_DEBUGPARANOID:STRING=-Wall -Wextra -g -O0
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMAKE_CXX_FLAGS_NOOPTWITHASM:STRING=-Wall -save-temps -g -O0
CMAKE_CXX_FLAGS_O2WITHASM:STRING=-Wall -save-temps -g -O2
CMAKE_CXX_FLAGS_O3WITHASM:STRING=-Wall -save-temps -g -O3
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-4.9
CMAKE_C_COMPILER_WITH_PATH:FILEPATH=/usr/bin/gcc-4.9
CMAKE_C_FLAGS:STRING=-mcpu=cortex-a15.cortex-a7 -mtune=cortex-a15.cortex-a7 
-mfpu=neon-vfpv4 -mfloat-abi=hard -funsafe-math-optimizations
CMAKE_C_FLAGS_DEBUG:STRING=-g
CMAKE_C_FLAGS_DEBUGPARANOID:STRING=-Wall -Wextra -g -O0
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMAKE_C_FLAGS_NOOPTWITHASM:STRING=-Wall -save-temps -g -O0
CMAKE_C_FLAGS_O2WITHASM:STRING=-Wall -save-temps -g -O2
CMAKE_C_FLAGS_O3WITHASM:STRING=-Wall -save-temps -g -O3
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
CMAKE_ASM_FLAGS:STRING=-mcpu=cortex-a15.cortex-a7 -mtune=cortex-a15.cortex-a7 
-mfpu=neon-vfpv4 -mfloat-abi=hard -funsafe-math-optimizations
CMAKE_ASM_FLAGS_DEBUG:STRING=-g
CMAKE_ASM_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
CMAKE_ASM_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
CMAKE_ASM_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG


Sean Nowlan

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

Re: [Discuss-gnuradio] Should Control Ports Work?

[Tom Rondeau]

On Fri, Jun 5, 2015 at 3:59 PM, Richard Bell 
wrote:

> Hey all,
>
> GNU Radio 3.7.7.1, Ubuntu 14.04
>
> Thank you Nathan for giving me that paper on Performance Counters and
> Control Ports. That is exactly the kind of debug analysis I want to do.
>
> I remember a long while back control ports had to be disable, I don't
> remember why. My install seems to fail with a CtrlPort Monitor in my
> flowgraph (AttributeError: 'NoneType' object has no attribute 'endpoints').
> Is this because they are still disabled, or should I look into fixing my
> install?
>
> Thanks,
> Rich
>


Nope, ControlPort was put in after 3.7.7 (and 3.7.7.1). It is enabled on
Master and will be released with 3.7.8.

We reimplemented the backend using Thrift, and there were too many
uncertainties with it when we were ready with 3.7.7, so we decided to leave
it out. It's now in master for those wanting and able to test it.

I've also used it on Android-based GNU Radio apps to optimize performance,
which gives me a lot of confidence about it.

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

[Discuss-gnuradio] Should Control Ports Work?

[Richard Bell]

Hey all,

GNU Radio 3.7.7.1, Ubuntu 14.04

Thank you Nathan for giving me that paper on Performance Counters and
Control Ports. That is exactly the kind of debug analysis I want to do.

I remember a long while back control ports had to be disable, I don't
remember why. My install seems to fail with a CtrlPort Monitor in my
flowgraph (AttributeError: 'NoneType' object has no attribute 'endpoints').
Is this because they are still disabled, or should I look into fixing my
install?

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

Re: [Discuss-gnuradio] What is the difference between Streams To Stream and Streams to Vector

[Richard Bell]

Hi Carl,

I can't answer the question for you directly, but I can give you a way to
figure it out.

Use two vector source blocks to generate two different known streams. The
first stream vector would be [1,3,5,7,...], a list of odd numbers however
long you want to make it. Set the block to repeat this. The second vector
would be [0,2,4,6,...], a list of even numbers. Feed these two streams into
your Streams to Vector block and dump it to a file. Now inspect the file
and see how these two streams were merged together.

Hope that helps.

Rich

On Fri, Jun 5, 2015 at 12:11 PM, Carl Olsson 
wrote:

> Hi all!
>
> I am recording data from two USRP:s and I want to put the data into one
> file sink.
> I think I could do it by using the Streams To Vector block and then
> changing the vector parameter in the file sink to 2.
>
> 1) How would I read that data in e.g. Matlab. Right now I am using the
> read_complex_binary function when I don't have a vector input. Is the
> format the same just that every second variable is from element 2 of the
> vector input?
>
> 2) There is also the Streams To Stream block. What would the difference be
> if I connected that block to the two USRP source blocks and then the output
> to a file sink, would that be the same as in Q1?
>
> 3) Could I read myself to this information anywhere?
>
> Thank you very much!
>
> Best Regards,
>
> Carl
>
> ___
> 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] What is the difference between Streams To Stream and Streams to Vector

[Carl Olsson]

Hi all!

I am recording data from two USRP:s and I want to put the data into one
file sink.
I think I could do it by using the Streams To Vector block and then
changing the vector parameter in the file sink to 2.

1) How would I read that data in e.g. Matlab. Right now I am using the
read_complex_binary function when I don't have a vector input. Is the
format the same just that every second variable is from element 2 of the
vector input?

2) There is also the Streams To Stream block. What would the difference be
if I connected that block to the two USRP source blocks and then the output
to a file sink, would that be the same as in Q1?

3) Could I read myself to this information anywhere?

Thank you very much!

Best Regards,

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

Re: [Discuss-gnuradio] core dumped when closing GRC

[Nemanja Savic]

Hi,

yeah basically it's not a big deal, just a bit anonying. However it can be
probably problem with glib since my RHEL6 probably has some ancient version
...

Thanks,
Nemanja

On Fri, Jun 5, 2015 at 12:32 AM, Tom Rondeau  wrote:

> On Thu, Jun 4, 2015 at 12:58 PM, Martin Braun 
> wrote:
>
>> OK, in that case probably some other issue. Can't really say more from
>> afar.
>>
>> Cheers,
>> Martin
>>
>> On 04.06.2015 09:33, Nemanja Savic wrote:
>> > Hi,
>> >
>> > so, well, I did like it should be, first I installed UHD and then
>> > GNURadio...
>> > The point is that segmentation fault happens when I am closing GRC. So,
>> > even without any flowgraph.
>> >
>> > Nemanja
>> >
>> > On Thu, Jun 4, 2015 at 5:43 PM, Martin Braun > > > wrote:
>> >
>> >
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#My-application-segfaults-immediately-It-used-to-work-and-I-didnt-change-it-What-the
>> >
>> > M
>> >
>> > On 04.06.2015 05:42, Nemanja Savic wrote:
>> > > Hi all,
>> > >
>> > > i finally managed to install newest version of gnuradio (3.7.7.1)
>> > on mu
>> > > RHEL6. Everyrhing look sjust fine except segmentation fault when
>> > closing
>> > > GRC. Didi anybody experience something like this and how can I
>> > debug it?
>> > >
>> > > Best
>> > >
>> > > --
>> > > Nemanja Savić
>>
>
> I think we've seen this before with certain versions of glibc (possibly
> another library that we haven't looked at). It used to effect older
> versions of Ubuntu (14.04 IIRC) but not the latest couple of versions. We
> tried to track it down, but since it looked like it was in glibc and was
> fixed with newer versions (and it only happens on exit), we didn't go too
> far in looking into this one.
>
> Tom
>
>



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

Re: [Discuss-gnuradio] question developing a new block

[Marcus Müller]

Hi Andreas,

On 06/05/2015 12:51 PM, Andreas Ladanyi wrote:
> Hi Marcus,
>
>> Dear Andreas,
>>> How is it possible to fill a python grc variable block with data from
>> another block C++ variable.
>> not really. GRC variables are a concept that doesn't exist in the flow
>> graph or, really, in the python file that GRC generates. They just are
>> python variables used when setting up the block
> Setting up means to insert the block in the flow graph and configure
> them ?!
>> , and if they are used in
>> a field for which the block specified a callback method, that method
>> will be included in a python function that gets called by blocks that
>> GRC knows can change variables (e.g. GUI input elements); this mechanism
>> of calling the callbacks doesn't really work without special glue;
> ok and this glue (swig file) is produced by a process triggered by the
> make command in a gr_modtools environment ?
There's more glue involved than just swig here. Again, all the magic
that happens behind the curtain can be found when you read the generated
python code.
You'll notice that for some graphical input elements, there are
functions defined that these input widgets get instructed to inform as
soon as things change. That works because the GUI toolkits allow for
this kind of callback-emulation.
>
> How can i tell gr_modtools or make to produce a callback function or
> howto program a callback function in the C++ code and the 
> xml tag in the block xml file myself for my own block so a grc python
> variable name from flow graph could be inserted in a field of my new
> block later when configuring my new block in the flow graph ?
Not at all. You'll need to analyze the way the XML blocks for example of
the qtgui widgets are written, and what the generated python code looks
like, and then you'll have to manually copy that.
>>  
>> I heartily invite you to do this the "GNU Radio way": Using message
>> passing as the way to exchange information between blocks inherently
>> solves the multithreading problems that otherwise would arise (for
>> example, assume you'd be able to change the taps of a FIR whilst that
>> FIR's work() function is working; what's the correct behaviour? How do
>> you avoid segmentation faults when the new taps are shorter than the old
>> ones?). Also, it lets users understand where data/commands flow rather
>> than hiding that behind a variable name.
> Yes i read the message passing chapter and the pmt and will go in
> detail later.
Really, do it sooner than later; I do like variables as a means of
thinking when constructing my flow graph, they are O.K. for GUI widgets,
but things get ugly the moment you really want to use them from within a
block -- as you might have noticed :) GRC variables originally were
really meant only to be used by python during flow graph creation, and
the whole dynamic reconfigurability of variables at run time came later,
but before message passing worked the way it does now -- if I may throw
in wild speculation, I'd assume that if GRC was re-invented today, it
would just set up a message handler for each block using a variable, and
just allow the block author to specify what happens in that message
handler, as well as forcing every variable-changing block to have a
message output port; but: GRC has been around for quite some time, and
its maintenance is a remarkable effort, plus people get slightly
irritated when their block XML stops working.

Is there a particular reason why you wouldn't use messages?
If you need to use a block that doesn't take instructions via messages,
write a hier block that accepts messages from the blocks inside of it,
and translates them into getter/setter calls on other blocks; or, better
even, if you think the block you want to use would profit generally from
having a message port for commands/settings, fix that up-stream. There's
virtually no overhead to having a message port/handler!

Best regards,
Marcus

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

Re: [Discuss-gnuradio] question developing a new block

[Andreas Ladanyi]

Hi Marcus,


Dear Andreas,

How is it possible to fill a python grc variable block with data from

another block C++ variable.
not really. GRC variables are a concept that doesn't exist in the flow
graph or, really, in the python file that GRC generates. They just are
python variables used when setting up the block
Setting up means to insert the block in the flow graph and configure 
them ?!

, and if they are used in
a field for which the block specified a callback method, that method
will be included in a python function that gets called by blocks that
GRC knows can change variables (e.g. GUI input elements); this mechanism
of calling the callbacks doesn't really work without special glue;
ok and this glue (swig file) is produced by a process triggered by the 
make command in a gr_modtools environment ?


How can i tell gr_modtools or make to produce a callback function or 
howto program a callback function in the C++ code and the  xml 
tag in the block xml file myself for my own block so a grc python 
variable name from flow graph could be inserted in a field of my new 
block later when configuring my new block in the flow graph ?


I heartily invite you to do this the "GNU Radio way": Using message
passing as the way to exchange information between blocks inherently
solves the multithreading problems that otherwise would arise (for
example, assume you'd be able to change the taps of a FIR whilst that
FIR's work() function is working; what's the correct behaviour? How do
you avoid segmentation faults when the new taps are shorter than the old
ones?). Also, it lets users understand where data/commands flow rather
than hiding that behind a variable name.
Yes i read the message passing chapter and the pmt and will go in detail 
later.


Best regards,
Marcus

regards und thanks,
Andy
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem with ofdm bandwidth and sampling rate

[Marcus Müller]

Hi Alphonso,

On 06/05/2015 11:22 AM, bh...@web.de wrote:
> i think i have understand the concept now: the sampling rate is valid
> global for the hole graph.if there is a previous/following block or
> source with a different rate, i have to resample it with such a
> resampler block. i am right?
No. There is no sampling rate in GNU Radio, really. It's just a
numerical concept for each block. For example, look at the standard
"signal source". It takes a frequency and a sampling rate argument. If
you use f=1000 and sampling rate=4000, the signal source (float mode)
will just calculate how to scale the values that it puts into the sine
function. You will get exactly the same signal (really, no difference
*anywhere*) if you used f=0.5, rate=2, or f=1e9 and rate=4e9.
So, each block has only "sample" as a means to measure time, and
1/sample as a means to measure frequency. You need to start thinking
relative to Nyquist frequency, i.e. to say "this signal source generates
a signal at 0.25 of the sample rate, which is equivalent to 0.5 nyquist
frequency, because this is real sampling".
You'll quickly see that the OFDM modulator and demodulator always uses
the whole possible bandwidth (complex sampling, hence nyquist frequency
== sampling rate), and your resampler generates a signal where only a
part of the bandwidth is occupied.

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

Re: [Discuss-gnuradio] problem with ofdm bandwidth and sampling rate

[BHN66]

hi marcus,

>>You will have to resample exactly inversely to your TX resampler, before trying to demodulate that.

 

done... and it works! thanks for your explanation. i hope that will help me to better understand the background and to avoid new mistakes.

 

>>You still have to move the upsampled signal from 0 Hz to your desired center frequency, and then you'll have to convert to a real signal, before being able to feed things to a sound card. On the receive side, you'd need to do the inverse.

 

that part still works but was not implemented to this flowgraph. i have used a complex signal that i have found on the internet and the mixing up/down procedure works fine. on the rx side i get a real signal so i have to convert it to a complex signal by a hilbert filter for further processing (--> ofdm demod block). is that ok or are there some sticking points which i have not considered at the moment?

 

thanks a lot for your help!

 

alphonso

 

Gesendet: Freitag, 05. Juni 2015 um 02:02 Uhr
Von: "Marcus Müller" 
An: discuss-gnuradio@gnu.org
Betreff: Re: [Discuss-gnuradio] problem with ofdm bandwidth and sampling rate


Hi Alphonso,

well, your OFDM mod block uses the whole nyquist bandwidth of your sampled signal, ie. at the output of the OFDM mod block, all frequencies in [-pi;pi] (relative frequencies, as sampling rate doesn't really exist in this world) are used. After the resampler, only frequencies in [-(11/48)pi;(11/48)pi] are occupied. You feed that signal directly into the OFDM demod block. How is that block supposed to know to only look into that sub band? You will have to resample exactly inversely to your TX resampler, before trying to demodulate that.

You still have to move the upsampled signal from 0 Hz to your desired center frequency, and then you'll have to convert to a real signal, before being able to feed things to a sound card. On the receive side, you'd need to do the inverse.

Best regards,
Marcus
On 06/05/2015 10:15 AM, bh...@web.de wrote:



hi felix,

i have tried it with the resampler block but it didn't work well.

 

on the tx side i have used it to resample from 11khz, which i need for my 10khz bandwidth, to 48khz. on the rx side i can see the spectrum with 48khz and the bandwidth of my signal still remains at 10khz (as requested). the problem is that i can't detect any signal at rx side. when i adjust both parts (tx and rx) with a sampling rate at 11khz it works.

 

for better understanding i have attached my flowgraphs and sink outputs.

 

alphonso


Gesendet: Donnerstag, 04. Juni 2015 um 23:40 Uhr
Von: "Wunsch, Felix (CEL)" 
An: "bh...@web.de" , "discuss-gnuradio@gnu.org" 
Betreff: Re: [Discuss-gnuradio] problem with ofdm bandwidth and sampling rate


 
On 03.06.2015 17:29, bh...@web.de wrote:




hello felix,

>>please remember to always reply to the list.

i'm sorry, i'm new at this. i have checked my configuration and i hope it works the next time.

 

to mix up the baseband signal to 12khz or higher to short wave (3-30mhz) should be the same procedure. i have tested it by using a multiply block and a signal source block as the carrier frequency.

 

but there is an other question: if i configured my system as described, can i be sure that the bandwidth of each sub carrier has the bandwidth and symbol duration as shown by the equations?

 

used_bw = occupied_carriers * df

df = used_bw / occupied_carriers = 10khz / 228

df = 43.86hz   -->   tsym = 22.8ms

 

it's very confusing why i have to adjust my used bw by changing the sampling rate. when i follow the equations and the standard i choose one mode (RM A, SO 3). that means i have to use 228 carriers
and have a symbol duration with 24ms which leads to 41.66hz carrier spacing. so the used bw is 228 * 41.66hz = 9.5khz (approx. 10khz). this bw should be fix and should not change by the sampling rate.

 

sorry for the maybe silly questions but i want to keep on that stuff.



Well, the measurable on-air bandwidth is always defined by the speed/rate at which your soundcard processes your digital samples. If you remember that B ~ 1/T and that the rate of your soundcard controls T it becomes obvious that changing the sample rate changes the bandwidth. If you don't want that, you could use a resampler that adapts its resampling ratio to the sampling rate of the soundcard.

Felix



 

@Marcus

you mean if there were pilots for a channel estimation in the transmitted signal?

 

alphonso

 



 

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

Felix Wunsch, M. Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu

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/discu

Re: [Discuss-gnuradio] problem with ofdm bandwidth and sampling rate

[BHN66]

hi felix,

thanks, you are right! now it works!

 

i think i have understand the concept now: the sampling rate is valid global for the hole graph. if there is a previous/following block or source with a different rate, i have to resample it with such a resampler block. i am right?

 

but there are still two questions left concerning the sampling rate:

 

1) as written in previous posts i have to adjust my sampling rate to 11.228khz to get a bandwidth of 10khz. but with the resampler block i can only set the interpolation/decimation factor as an integer value. now i have set the sampling rate to 11khz to get afterwards a rate of 48khz by resampling (dec=11, int=48) but this will affect my bandwidth again. is there no way to adjust the exact bandwidth?

 

2) if i configured my system as described, can i be sure that the bandwidth of each sub carrier has the bandwidth and symbol duration as shown by the equations?


used_bw = occupied_carriers * df

df = used_bw / occupied_carriers = 10khz / 228

df = 43.86hz   -->   tsym = 22.8ms



 

alphonso


Gesendet: Freitag, 05. Juni 2015 um 01:28 Uhr
Von: "Wunsch, Felix (CEL)" 
An: "bh...@web.de" , "discuss-gnuradio@gnu.org" 
Betreff: Re: Aw: Re: [Discuss-gnuradio] problem with ofdm bandwidth and sampling rate


Hi Alphonso,

keep in mind that if you don't resample on RX side your signal processing has to deal with the oversampled signal. If you use the same chain to demodulate your signal I can see why it only works when you resample on RX side.

-- Felix
 
On 05.06.2015 10:15, bh...@web.de wrote:



hi felix,

i have tried it with the resampler block but it didn't work well.

 

on the tx side i have used it to resample from 11khz, which i need for my 10khz bandwidth, to 48khz. on the rx side i can see the spectrum with 48khz and the bandwidth of my signal still remains at 10khz (as requested). the problem is that i can't detect any signal at rx side. when i adjust both parts (tx and rx) with a sampling rate at 11khz it works.

 

for better understanding i have attached my flowgraphs and sink outputs.

 

alphonso


Gesendet: Donnerstag, 04. Juni 2015 um 23:40 Uhr
Von: "Wunsch, Felix (CEL)" 
An: "bh...@web.de" , "discuss-gnuradio@gnu.org" 
Betreff: Re: [Discuss-gnuradio] problem with ofdm bandwidth and sampling rate


 
On 03.06.2015 17:29, bh...@web.de wrote:




hello felix,

>>please remember to always reply to the list.

i'm sorry, i'm new at this. i have checked my configuration and i hope it works the next time.

 

to mix up the baseband signal to 12khz or higher to short wave (3-30mhz) should be the same procedure. i have tested it by using a multiply block and a signal source block as the carrier frequency.

 

but there is an other question: if i configured my system as described, can i be sure that the bandwidth of each sub carrier has the bandwidth and symbol duration as shown by the equations?

 

used_bw = occupied_carriers * df

df = used_bw / occupied_carriers = 10khz / 228

df = 43.86hz   -->   tsym = 22.8ms

 

it's very confusing why i have to adjust my used bw by changing the sampling rate. when i follow the equations and the standard i choose one mode (RM A, SO 3). that means i have to use 228 carriers
and have a symbol duration with 24ms which leads to 41.66hz carrier spacing. so the used bw is 228 * 41.66hz = 9.5khz (approx. 10khz). this bw should be fix and should not change by the sampling rate.

 

sorry for the maybe silly questions but i want to keep on that stuff.



Well, the measurable on-air bandwidth is always defined by the speed/rate at which your soundcard processes your digital samples. If you remember that B ~ 1/T and that the rate of your soundcard controls T it becomes obvious that changing the sample rate changes the bandwidth. If you don't want that, you could use a resampler that adapts its resampling ratio to the sampling rate of the soundcard.

Felix



 

@Marcus

you mean if there were pilots for a channel estimation in the transmitted signal?

 

alphonso

 



 

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

Felix Wunsch, M. Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu

www.cel.kit.edu

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









 

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

Felix Wunsch, M. Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu

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

Re: [Discuss-gnuradio] problem with ofdm bandwidth and sampling rate

[Marcus Müller]

Hi Alphonso,

well, your OFDM mod block uses the whole nyquist bandwidth of your
sampled signal, ie. at the output of the OFDM mod block, all frequencies
in [-pi;pi] (relative frequencies, as sampling rate doesn't really exist
in this world) are used. After the resampler, only frequencies in
[-(11/48)pi;(11/48)pi] are occupied. You feed that signal directly into
the OFDM demod block. How is that block supposed to know to only look
into that sub band? You will have to resample exactly inversely to your
TX resampler, before trying to demodulate that.

You still have to move the upsampled signal from 0 Hz to your desired
center frequency, and then you'll have to convert to a real signal,
before being able to feed things to a sound card. On the receive side,
you'd need to do the inverse.

Best regards,
Marcus
On 06/05/2015 10:15 AM, bh...@web.de wrote:
> hi felix,
> i have tried it with the resampler block but it didn't work well.
>  
> on the tx side i have used it to resample from 11khz, which i need for
> my 10khz bandwidth, to 48khz. on the rx side i can see the spectrum
> with 48khz and the bandwidth of my signal still remains at 10khz (as
> requested). the problem is that i can't detect any signal at rx side.
> when i adjust both parts (tx and rx) with a sampling rate at 11khz it
> works.
>  
> for better understanding i have attached my flowgraphs and sink outputs.
>  
> alphonso
> *Gesendet:* Donnerstag, 04. Juni 2015 um 23:40 Uhr
> *Von:* "Wunsch, Felix (CEL)" 
> *An:* "bh...@web.de" , "discuss-gnuradio@gnu.org"
> 
> *Betreff:* Re: [Discuss-gnuradio] problem with ofdm bandwidth and
> sampling rate
>  
> On 03.06.2015 17:29, bh...@web.de wrote:
>
> hello felix,
> >>please remember to always reply to the list.
> i'm sorry, i'm new at this. i have checked my configuration and i
> hope it works the next time.
>  
> to mix up the baseband signal to 12khz or higher to short wave
> (3-30mhz) should be the same procedure. i have tested it by using
> a multiply block and a signal source block as the carrier frequency.
>  
> but there is an other question: if i configured my system as
> described, can i be sure that the bandwidth of each sub carrier
> has the bandwidth and symbol duration as shown by the equations?
>  
> used_bw = occupied_carriers * df
> df = used_bw / occupied_carriers = 10khz / 228
> df = 43.86hz   -->   tsym = 22.8ms
>  
> it's very confusing why i have to adjust my used bw by changing
> the sampling rate. when i follow the equations and the standard i
> choose one mode (RM A, SO 3). that means i have to use 228 carriers
> and have a symbol duration with 24ms which leads to 41.66hz
> carrier spacing. so the used bw is 228 * 41.66hz = 9.5khz (approx.
> 10khz). this bw should be fix and should not change by the
> sampling rate.
>  
> sorry for the maybe silly questions but i want to keep on that stuff.
>
> Well, the measurable on-air bandwidth is always defined by the
> speed/rate at which your soundcard processes your digital samples. If
> you remember that B ~ 1/T and that the rate of your soundcard controls
> T it becomes obvious that changing the sample rate changes the
> bandwidth. If you don't want that, you could use a resampler that
> adapts its resampling ratio to the sampling rate of the soundcard.
>
> Felix
>
>  
> @Marcus
> you mean if there were pilots for a channel estimation in the
> transmitted signal?
>  
> alphonso
>  
>
>  
> -- 
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Felix Wunsch, M. Sc.
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-46276
> Fax: +49 721 608-46071
> E-Mail: felix.wun...@kit.edu
>
> 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] problem with ofdm bandwidth and sampling rate

[Wunsch, Felix (CEL)]

Hi Alphonso,

keep in mind that if you don't resample on RX side your signal 
processing has to deal with the oversampled signal. If you use the same 
chain to demodulate your signal I can see why it only works when you 
resample on RX side.


-- Felix

On 05.06.2015 10:15, bh...@web.de wrote:

hi felix,
i have tried it with the resampler block but it didn't work well.
on the tx side i have used it to resample from 11khz, which i need for 
my 10khz bandwidth, to 48khz. on the rx side i can see the spectrum 
with 48khz and the bandwidth of my signal still remains at 10khz (as 
requested). the problem is that i can't detect any signal at rx side. 
when i adjust both parts (tx and rx) with a sampling rate at 11khz it 
works.

for better understanding i have attached my flowgraphs and sink outputs.
alphonso
*Gesendet:* Donnerstag, 04. Juni 2015 um 23:40 Uhr
*Von:* "Wunsch, Felix (CEL)" 
*An:* "bh...@web.de" , "discuss-gnuradio@gnu.org" 

*Betreff:* Re: [Discuss-gnuradio] problem with ofdm bandwidth and 
sampling rate

On 03.06.2015 17:29, bh...@web.de wrote:

hello felix,
>>please remember to always reply to the list.
i'm sorry, i'm new at this. i have checked my configuration and i
hope it works the next time.
to mix up the baseband signal to 12khz or higher to short wave
(3-30mhz) should be the same procedure. i have tested it by using
a multiply block and a signal source block as the carrier frequency.
but there is an other question: if i configured my system as
described, can i be sure that the bandwidth of each sub carrier
has the bandwidth and symbol duration as shown by the equations?
used_bw = occupied_carriers * df
df = used_bw / occupied_carriers = 10khz / 228
df = 43.86hz   -->   tsym = 22.8ms
it's very confusing why i have to adjust my used bw by changing
the sampling rate. when i follow the equations and the standard i
choose one mode (RM A, SO 3). that means i have to use 228 carriers
and have a symbol duration with 24ms which leads to 41.66hz
carrier spacing. so the used bw is 228 * 41.66hz = 9.5khz (approx.
10khz). this bw should be fix and should not change by the
sampling rate.
sorry for the maybe silly questions but i want to keep on that stuff.

Well, the measurable on-air bandwidth is always defined by the 
speed/rate at which your soundcard processes your digital samples. If 
you remember that B ~ 1/T and that the rate of your soundcard controls 
T it becomes obvious that changing the sample rate changes the 
bandwidth. If you don't want that, you could use a resampler that 
adapts its resampling ratio to the sampling rate of the soundcard.


Felix

@Marcus
you mean if there were pilots for a channel estimation in the
transmitted signal?
alphonso

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

Felix Wunsch, M. Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail:felix.wun...@kit.edu

www.cel.kit.edu

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



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

Felix Wunsch, M. Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu

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

Re: [Discuss-gnuradio] Move USRP LO with USRP sink block?

[Marcus Müller]

Hi John,

I'm a bit confused. You're using the WBX, correct?
The WBX can not go down to 3.something MHz, that's outside its frequency
range. You should be getting warnings about that when trying to tune
there; you're most probably looking at the signal at the lowest
frequency that the WBX can do.

The other things you said were a bit questionable, but I'd prefer to
discuss them when I understand where the signal you're interested in
actually lies.

Best regards,
Marcus

On 06/05/2015 01:41 AM, John Petrich wrote:
>
> Oh, thanks Marcus.  So, you are saying that there is no way to shift
> the DC spike at baseband.  Got what you are saying.  As a practical
> matter at baseband, I shift the DC point by specifying a frequency in
> the USRP higher than the target frequency, and then specify a
> frequency in the Xlating filter that is lower than the desired
> frequency.  Ends up shifting the DC spike away from the desired
> frequency.
>
>  
>
> However, with my WBX board, what command would you suggest in the USRP
> Source center frequency parameter field?
>
>  
>
> Thank you very much for your time and help.
>
>  
>
> Regards,
>
> John Petrich
>
>  
>
> *From:*Marcus Müller [mailto:marcus.muel...@ettus.com]
> *Sent:* Thursday, June 4, 2015 3:33 PM
> *To:* John Petrich; GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] Move USRP LO with USRP sink block?
>
>  
>
> You can request that UHD tries to get the LO offset you request as
> close as possible, but because the LO synthesizers used on the
> USRPs/daughterboards (what are you using, by the way?) can only
> synthesize a discrete set of frequencies, not everything is possible.
> Now, I just realized you tried to tune a daughterboard to 3MHz (I
> misread and thought you'd try to tune to 3GHz). There's no
> daughterboard that goes that far down, because that's really just
> baseband.
> So I have to assume that you're using LFRX or BasicRX, which don't
> have mixers, so the LO frequency is always 0 and the digital shifting
> is always the center frequency you ask for.
>
> Best regards,
> Marcus
>
> On 06/05/2015 12:20 AM, John Petrich wrote:
>
> Marcus,
>
>  
>
> Yes, could you help me with a specific command for the properties
> field:  I want a rx frequency of 3.545 MHz with an LO offset of
> 50e3 Hz.
>
>  
>
> Thank you,
>
> John Petrich
>
>  
>
> *From:*Marcus Müller [mailto:marcus.muel...@ettus.com]
> *Sent:* Thursday, June 4, 2015 2:41 PM
> *To:* John Petrich; GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] Move USRP LO with USRP sink
> block? (was: Re: question per your 2/10/15 post on Ruby Forum)
>
>  
>
> Hi John,
> I'm a bit confused; which discussion is this from?
> Ruby-Forum is not actually the platform we use, they just "mirror"
> the GNU mailing list archives (I don't really know why they do
> that -- we don't have anything to do with them). I'd recommend
> joining that mailing list personally [1].
>
> Regarding your question:
> 10kHz is very small. Possibly, the closest possible physical LO
> frequency is still the one you'd have if you didn't shift. Try
> increasing 10e3 to something that is out of the band that you want
> to observe; for example, if you're using a sampling rate of 10e6,
> try 11e6. The only important thing is that the whole observed band
> stays within the analog bandwidth of your USRP (B2x0) or the
> daughterboard used (modular USRPs).
>
> Best regards,
> Marcus
>
> [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> On 06/04/2015 11:26 PM, John Petrich wrote:
>
> Marcus,
>
>  
>
> I cannot get the DC component to shift using this command in
> the USRP _Source_ block properties: 
> uhd.tune_request(3.545e6,10e3)  What am I missing?
>
>  
>
> Thank you in advance,
>
> John Petrich
>
>  
>
> *Re: Move USRP LO with USRP sink block?*
> 
>
> D17685d174fee4ca258c75cce7bc2202?d=identicon&s=25Marcus Müller
> (Guest)
>
> on 2015-02-10 20:10
>
> (Received via mailing list)
>
> Well, you nearly already are doing this!
>
> just use "uhd.tune_request(...,...)" where you'd set the TX frequency
>
> normally in the USRP sink's properties dialog.
>
>  
>
>  
>
>  
>

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