[Discuss-gnuradio] No attribute 'message_sink'

[Ting Wu]

Hi,

 

I'm using USRP N210 with LFRX.

I installed uhd and gnuradio with build-gnuradio script without any problem.

However, when I run an application, it has such error message:

 

self.sink = gr.message_sink(gr.sizeof_short*2, self.queue, False)

AttributeError: 'module' object has no attribute 'message_sink'

 

Several months ago, I installed on several computers with the build-gnuradio
script and run the same application, and there was no such problem.

Has gnuradio changed something recently?

 

Best regards,

 

Wu

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

Re: [Discuss-gnuradio] No attribute 'message_sink'

[Marcus Müller]

Hi Wu,
yes, something has changed: GNU Radio made a version progression from
3.6 to 3.7. Part of this progress was that the standards blocks are now
part of the "blocks" module, and no longer of the "gr" module. 
Please refer to the official GR wiki to learn about conversion from 3.6
to 3.7.

Greetings,
Marcus

On Fri, 2013-11-01 at 17:00 +0900, Ting Wu wrote:
> Hi,
> 
>  
> 
> I’m using USRP N210 with LFRX.
> 
> I installed uhd and gnuradio with build-gnuradio script without any
> problem.
> 
> However, when I run an application, it has such error message:
> 
>  
> 
> self.sink = gr.message_sink(gr.sizeof_short*2, self.queue, False)
> 
> AttributeError: 'module' object has no attribute 'message_sink'
> 
>  
> 
> Several months ago, I installed on several computers with the
> build-gnuradio script and run the same application, and there was no
> such problem.
> 
> Has gnuradio changed something recently?
> 
>  
> 
> Best regards,
> 
>  
> 
> Wu
> 
> 
> ___
> 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] band pass filter

[Marcus Müller]

Nevertheless, using a "throttle" block with 400e6 samples/second seems
to be inadequate. The throttle rate (which has nothing to do with the
sampling rate) should be reduced to something the average computer can
deal with when visualizing. Maheshkumar, use something like 100k for the
beginning.

On Thu, 2013-10-31 at 14:38 +, Marcus Leech wrote:
> Oh, nevermind.  I missed the "simulation" part.
> 
> 
>  
> on Oct 31, 2013, Marcus Leech  wrote:
> What SDR is being used that samples at 400e6 SPS, and what
> *computer* is being used that can keep up?  Inquiring minds
> want to know...
> 
> 
>  
> on Oct 31, 2013, Mike Jameson  wrote:
> 
> Hi Maheshkumar,
> 
> 
> For your example using a sample rate of 400e6, the low
> and high cutoff frequencies need to be between -200e6
> and 200e6, not 800+ as you currently have them
> configured.
> Try 10e6 for low cutoff and 20e6 for high cutoff.
>  
> Regards,
> 
> 
> Mike
> 
> --
> Mike Jameson M0MIK BSc MIET
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: http://www.ettus.com
> 
> 
> On Thu, Oct 31, 2013 at 10:54 AM, Maheshkumar Pandit
>  wrote:
> hello every one .. 
>  
>  
>i implement the following
> spectrum  generation stimulation but band pass
> parameter show error . 
> 
>   File
> "/home/mahesh/Documents/3110/1/top_block.py",
> line 128, in __init__
> 1, samp_rate, 83000, 84000, 1,
> firdes.WIN_HAMMING, 6.76))
>   File
> 
> "/usr/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_general.py", line 
> 9544, in band_pass
> return
> _gnuradio_core_general.firdes_band_pass(*args,
> **kwargs)
> RuntimeError: gr_firdes check failed: 0 < fa
> <= sampling_freq / 2
> 
> 
> guude me if any buddy face sane problem
> -- 
> Thanks and regard:
>  
> MR.Maheshkumar Pandit
> 
> call @ 9662784649
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> __
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>  
> 
> 
> __
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>  
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



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

Re: [Discuss-gnuradio] How to make an FFT block in c++

[Alexandru Csete]

On Fri, Nov 1, 2013 at 6:16 AM, Tommy Tracy II  wrote:
> Thanks a lot. I do have a question about the 6.67 that you pass to the
> gr::firdes::window(gr::filter::firdes::WIN_BLACKMAN_HARRIS, SIZE, 6.67);
>
> What is the importance of this value? Is this the default BETA? I found that
> when creating a BLACKMANHARRIS window in python and c++, I got two different
> results.

If I recall correctly that parameter is only used for the Kaiser
window and not for the others.

Alex

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

Re: [Discuss-gnuradio] How to get multipe rx_time tags while receiving continuously

[Tom Rondeau]

On Thu, Oct 31, 2013 at 3:46 AM, Harry Zhang  wrote:
> Hi,
> As far as I know rx_time tag is associated with the first sample of a
> receive stream. If I wanna get multiple rx_time tags while receiving
> continuous data, should I stop and issue a new stream again and again
> for getting more rx_time tags.
> Thank you.

Harry,

We want to minimize tags through the flowgraph since it adds overhead.
The UHD driver only sends an rx_time tag whenever one is necessary.
That means that if there is a chance that the host has become
unsynchronized, it sends an updated tag. So there's one at the
beginning of the stream to set the initial time. Then, if a dropped
packet or overflow are detected, it sends a new rx_time tag.

Between time tags, you can count samples and you know the sample rate,
so you know the time of every sample based on that initial rx_time tag
(to within the tolerance of the sample clock on the USRP).

Tom

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

[Discuss-gnuradio] cross compiling make error within OpenEmbedded SDK

[Taylor Centers]

I'm trying to cross compile gnuradio for arm within an OpenEmbedded SDK
using
bitbake 1.18
meta-openembedded Dylan
openembedded-core Dylan
&
meta-ettus e100-updates

After generating and setting up the SDK, I have downloaded the gnuradio
source and am trying to build it from there.

When I run make I am given the error:

make[2]: *** No rule to make target `../gr-atsc/src/lib/atsci_
viterbi_gen', needed by `gr-atsc/src/lib/atsci_viterbi_mux.cc'.  Stop.
make[1]: *** [gr-atsc/src/lib/CMakeFiles/gnuradio-atsc.dir/all] Error 2
make: *** [all] Error 2

It wants to build atsci_viterbi_gen, a dependency for atsci_viterbi_mux.cc
but it can't find the rules for it.

To try and debug this I followed the same steps to build gnuradio within
the sdk and in my home directory and compared the differences.

Initially after downloading a fresh version of the gnuradio source in each
directory I ran a grep for the string "atsci_viterbi_gen" and receive the
same output, as expected.

gr-atsc/lib/CMakeLists.txt:add_executable(atsci_viterbi_gen
atsci_viterbi_gen.cc)
gr-atsc/lib/CMakeLists.txt:export(TARGETS atsci_viterbi_gen APPEND FILE
${EXPORT_FILE})
gr-atsc/lib/CMakeLists.txt:DEPENDS atsci_viterbi_gen
gr-atsc/lib/CMakeLists.txt:COMMAND atsci_viterbi_gen -o
${atsci_viterbi_mux_cc}

However, after running cmake on both gnuradio's and then grepping for the
same string I notice a huge difference.

The output from the grep in my home directory is very verbose with tons of
additional files created that reference atsci_viterbi_gen as well as its
own directory
build/gr-atsc/lib/CMakeFiles/atsci_viterbi_gen.dir/

Contrarily only two additional references were made to "atsci_viterbi_gen"
after running cmake within the sdk, both occur when it was referred to as a
dependency for atsci_viterbi_mux

build/gr-atsc/lib/CMakeFiles/gnuradio-atsc.dir/build.make:gr-atsc/lib/atsci_viterbi_mux.cc:
../gr-atsc/lib/atsci_viterbi_gen
build/gr-atsc/lib/CMakeFiles/gnuradio-atsc.dir/build.make:cd
/usr/local/e100.3/gnuradio/build/gr-atsc/lib && atsci_viterbi_gen -o
/usr/local/e100.3/gnuradio/build/gr-atsc/lib/atsci_viterbi_mux.cc

gnuradio make's flawlessly within my home directory.

Why doesn't cmake generate the same files within the SDK that it does
natively?
How can I get it to?
Am I looking in the right place to get to the bottom of this error?

Any tips or additional direction would help.  Thanks a ton,

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

Re: [Discuss-gnuradio] cross compiling make error within OpenEmbedded SDK

[Tom Rondeau]

On Fri, Nov 1, 2013 at 11:06 AM, Taylor Centers
 wrote:
> I'm trying to cross compile gnuradio for arm within an OpenEmbedded SDK
> using
> bitbake 1.18
> meta-openembedded Dylan
> openembedded-core Dylan
> &
> meta-ettus e100-updates
>
> After generating and setting up the SDK, I have downloaded the gnuradio
> source and am trying to build it from there.
>
> When I run make I am given the error:
>
> make[2]: *** No rule to make target `../gr-atsc/src/lib/atsci_
> viterbi_gen', needed by `gr-atsc/src/lib/atsci_viterbi_mux.cc'.  Stop.
> make[1]: *** [gr-atsc/src/lib/CMakeFiles/gnuradio-atsc.dir/all] Error 2
> make: *** [all] Error 2
>
> It wants to build atsci_viterbi_gen, a dependency for atsci_viterbi_mux.cc
> but it can't find the rules for it.
>
> To try and debug this I followed the same steps to build gnuradio within the
> sdk and in my home directory and compared the differences.
>
> Initially after downloading a fresh version of the gnuradio source in each
> directory I ran a grep for the string "atsci_viterbi_gen" and receive the
> same output, as expected.
>
> gr-atsc/lib/CMakeLists.txt:add_executable(atsci_viterbi_gen
> atsci_viterbi_gen.cc)
> gr-atsc/lib/CMakeLists.txt:export(TARGETS atsci_viterbi_gen APPEND FILE
> ${EXPORT_FILE})
> gr-atsc/lib/CMakeLists.txt:DEPENDS atsci_viterbi_gen
> gr-atsc/lib/CMakeLists.txt:COMMAND atsci_viterbi_gen -o
> ${atsci_viterbi_mux_cc}
>
> However, after running cmake on both gnuradio's and then grepping for the
> same string I notice a huge difference.
>
> The output from the grep in my home directory is very verbose with tons of
> additional files created that reference atsci_viterbi_gen as well as its own
> directory
> build/gr-atsc/lib/CMakeFiles/atsci_viterbi_gen.dir/
>
> Contrarily only two additional references were made to "atsci_viterbi_gen"
> after running cmake within the sdk, both occur when it was referred to as a
> dependency for atsci_viterbi_mux
>
> build/gr-atsc/lib/CMakeFiles/gnuradio-atsc.dir/build.make:gr-atsc/lib/atsci_viterbi_mux.cc:
> ../gr-atsc/lib/atsci_viterbi_gen
> build/gr-atsc/lib/CMakeFiles/gnuradio-atsc.dir/build.make:cd
> /usr/local/e100.3/gnuradio/build/gr-atsc/lib && atsci_viterbi_gen -o
> /usr/local/e100.3/gnuradio/build/gr-atsc/lib/atsci_viterbi_mux.cc
>
> gnuradio make's flawlessly within my home directory.
>
> Why doesn't cmake generate the same files within the SDK that it does
> natively?
> How can I get it to?
> Am I looking in the right place to get to the bottom of this error?
>
> Any tips or additional direction would help.  Thanks a ton,
>
> Taylor

I'm sure Philip or some of the other OE people on the list can help
you more than I can. But unless you are trying to do ATSC stuff, I
would recommend just disabling it for now. There's work going on to
update the ATSC code, and it's unlikely that you'll be able to do too
much with what's in gr-atsc right now on an e100 (unless someone can
verify they've got it to work there?). So you can pass
-DENABLE_GR_ATSC=False to the cmake command to remove it from the
build.

Tom

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

Re: [Discuss-gnuradio] Sampling with multiple USRP N210s with one host computer

[Per Zetterberg]

I have a PC with two PCIe express cards each of which has four Ethernet 
connections. I connect 6 USRP N210 to them. For shorter transmissions, like 
8 samples, I can do 25Msamp/sec on all simultaneously. But I have issues 
with latencies. I am using UHD driver version 3.3.2 still. I spent two weeks 
trying to upgrade a year ago - but it became insanely slow. I can't say for 
sure that I didn't do a mistake. I have a feeling that it has something to with 
long turn around times in my system (going from TX to RX ...).
BR/
Per


From: discuss-gnuradio-bounces+perz=kth...@gnu.org 
[discuss-gnuradio-bounces+perz=kth...@gnu.org] on behalf of rmsrms1987 
[rmsrms1...@gmail.com]
Sent: Thursday, October 31, 2013 9:54 PM
To: Discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Sampling with multiple USRP N210s with one host 
computer

Hi Everyone,

I recently discovered that Ettus offer a way of synchronizing up the eight
USRPs with the following clock distribution system:

https://www.ettus.com/product/details/OctoClock-G


Out of curiosity, how would one be able to connect and sample with eight
separate USRPs with one host computer.  Would you need eight separate
ethernet ports?  That seems like more than what a typical motherboard would
be able to handle.

Or can the USRPs all be connected to a server, which can be individually
accessed through the host computer
Understanding how to do this will be extremely beneficial in order to gather
some ideas for a project.

Thank you very much in advance,
Rob



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Sampling-with-multiple-USRP-N210s-with-one-host-computer-tp44502.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

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

Re: [Discuss-gnuradio] DC Nonexistent Peak at Transmitter

[Mike Jameson]

Hi Sema,

You are most likely seeing the local oscillator at the centre due to the
WBX being a direct conversion daughterboard:

http://en.wikipedia.org/wiki/Direct-conversion_receiver

To remove this, you can put the following in the center frequency box of
the UHD source/sink block in GRC:

uhd.tune_request(uhd_center_freq,
rf_freq=(uhd_center_freq+uhd_lo_offset),rf_freq_policy=uhd.tune_request.POLICY_MANUAL)

The 'uhd_center_freq'  and 'uhd_lo_offset' need to be specified. Set
'uhd_lo_offset' to be something like ((samp_rate/2)*1.1).

Regards,

Mike

--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com 


On Fri, Nov 1, 2013 at 3:21 PM, s k  wrote:

> Hi all,
>
> I am trying to create a complex cosine signal in 100kHz and transmit it
> with USRP in 110MHz using WBX daughterboard. I have observed this signal in
> an oscilloscope and a spectrum analyzer. It can be seen that there is a
> nonexistent peak at transmit frequency of USRP. I also added the related
> photos to be clear.
>
> Any help would be kindly appreciated.
>
> Sema
>
> ___
> 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] gnuradio-3.7.2, qwt6 and qtgui on gentoo

[Volker Schroer]

Hi

On an gentoo system with qwt-6.0.2 the qtgui builds nut fails to run.
The test reports
libgnuradio-qtgui-3.7.2git.so.0.0.0: undefined symbol: 
_ZNK7QwtPlot9drawItemsEP8QPainterRK6QRectFPK11QwtScaleMapq


This is due to mixture of qwt5 ( used for PyQt )and qwt libs.

FindQwt.cmake sets:

//Path to a file.
QWT_INCLUDE_DIRS:PATH=/usr/include/qwt6

//Path to a library.
QWT_LIBRARIES:FILEPATH=/usr/lib64/libqwt.so

But on gentoo

/usr/lib64/libqwt6.so -> libqwt6.so.6.0.2
/usr/lib64/libqwt6.so.6 -> libqwt6.so.6.0.2
/usr/lib64/libqwt6.so.6.0 -> libqwt6.so.6.0.2
/usr/lib64/libqwt6.so.6.0.2
/usr/lib64/libqwt.so -> libqwt.so.5.2.3
/usr/lib64/libqwt.so.5 -> libqwt.so.5.2.3
/usr/lib64/libqwt.so.5.2 -> libqwt.so.5.2.3
/usr/lib64/libqwt.so.5.2.3

So the header files are taken from qwt6 but the used library is qwt5 .

I suggest to change

find_library (QWT_LIBRARIES
  NAMES qwt qwt6 qwt-qt4

in FindQwt.cmake

to

find_library (QWT_LIBRARIES
  NAMES qwt6 qwt qwt-qt4

Then qtgui is build correctly and runs without problems.

But I don't know if there are side effects on other distros.

--Volker


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

Re: [Discuss-gnuradio] cross compiling make error within OpenEmbedded SDK

[Philip Balister]

I replied, if anyone is interested ping me and I'll resend to the list.

On 11/01/2013 08:11 AM, Tom Rondeau wrote:
> On Fri, Nov 1, 2013 at 11:06 AM, Taylor Centers
>  wrote:
>> I'm trying to cross compile gnuradio for arm within an OpenEmbedded SDK
>> using
>> bitbake 1.18
>> meta-openembedded Dylan
>> openembedded-core Dylan
>> &
>> meta-ettus e100-updates
>>
>> After generating and setting up the SDK, I have downloaded the gnuradio
>> source and am trying to build it from there.
>>
>> When I run make I am given the error:
>>
>> make[2]: *** No rule to make target `../gr-atsc/src/lib/atsci_
>> viterbi_gen', needed by `gr-atsc/src/lib/atsci_viterbi_mux.cc'.  Stop.
>> make[1]: *** [gr-atsc/src/lib/CMakeFiles/gnuradio-atsc.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> It wants to build atsci_viterbi_gen, a dependency for atsci_viterbi_mux.cc
>> but it can't find the rules for it.
>>
>> To try and debug this I followed the same steps to build gnuradio within the
>> sdk and in my home directory and compared the differences.
>>
>> Initially after downloading a fresh version of the gnuradio source in each
>> directory I ran a grep for the string "atsci_viterbi_gen" and receive the
>> same output, as expected.
>>
>> gr-atsc/lib/CMakeLists.txt:add_executable(atsci_viterbi_gen
>> atsci_viterbi_gen.cc)
>> gr-atsc/lib/CMakeLists.txt:export(TARGETS atsci_viterbi_gen APPEND FILE
>> ${EXPORT_FILE})
>> gr-atsc/lib/CMakeLists.txt:DEPENDS atsci_viterbi_gen
>> gr-atsc/lib/CMakeLists.txt:COMMAND atsci_viterbi_gen -o
>> ${atsci_viterbi_mux_cc}
>>
>> However, after running cmake on both gnuradio's and then grepping for the
>> same string I notice a huge difference.
>>
>> The output from the grep in my home directory is very verbose with tons of
>> additional files created that reference atsci_viterbi_gen as well as its own
>> directory
>> build/gr-atsc/lib/CMakeFiles/atsci_viterbi_gen.dir/
>>
>> Contrarily only two additional references were made to "atsci_viterbi_gen"
>> after running cmake within the sdk, both occur when it was referred to as a
>> dependency for atsci_viterbi_mux
>>
>> build/gr-atsc/lib/CMakeFiles/gnuradio-atsc.dir/build.make:gr-atsc/lib/atsci_viterbi_mux.cc:
>> ../gr-atsc/lib/atsci_viterbi_gen
>> build/gr-atsc/lib/CMakeFiles/gnuradio-atsc.dir/build.make:cd
>> /usr/local/e100.3/gnuradio/build/gr-atsc/lib && atsci_viterbi_gen -o
>> /usr/local/e100.3/gnuradio/build/gr-atsc/lib/atsci_viterbi_mux.cc
>>
>> gnuradio make's flawlessly within my home directory.
>>
>> Why doesn't cmake generate the same files within the SDK that it does
>> natively?
>> How can I get it to?
>> Am I looking in the right place to get to the bottom of this error?
>>
>> Any tips or additional direction would help.  Thanks a ton,
>>
>> Taylor
> 
> I'm sure Philip or some of the other OE people on the list can help
> you more than I can. But unless you are trying to do ATSC stuff, I
> would recommend just disabling it for now. There's work going on to
> update the ATSC code, and it's unlikely that you'll be able to do too
> much with what's in gr-atsc right now on an e100 (unless someone can
> verify they've got it to work there?). So you can pass
> -DENABLE_GR_ATSC=False to the cmake command to remove it from the
> build.
> 
> 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] How to make an FFT block in c++

[Tommy Tracy II]

You’re right; the following syntax is the least ambiguous for creating 
Blackmanharris windows in c++:

const std::vector< float >  fft_window = 
gr::filter::firdes::window(gr::filter::firdes::WIN_BLACKMAN_HARRIS, 1024, NULL);

Sincerely,
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241

On Nov 1, 2013, at 6:04 AM, Alexandru Csete  wrote:

> On Fri, Nov 1, 2013 at 6:16 AM, Tommy Tracy II  wrote:
>> Thanks a lot. I do have a question about the 6.67 that you pass to the
>> gr::firdes::window(gr::filter::firdes::WIN_BLACKMAN_HARRIS, SIZE, 6.67);
>> 
>> What is the importance of this value? Is this the default BETA? I found that
>> when creating a BLACKMANHARRIS window in python and c++, I got two different
>> results.
> 
> If I recall correctly that parameter is only used for the Kaiser
> window and not for the others.
> 
> Alex



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to make an FFT block in c++

[Tom Rondeau]

On Fri, Nov 1, 2013 at 4:42 PM, Tommy Tracy II  wrote:
> You’re right; the following syntax is the least ambiguous for creating
> Blackmanharris windows in c++:
>
> const std::vector< float >  fft_window =
> gr::filter::firdes::window(gr::filter::firdes::WIN_BLACKMAN_HARRIS, 1024,
> NULL);

I'm actually going to update that to have a default argument for beta,
so you don't even need to set anything if you aren't using a Kaiser
window.

Tom



> Sincerely,
> Tommy James Tracy II
> Ph.D Student
> High Performance Low Power Lab
> University of Virginia
> Phone: 913-775-2241
>
> On Nov 1, 2013, at 6:04 AM, Alexandru Csete  wrote:
>
> On Fri, Nov 1, 2013 at 6:16 AM, Tommy Tracy II  wrote:
>
> Thanks a lot. I do have a question about the 6.67 that you pass to the
> gr::firdes::window(gr::filter::firdes::WIN_BLACKMAN_HARRIS, SIZE, 6.67);
>
> What is the importance of this value? Is this the default BETA? I found that
> when creating a BLACKMANHARRIS window in python and c++, I got two different
> results.
>
>
> If I recall correctly that parameter is only used for the Kaiser
> window and not for the others.
>
> Alex
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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

[Discuss-gnuradio] generic LP/BP filters

[Marcus D. Leech]

For the "generic" LP/BP filter blocks, would it make sense for them to 
automatically select either a conventional FIR or FFT-fast-convolution 
filter,

  depending on the number of taps and other parameters?

The user still has access to the low-level implementations, but the 
choice between conventional FIR and fast convolution based on FFT is 
something that

  *could* be done whenever the filter parameters change, yes?

Furthermore when running a standard dot-product FIR filter, do we take 
advantage of the identities shown in this paper:


http://www.ws.binghamton.edu/fowler/fowler%20personal%20page/EE521_files/IV-05%20Polyphase%20FIlters_2007.pdf

Which allows you to avoid computations in a FIR that will never be used 
in the output?   Looking at the code, it *looks* like we do, but I'm

  not certain.


--
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] How to get multipe rx_time tags while receiving continuously

[Harry Zhang]

Tom,
Thanks for your reply.
I got a weird problem when using rx_time tags. I have three nodes, 
node A sends 10 packets within 0.2 sec ,stops for 1sec sends 10 packets 
, stops..., sends,stops  . Node B and C receive it and record 
the receive time using (rx_time+ sample_count*sample_rate).  
Considerating the clock offset between B and C, the difference of B and 
C's receive time must remain stable. But every time after A stops for 
1sec, the receive time's difference varies several hundreds of 
microsecond. I'm stumped by this problem.

Could you give me some advice. Thank you in advance.

Harry

2013/11/1 22:26, Tom Rondeau wrote:

On Thu, Oct 31, 2013 at 3:46 AM, Harry Zhang  wrote:

Hi,
As far as I know rx_time tag is associated with the first sample of a
receive stream. If I wanna get multiple rx_time tags while receiving
continuous data, should I stop and issue a new stream again and again
for getting more rx_time tags.
Thank you.

Harry,

We want to minimize tags through the flowgraph since it adds overhead.
The UHD driver only sends an rx_time tag whenever one is necessary.
That means that if there is a chance that the host has become
unsynchronized, it sends an updated tag. So there's one at the
beginning of the stream to set the initial time. Then, if a dropped
packet or overflow are detected, it sends a new rx_time tag.

Between time tags, you can count samples and you know the sample rate,
so you know the time of every sample based on that initial rx_time tag
(to within the tolerance of the sample clock on the USRP).

Tom




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

[Discuss-gnuradio] Why the Qam modulation cannot work well in ofdm benchmark example?

[Yingjie Chen]

Hi guys,

Recently, I have conducted a project based on ofdm benchmark. However, when
I use the high modulation rate like qam16 and qam64, the packet error rate
increase significantly. I guess the reason is that the preamble in gunradio
is too weak to do channel estimation, thereby raising the  packet error
rate.

Furthermore, even though I test the example offline without going through
the channel, the packet error rate  still very high, which make me feel
confused. It is supposed to perform normally offline, without any decoding
error right?

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

Re: [Discuss-gnuradio] No attribute 'message_sink'

[Ting Wu]

Hi Marcus,

Thanks!
I changed the line to " self.sink = blocks.message_sink(gr.sizeof_short*2, 
self.queue, False)"
and now it works.

Wu


-Original Message-
From: Marcus Müller [mailto:mar...@hostalia.de] 
Sent: Friday, November 01, 2013 6:23 PM
To: Ting Wu
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] No attribute 'message_sink'

Hi Wu,
yes, something has changed: GNU Radio made a version progression from
3.6 to 3.7. Part of this progress was that the standards blocks are now part of 
the "blocks" module, and no longer of the "gr" module. 
Please refer to the official GR wiki to learn about conversion from 3.6 to 3.7.

Greetings,
Marcus

On Fri, 2013-11-01 at 17:00 +0900, Ting Wu wrote:
> Hi,
> 
>  
> 
> I’m using USRP N210 with LFRX.
> 
> I installed uhd and gnuradio with build-gnuradio script without any 
> problem.
> 
> However, when I run an application, it has such error message:
> 
>  
> 
> self.sink = gr.message_sink(gr.sizeof_short*2, self.queue, False)
> 
> AttributeError: 'module' object has no attribute 'message_sink'
> 
>  
> 
> Several months ago, I installed on several computers with the 
> build-gnuradio script and run the same application, and there was no 
> such problem.
> 
> Has gnuradio changed something recently?
> 
>  
> 
> Best regards,
> 
>  
> 
> Wu
> 
> 
> ___
> 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