Re: [Discuss-gnuradio] gnuradio in windows
Hello Geof, Thank you so much for the response. I need to know where should I place the dll files of qwt for the installation? On Sun, Jul 17, 2016 at 6:45 AM, Geof Nieboer <gnieb...@corpcomm.net> wrote: > The Qt GUI problem can be fixed by downloading a version of the qwt dll > from the binaries site, but Wx will work in the meantime. By the end of > the month a new version of the binaries should be posted that will fix that > issue. > > Is the gnuradio-grc.png causing a problem other than the windows icon not > appearing as expected? > > No, there is no problem with grc icon and it is appearing as expected. However, when WX GUI is appeared, the exact bellow error message is shown: *" Failed to load image from file "C:\Program Files\GNURadio-3.7\share\icons\hicolor|8x48/apps\gnuradio-grc.png"* Best, Mostafa > Geof > > On Fri, Jul 15, 2016 at 5:14 AM, Mostafa Alizadeh <m.alizade...@gmail.com> > wrote: > >> Hello all, >> >> Is there any one who tried to use GNURadio in windows? >> >> I should use it because I have some special programs in windows and I >> want to use them in conjunction with GNURadio. I installed the prebuild >> version, but there are so many problems with running a flowgraph: >> - "python.exe" stops working when running a flowgraph with Qt: >> - when using wx GUIs, it says: "can't open file : ... /gnuradio-grc.png. >> In fact the problem is with the path where there is a difference between >> windows path representations and linux one. >> >> How could I solve this problem? >> >> Best, >> Mostafa >> >> ******* >> Tehran >> IRAN >> Tel: +98 (919) 158-7730 >> Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir >> Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169> >> >> *** >> >> ___ >> 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 in windows
Hello all, Is there any one who tried to use GNURadio in windows? I should use it because I have some special programs in windows and I want to use them in conjunction with GNURadio. I installed the prebuild version, but there are so many problems with running a flowgraph: - "python.exe" stops working when running a flowgraph with Qt: - when using wx GUIs, it says: "can't open file : ... /gnuradio-grc.png. In fact the problem is with the path where there is a difference between windows path representations and linux one. How could I solve this problem? Best, Mostafa *** Tehran IRAN Tel: +98 (919) 158-7730 Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169> *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] installing gnuradio on Windows
thank you for your help, but I currently could not download the *"gnuradio_3.7.9.2_win64.msi"* file!! why? Best, Mostafa *** Tehran IRAN Tel: +98 (919) 158-7730 Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169> *** On Wed, Jul 6, 2016 at 9:52 PM, Gavin Jacobs <apriljunk...@hotmail.com> wrote: > Mostafa, > Those scripts are torturous. You can now download pre-built gnuradio for > windows here: > http://www.gcndevelopment.com/gnuradio/downloads.htm > > i am using those binaries on Windows 10 (64bit) and I can run GnuRadio > Companion and GQRX. So far I have not been able to create a new OOT module. > > If you really want to build from source, you can try the scripts, BUT - I > have tried several times and never succeeded. Your milage may vary. > > Jake > > Date: Wed, 6 Jul 2016 19:14:50 +0430 > > From: Mostafa Alizadeh <m.alizade...@gmail.com> > > To: discuss-gnuradio@gnu.org > > Subject: Re: [Discuss-gnuradio] installing gnuradio on Windows > > Message-ID: > >
Re: [Discuss-gnuradio] installing gnuradio on Windows
EDIT: After so may trials and searches, I found that the problem resides inside the file: "Step2-GetStage1Packages" where it wants to build libraries with "msbuild". I tried to run the command alone and it turned out that the command is wrong syntactically: it must use : *msbuild vstudio.sln /m /p:configuration=Debug /p:platform=x64* instead of : *msbuild vstudio.sln /m /p:"configuration=Debug;platform=x64"* After that I encountered with a new problem and I do not know when these perplexing problems want to disappear: running this: *msbuild vstudio.sln /m /p:configuration=Debug /p:platform=x64* got this: *C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(203,5): error MSB3073: The command "copy ..* *\..\..\scripts\pnglibconf.h.prebuilt ..\..\..\pnglibconf.h\r [E:\GNURadio_src\build\src-stage1-dependencies\libpng\projects\vs* *tudio-vs2015\pnglibconf\pnglibconf.vcxproj]* *C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(203,5): error MSB3073: :VCEnd" exited with* *code 1. [E:\GNURadio_src\build\src-stage1-dependencies\libpng\projects\vstudio-vs2015\pnglibconf\pnglibconf.vcxproj]* what could I do? please help me :( Thanks in advance, Mostafa *** Tehran IRAN Tel: +98 (919) 158-7730 Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169> ******* On Wed, Jul 6, 2016 at 1:55 PM, Mostafa Alizadeh <m.alizade...@gmail.com> wrote: > Hi all, > > I tried to install GNURadio with the given instructions in the link below: > > https://github.com/gnieboer/gnuradio_windows_build_scripts > > I downloaded all the dependencies, however, at the "second stage", while > building dependencies, I encountered an error like (for Zlib): > > Validation Failed, x64/ZlibDllDebug/zlibwapi.dll was not found and is > required > > and I also have similar error after building other libraries too. Where is > the problem? > > Best, > Mostafa > > > *** > Tehran > IRAN > Tel: +98 (919) 158-7730 > Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir > Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169> > > *** > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] installing gnuradio on Windows
Hi all, I tried to install GNURadio with the given instructions in the link below: https://github.com/gnieboer/gnuradio_windows_build_scripts I downloaded all the dependencies, however, at the "second stage", while building dependencies, I encountered an error like (for Zlib): Validation Failed, x64/ZlibDllDebug/zlibwapi.dll was not found and is required and I also have similar error after building other libraries too. Where is the problem? Best, Mostafa *** Tehran IRAN Tel: +98 (919) 158-7730 Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169> *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-radar make problem
As Martin said, this gr-radar is an amazing tool. I finally, changed the UHD version from 003.005.xxx to 003.009.003 and the problem is resolved. Thanks all particularly "Marcus" :) Best, Mostafa *** Tehran IRAN Tel: +98 (919) 158-7730 Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169> *** On Thu, Mar 31, 2016 at 10:42 PM, Martin Braun <mar...@gnuradio.org> wrote: > On 03/30/2016 10:46 AM, Stefan Wunsch wrote: > > - gnuradio 3.7.9.1 > > - uhd 3.9.2 > > - boost 1.60.0 > > gr-radar is a fantastic project, and I'm not going to tell OOT authors > who deliver cool stuff what to do, but I would like to encourage people > in general not to require the latest Boost version. If GNU Radio's > minimum version works, that's usually a good default choice. > > M > > > ___ > 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] gr-radar make problem
Thanks all,
I actually have Ubuntu 14.04, so there is not libboost 1.60 in its
repository. What should I do?
Best,
Mostafa
***
Tehran
IRAN
Tel: +98 (919) 158-7730
Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir
Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169>
***
On Wed, Mar 30, 2016 at 10:16 PM, Stefan Wunsch <
stefan.wun...@student.kit.edu> wrote:
> Hi,
>
> Sebastian is right, it's most likely a dependency problem. I've tested
> the source from git and it compiles fine with following dependencies:
>
> - gnuradio 3.7.9.1
> - uhd 3.9.2
> - boost 1.60.0
>
> First check boost, old versions don't have the strerror function. If
> boost is the problem, I should really fix the cmake so that it checks
> the boost version.
>
> Greetings
> Stefan
>
> On 03/30/2016 09:57 AM, Mostafa Alizadeh wrote:
> > Hi all,
> >
> > I tried to build gr-radar <https://github.com/kit-cel/gr-radar> master
> > branch but I got the error:
> >
> >
> > /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc: In
> > member function ‘void gr::radar::usrp_echotimer_cc_impl::receive()’:
> >
> /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:232:16:
> error:
> > ‘class uhd::rx_streamer’ has no member named ‘issue_stream_cmd’
> >d_rx_stream->issue_stream_cmd(stream_cmd);
> > ^
> >
> /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:84:
> error:
> > ‘struct uhd::rx_metadata_t’ has no member named ‘strerror’
> > throw std::runtime_error(str(boost::format("Receiver error %s") %
> > d_metadata_rx.strerror()));
> >
> > ^
> >
> */home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94:
> > error: ‘str’ was not declared in this scope*
> > throw std::runtime_error(str(boost::format("Receiver error %s") %
> > d_metadata_rx.strerror()));
> >
> > ^
> >
> /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94:
> note:
> > suggested alternatives:
> > In file included from /usr/include/boost/format.hpp:53:0,
> > from /usr/local/include/gnuradio/logger.h:55,
> > from /usr/local/include/gnuradio/block.h:29,
> > from
> /usr/local/include/gnuradio/tagged_stream_block.h:27,
> > from
> > /home/mostafa/RADAR/gr-radar-master/include/radar/usrp_echotimer_cc.h:25,
> > from
> > /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.h:24,
> > from
> > /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:26:
> > /usr/include/boost/format/free_funcs.hpp:22:38: note: ‘boost::str’
> > std::basic_string<Ch, Tr, Alloc> str(const basic_format<Ch, Tr,
> > Alloc>& f) {
> > ^
> > /usr/include/boost/format/free_funcs.hpp:22:38: note: *‘boost::str’*
> > make[2]: ***
> > [lib/CMakeFiles/gnuradio-radar.dir/usrp_echotimer_cc_impl.cc.o] Error 1
> > make[1]: *** [lib/CMakeFiles/gnuradio-radar.dir/all] Error 2
> > make: *** [all] Error 2
> >
> >
> > *This is due to "boost::str" which is not declared! *
> >
> > What could I do?
> >
> > Best,
> > Mostafa
> >
> >
> >
> > ***
> > Tehran
> > IRAN
> > Tel: +98 (919) 158-7730
> > Emails: m.alizade...@gmail.com <mailto:m.alizade...@gmail.com>,
> > m.alizade...@aut.ac.ir <mailto:m.alizade...@aut.ac.ir>
> > Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169
> >
> >
> > ***
> >
> >
> > ___
> > 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] gr-radar make problem
Hi all,
I tried to build gr-radar <https://github.com/kit-cel/gr-radar> master
branch but I got the error:
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc: In
member function ‘void gr::radar::usrp_echotimer_cc_impl::receive()’:
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:232:16:
error: ‘class uhd::rx_streamer’ has no member named ‘issue_stream_cmd’
d_rx_stream->issue_stream_cmd(stream_cmd);
^
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:84:
error: ‘struct uhd::rx_metadata_t’ has no member named ‘strerror’
throw std::runtime_error(str(boost::format("Receiver error %s") %
d_metadata_rx.strerror()));
^
*/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94:
error: ‘str’ was not declared in this scope*
throw std::runtime_error(str(boost::format("Receiver error %s") %
d_metadata_rx.strerror()));
^
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94:
note: suggested alternatives:
In file included from /usr/include/boost/format.hpp:53:0,
from /usr/local/include/gnuradio/logger.h:55,
from /usr/local/include/gnuradio/block.h:29,
from /usr/local/include/gnuradio/tagged_stream_block.h:27,
from
/home/mostafa/RADAR/gr-radar-master/include/radar/usrp_echotimer_cc.h:25,
from
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.h:24,
from
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:26:
/usr/include/boost/format/free_funcs.hpp:22:38: note: ‘boost::str’
std::basic_string<Ch, Tr, Alloc> str(const basic_format<Ch, Tr,
Alloc>& f) {
^
/usr/include/boost/format/free_funcs.hpp:22:38: note: *‘boost::str’*
make[2]: ***
[lib/CMakeFiles/gnuradio-radar.dir/usrp_echotimer_cc_impl.cc.o] Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-radar.dir/all] Error 2
make: *** [all] Error 2
*This is due to "boost::str" which is not declared! *
What could I do?
Best,
Mostafa
***
Tehran
IRAN
Tel: +98 (919) 158-7730
Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir
Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169>
***
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: Packet drop from Ethernet (A BIG PROBLEM)
*** Tehran IRAN Tel: +98 (919) 158-7730 Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169> *** -- Forwarded message -- From: Mostafa Alizadeh <m.alizade...@gmail.com> Date: Wed, Mar 9, 2016 at 1:52 PM Subject: Re: [Discuss-gnuradio] Packet drop from Ethernet (A BIG PROBLEM) To: Nikos Balkanas <nbalka...@gmail.com> I said changing the resolution of the samples does not any effect on the network transferring rate! In the figure below, I tested two cases by USRP source, the first one with "complex int 16" (the left bit stream shown in the figure below) and the second one with "complex float 32" (the second bit stream show in the figure below). The bit rate is the same. I do not know about ADC/DAC, however I see the bit rate coming the Ethernet. [image: Inline image 1] My operating system is Ubuntu 14.04 and I have a PCI-based Ethernet! :( *** Tehran IRAN Tel: +98 (919) 158-7730 Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir Homepage: Linkedin <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169> *** On Wed, Mar 9, 2016 at 1:26 PM, Nikos Balkanas <nbalka...@gmail.com> wrote: > Hi Mostafa, > > This is a usrp issue, and depends exactly on the hardware. Before you look > into the host for optimizing its networking parameters, you should make > sure that your hardware can handle it. > For example reducing the sample resolution in your N200. ADCs in USRPs use > quad sampling, which means they generate I/Q (imaginary/real) data for each > sample. At full resolution, this is 16 bits each or 32 bits/Sample. At > reduced sample resolution, which takes place in the FPGA, you get 8 + 8 = > 16 bits/sample, therefore half the bandwidth of full resolution going > through the wire. > > Now, you should be able to handle 20 MS/s at full resolution, 20x32 = 640 > Mbps. But a lot of NICS have problems, especially the PCI ones. What is > your NIC? What is your OS? > > BR, > Nikos > > > On Wed, Mar 9, 2016 at 11:33 AM, Mostafa Alizadeh <m.alizade...@gmail.com> > wrote: > >> Hi Nikos, >> >> This is exaclty the issue related to the GNURadio application rather than >> USRP because the problem is from the host. That is not possible to transfer >> 30 Msps, however, what about 20 Msps? I expect to be able to transfer 20 >> Msps at least. >> >> Another point that you mentioned is "changing the resolution of the >> samples". In contrast, as far as I know, if you change the sample >> resolution it does not reduce the bit rate of the Ethernet interface, >> however, it changes the interpretation of the samples! It is easy to run a >> program for different sample resolution and observe that there is no change >> in the bit rate of the Eth. Interface. >> >> How to change the ethernet parameters or anything else ( if any idea ) to >> reduce packet dropping?? >> >> Thanks in advance, >> Mostafa >> On Mar 9, 2016 11:25 AM, "Nikos Balkanas" <nbalka...@gmail.com> wrote: >> >>> Hi, >>> >>> This issue is better addressed to usrp-us...@ettus.com. Briefly I can >>> tell you that you can never reach 30M samples/sec over a 1 GbE interface. >>> 30 x 32/bits/sample = 960. Need a bit for metadata, packet overheads, >>> etc. you will drop packages. Especially if your NIC is PCI based :( >>> Try reducing your sample resolution to 8 bits. You may have better luck. >>> >>> HTH, >>> Nikos >>> >>> On Wed, Mar 9, 2016 at 9:42 AM, Mostafa Alizadeh <m.alizade...@gmail.com >>> > wrote: >>> >>>> Hello all, >>>> I stuck on an incridible challenge in sending/receiving a large >>>> bandwidth. I have an USRP N210 and an WBX daughterboard, while I must be >>>> able to capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with >>>> the sample rate of 25Msps or even 20Msps I have some dropped packets. Based >>>> on my knowledge, this is due to CPU which does not have enough time to >>>> capture from Ethernet, however, I have the powerful one, 12 core CPU. When >>>> I have a large GNURadio program to run, there are some dropped packets. I >>>> searched everywhere but I did not find a complete description of the >>>> solution. What is (are ) the solution(s )? Please help me with any >>>> information! :( >>>> >>>> Best regards >>>> Mostafa >>>> >>>> ___ >>>> 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] Packet drop from Ethernet (A BIG PROBLEM)
Hi Nikos, This is exaclty the issue related to the GNURadio application rather than USRP because the problem is from the host. That is not possible to transfer 30 Msps, however, what about 20 Msps? I expect to be able to transfer 20 Msps at least. Another point that you mentioned is "changing the resolution of the samples". In contrast, as far as I know, if you change the sample resolution it does not reduce the bit rate of the Ethernet interface, however, it changes the interpretation of the samples! It is easy to run a program for different sample resolution and observe that there is no change in the bit rate of the Eth. Interface. How to change the ethernet parameters or anything else ( if any idea ) to reduce packet dropping?? Thanks in advance, Mostafa On Mar 9, 2016 11:25 AM, "Nikos Balkanas" <nbalka...@gmail.com> wrote: > Hi, > > This issue is better addressed to usrp-us...@ettus.com. Briefly I can > tell you that you can never reach 30M samples/sec over a 1 GbE interface. > 30 x 32/bits/sample = 960. Need a bit for metadata, packet overheads, etc. > you will drop packages. Especially if your NIC is PCI based :( > Try reducing your sample resolution to 8 bits. You may have better luck. > > HTH, > Nikos > > On Wed, Mar 9, 2016 at 9:42 AM, Mostafa Alizadeh <m.alizade...@gmail.com> > wrote: > >> Hello all, >> I stuck on an incridible challenge in sending/receiving a large >> bandwidth. I have an USRP N210 and an WBX daughterboard, while I must be >> able to capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with >> the sample rate of 25Msps or even 20Msps I have some dropped packets. Based >> on my knowledge, this is due to CPU which does not have enough time to >> capture from Ethernet, however, I have the powerful one, 12 core CPU. When >> I have a large GNURadio program to run, there are some dropped packets. I >> searched everywhere but I did not find a complete description of the >> solution. What is (are ) the solution(s )? Please help me with any >> information! :( >> >> Best regards >> Mostafa >> >> ___ >> 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] Packet drop from Ethernet (A BIG PROBLEM)
Hello all, I stuck on an incridible challenge in sending/receiving a large bandwidth. I have an USRP N210 and an WBX daughterboard, while I must be able to capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with the sample rate of 25Msps or even 20Msps I have some dropped packets. Based on my knowledge, this is due to CPU which does not have enough time to capture from Ethernet, however, I have the powerful one, 12 core CPU. When I have a large GNURadio program to run, there are some dropped packets. I searched everywhere but I did not find a complete description of the solution. What is (are ) the solution(s )? Please help me with any information! :( Best regards Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio on android
Hi I'm looking for GNURadio on android applications. I mean what kind stuffs already can I do with GNURadio on android? I have not tried the process of making GNURadio on a mobile device since I don't know what's its application. To be specific, is it possible to, for instance, use mobile (or tablet) hardware to capture or send signals with GNURadio on it (instead of using an external USRP)? Thanks in advance for any clarification, Mostafa -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Message passing(connect) in C++
excuse me, I'm seeing the new API 3.7.7 of GNURadio which is changed. The connect is a member of gr::flowgraph which connects both blocks' ports and message ports: http://gnuradio.org/doc/doxygen/classgr_1_1flowgraph.html#af8678658129a819673a59555d030aaac Best, On Thu, Apr 30, 2015 at 4:15 PM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hi Marco, The top_block class has a member named: connect. You can use it in the main() to connect different blocks. However, if you want to dis/connect blocks within C++ blocks, you must pass top_block pointer to the class in some fashion. Once I did and I got errors because I didn't have accessed to the connect from within the block. I prefer to change your topology to refuse the need you've mentioned. Otherwise describe your problem with more details. Best, Mostafa On Thu, Apr 30, 2015 at 3:43 PM, marco Ribero spam.marco.s...@gmail.com wrote: Hi all, I have another question. How can I connect the input and output port of different blocks,from inside a C++ block? In the documentation I've only seen the msg_connect() for python Thanks, marco ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Message passing(connect) in C++
Hi Marco, The top_block class has a member named: connect. You can use it in the main() to connect different blocks. However, if you want to dis/connect blocks within C++ blocks, you must pass top_block pointer to the class in some fashion. Once I did and I got errors because I didn't have accessed to the connect from within the block. I prefer to change your topology to refuse the need you've mentioned. Otherwise describe your problem with more details. Best, Mostafa On Thu, Apr 30, 2015 at 3:43 PM, marco Ribero spam.marco.s...@gmail.com wrote: Hi all, I have another question. How can I connect the input and output port of different blocks,from inside a C++ block? In the documentation I've only seen the msg_connect() for python Thanks, marco ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multipath Fading
I think this block is just a single tap channel. If you want to have multipath channel use channel_model2 instead: http://gnuradio.org/doc/doxygen/classgr_1_1channels_1_1channel__model2.html Best, Mostafa On Sat, Apr 25, 2015 at 8:44 PM, Ritvik Pandey pandey.rit...@gmail.com wrote: Okay ill work on this and get back to you if i face any problems...for now one last thing according to the theory fading is a result of multipath so does this block implements multipath and then shows the faded result or it just filters the fading output of an input signal. On Sat, Apr 25, 2015 at 9:41 PM, Mostafa Alizadeh m.alizade...@gmail.com wrote: The frequency measurement doesn't give any insight rather to see just time variation of the power of the signal (i think you're using a single tone source ). I prefer to plot the singal in time domain to see fading effects. The fading block has different parameters as said: http://gnuradio.org/doc/doxygen/classgr_1_1channels_1_1fading__model.html Set like this: N = 8 FTds = .01 LOS = false K = 4 Seed = 1 On Apr 25, 2015 8:27 PM, Ritvik Pandey pandey.rit...@gmail.com wrote: See i am using a signal source and fast noise source as inputs...adding these it passes through the fading block and then towards the fft sink or waterfall sink. Input Parameters in signal source: Freq: 1 M Amplitude: 1 Noise Source: Amplitude: 1 Fading Block: Normalized Doppler: 10.0 Rayleigh This for testing the fading block initially in the final stage i have to take the signal from usrp. On Sat, Apr 25, 2015 at 9:23 PM, Mostafa Alizadeh m.alizade...@gmail.com wrote: What is the input of the gnuradio's block you've set?? I think you're using the gnuradio's block wrongly! Dear Mostafa, I have tried making a flowgraph using the fading blocks, but i am not able to understand the output. I have compared the input and output it seems almost the same. Can you guide to the mathematical model of the fading block in gnu radio, so that i can understand what actually is happening to the input signal? Regards On Sat, Apr 25, 2015 at 9:07 PM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hi Ritvik, If you have enough background knowledge you need classify channels as follow: 1) Rician channel: which has a line-of-sight(LOS) path between a transmitter and a receiver. 2) Rayleigh fading channel: which doesn't have any LOS. 3) Something between Rayleigh and Ricean channel: using Nakagami distribution with parameter K varying 0-inf. You need to first generate samples of these distributions. On Sat, Apr 25, 2015 at 4:06 PM, Ritvik Pandey pandey.rit...@gmail.com wrote: Regarding my last post i want to bring it to your notice that i have to implement a multipath fading channel emulator so can you tell me how can i do that? On Sat, Apr 25, 2015 at 5:03 PM, Ritvik Pandey pandey.rit...@gmail.com wrote: Dear Sir/Mam, Hello, i am a student working on the development of a channel emulator, Can you tell me how can you make one in GNU Radio? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to put things out of a block
Hi all, In GNURadio we had ControlPort capability which is now disabled based on some (unknown to me) reasons. ControlPort gave us a sort of control over flowgraph such as setting or getting different parameters from different blocks. So I have seriously a problem with accessing a parameter within a block from main during runtime. Specially I'm speaking in C++ jargon so I expect there is a kind of mechanism to put things out of a block (to main) just like ControlPort. Anyway, if someone knows how it's possible without using ControlPort, he/she will solve an old problem for me! Best regards, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Phase locked loop
Hi Yee, Oh I did forget to put the link of the book, sorry!!! Here is the book: http://www.amazon.com/Digital-Communications-A-Discrete-Time-Approach/dp/0130304972 If you want to implement a PLL by yourself, I prefer to see an example of QPSK Tx/Rx in Matlab: http://www.mathworks.com/help/comm/examples/qpsk-transmitter-and-receiver.html However, it's convenient to use available blocks in GNURadio. Best, Mostafa On Wed, Mar 18, 2015 at 4:11 AM, yee_yy1992 yee_yy1...@hotmail.co.uk wrote: Dear Mostafa, Thank you very much on your reply. May I know where can I find the link for chapter 8 and 7 of [2] for the description and implementation of PLL? Appreciate your kind help. Best regards, Wai Yee Original message From: Mostafa Alizadeh Date:18/03/2015 01:07 (GMT+08:00) To: yee_yy1992 Subject: Re: [Discuss-gnuradio] Phase locked loop Hi Yee, If you want to have a loop within GNURadio, you must have a delay within the loop to force zero initial state in the loop (here PLL loop). So in the costas loop of [1], there is a delay between phase difference calculation and the loop (which is )called advance_loop). If you're going to write your own OOT, take look at chapter 8 and 7 of [2]. It has a complete description of PLL and its implementation. [1] https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/costas_loop_cc_impl.cc On Tue, Mar 17, 2015 at 4:35 AM, yee_yy1992 yee_yy1...@hotmail.co.uk wrote: Hi, Currently I am doing my Final Year Project to develop a phase measurement using Phase Locked Loop theory. I am using *USRP N210* for the hardware and I have installed *Gnuradio Companion* in *Ubuntu 12.04 LTS* (running in VMplayer). I have studied online that I can't use companion to add and drop the current available blocks to construct a phase locked loop. I managed to locate gr_pll_carriertracking_cc.cc and gr_pll_carriertracking_cc.h file from gnuradio source archive. I also know that I can use gr_modtool to construct my own OOT module. But I am having some difficulties in using gr_modtool. There are many functions is the gr_pll_carriertracking_cc.cc. My question are (a)What should I include for the valid argument list during the gr_modtool add process? reference link : http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_C++#432-Specific-block-categories (4.2.3 Step 2) (b) Am I putting the whole code (gr_pll_carriertracking_cc.cc) and generate it as *ONE* OOT module with few functions inside or should I separate the functions to become more OOT module and connect them using wire in companion? (c)How can I include all the header file into the make process? There are few header files being used in the code such as gr_io_signature.h , gr_sincos.h I would really appreciate your help in guiding me. Thank you very much. Best regards, Wai Yee. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] using virtual member functions
Hello all, I'm about to use member functions of the abstract base class of qtgui classes to adjust visualization parameters such as set_title, set_line_label etc. There is an explanation of virtual based classes in [1]. So it's possible to use pure virtual functions by the derived classes. When we're in GNURadio, there is an abstract class and an implementation class which is derived from the abstract class. So I expect to be able of using the pure virtual functions declared in abstract class by having a pointer of the implementation class. However the members aren't accessible. What can I do to use them? Best, Mostafa [1] http://www.cplusplus.com/doc/tutorial/polymorphism/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] eye diagram error
Hi Marcus, I'm using GNURadio 3.7.5.1. Under [Graphical Sinks], I have Baudline Sink , Fast AutoCorrelation Sink and also Eye diagram. It doesn't work! I didn't get your hint of creating an eye diagram :( Best, Mostafa On Tue, Feb 17, 2015 at 9:39 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Mostafa, which GNU Radio version are you using? GNU Radio itself (to my knowledge) doesn't come with a dedicated eye diagram, and it's possible that you're trying to use an out-of-tree module that was meant for another version of GNU Radio. You can try to emulate an eye diagram by using the Scope Sink, and triggering on a signal that has an edge on every symbol center. Best regards, Marcus On 02/17/2015 06:30 PM, Mostafa Alizadeh wrote: Hello, When I used eye diagram block (which seems to be a member of WxGUI class), the following error appeared: File /usr/local/lib/python2.7/dist-packages/baz/eye.py, line 98, in __init__ self.st = gr.message_sink(gr.sizeof_float, msgq, dont_block=1) AttributeError: 'module' object has no attribute 'message_sink' what is the main problem? best, Mostafa ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] eye diagram error
Hello, When I used eye diagram block (which seems to be a member of WxGUI class), the following error appeared: File /usr/local/lib/python2.7/dist-packages/baz/eye.py, line 98, in __init__ self.st = gr.message_sink(gr.sizeof_float, msgq, dont_block=1) AttributeError: 'module' object has no attribute 'message_sink' what is the main problem? best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distorted QPSK Constellation
Hi, For reading your data from file, you need to have a binary data file. Libre office file has a header and after that your text , in which 1 or 0' is a char not a bit! GNURadio bit generation sources assume 0 is a byte of bits and 1 is a byte of bits 1000. So you need to store your data in this binary format into a file. Great, Mostafa On Thu, Jan 15, 2015 at 10:11 PM, Salman Dinani salmandin...@gmail.com wrote: Hi to all, Thanks very much to all of you for your valuable suggestions.In accordance with your suggestions, I experimented with my designed DQPSK system and got few problems which I am listing down.All the referenced figures are attached. - I reduced the symbol per sample to 4 (previously it was 8) and added a RRC filter before constellation plot (figure RRC_const) but constellation remains the same L - I successfully demodulated the distorted constellation output by using Cosine signal source as input (figure DQPSK_demod_S_2). As someone previously suggested reducing the samples per symbol, I set it to 2 and ran the simulation. The demodulated output was out of phase w.r.t input (figure S_2_P_1).As I varied the frequency, the phase difference also varied as shown in figures S_2_P_2 and S_2_P_3. When I set this parameter to 4 (figure DQPSK_demod_S_4). The output got corrected (In-Phase) for all frequencies (figure Plot_DQPSK_S_4). Why the signal is out of phase and phase shift is varying with frequency??Why this problem got corrected when Samples per symbol changed to 4? - In order to send my desired bit stream, I made a file in Libre office with bits and saved it with txt extension. (i.e. data.txt). Before applying to the system, I tried to check the output of file source on scope. But when I ran the program (figure File_source), the output was zero. After several trials, I put the bit streams in inverted commas (figure file_dat ) some data appeared at the output (figure output_dat). But this is not the data which I wrote in the file. Is there a special format for sending data via File Source?? I am very sorry if my questions appear to be childish but I am not able to figure them out. Eagerly waiting for your expert opinions. Regards Salman Dinani ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC
Hi Marcus, You pointed out important notes. The first one is that there is two possible solution for implementing such wideband system: 1- Bringing the whole bandwidth to the baseband. 2- Using timed command for tuning to the desired center frequency. The second point is that the instantaneous bandwidth of the system, or better to say, the bandwidth of the modulated signal is a few portion of the whole bandwidth, so the first scheme isn't appropriate in the sense of wideband digitalization. However, there is another point needed to be noticed and that's the LO (local oscillator) capability of the daughterboard. I mean, does have the X-series enough ppm (lower than 3 ppm)? The LO also shall have suitable switching time too. Best, Mostafa On Tue, Jan 13, 2015 at 5:46 PM, Marcus Müller marcus.muel...@ettus.com wrote: The architecture itself can basically deal at arbitrary sample boundaries; however, as soon as you tune a physical thing like an LO, you need some time, especially since the LOs generated on USRP daughterboards discipline the LOs to the high-quality reference clock using PLLs. Depending on the frequency, the frequency delta, the daughterboard, environmental situations as well as individual component variances, the time from tune to stable oscillator changes; these times are in the order of multiple milliseconds, in most cases. You could avoid analog tuning by only doing frequency shifting in the DSP on the N210's FPGA; however, the N210-compatible daughterboards have a bandwidth of 40MHz, so this is not possible for Bluetooth (which is spread over 80MHz). With the X3x0, you can use 120MHz daughterboards, which would enable you to do purely digital tuning. I am, however, not familiar enough with the Bluetooth PHY to assess whether there are latency constraints that prohibit control by a PC -- if the hop sequence is known sufficiently before transmission starts, one could try to generate timed commands that tune the DSP on specific samples. However, that might get a bit ugly, because the on-device command queue has a limited length, so you might need to send timed commands at high rates. Alternatively, the 80 MHz bandwidth comfortably fits into the sampling rate you can get in and out of the X3x0 via 10GigEthernet -- but then, your PC will be burdened with the task of continously generating more than 80MS/s -- for 2 MHz of instantaneous bandwidth. Best regards, Marcus On 01/13/2015 02:44 PM, Mostafa Alizadeh wrote: Yeah I have had a look at Bluetooth PHY. The hop rate of Bluetooth in paging substate increases as 3200 hop/sec too. So you mean the N210 USRP can't support 1600 (or 3200) hop/sec? What do you mean by latency? Is that the latency of the USB or Ethernet? Jeff, please clarify your stance. Why the latency problem doesn't matter X-series USRP? Best, Mostafa On Tue, Jan 13, 2015 at 3:02 PM, Jeff Long willco...@gmail.com willco...@gmail.com wrote: On 01/12/2015 01:07 PM, Mostafa Alizadeh wrote: Hi Jeff, What is your reason for saying: Latency and tuning of the N210 device isn't appropriate??? I should have said that, with either USB or Ethernet, and with a non-real-time O/S, the latency to too great. Hop rate is generally 1600 hops/sec. Take a look at the Bluetooth physical layer spec for more info. Best, Mostafa On Mon, Jan 12, 2015 at 2:52 PM, Jeff Long willco...@gmail.commailto:willco...@gmail.com willco...@gmail.com wrote: On 01/10/2015 02:46 PM, vaibhav kulkarni wrote: Hi All, I am searching for an implementation of a complete Bluetooth stack on GRC 3.7 ( Including the Bluetooth Transmitter and Receiver) preferably working with USRP N210. So far I got this gr-Bluetooth, Bluetooth for You could build one in the FPGA of an X-series box. Latency and tuning requirements exceed what you can do with a N210. GNU Radio (http://gr-bluetooth.__sourceforge.net/ http://gr-bluetooth.sourceforge.net/ http://gr-bluetooth.sourceforge.net/), However it is not a complete stack and I guess it doesent include the Bluetooth Transmitter. I built it and checked but couldn't find one. Can you suggest any existing implementation of complete Bluetooth stack ? Any Help is appreciated. Regards, Vaibhav _ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio https://lists.gnu.org/mailman/listinfo/discuss-gnuradio https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org Discuss-gnuradio@gnu.org
Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC
Thank you for providing enough information about USRPs. So as a conclusion, if one needs to implement a Bluetooth device, he shall use X3xx USRP. Best, Mostafa On Thu, Jan 15, 2015 at 12:10 AM, Marcus D. Leech mle...@ripnet.com wrote: On 01/14/2015 02:29 PM, Mostafa Alizadeh wrote: Hi However, there is another point needed to be noticed and that's the LO (local oscillator) capability of the daughterboard. I mean, does have the X-series enough ppm (lower than 3 ppm)? The LO also shall have suitable switching time too. The X3xx series uses a 2.5PPM TCXO, just like the N2xx series. If that isn't accurate enough, you can always use an external, higher-accuacy reference. You use the same daughtercards in the X3xx as the N2xx, except that with the -120 cards (designed specifically for X3xx), they have a wider analog baseband, to match the ADC sample rate. So, the LO switching times would be the same--on the order of a few milliseconds. LO architectures for wideband frequency hopping need to be explicitly engineered for that particular application, and it looks like BlueTooth hop-rates are sub-millisecond, so you can't hop the LO fast enough, but as Marcus Mueller points out, you can hop within a wide baseband. Best, Mostafa On Tue, Jan 13, 2015 at 5:46 PM, Marcus Müller marcus.muel...@ettus.com wrote: The architecture itself can basically deal at arbitrary sample boundaries; however, as soon as you tune a physical thing like an LO, you need some time, especially since the LOs generated on USRP daughterboards discipline the LOs to the high-quality reference clock using PLLs. Depending on the frequency, the frequency delta, the daughterboard, environmental situations as well as individual component variances, the time from tune to stable oscillator changes; these times are in the order of multiple milliseconds, in most cases. You could avoid analog tuning by only doing frequency shifting in the DSP on the N210's FPGA; however, the N210-compatible daughterboards have a bandwidth of 40MHz, so this is not possible for Bluetooth (which is spread over 80MHz). With the X3x0, you can use 120MHz daughterboards, which would enable you to do purely digital tuning. I am, however, not familiar enough with the Bluetooth PHY to assess whether there are latency constraints that prohibit control by a PC -- if the hop sequence is known sufficiently before transmission starts, one could try to generate timed commands that tune the DSP on specific samples. However, that might get a bit ugly, because the on-device command queue has a limited length, so you might need to send timed commands at high rates. Alternatively, the 80 MHz bandwidth comfortably fits into the sampling rate you can get in and out of the X3x0 via 10GigEthernet -- but then, your PC will be burdened with the task of continously generating more than 80MS/s -- for 2 MHz of instantaneous bandwidth. Best regards, Marcus On 01/13/2015 02:44 PM, Mostafa Alizadeh wrote: Yeah I have had a look at Bluetooth PHY. The hop rate of Bluetooth in paging substate increases as 3200 hop/sec too. So you mean the N210 USRP can't support 1600 (or 3200) hop/sec? What do you mean by latency? Is that the latency of the USB or Ethernet? Jeff, please clarify your stance. Why the latency problem doesn't matter X-series USRP? Best, Mostafa On Tue, Jan 13, 2015 at 3:02 PM, Jeff Long willco...@gmail.com willco...@gmail.com wrote: On 01/12/2015 01:07 PM, Mostafa Alizadeh wrote: Hi Jeff, What is your reason for saying: Latency and tuning of the N210 device isn't appropriate??? I should have said that, with either USB or Ethernet, and with a non-real-time O/S, the latency to too great. Hop rate is generally 1600 hops/sec. Take a look at the Bluetooth physical layer spec for more info. Best, Mostafa On Mon, Jan 12, 2015 at 2:52 PM, Jeff Long willco...@gmail.commailto:willco...@gmail.com willco...@gmail.com wrote: On 01/10/2015 02:46 PM, vaibhav kulkarni wrote: Hi All, I am searching for an implementation of a complete Bluetooth stack on GRC 3.7 ( Including the Bluetooth Transmitter and Receiver) preferably working with USRP N210. So far I got this gr-Bluetooth, Bluetooth for You could build one in the FPGA of an X-series box. Latency and tuning requirements exceed what you can do with a N210. GNU Radio (http://gr-bluetooth.__sourceforge.net/ http://gr-bluetooth.sourceforge.net/ http://gr-bluetooth.sourceforge.net/), However it is not a complete stack and I guess it doesent include the Bluetooth Transmitter. I built it and checked but couldn't find one. Can you suggest any existing implementation of complete Bluetooth stack ? Any Help is appreciated. Regards, Vaibhav
Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC
Yeah I have had a look at Bluetooth PHY. The hop rate of Bluetooth in paging substate increases as 3200 hop/sec too. So you mean the N210 USRP can't support 1600 (or 3200) hop/sec? What do you mean by latency? Is that the latency of the USB or Ethernet? Jeff, please clarify your stance. Why the latency problem doesn't matter X-series USRP? Best, Mostafa On Tue, Jan 13, 2015 at 3:02 PM, Jeff Long willco...@gmail.com wrote: On 01/12/2015 01:07 PM, Mostafa Alizadeh wrote: Hi Jeff, What is your reason for saying: Latency and tuning of the N210 device isn't appropriate??? I should have said that, with either USB or Ethernet, and with a non-real-time O/S, the latency to too great. Hop rate is generally 1600 hops/sec. Take a look at the Bluetooth physical layer spec for more info. Best, Mostafa On Mon, Jan 12, 2015 at 2:52 PM, Jeff Long willco...@gmail.com mailto:willco...@gmail.com wrote: On 01/10/2015 02:46 PM, vaibhav kulkarni wrote: Hi All, I am searching for an implementation of a complete Bluetooth stack on GRC 3.7 ( Including the Bluetooth Transmitter and Receiver) preferably working with USRP N210. So far I got this gr-Bluetooth, Bluetooth for You could build one in the FPGA of an X-series box. Latency and tuning requirements exceed what you can do with a N210. GNU Radio (http://gr-bluetooth.__sourceforge.net/ http://gr-bluetooth.sourceforge.net/), However it is not a complete stack and I guess it doesent include the Bluetooth Transmitter. I built it and checked but couldn't find one. Can you suggest any existing implementation of complete Bluetooth stack ? Any Help is appreciated. Regards, Vaibhav _ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC
Hi Jeff, What is your reason for saying: Latency and tuning of the N210 device isn't appropriate??? Best, Mostafa On Mon, Jan 12, 2015 at 2:52 PM, Jeff Long willco...@gmail.com wrote: On 01/10/2015 02:46 PM, vaibhav kulkarni wrote: Hi All, I am searching for an implementation of a complete Bluetooth stack on GRC 3.7 ( Including the Bluetooth Transmitter and Receiver) preferably working with USRP N210. So far I got this gr-Bluetooth, Bluetooth for You could build one in the FPGA of an X-series box. Latency and tuning requirements exceed what you can do with a N210. GNU Radio (http://gr-bluetooth.sourceforge.net/), However it is not a complete stack and I guess it doesent include the Bluetooth Transmitter. I built it and checked but couldn't find one. Can you suggest any existing implementation of complete Bluetooth stack ? Any Help is appreciated. Regards, Vaibhav ___ 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 -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Stack Overflow
Hi, It's good news. Stack Overflow is a more general place not to discuss just GNURadio, also *topics little related *to GNURadio can be discussed there (as they may be disgusting to be discussed here!). Thank you Martin. Best, Mostafa On Thu, Jan 8, 2015 at 2:35 PM, Martin Braun martin.br...@ettus.com wrote: Everyone, we're in an interesting spot community-wise right now, which should be clear to people who've been around here for a while, and definitely to everyone at GRCon last year. While we're still a smallish free software project compared to KDE, Linux etc. we've gained a lot of traction in the last years. Also, we cover an interesting spot where all the serious competitors are expensive proprietary software. But let's cut to the chase: With a community that's growing as fast as it is, we'll need to open up new avenues for communication, and weaken our stance that the mailing list is the one-and-only place to ask questions. For this reason, we would like to publicly announce that we'll be promoting Stack Overflow as an alternative from now on. Right now, it's just regular Stack Overflow with questions tagged 'gnuradio'. And people have already been using this: http://stackoverflow.com/questions/tagged/gnuradio This was brought up at the Community working group at GRCon'14, and Samantha (you may remember her from the panel) has volunteered to initially make sure this gets off on a good start by monitoring SO activities. Now, some disclaimers: Most of us core developers probably won't be jumping onto this, you'll find us mostly on this mailing list in the future, as it is right now. However, with such a growth in the community (at conferences all over the world, people who I've never heard of are doing GNU Radio tutorials. That's a good sign!), I'm hoping there'll be enough volunteers to keep this going. Also, some things are simply better done on the mailing list than Stack Overflow, such as lively discussions, announcements, bug dissections etc. But we get enough one-off questions here which would be better suited on Stack Overflow. The biggest advantage, if you ask me, is that questions tagged 'good' on Stack Overflow are very easy to find, and search engines such as DuckDuckGo show these answers directly at the top of search results. Much, much easier than searching the ML archives. OK, everyone. Let's do this. Martin tl;dr: Stack Overflow can and should be used for questions as well as the mailing list, and we need people to read and answer those Q's. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BER over air
I finally got to this point that if one need to measure SNR, it means that he/she has to eliminate all the other channel effects as well as receiver uncertainties, (like fading, shadowing, Doppler shift, carrier frequency and phase offsets etc.) to have a correct estimate of SNR. Otherwise, he/she coudln't obtain signal-to-noise power ratio. Remember the received signal formulation I mentioned before: y(t) = h(t) * x(t) + n(t). Thank you all. Any interesting ideas would be appreciated. Best, Mostafa On Sun, Dec 28, 2014 at 10:53 PM, Iain Young, G7III g7...@g7iii.net wrote: On 28/12/14 19:08, Mostafa Alizadeh wrote: Again I think we need to remove fading channel before SNR estimation. Is it true? To answer this specific point (and Marcus is far more better versed than I in this science): More fading equals less signal, more noise at particular times, thus worse Signal to Noise Ratio. If you need to be able to pass data during any fading, then you need to take it into account (often this is done with FEC or PM schemes etc) SNR is only true for a moment in time. The next moment, both signal and noise may change. Best Regards Iain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BER over air
Hi Marcus, I completely agree to the statement. But take a look at this simple model: y(t) = h(t) * x(t) + n(t). 'y' is the received signal, 'h' is the channel response (here I assumed that the channel is linear as a filter), 'x' is the *desired *signal and 'n' is noise and the sign '*' is the convolution. Hence, if we try to find signal (x) power to noise (n), it implies that the 'h' is somehow estimated. *Again, consider that noise and channel are different both statistically and in nature.* take look at the Tom Rondeaus website: http://www.trondeau.com/blog/2011/12/30/snr-estimators.html He said: In the case of an SNR estimator, though, I thought about this and had to come to the conclusion that the only way to handle this is to have an estimator that you can plug in variables for your channel model, which of course assumes that you have or can estimate these parameters. So we need acquire 'h'. Best, Mostafa On Mon, Dec 29, 2014 at 3:42 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hello Mostafa, On 12/29/2014 12:55 PM, Mostafa Alizadeh wrote: I finally got to this point that if one need to measure SNR, it means that he/she has to eliminate all the other channel effects as well as receiver uncertainties, (like fading, shadowing, Doppler shift, carrier frequency and phase offsets etc.) to have a correct estimate of SNR. SNR is relative to signal. Signal is what you define it to be. You can say I measure my SNR after equalizing and perfect synchronization, you could also say the power of the signal coming out of the receiver amplifier relative to the noise generated in that amplifier, before any filtering. It's all up to your definition. I will never cease to repeat that. There is no physical entity SNR to measure. When you say SNR is XY dB, it is utterly meaningless unless you define what your signal is and where in your signal processing chain you determine the SNR. Otherwise, he/she coudln't obtain signal-to-noise power ratio. Remember the received signal formulation I mentioned before: y(t) = h(t) * x(t) + n(t). Thank you all. Any interesting ideas would be appreciated. ... you're still asking for easy ideas how to solve your problem which is complicated. You will have to accept the fact that SNR is not a universal measure with a right way to measure for any kind of signal, any kind of channel, any kind of system. Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BER over air
Marcus you're right. This question is somehow out of GNURadio discussion. However, I've found something about different perspectives of SNR calculation at a receiver. Thank you for participating in this discussion. If I find enough time, I will try to generate a code for SNR calculation regardless of type of modulation used and I will share it. Best, Mostafa On Dec 29, 2014 4:53 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Mostafa, On 12/29/2014 01:58 PM, Mostafa Alizadeh wrote: I completely agree to the statement. But take a look at this simple model: y(t) = h(t) * x(t) + n(t). it's totally ok to use that model, but only if your application indicates that this is the right model to use. By the way, *all* components in your equation have time dependency (t), so this alone doesn't justify assuming time-invariance. Estimation h is called gaining channel state information, to give you some hints on what to look for in literature. 'y' is the received signal, 'h' is the channel response (here I assumed that the channel is linear as a filter), 'x' is the *desired *signal and 'n' is noise and the sign '*' is the convolution. Hence, if we try to find signal (x) power to noise (n), it implies that the 'h' is somehow estimated. convolution with the channel is exactly identical to applying a filter. This implies your channel is not flat. *Again, consider that noise and channel are different both statistically and in nature.* If I understand you correctly, then you state exactly what I'm saying: everything you calculate is but an estimate, and the things you can say about SNR are thus only estimates. Whether or not that estimate is a good representation for the reality depends on the way you estimate, and how well your assumptions match reality. This demands a high level of understanding for the underlying concepts! He said: In the case of an SNR estimator, though, I thought about this and had to come to the conclusion that the only way to handle this is to have an estimator that you can plug in variables for your channel model, which of course assumes that you have or can estimate these parameters. So we need acquire 'h'. There's two key words in this paragraph: 1. channel model and 2. acquire. 1. channel model: this implies you model the channel, ie. you make justified assumptions on what the channel is. in the y(t) = h(t)*x(t)+n(t), it's implied the channel is linear and might have a time dependence. 2. acquiring channel state information usually is done by transmitting something that you already know (e.g. a preamble) or using redundancy (ie. coding); if you're being honest, you would have to say ok, now that I have information about h, I can actually transmit data, but since it took energy and time to get that information, I must account for this effort (==energy) when considering the effort I have sending the data (==bit energy). That's a strong argument for not using SNR but E_b/N. All in all, I think I should stop participating in this thread, since I feel that I'm repeating myself. I'd very very humble suggest that you take a few days with the appropriate theoretical literature on digital communications [1], as you seem to be about to write something with a very strong theoretical aspect. None of these mails related in any kind to GNU Radio or even SDR, just basic digital communication theory. Best regards, and all the best, Marcus [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading#Digital-Comms ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BER over air
Hi Martin, Thank you for response. I don't want Eb/N0, because there is not bit stream but complex symbols. As you said, there are two possible solutions: 1- If one uses a specific modulation, so by sending a long known bit sequence, the BER (bit error rate) can be found accordingly then the SNR can be obtained from the theoretical relationship between BER and SNR (here SNR is Eb/N0). I think this is not practical due to the fact that we use the analytic relationship while in practice we want to, for instance, prove that relationship is true. 2- Measuring SNR in analog is, in fact, a hard task. Because as you said it depends on both receiver hardware parameters (such as phase noise, frequency offset, timing offset, quantization, ... ) and channel characteristics (such as small and large scale fadings). This method also may need a sort of channel sounding to extract the channel response corresponding to the measurement environment. The third way I could add here is: using a kind a calibration between Tx/Rx with sending a sine wave pilot. Suppose a sine wave (in base band) with frequency 'fm' is sent via a Tx with the power of 'A' dB. At Rx we take FFT of the signal which has a shape like this: [image: Inline image 1] I assumed that the power level out of sine wave is about -10dBm, call it 'noise_floor', and the received power level of the sine is 0dBm, call it 'peak'. By using the following formula the SNR can be calculated: SNR = peak - noise_floor - 10 log (N_fft/2). N_fft is the number of fft points. Once the SNR value is calculated for 'A' dB Tx power, it seems reasonable to have different SNRs with changing just the Tx power. I'm not sure whether this approach is accurate as we need or not! Is it true? I want to know your recommendations. Thanks in advance, Mostafa On Sat, Dec 27, 2014 at 12:01 AM, Martin Braun martin.br...@ettus.com wrote: On 12/25/2014 11:06 AM, Mostafa Alizadeh wrote: I have a question regarding how it's possible to measure SNR @ an Rx with a USRP? In fact to obtain a graph of BER vs SNR I need to measure SNR ! I didn't find anything specific to this question. However, I've heard it's possible to estimate an initial SNR in Rx by accounting noise figure of the USRP, then by changing the transmitter's power, different SNRs can be seen at Rx. Any idea please!? Measuring exact SNR is a difficult science. What you can do quite easily is to use the SNR estimator blocks. However, for accurate BER/SNR curves, there's a catch-22 here because you're using the same noise to estimate noise power that's affecting the signal (and hence, BER). So, if you're writing a paper, don't forget to mention and explain this. Also, when you say SNR, what *exactly* do you want? Is it Eb/N0? If you want to figure out SNR by analog measurements (i.e. by measuring the exact rx power and estimating the exact noise figure), that's a lot of work. And your calibrations will be off if you open the window and the temperature drops (depending on how accurate you need these values). Also, when doing real measurements, you're including lots of other effects (multipath, phase noise, quantization noise, frequency offset, timing offset... most of these can be modeled as an additional noise figure if they're static, but with some limited accuracy). Is that really what you want? If multipath is negligible you might be able to transmit a very long known BPSK sequence and use the analytical functions for BER in AWGN to estimate Eb/N0 (measure BER and solve for the Eb/N0). I'd need to have another look at the math for our SNR estimators, but they probably do something similar. This only works for *perfect time and frequency synchronisation*! M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BER over air
Hi Marcus, I did forget to mention the basic premises you've mentioned, thank you for them. All these assumptions can be said in a few words: my proposed approach is applicable when the channel is purely AWGN. All nonlinear and time variant effects isn't just due to the channel but the RF hardware. I think, the only satisfactory way to have an estimate of SNR (as you said, signal power to noise) is to find a proper model, also a simple one, for the channel together with the hardware. *Is there any way (like sending and receiving a simple sine wave) to extract this model?* Best, Mostafa On Sun, Dec 28, 2014 at 8:11 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Mostafa, On 12/28/2014 03:54 PM, Mostafa Alizadeh wrote: Hi Martin, Thank you for response. I don't want Eb/N0, because there is not bit stream but complex symbols. A symbol represents information you want to transmit. The unit for information is bit. As you said, there are two possible solutions: 1- If one uses a specific modulation, so by sending a long known bit sequence, the BER (bit error rate) can be found accordingly then the SNR can be obtained from the theoretical relationship between BER and SNR (here SNR is Eb/N0). I think this is not practical due to the fact that we use the analytic relationship while in practice we want to, for instance, prove that relationship is true. 2- Measuring SNR in analog is, in fact, a hard task. Because as you said it depends on both receiver hardware parameters (such as phase noise, frequency offset, timing offset, quantization, ... ) and channel characteristics (such as small and large scale fadings). This method also may need a sort of channel sounding to extract the channel response corresponding to the measurement environment. The third way I could add here is: using a kind a calibration between Tx/Rx with sending a sine wave pilot. Suppose a sine wave (in base band) with frequency 'fm' is sent via a Tx with the power of 'A' dB. At Rx we take FFT of the signal which has a shape like this: [image: Inline image 1] I assumed that the power level out of sine wave is about -10dBm, call it 'noise_floor', and the received power level of the sine is 0dBm, call it 'peak'. By using the following formula the SNR can be calculated: SNR = peak - noise_floor - 10 log (N_fft/2). N_fft is the number of fft points. Once the SNR value is calculated for 'A' dB Tx power, it seems reasonable to have different SNRs with changing just the Tx power. I'm not sure whether this approach is accurate as we need or not! Is it true? I want to know your recommendations. Assuming you're noise is a) purely additive, b) your channel is absolutely flat, and so is your noise (white), c) everything is linear (memoryless channel) and c) you're able to reliably measure the power of a infinitely narrow peak (which implies you can produce a infinitely narrow peak), this applies. As you can see in your picture, the peak is *not* infinitely narrow (obviously, the FFT has limited length, so frequency resolution can't be arbitrarily fine). It's but a basic estimate. Giving you the rx power for a specific frequency and estimating noise power by averaging for a limited amount of time, you get something that, depending on how your system behaves, might or might not represent actual SNR well. I have to stress this: SNR is *signal* to noise ratio. Signal is what your application defines to be signal! Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BER over air
Yeah, If we have include the chanel the received symbol is: y(t) = h(t) * x(t) + n(t). So h can vary with time and isn't flat. In SNR we would know h. For simplicity I ignored it by setting h = 1 which is not acurrate. On Dec 28, 2014 9:01 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hello Mostafa, I've forgot to add that All nonlinear and time variant effects isn't just due to the channel but the RF hardware. is usually not true -- again, SNR is signal to noise, and maybe your signal undergoes correction, and I don't know if that is going to be memoryless. Far more importantly, real radio channels *are not* flat. They are frequency-selective, and they are time-variant. In many (easier) cases, you can consider the channel to be flat for your very limited bandwidth, and you can consider it's properties (or at least the statistical properties of these properties) to be stationary -- but if you're serious about channel characteristics, you can't just say my channel is flat and time-invariant, without really saying why you can make these simplifications. Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BER over air
I suddenly found a book which discussed SNR estimation which is also assumed the AWGN channel [1, chap. 6, p. 121]. This book also considers carrier phase and frequency uncertainties and developed a kind of compensation for them. Again I think we need to remove fading channel before SNR estimation. Is it true? Best, Mostafa [1] Jon Hamkins; Marvin Kenneth Simon,Autonomous software-defined radio receivers for deep space applications,Wiley-Interscience, 2006. On Sun, Dec 28, 2014 at 9:01 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hello Mostafa, I've forgot to add that All nonlinear and time variant effects isn't just due to the channel but the RF hardware. is usually not true -- again, SNR is signal to noise, and maybe your signal undergoes correction, and I don't know if that is going to be memoryless. Far more importantly, real radio channels *are not* flat. They are frequency-selective, and they are time-variant. In many (easier) cases, you can consider the channel to be flat for your very limited bandwidth, and you can consider it's properties (or at least the statistical properties of these properties) to be stationary -- but if you're serious about channel characteristics, you can't just say my channel is flat and time-invariant, without really saying why you can make these simplifications. Greetings, Marcus -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] BER over air
Hello all, BER (Bit Error Rate) measurement isn't a cumbersome task which is realizable for each system with transmitting a known sequence of bits and take them @ a receiver which translates BER measurement into a simple comparison. I have a question regarding how it's possible to measure SNR @ an Rx with a USRP? In fact to obtain a graph of BER vs SNR I need to measure SNR ! I didn't find anything specific to this question. However, I've heard it's possible to estimate an initial SNR in Rx by accounting noise figure of the USRP, then by changing the transmitter's power, different SNRs can be seen at Rx. Any idea please!? Best, Mostafa -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] connecting GNURadio to xilinx evaluation board
Hi, I have KC705 evaluation board of xilinx: http://www.xilinx.com/products/boards-and-kits/ek-k7-kc705-g.html I have also a daughter board of fmcomms1: http://wiki.analog.com/resources/eval/user-guides/ad-fmcomms1-ebz I want to use GNURadio alongside of this board. I suddenly saw Zynq system here (I don't know anything about Zynq system): http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq Is it possible to use KC705 with GNURadio? To be specific, is there any FPGA program for KC705 to integrate it with GNURadio? Any suggestions? Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio retrictions
Hi Marcus, On Mon, Nov 24, 2014 at 1:33 AM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Mostafa, On 11/23/2014 10:39 PM, Mostafa Alizadeh wrote: I just figured out the following limitation of GNURadio's framework that I want to diacuss them to clarify whether I'm wrong or not: 1- For general blocks with multiple output ports, there is a problem with the amount of producing items when the general work routine just gives you the maximum available number of output items for all output ports, and also set_output_multiple or other functions like set_alignment dealing with all output ports rather than individual ones. So if one wants to produce items on the output ports with large different numbers, such as 100 items on one port and 2000 items on the other one, the scheduler will fail to manage this high diverse ports. Ok, I think this needs some explanation. What does fail to manage imply exactly? Generally, I think if you're having something like a block that produces 2000 samples on one, and 100 on another, but does not have a fixed rate between in- and output, this sounds you like, from a logical point of view as much as by performance considerations, be better of using messages. That's a good idea ( using messages instead)! But I think if you illustrate more closely, it's likely we can figure out where the problem lies. 2- The scheduler jumps through different blocks before finishing the work routine's job which causes some problems. No, it doesn't. At least the GNU Radio scheduler won't interrupt a work function I believe in what I see in GNURadio! It forsakes the work's routine somewhere in amidst of it!! Ok, so here's the problem I have with your phrasing: you use scheduler, and I *assume* you mean the GNU Radio scheduler. It's the thread-per-block scheduler, which executes multiple blocks /simultaneously/. Underneath, of course, lies a runtime environment (boost threads), which uses underlying threading libraries (on unixoids usually pthreads), which use the underlying operating system's multithreading routines (aka. the OS's scheduler) , which will execute blocks interleaved (depending on system architecture, number of CPUs etc). OK, these information doesn't solve the problem at least for me who don't know anything about boost. For example, consider the below code which is placed somewhere in the work (general_work ): memcpy (out, temp, n_out_produced * sizeof(gr_complex); produce(0, n_out_produced); add_item_tag(0, nitems_written(0), ... , ... ); So if we change the order of the code like this: memcpy (out, temp, n_out_produced * sizeof(gr_complex); add_item_tag(0, nitems_written(0), ... , ... ); produce(0, n_out_produced); Obviously, calling produce() increments the value that nitems_written() should return! (nitems_written is number of produced samples) So these are two very different programs, semantically. In the second case there is no problem with tagging process, although in the first case the scheduler may jump out of this block right after calling produce function, No, he doesn't ;) you've just written buggy code. Greetings, Marcus I swear that I wrote a clean code :), I see what I see. This is also so complicated, I forgot to add, that sometime calling the produce() function before add_item_tag() increments the nitems_written() and sometime doesn't why?? Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio retrictions
On Mon, Nov 24, 2014 at 4:11 PM, Sylvain Munaut 246...@gmail.com wrote: Please help me find the rational reason! Because calling produce means, I'm done, go ahead and take those sample. Don't call it until you are reall done ... GR is a multi-threaded applications, each work() function is executed in different threads and as soon as you call produce(), other threads are signalled that the samples are ready. Cheers, Sylvain Hi Sylvain, I infer from what you said that what I see is true and logical! In another word, the nitems_written can be updated permanently in the middle of the work's routine. OK But I still think that this is not logical to update the number of items written before returning from work call. Thank you, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNURadio retrictions
Hello GNURadioers! I've been working with GNURadio since about one year ago. I just figured out the following limitation of GNURadio's framework that I want to diacuss them to clarify whether I'm wrong or not: 1- For general blocks with multiple output ports, there is a problem with the amount of producing items when the general work routine just gives you the maximum available number of output items for all output ports, and also set_output_multiple or other functions like set_alignment dealing with all output ports rather than individual ones. So if one wants to produce items on the output ports with large different numbers, such as 100 items on one port and 2000 items on the other one, the scheduler will fail to manage this high diverse ports. 2- The scheduler jumps through different blocks before finishing the work routine's job which causes some problems. For example, consider the below code which is placed somewhere in the work (general_work ): memcpy (out, temp, n_out_produced * sizeof(gr_complex); produce(0, n_out_produced); add_item_tag(0, nitems_written(0), ... , ... ); So if we change the order of the code like this: memcpy (out, temp, n_out_produced * sizeof(gr_complex); add_item_tag(0, nitems_written(0), ... , ... ); produce(0, n_out_produced); In the second case there is no problem with tagging process, although in the first case the scheduler may jump out of this block right after calling produce function, so the position of the tagging which is nitems_written(0) will change to the new value. Suppose in the next call to the first code, after calling produce function, the add_item_tag is called and the item is tagged on nitems_written(0) position which is the same as the previous call. So these two consecutive tags are placed on the same position in the stream. Why is this happening? This is just because before finishing the job of this work routine, scheduler jumps somewhere else. Please help me find the rational reason! Thanks in advance, Alizadeh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] List of GNURadio project
Hello, I want to know how to obtain a list of GNURadio projects? After shutting down cgran there is no reference for them. Is there anything else? Thanks, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AttributeError: 'module' object has no attribute 'block_name'
Hello all,
I've just created a block called sliding_fft. The _impl.h file looks
like:
#include gnuradio/fft/fft.h
namespace gr {
namespace lte_dl_rx {
class sliding_fft_impl : public sliding_fft
{
private:
fft::fft_complex *d_fft;
uint d_fft_size;
uint count;
public:
sliding_fft_impl(uint fft_size);
~sliding_fft_impl();
// Where all the action really happens
int work(int noutput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items);
};
} // namespace lte_dl_rx
} // namespace gr
and the _impl.cc looks like:
/*
* The private constructor
*/
sliding_fft_impl::sliding_fft_impl(uint fft_size)
: gr::sync_block(sliding_fft,
gr::io_signature::make(1, 1, sizeof(gr_complex)),
gr::io_signature::make(1, 1, fft_size*sizeof(gr_complex))),
d_fft_size(fft_size),
count(1)
{
d_fft = new fft::fft_complex (fft_size, 1, 1);
set_history(fft_size);
}
There is no attribute problem till I don't use the d_fft = new
fft::fft_complex (fft_size, 1, 1); line in the constructor!
After working a lot, I got the attribute error in grc is due to this line!
Please help me why this is happening ?
Thank you kindly,
Mostafa
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] volk error
I have also tested that this is fine to use 'decimating fir filter' in GRC but I don't know why I got this error on c++: symbol lookup error: /usr/local/lib/libgnuradio-filter-3.7.5.so.0.0.0: undefined symbol: volk_malloc Is there a library link error which causes this unknown error? PLZ help me I can't go further till this error being solved. Best, Mostafa On Sat, Nov 1, 2014 at 11:38 AM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hello all, I have a c++ code containing filter::fir_filter_ccc, is built successfully, but there is an error when I run it due this filter: symbol lookup error: /usr/local/lib/libgnuradio-filter-3.7.5.so.0.0.0: undefined symbol: volk_malloc What is the problem and what can I do to foil it? Best, Mostafa -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] volk error
Hello all, I have a c++ code containing filter::fir_filter_ccc, is built successfully, but there is an error when I run it due this filter: symbol lookup error: /usr/local/lib/libgnuradio-filter-3.7.5.so.0.0.0: undefined symbol: volk_malloc What is the problem and what can I do to foil it? Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] couldn't find gnuradio-core.pc.
Hello, After installing gnuradio by running this command wget http://www.sbrac.org/files/build-gnuradio chmod a+x ./build-gnuradio ./build-gnuradio on ubuntu 14.04, I want to install 'gr-chancoding' but it couldn't find the 'gnuradio-core'. I also couldn't find 'gnuradio-core.pc.' in /usr/local/lib/pkgconfig. where is the problem? Best, ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gqrx gr project
Hello, There is an issue for the installation of gqrx. When qmake .. it says: *Project MESSAGE: No prefix given. Using /usr/local* why? Best, ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] multi thread fft execution
Hi all,
I have the following c++ code which gets fft by sliding on sample by sample
fo the input.
/*
* The private constructor
*/
sliding_fft_impl::sliding_fft_impl(uint fft_size)
: gr::sync_block(sliding_fft,
gr::io_signature::make(1, 1, sizeof(gr_complex)),
gr::io_signature::make(1, 1, fft_size * sizeof(gr_complex))),
d_fft_size(fft_size)
{
d_fft = new fft::fft_complex (d_fft_size, 1, 2);
set_history(fft_size);
}
sliding_fft_impl::~sliding_fft_impl()
{
delete d_fft;
}
int
sliding_fft_impl::work(int noutput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const gr_complex *in = (const gr_complex *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];
memcpy(d_fft-get_inbuf(), in, d_fft_size * sizeof(gr_complex));
d_fft-execute();
memcpy(out, d_fft-get_outbuf(), d_fft_size * sizeof(gr_complex));
//delete d_fft;
return 1;
}
If I run the fft execution on 2 threads, or more, is there any race
problem between these 2 threads and the work one? Inj another words,
is it possible that this work being called before finishing the fft
execution?
If it is so, there will be a race problem because work wants to
write on d_fft-get_inbuf() while fft execution wants to read from it!
please help me with this code. I don't know why at the runtime, the
data I give at the output aren't desired after a while!!
Best,
Mostafa
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi thread fft execution
Hello Marcus,
I checked my sliding fft works fine and the bug was somewhere else :)
In fact I want to detect a known sequence within data non-coherently. After
detection I want to neglect this 'work' process.
How would you prefer to stop this work process after detection? (Something
like putting this thread to sleep! )
Best,
Mostafa
On Sat, Oct 25, 2014 at 3:56 PM, Marcus Müller mar...@hostalia.de wrote:
Hi Mostafa,
is there any race problem between these 2 threads and the work one?
I think you might be confused what the FFT multithreading means here; I
hope I can illustrate this. Let's set the FFT multithreading level to two
threads:
sliding_fft_impl::work()
|
enter fft-execute
spawn thread 1 spawn thread 2
||
calculate calculate
||
+v---+
join threads
|
return from fft-execute
continue ::work
The work thread waits for fft-execute to return; there can be no
interference while the fft threads run, because at that time, the work
thread isn't active.
Inj another words, is it possible that this work being called before
finishing the fft execution?
no, a single block's work() cannot get called before the previous run of
work() has finished. That wouldn't make any sense -- how would the second
work now how many input samples it has, if the first one hadn't already
consumed?
Your code looks correct. I know I tell you this in almost every discussion
on here, but:
Please, tell us what undesired means. That would greatly reduce the
guesswork for the rest of the mailing list.
Also, sliding FFTs do look like a computational heavy load. What is the
application for that? I ask because getting an fft_length FFT for every
item increases item/sample rate without giving you
(information-theoretically speaking) any advantage over doing one FFT ever
fft_length samples.
Greetings,
Marcus
On 10/25/2014 12:03 PM, Mostafa Alizadeh wrote:
Hi all,
I have the following c++ code which gets fft by sliding on sample by
sample fo the input.
/*
* The private constructor
*/
sliding_fft_impl::sliding_fft_impl(uint fft_size)
: gr::sync_block(sliding_fft,
gr::io_signature::make(1, 1, sizeof(gr_complex)),
gr::io_signature::make(1, 1, fft_size * sizeof(gr_complex))),
d_fft_size(fft_size)
{
d_fft = new fft::fft_complex (d_fft_size, 1, 2);
set_history(fft_size);
}
sliding_fft_impl::~sliding_fft_impl()
{
delete d_fft;
}
int
sliding_fft_impl::work(int noutput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const gr_complex *in = (const gr_complex *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];
memcpy(d_fft-get_inbuf(), in, d_fft_size * sizeof(gr_complex));
d_fft-execute();
memcpy(out, d_fft-get_outbuf(), d_fft_size * sizeof(gr_complex));
//delete d_fft;
return 1;
}
If I run the fft execution on 2 threads, or more, is there any race
problem between these 2 threads and the work one? Inj another words, is it
possible that this work being called before finishing the fft execution?
If it is so, there will be a race problem because work wants to write on
d_fft-get_inbuf() while fft execution wants to read from it!
please help me with this code. I don't know why at the runtime, the data I
give at the output aren't desired after a while!!
Best,
Mostafa
___
Discuss-gnuradio mailing
listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
***
Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/
***
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi thread fft execution
Sliding fft is fundamentally different from spectral estimation in practice. Because in practice we never do sliding on sample by sample to get estimate of spectrum. The using purpose of sliding fft here is something else. Best, On Sat, Oct 25, 2014 at 6:08 PM, Marcus D. Leech mle...@ripnet.com wrote: On 10/25/2014 08:26 AM, Marcus Müller wrote: Also, sliding FFTs do look like a computational heavy load. What is the application for that? I ask because getting an fft_length FFT for every item increases item/sample rate without giving you (information-theoretically speaking) any advantage over doing one FFT ever fft_length samples. Sliding FFTs are used to provide spectral estimates with higher temporal resolution, while sacrificing (to some extent) the overall quality of the estimate. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OpenBTS-UMTS
Hi all, Is there anyone who used OpenBTS-UMTS http://openbts.org/w/index.php/OpenBTS-UMTS with USRPs? I want to know is there possible to run this openBTS on USRP with UHD? And if it is, what is the configuration process? Thanks in advance, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OpenBTS-UMTS
No, I didn't try OpenBTS mailing list, but I think this is possible to run the BTS over USRPs with some specific UHD configuration. Thank you for your hint. OpenBTS isn't even a GNURadio app. Did you try it? On Mon, Oct 20, 2014 at 3:17 PM, mle...@ripnet.com wrote: Have you tried the OpenBTS mailing lists? OpenBTS is *NOT* a Gnu Radio application, although it uses the same hardware as some Gnu Radio apps, it's not a Gnu Radio app itself. On 2014-10-20 15:15, Mostafa Alizadeh wrote: Hi all, Is there anyone who used OpenBTS-UMTS http://openbts.org/w/index.php/OpenBTS-UMTS with USRPs? I want to know is there possible to run this openBTS on USRP with UHD? And if it is, what is the configuration process? Thanks in advance, Mostafa ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OpenBTS-UMTS
I will ask the opentBTS-UMTS mailing list. I hop to find a wag y to run the BTS on a USRP. Best On Oct 20, 2014 11:04 PM, Neel Pandeya neel.pand...@ettus.com wrote: Hello Mostafa Alizadeh: OpenBTS and OpenBTS-UMTS do not use the GNU Radio framework at all, and so you don't need to install GNU Radio in order to use them. To use OpenBTS and OpenBTS-UMTS with USRP radios, you will need to install UHD [1], which you should install before installing OpenBTS and OpenBTS-UMTS. However, I don't think there is an OpenBTS-UMTS transceiver process for USRP radios yet, and you can't substitute the OpenBTS transceiver. [1] https://github.com/EttusResearch/uhd This conversation should be continued on the openbts-discuss mailing list. --Neel On Mon, Oct 20, 2014 at 12:23 PM, Mostafa Alizadeh m.alizade...@gmail.com wrote: No, I didn't try OpenBTS mailing list, but I think this is possible to run the BTS over USRPs with some specific UHD configuration. Thank you for your hint. OpenBTS isn't even a GNURadio app. Did you try it? On Mon, Oct 20, 2014 at 3:17 PM, mle...@ripnet.com wrote: Have you tried the OpenBTS mailing lists? OpenBTS is *NOT* a Gnu Radio application, although it uses the same hardware as some Gnu Radio apps, it's not a Gnu Radio app itself. On 2014-10-20 15:15, Mostafa Alizadeh wrote: Hi all, Is there anyone who used OpenBTS-UMTS with USRPs? I want to know is there possible to run this openBTS on USRP with UHD? And if it is, what is the configuration process? Thanks in advance, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ 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] pybombs error
Hi Nathan,
I think the package is going to be installed isn't python-qwt5-qt4. The
folder location of the package is going to be installed by pubombs is:
/home/alizadeh/gnuradio_src/pybombs/src/pyqwt5. I tried to find an
installation help for this package and I found it (in the attachment).
The installation configuration is returned with an error which doesn't lead
to produce a make file for the installation!
I wonder why? Please help me. I stranding on it for a while! :(
Best,
Mostafa
On Fri, Oct 17, 2014 at 12:43 PM, West, Nathan n...@ostatemail.okstate.edu
wrote:
I'm not sure what's wrong here, but it should be trying to install a
deb called python-qwt5-qt4, not pyqwt5. Perhaps run an apt-get update
and try again. The optimal solution is to find out if this is a bug in
pybombs or your setup and send a patch if it applies to others.
Otherwise you can get around this by installing python-qwt5-qt4
yourself and then use pybombs config to tell pybombs you already have
pyqwt5 installed.
On Fri, Oct 17, 2014 at 1:37 AM, Mostafa Alizadeh
m.alizade...@gmail.com wrote:
Hello guys,
I still trying to install GNURadio on debian 7.6 i86, but there is a
problem
with installing 'pyqwt5' package with pybombs! The following error is
appeared:
packages to install: ['pyqwt5', 'mcpp', 'db48', 'ice', 'gnuradio']
install called (pyqwt5)
install type priority: ['deb', 'src']
install deb called (pyqwt5)
deb is not available locally
check remote repositories...
install src called (pyqwt5)
state = configure
Current step: (pyqwt5 :: make)
make
('\nmake -j4\n', '\nmake -j$makewidth\n')
('\nmake -j4\n', '\nmake -j4\n')
bash exec (/home/alizadeh/gnuradio_src/pybombs/src/pyqwt5/configure)::
make -j4
make: *** No targets specified and no makefile found. Stop.
ERROR:root:PyBOMBS Make step failed for package (pyqwt5) please see bash
output above for a reason (hint: look for the word Error)
What I should do? Please help me :(
Best,
Mostafa
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
***
Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/
***
Title: Installation PyQwt v5.2.0 documentation
Navigation
index
modules |
next |
previous |
PyQwt v5.2.0 documentation
Installation¶
Source Code Installation¶
Build Prerequisites¶
Recommended build prerequisites for PyQwt-5.2.0 are:
Python, version 2.6.x and 2.5.x are
supported.
Qt, version 4.5.x, 4.4.x,
4.3.x, and 3.3.x are supported.
SIP,
version 4.8.x and 4.7.x (x 3) are supported.
PyQt
for Mac OS X, Windows, and/or X11, version 4.5.x, 4.4.x, 4.3.x,
3.18.x, and 3.17.x are supported.
optionally NumPy, version 1.3.x,
1.2.x, and 1.1.x are supported.
optionally Qwt, version 5.2.x,
5.1.x, and 5.0.x are supported.
The source package
PyQwt-5.2.0.tar.gz
contains a snapshot of the Qwt-5.2 subversion bug fix branch which may
fix some bugs in Qwt-5.2.0.
I recommend to compile and link the bug fix branch statically into PyQwt.
To exploit the full power of PyQwt, you should install at least one of
the numerical Python extensions:
NumPy
numarray
Numeric
and built PyQwt with support for the numerical Python extension(s) of
your choice. However, only NumPy is actively developed and numarray and
Numeric are deprecated.
PyQwt-5.2.0 and recent versions of the numerical Python extensions support
the N-D array interface
protocol. Therefore, PyQwt supports those extensions, even if they have not
been installed when PyQwt has been built. In this case, the functionality is
somewhat reduced, since conversion from an QImage to a Numerical
Python array is not supported.
Installation¶
The installation procedure consists of three steps:
Unpack PyQwt-5.2.0.tar.gz.
Invoke the following commands to build PyQwt-5.2.0 for Qt-4:
cd PyQwt-5.2.0
cd configure
python configure.py -Q ../qwt-5.2
make
make install
or invoke the commands to build PyQwt-5.2.0 for Qt-3:
cd PyQwt-5.2.0
cd configure
python configure.py -3 -Q ../qwt-5.2
make
make install
This assumes that the correct Python interpreter is on your path. Replace
make by nmake, if you use Microsoft Visual C++.
The commands build PyQwt against the included Qwt subversion snapshot and
install PyQwt.
Test the installation by playing with the example programs.
Fine tune (optional):
to use a Qwt library already installed on your system invoke
commands similar to:
python configure.py
[Discuss-gnuradio] pybombs error
Hello guys,
I still trying to install GNURadio on debian 7.6 i86, but there is a
problem with installing 'pyqwt5' package with pybombs! The following error
is appeared:
packages to install: ['pyqwt5', 'mcpp', 'db48', 'ice', 'gnuradio']
install called (pyqwt5)
install type priority: ['deb', 'src']
install deb called (pyqwt5)
deb is not available locally
check remote repositories...
install src called (pyqwt5)
state = configure
Current step: (pyqwt5 :: make)
make
('\nmake -j4\n', '\nmake -j$makewidth\n')
('\nmake -j4\n', '\nmake -j4\n')
bash exec (/home/alizadeh/gnuradio_src/pybombs/src/pyqwt5/configure)::
make -j4
make: *** No targets specified and no makefile found. Stop.
ERROR:root:PyBOMBS Make step failed for package (pyqwt5) please see bash
output above for a reason (hint: look for the word Error)
What I should do? Please help me :(
Best,
Mostafa
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] is there possible to have item drops?
Hi Marcus, I tested again my problem with connecting a data file (file source) to the fir filter and read the output with the one resulted from Matlab. The error which appears due to the data precision is in acceptable order. However, when I directly connect my tx to the fir filter, it did something strange after sometime which causes a great error with respect to the Matlab one. *I think the problem is with my tx! I really confused!! I just wanna know how could I identify the problem and how could I fix it? * My scheme: *[image: Inline image 1]* Best, Mostafa On Wed, Oct 15, 2014 at 9:03 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hello Mostafa, filtering is a inherently lossy operation: it's an operation that involves multiplication and addition of floating point numbers. Matlab internally uses double (float64) values, whereas GNU Radio, usually, uses single precision (float32) numbers for performance reasons. Now, without knowing what kind of signal you are filtering with what kind of taps you are using with what kind of GNU Radio filters and what Matlab functions, there's nothing to guess on how these differences occur. What I *can* say though is that I've never seen an item drop in GNU Radio's runtime, and we have strong tests against that. Now, it's entirely possible that any of our filter implementations might have bugs, but I kind of doubt that. It's most probably simply numeric accuracy that kills your samples. Greetings, Marcus On 15.10.2014 18:07, Mostafa Alizadeh wrote: Hi all, It seems this is a ridiculous question, however, I didn't find any solution for my problem. I have already a bunch of custom blocks connected to each other which play role as a transmitter (tx). I want to connect tx to a fir filter by using fir_filter_ccc block. I set the filter taps with specific ones. I also have this filter in Matlab. The output of the filter is connected to a sink file. When I see the output (tx) and filtering it by Matlab and comparing it with the output of the gnuradio filter, I see both of the following: 1) Both matlab and gnuradio filtered output, have little difference in a range of 0.01. (I'm using gr_complex data). 2) After a while, Matlab output and GNURadio's output will differ as high as 1000 in magnitude!! I guess, there is item drops in this filtering. I know, the probability of this event is so weak, anyway, item drop even can happen in GNURadio? Where is my problem? Best, Mostafa ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] is there possible to have item drops?
Tx is an abbreviation of tx blocks! :) I finally found the problem! I used heap memory but I never release it in different blocks! So during the runtime, the memory allocation get the error: std::bad_alloc after somewhile. Now this is fine. Thank you too much, Best, Mostafa On Thu, Oct 16, 2014 at 4:16 PM, Marcus Müller marcus.muel...@ettus.com wrote: I'm a bit confused. Your diagram TX-FIR-... -Filesink Indicates that TX is a source, whereas TX usually is an information sink in DSP. Maybe you want to fill us in about the type of block TX is? Greetings, Marcus On 16.10.2014 13:47, Mostafa Alizadeh wrote: Hi Marcus, I tested again my problem with connecting a data file (file source) to the fir filter and read the output with the one resulted from Matlab. The error which appears due to the data precision is in acceptable order. However, when I directly connect my tx to the fir filter, it did something strange after sometime which causes a great error with respect to the Matlab one. *I think the problem is with my tx! I really confused!! I just wanna know how could I identify the problem and how could I fix it? * My scheme: *[image: Inline image 1]* Best, Mostafa On Wed, Oct 15, 2014 at 9:03 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hello Mostafa, filtering is a inherently lossy operation: it's an operation that involves multiplication and addition of floating point numbers. Matlab internally uses double (float64) values, whereas GNU Radio, usually, uses single precision (float32) numbers for performance reasons. Now, without knowing what kind of signal you are filtering with what kind of taps you are using with what kind of GNU Radio filters and what Matlab functions, there's nothing to guess on how these differences occur. What I *can* say though is that I've never seen an item drop in GNU Radio's runtime, and we have strong tests against that. Now, it's entirely possible that any of our filter implementations might have bugs, but I kind of doubt that. It's most probably simply numeric accuracy that kills your samples. Greetings, Marcus On 15.10.2014 18:07, Mostafa Alizadeh wrote: Hi all, It seems this is a ridiculous question, however, I didn't find any solution for my problem. I have already a bunch of custom blocks connected to each other which play role as a transmitter (tx). I want to connect tx to a fir filter by using fir_filter_ccc block. I set the filter taps with specific ones. I also have this filter in Matlab. The output of the filter is connected to a sink file. When I see the output (tx) and filtering it by Matlab and comparing it with the output of the gnuradio filter, I see both of the following: 1) Both matlab and gnuradio filtered output, have little difference in a range of 0.01. (I'm using gr_complex data). 2) After a while, Matlab output and GNURadio's output will differ as high as 1000 in magnitude!! I guess, there is item drops in this filtering. I know, the probability of this event is so weak, anyway, item drop even can happen in GNURadio? Where is my problem? Best, Mostafa ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps:// lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] is there possible to have item drops?
Hi all, It seems this is a ridiculous question, however, I didn't find any solution for my problem. I have already a bunch of custom blocks connected to each other which play role as a transmitter (tx). I want to connect tx to a fir filter by using fir_filter_ccc block. I set the filter taps with specific ones. I also have this filter in Matlab. The output of the filter is connected to a sink file. When I see the output (tx) and filtering it by Matlab and comparing it with the output of the gnuradio filter, I see both of the following: 1) Both matlab and gnuradio filtered output, have little difference in a range of 0.01. (I'm using gr_complex data). 2) After a while, Matlab output and GNURadio's output will differ as high as 1000 in magnitude!! I guess, there is item drops in this filtering. I know, the probability of this event is so weak, anyway, item drop even can happen in GNURadio? Where is my problem? Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Connecting an output to multiple input
Hello GNURadioers! I have a block (blck #1) connected to multiple of blocks. Here I have two blocks' (call blck #2 and blck #3) connected to blck #1 output. I'm confused when I saw nitems_read of blck #2 and #3 aren't the same, say 1000 items are read by blck #2 and 155000 items read by blck #3 after sometimes. I know the processing chain of blck #2 and blck #3 is so different which causes a low rate of reading items by blck #2 rather than blck #3 can read so faster. My question is why? why is this happening? Both of blck #2 3 are reading from one output port? Any idea? Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] installing gnuradio with pybombs on debian
yeah, you're right That's the problem with my location !! Thank u :) On Thu, Oct 9, 2014 at 8:06 AM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Mostafa, pybombs tries to install boost from source because 1.49 is known to be buggy. It seems like it can't download the file. Since this works here, that might have been a temporary issue (try again!) or it might be caused by the need to use a proxy to access websites from where you are working. In that case, set the http_proxy environnment variable accordingly (ask your local admin for the right setting). Greetings, Marcus On 09.10.2014 13:35, Mostafa Alizadeh wrote: Hello guys, I have a problem with installing GNURadio on Debian i86 7.6. After executing ./pybombs install gnuradio, I got the following error related to boost: File /home/alizadeh/gnuradio_src/pybombs/mod_pybombs/recipe.py, line 649, in fetch raise Exception(Failed to Fetch package '%s' sources were '%s'!%( self.name, self.source)); Exception: Failed to Fetch package 'boost' sources were '['wget:// http://downloads.sourceforge.net/project/boost/boost/1.53.0/boost_1_53_0.tar.bz2 '] '! I saw my Synaptic package manager, the below libboosts are already installed: libboost-iostreams1.49.0 libboost-thread1.49.0 libboost-program-options1.49.0 What I should do to install GNURadio on this device? (I always have a problem with boost library for GNURadio! :( ) Best, Mostafa ___ 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 -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using volk
Thank you so much Marcus, I've learnt so much from you here :) The algorithm of finding the Max of a vector by comparing one half to the other half, is an appropriate idea! I can't use GNURadio blocks for this calculation because I must do these within my own block. Unfortunately, I'm not familiar with optimization and parallelization algorithm, so I just want to compute fast not necessarily as fast as possible :) Best, Mostafa On Wed, Oct 8, 2014 at 5:56 AM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Mostafa, VOLK is but an accelerated Library of Vector Optimized Kernels. What you want is basically three operations: a) finding maximum absolute b) finding average absolute c) dividing these two values Now, looking closer at a) and b), one notices that both require the samples to be converted to their magnitudes, first. And because we're in the business of optimizing things, let's just use the squared magnitude, because that's faster to compute by one sqrt, usually. So this boils down to a) take mag_squared of input (length N) b1) find maximum of a) b2) find sum of a) c) sqrt(b2/b1)/N As you can see, c) is not a vector operation, and thus not a case for volk. For a) (Complex to Mag ^ 2) there is a GNU Radio block that uses VOLK. That's the example for using VOLK that I would have recommended to read, anyway :) In other terms: If you don't have to write your own highly optimized block, don't use VOLK directly, use the standard GNU Radio blockset. It's rather optimized ;) Now, for the maximum search b1, things are a bit more complicated. Searching for a maximum is not *easily* vectorizable, because it is a inherently sequential operation (think of it as the first step of a bubble sort). Now, you can achieve *awesome* performance by basically turning your linear search into a N-ary tree, with N being the order of parallelism you can achieve by using a maximum-finding SIMD instruction. But that requires the size of the problem to be a power of N. That just doesn't fly well with the usually more multiple of 64 bit-typey alignment restrictions. You're however, highly encouraged to try just that: use the existing volk_32f_x2_max_32f, which compares two vectors, and stores the element-wise maximum in a third one, to compare the first with the second half of your mag_squared vector, and repeat the same with the first and second half of the result (and so on) until you have a single maximum value. That's the comparison tree from above for the N=2 case. You can employ clever overlapping to use as many values twice in the input to virtually extend your input's length to a power of two, and then just waltz on. For b2) you can simply use the integrate block, which is not VOLK optimized (possibly because it's a gengen template and these are *so much fun* to specialize). But seeing as it is simply an accumulating for loop, I kind of expect your compiler to make the best of the situation. However, you can also use the volk_32f_accumulator_s32f VOLK kernel. I kind of want to use that in integrate, because for my machine, the SSE VOLK kernel is 4 times as fast as the generic implementation, which nicely matches the 4-operand SSE SIMD instruction behind it. Greetings, Marcus On 07.10.2014 21:49, Mostafa Alizadeh wrote: Hello all, I wondered about volk. I want it to compute mean to peak value of a complex array. How could I do this? Besides, I really need to know is there any example of using volk? The code itself, doesn't reflect input and output parameters explicitly. Best, Mostafa ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] installing gnuradio with pybombs on debian
Hello guys, I have a problem with installing GNURadio on Debian i86 7.6. After executing ./pybombs install gnuradio, I got the following error related to boost: File /home/alizadeh/gnuradio_src/pybombs/mod_pybombs/recipe.py, line 649, in fetch raise Exception(Failed to Fetch package '%s' sources were '%s'!%( self.name, self.source)); Exception: Failed to Fetch package 'boost' sources were '['wget:// http://downloads.sourceforge.net/project/boost/boost/1.53.0/boost_1_53_0.tar.bz2'] '! I saw my Synaptic package manager, the below libboosts are already installed: libboost-iostreams1.49.0 libboost-thread1.49.0 libboost-program-options1.49.0 What I should do to install GNURadio on this device? (I always have a problem with boost library for GNURadio! :( ) Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using volk
Hello all, I wondered about volk. I want it to compute mean to peak value of a complex array. How could I do this? Besides, I really need to know is there any example of using volk? The code itself, doesn't reflect input and output parameters explicitly. Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] using control port monitor
Hello Tom, Is there a timeline for fixing the issue with control port and backing it to its normal operation? Best, On Sat, Sep 13, 2014 at 7:31 PM, Tom Rondeau t...@trondeau.com wrote: On Sat, Sep 13, 2014 at 10:43 AM, Vanush Vaswani van...@gmail.com wrote: That doesn't specify what the underlying concern was. Nope. No it doesn't. Tom On Sat, Sep 13, 2014 at 11:46 PM, Tom Rondeau t...@trondeau.com wrote: On Sat, Sep 13, 2014 at 8:35 AM, Vanush Vaswani van...@gmail.com wrote: What are the issues? http://lists.gnu.org/archive/html/discuss-gnuradio/2014-08/msg00166.html Tom On Sat, Sep 13, 2014 at 3:38 PM, Sylvain Munaut 246...@gmail.com wrote: Pleas help me to use control port monitor. You can't. See a mail from Tom Rondeau a few weeks back : ctrl port has been temporarly removed from gnuradio due to some issues with its middleware. It's being worked on. Cheers, Sylvain ___ 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 -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Latency measurements
Harold, I'm not using any protocol. This is just a GNURadio application. It is important to me to know is there any way to optimize input/output buffers of blocks to reduce latency as much as possible? Is the GNURadio able to do so automatically? Best, Mostafa On Sun, Sep 7, 2014 at 9:49 PM, Harold Daniel Moreno Urbina harol...@gmail.com wrote: Hello, There is a mathematical relationship in the latency time? May be there is something related to Ethernet protocol to handle collicollisions. El 07/09/2014 09:39, Mostafa Alizadeh m.alizade...@gmail.com escribió: The second problem I encountered that I forgot to mention is: when I send multiple of packets from a source block to a sink block and I measure the latency for each packet, the latency is increasing constantly as time advances. Why is this happening? Best, Mostafa On Sun, Sep 7, 2014 at 8:04 PM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hi Marcus, I did what you recommended for measuring latency which is defined as followed: the traveling duration of a packet through blocks until some specified processing in one block is done. However, there are obstacles again. Firstly, how can optimize I/O buffers of my blocks to obtain a minimum latency. I tried to use set_alignment for output buffers. When I change them a little, the latency will change within a hundred of milliseconds. Although, the input buffers must be determined in an efficient manner but how to do so? This is important to mention that the latency here is just accounted for GNURadio latency which is not included other delays such as hardware and UHD delays. Thanks in advance, Mostafa On Fri, Sep 5, 2014 at 3:32 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Mostafa, I never tire to say that such measurements are often meaningless, as a) on general purpose processors and operating systems *anything* can happen, stalling your flow graph, and b) as GNU Radio scales well on multiprocessor platforms and algorithms are steadily optimized, you can expect no two installations to exhibit the same latency. That being said, it's still a helpful measurement when actually implementing something for a given system configuration, so here's my advice: Just compare the nitems_written() of an upstream block with the nitems_read() of a downstream block at singulare times, which will give you the numbers of items in the flow between these two. Also, take the nitems_read() of an upstream block, and measure the host time passing until nitems_read() of a downstream block is greater or equal that number. Apply statistics. The easiest way to find out how long an item has been in the flight would be adding a stream tag containing the current host time at an upstream block, and reading that tag somewhere downstream, comparing the contained timestamp with the now current system time. Also, since I bet this ends up on the Google search results for GNU Radio latency sooner or later, a word to the uninitiated reader: Usually, real time doesn't matter in DSP systems such as GNU Radio. Samples are not processed at their signal theoretical speed, but at the rate that they become available, limited by the speed at which the processor can process them. In the GNU Radio case, this is even more evident because normally, GNU Radio lets blocks process samples en bloc, meaning that you usually see something like 4096 samples going into a block, which then processes them, and outputs another chunk of samples (often of the same length), and then goes to sleep, until its woken up to process another chunk of samples at its input. Latency is thus strongly dependent on how big GNU Radio makes these chunks, which is a thing that as developer/user you can configure, but lowering buffer sizes usually decreases efficiency, and thus doesn't necessarily reduce latency. Generally, if you try to optimize something for throughput, just write your blocks as efficiently as possible and use GNU Radio/volk optimized things as often as sensible; if you try to optimize for latency, you need to put in more thought, optimize individual buffer sizes, consider what optimal work chunk sizes are and if you want to go as far as breaking up GNU Radios highly modular approach. Greetings, Marcus On 05.09.2014 12:14, Mostafa Alizadeh wrote: Hi guys, In simulation, sometime we need to measure the latency of a packet in terms of the duration is needed to perform some certain signal processing on the packet. Assume that we have a source which generates packets with specific lengths. I want to know how long does it take for the packet to go through blocks and receive to a particular block? Is there any solution in GNURadio? I think it's possible with *performance counters* but I don't know how? Best, Mostafa ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman
Re: [Discuss-gnuradio] Latency measurements
Hi Marcus, I did what you recommended for measuring latency which is defined as followed: the traveling duration of a packet through blocks until some specified processing in one block is done. However, there are obstacles again. Firstly, how can optimize I/O buffers of my blocks to obtain a minimum latency. I tried to use set_alignment for output buffers. When I change them a little, the latency will change within a hundred of milliseconds. Although, the input buffers must be determined in an efficient manner but how to do so? This is important to mention that the latency here is just accounted for GNURadio latency which is not included other delays such as hardware and UHD delays. Thanks in advance, Mostafa On Fri, Sep 5, 2014 at 3:32 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Mostafa, I never tire to say that such measurements are often meaningless, as a) on general purpose processors and operating systems *anything* can happen, stalling your flow graph, and b) as GNU Radio scales well on multiprocessor platforms and algorithms are steadily optimized, you can expect no two installations to exhibit the same latency. That being said, it's still a helpful measurement when actually implementing something for a given system configuration, so here's my advice: Just compare the nitems_written() of an upstream block with the nitems_read() of a downstream block at singulare times, which will give you the numbers of items in the flow between these two. Also, take the nitems_read() of an upstream block, and measure the host time passing until nitems_read() of a downstream block is greater or equal that number. Apply statistics. The easiest way to find out how long an item has been in the flight would be adding a stream tag containing the current host time at an upstream block, and reading that tag somewhere downstream, comparing the contained timestamp with the now current system time. Also, since I bet this ends up on the Google search results for GNU Radio latency sooner or later, a word to the uninitiated reader: Usually, real time doesn't matter in DSP systems such as GNU Radio. Samples are not processed at their signal theoretical speed, but at the rate that they become available, limited by the speed at which the processor can process them. In the GNU Radio case, this is even more evident because normally, GNU Radio lets blocks process samples en bloc, meaning that you usually see something like 4096 samples going into a block, which then processes them, and outputs another chunk of samples (often of the same length), and then goes to sleep, until its woken up to process another chunk of samples at its input. Latency is thus strongly dependent on how big GNU Radio makes these chunks, which is a thing that as developer/user you can configure, but lowering buffer sizes usually decreases efficiency, and thus doesn't necessarily reduce latency. Generally, if you try to optimize something for throughput, just write your blocks as efficiently as possible and use GNU Radio/volk optimized things as often as sensible; if you try to optimize for latency, you need to put in more thought, optimize individual buffer sizes, consider what optimal work chunk sizes are and if you want to go as far as breaking up GNU Radios highly modular approach. Greetings, Marcus On 05.09.2014 12:14, Mostafa Alizadeh wrote: Hi guys, In simulation, sometime we need to measure the latency of a packet in terms of the duration is needed to perform some certain signal processing on the packet. Assume that we have a source which generates packets with specific lengths. I want to know how long does it take for the packet to go through blocks and receive to a particular block? Is there any solution in GNURadio? I think it's possible with *performance counters* but I don't know how? Best, Mostafa ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Latency measurements
The second problem I encountered that I forgot to mention is: when I send multiple of packets from a source block to a sink block and I measure the latency for each packet, the latency is increasing constantly as time advances. Why is this happening? Best, Mostafa On Sun, Sep 7, 2014 at 8:04 PM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hi Marcus, I did what you recommended for measuring latency which is defined as followed: the traveling duration of a packet through blocks until some specified processing in one block is done. However, there are obstacles again. Firstly, how can optimize I/O buffers of my blocks to obtain a minimum latency. I tried to use set_alignment for output buffers. When I change them a little, the latency will change within a hundred of milliseconds. Although, the input buffers must be determined in an efficient manner but how to do so? This is important to mention that the latency here is just accounted for GNURadio latency which is not included other delays such as hardware and UHD delays. Thanks in advance, Mostafa On Fri, Sep 5, 2014 at 3:32 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Mostafa, I never tire to say that such measurements are often meaningless, as a) on general purpose processors and operating systems *anything* can happen, stalling your flow graph, and b) as GNU Radio scales well on multiprocessor platforms and algorithms are steadily optimized, you can expect no two installations to exhibit the same latency. That being said, it's still a helpful measurement when actually implementing something for a given system configuration, so here's my advice: Just compare the nitems_written() of an upstream block with the nitems_read() of a downstream block at singulare times, which will give you the numbers of items in the flow between these two. Also, take the nitems_read() of an upstream block, and measure the host time passing until nitems_read() of a downstream block is greater or equal that number. Apply statistics. The easiest way to find out how long an item has been in the flight would be adding a stream tag containing the current host time at an upstream block, and reading that tag somewhere downstream, comparing the contained timestamp with the now current system time. Also, since I bet this ends up on the Google search results for GNU Radio latency sooner or later, a word to the uninitiated reader: Usually, real time doesn't matter in DSP systems such as GNU Radio. Samples are not processed at their signal theoretical speed, but at the rate that they become available, limited by the speed at which the processor can process them. In the GNU Radio case, this is even more evident because normally, GNU Radio lets blocks process samples en bloc, meaning that you usually see something like 4096 samples going into a block, which then processes them, and outputs another chunk of samples (often of the same length), and then goes to sleep, until its woken up to process another chunk of samples at its input. Latency is thus strongly dependent on how big GNU Radio makes these chunks, which is a thing that as developer/user you can configure, but lowering buffer sizes usually decreases efficiency, and thus doesn't necessarily reduce latency. Generally, if you try to optimize something for throughput, just write your blocks as efficiently as possible and use GNU Radio/volk optimized things as often as sensible; if you try to optimize for latency, you need to put in more thought, optimize individual buffer sizes, consider what optimal work chunk sizes are and if you want to go as far as breaking up GNU Radios highly modular approach. Greetings, Marcus On 05.09.2014 12:14, Mostafa Alizadeh wrote: Hi guys, In simulation, sometime we need to measure the latency of a packet in terms of the duration is needed to perform some certain signal processing on the packet. Assume that we have a source which generates packets with specific lengths. I want to know how long does it take for the packet to go through blocks and receive to a particular block? Is there any solution in GNURadio? I think it's possible with *performance counters* but I don't know how? Best, Mostafa ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh
Re: [Discuss-gnuradio] Latency measurements
Thank you Harold, On Fri, Sep 5, 2014 at 7:41 PM, Harold Daniel Moreno Urbina harol...@gmail.com wrote: Hello Mostafa, I read this article and think you can find it interesting: http://academic.csuohio.edu/yuc/papers/PID2932179.pdf Greetings Harold Daniel Moreno Urbina 2014-09-05 4:14 GMT-06:00 Mostafa Alizadeh m.alizade...@gmail.com: Hi guys, In simulation, sometime we need to measure the latency of a packet in terms of the duration is needed to perform some certain signal processing on the packet. Assume that we have a source which generates packets with specific lengths. I want to know how long does it take for the packet to go through blocks and receive to a particular block? Is there any solution in GNURadio? I think it's possible with *performance counters* but I don't know how? Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Latency measurements
Thank you very much Marcus, As always you explain in details :) . I knew that the latency is architecture dependent, however, I'm looking for a measurement as a role of thumb. You're idea was great which is tagging the stream with time stamp and reading the tag and comparing it with the received time. Best, Mostafa On Fri, Sep 5, 2014 at 3:32 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Mostafa, I never tire to say that such measurements are often meaningless, as a) on general purpose processors and operating systems *anything* can happen, stalling your flow graph, and b) as GNU Radio scales well on multiprocessor platforms and algorithms are steadily optimized, you can expect no two installations to exhibit the same latency. That being said, it's still a helpful measurement when actually implementing something for a given system configuration, so here's my advice: Just compare the nitems_written() of an upstream block with the nitems_read() of a downstream block at singulare times, which will give you the numbers of items in the flow between these two. Also, take the nitems_read() of an upstream block, and measure the host time passing until nitems_read() of a downstream block is greater or equal that number. Apply statistics. The easiest way to find out how long an item has been in the flight would be adding a stream tag containing the current host time at an upstream block, and reading that tag somewhere downstream, comparing the contained timestamp with the now current system time. Also, since I bet this ends up on the Google search results for GNU Radio latency sooner or later, a word to the uninitiated reader: Usually, real time doesn't matter in DSP systems such as GNU Radio. Samples are not processed at their signal theoretical speed, but at the rate that they become available, limited by the speed at which the processor can process them. In the GNU Radio case, this is even more evident because normally, GNU Radio lets blocks process samples en bloc, meaning that you usually see something like 4096 samples going into a block, which then processes them, and outputs another chunk of samples (often of the same length), and then goes to sleep, until its woken up to process another chunk of samples at its input. Latency is thus strongly dependent on how big GNU Radio makes these chunks, which is a thing that as developer/user you can configure, but lowering buffer sizes usually decreases efficiency, and thus doesn't necessarily reduce latency. Generally, if you try to optimize something for throughput, just write your blocks as efficiently as possible and use GNU Radio/volk optimized things as often as sensible; if you try to optimize for latency, you need to put in more thought, optimize individual buffer sizes, consider what optimal work chunk sizes are and if you want to go as far as breaking up GNU Radios highly modular approach. Greetings, Marcus On 05.09.2014 12:14, Mostafa Alizadeh wrote: Hi guys, In simulation, sometime we need to measure the latency of a packet in terms of the duration is needed to perform some certain signal processing on the packet. Assume that we have a source which generates packets with specific lengths. I want to know how long does it take for the packet to go through blocks and receive to a particular block? Is there any solution in GNURadio? I think it's possible with *performance counters* but I don't know how? Best, Mostafa ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Latency measurements
Hi guys, In simulation, sometime we need to measure the latency of a packet in terms of the duration is needed to perform some certain signal processing on the packet. Assume that we have a source which generates packets with specific lengths. I want to know how long does it take for the packet to go through blocks and receive to a particular block? Is there any solution in GNURadio? I think it's possible with *performance counters* but I don't know how? Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to stop a flowgraph
In the other words, I want to stop top block but I don't know how? If I have one source and one sink, I could stop the top block by returning -1 from the source, but I don't know what is the solution here when I have multiple sources. best, Mostafa On Wed, Sep 3, 2014 at 10:20 AM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hi all, I have the following flowgraph: [image: Inline image 2] I want to interrupt the whole flowgraph to back to the main function (C++). I used to return -1 or WORK_DONE in the work function of the sink block but it doesn't work. What is the solution? Thanks in advance, Mostafa -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to stop a flowgraph
Hi all, I have the following flowgraph: [image: Inline image 2] I want to interrupt the whole flowgraph to back to the main function (C++). I used to return -1 or WORK_DONE in the work function of the sink block but it doesn't work. What is the solution? Thanks in advance, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] a crazy problem with GNURadio fft
Hi all,
I was wonder why my codes in Matlab aren't compatible with GNURadio ones!
After all, I found the fft output in GNURadio is different to Matlab!!
Here is my simple code for fft testing with the real inputs of 0 to 63:
#include iostream
#include gnuradio/fft/fft.h
using namespace std;
using namespace gr;
int main()
{
int fft_size = 64;
gr::fft::fft_complex *ifft = new gr::fft::fft_complex (fft_size, true, 1);
// making complex data
gr_complex in[fft_size];
for (int i=0; ifft_size; i++)
{
in[i] = i;
}
memcpy(ifft-get_inbuf(), in, fft_size);
ifft-execute();
cout output endl;
for (int i=0; ifft_size; i++)
{
cout ifft-get_outbuf()[i] endl;
}
cout THE END! endl;
return 0;
}
the output in GNURadio:
(28,0)
(24.3326,-13.0209)
(14.591,-22.0217)
(2.07356,-24.4501)
(-9.13707,-20.1094)
(-15.692,-11.1259)
(-16.1531,-1.03318)
(-11.3785,6.63407)
(-4,9.65685)
(2.75122,7.8416)
(6.35844,2.87496)
(5.93264,-2.55936)
(2.38009,-5.98642)
(-2.18793,-6.14396)
(-5.4952,-3.37881)
(-6.11148,0.684235)
(-4,4)
(-0.398263,5.06997)
(2.86434,3.58162)
(4.26461,0.45671)
(3.27677,-2.67271)
(0.553035,-4.28344)
(-2.45947,-3.67857)
(-4.25578,-1.27436)
(-4,1.65685)
(-1.899,3.64105)
(0.940382,3.727)
(3.08336,1.93207)
(3.48022,-0.795649)
(1.9727,-3.06732)
(-0.646391,-3.74757)
(-3.04078,-2.51227)
(-4,0)
(-3.04078,2.51227)
(-0.646391,3.74757)
(1.9727,3.06732)
(3.48022,0.795649)
(3.08336,-1.93207)
(0.940382,-3.727)
(-1.899,-3.64105)
(-4,-1.65685)
(-4.25578,1.27436)
(-2.45947,3.67857)
(0.553035,4.28344)
(3.27677,2.67271)
(4.26461,-0.45671)
(2.86434,-3.58162)
(-0.398263,-5.06997)
(-4,-4)
(-6.11148,-0.684235)
(-5.4952,3.37881)
(-2.18793,6.14396)
(2.38009,5.98642)
(5.93264,2.55936)
(6.35844,-2.87496)
(2.75122,-7.8416)
(-4,-9.65685)
(-11.3785,-6.63407)
(-16.1531,1.03318)
(-15.692,11.1259)
(-9.13707,20.1094)
(2.07356,24.4501)
(14.591,22.0217)
(24.3326,13.0209)
the output of the Matlab:
1.0e+03 *
2.0160
-0.0320 + 0.6514i
-0.0320 + 0.3249i
-0.0320 + 0.2157i
-0.0320 + 0.1609i
-0.0320 + 0.1278i
-0.0320 + 0.1055i
-0.0320 + 0.0894i
-0.0320 + 0.0773i
-0.0320 + 0.0677i
-0.0320 + 0.0599i
-0.0320 + 0.0534i
-0.0320 + 0.0479i
-0.0320 + 0.0431i
-0.0320 + 0.0390i
-0.0320 + 0.0353i
-0.0320 + 0.0320i
-0.0320 + 0.0290i
-0.0320 + 0.0263i
-0.0320 + 0.0237i
-0.0320 + 0.0214i
-0.0320 + 0.0192i
-0.0320 + 0.0171i
-0.0320 + 0.0151i
-0.0320 + 0.0133i
-0.0320 + 0.0114i
-0.0320 + 0.0097i
-0.0320 + 0.0080i
-0.0320 + 0.0064i
-0.0320 + 0.0047i
-0.0320 + 0.0032i
-0.0320 + 0.0016i
-0.0320
-0.0320 - 0.0016i
-0.0320 - 0.0032i
-0.0320 - 0.0047i
-0.0320 - 0.0064i
-0.0320 - 0.0080i
-0.0320 - 0.0097i
-0.0320 - 0.0114i
-0.0320 - 0.0133i
-0.0320 - 0.0151i
-0.0320 - 0.0171i
-0.0320 - 0.0192i
-0.0320 - 0.0214i
-0.0320 - 0.0237i
-0.0320 - 0.0263i
-0.0320 - 0.0290i
-0.0320 - 0.0320i
-0.0320 - 0.0353i
-0.0320 - 0.0390i
-0.0320 - 0.0431i
-0.0320 - 0.0479i
-0.0320 - 0.0534i
-0.0320 - 0.0599i
-0.0320 - 0.0677i
-0.0320 - 0.0773i
-0.0320 - 0.0894i
-0.0320 - 0.1055i
-0.0320 - 0.1278i
-0.0320 - 0.1609i
-0.0320 - 0.2157i
-0.0320 - 0.3249i
-0.0320 - 0.6514i
Please help me!! I'm totally confused.
Best
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a crazy problem with GNURadio fft
Excuse me all! That was my fault because previously I checked the FFTW with Matlab I did know its difference as Murcus mentioned. However, I suddenly suspect the FFTW again! Thank you so much On Tue, Aug 26, 2014 at 6:31 PM, Marcus Müller marcus.muel...@ettus.com wrote: Thanks Sylvain, not finding that drove me crazy (more crazy than usual); the zeroth element must be sum(range(fftlen))=(63+0)*(64/2) = 63*32 = 2048 - 32 = 2016, like in the matlab result, yet I did not find where the data stopped flowing... now, sum(range(fftlen/sizeof(gr_complex)))=sum(range(8))=(7+0)*8/2=28 explains that :) Also, Mostafa, you call your transform ifft, yet you set forward=true, which might be a bit confusing in the future. For the IFFT, Matlab does something different than the pure FFTW that GNU Radio uses: it divides by fft_size, compare [1] to [2]. Greetings, Marcus [1]http://www.mathworks.de/de/help/matlab/ref/fft.html [2] http://www.fftw.org/doc/The-1d-Discrete-Fourier-Transform-_0028DFT_0029.html#The-1d-Discrete-Fourier-Transform-_0028DFT_0029 On 26.08.2014 15:36, Sylvain Munaut wrote: memcpy(ifft-get_inbuf(), in, fft_size); fft_size * sizeof(gr_complex) ___ 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 -- *** Department of Electrical Engineering Aboureyhan Building MMWCL LAB Amirkabir University Of Technology Tehran IRAN Tel: +98 (919) 158-7730 LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411 Homepage: http://ele.aut.ac.ir/~alizadeh/ *** ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] adding controlPort to GNURadio tree
Hello all, I recently started to work with controlport because I think exploit its ability for my projetc. I found an example of grc using controlport at ***/gnuradio/gr-blocks/examples/ctrlport but it couldn't find the module ctrlport.monitor , so I think I didn't install controlport when I was trying to install GNURadio. How I could add controlport to this installed GNURadio? (may it seems silly question!!! ) Thanks in advance, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: Problem with large number of inputs.
-- Forwarded message --
From: Mostafa Alizadeh m.alizade...@gmail.com
Date: Mon, Jul 28, 2014 at 7:21 PM
Subject: Re: [Discuss-gnuradio] Problem with large number of inputs.
To: Activecat active...@gmail.com
Dear Activecat,
I run the whole GNURadio C++ codes in Qtcreator without any problem by
adding these lines to its .pro file:
LIBS += /usr/lib/libboost_signals.so\
/usr/lib/libboost_signals.so.1.48.0\
/usr/lib/libboost_system-mt.so\
/usr/lib/libboost_system.so\
/usr/lib/libboost_system.so.1.48.0\
/usr/lib/libboost_thread-mt.so\
/usr/lib/libboost_thread.so\
/usr/lib/libboost_thread.so.1.48.0\
/usr/lib/libboost_timer-mt.so\
/usr/lib/libboost_timer.so\
-L/usr/local/lib -lgnuradio-audio -lgnuradio-runtime -lgnuradio-pmt
-lgnuradio-blocks -lgnuradio-filter
LIBS+= -L/usr/local/lib -lgnuradio-analog -lgnuradio-runtime
-lgnuradio-pmt -lgnuradio-audio -lgnuradio-blocks -lgnuradio-filter
LIBS+=-lboost_system -lboost_thread-mt -lboost_thread
-lboost_filesystem-mt -lboost_filesystem -lgnuradio-qtgui
-lgnuradio-fft
LIBS += -lfftw3f -lfftw3 \
I didn't reveal the big picture because I thought I doesn't help to
figure out the problem :)
I finally found the problem! That was so hard to me to do so! I
suddenly recognized that the proceeding block which is connected to
input ports of this block , have a problem and that is, I set the item
sizes of the previous blocks output as gr_complex but in its work
function I set the pointer to the ouput_items as byte instead of
gr_complex!!!
Anyway, I have to thank all of you following my questions sincerely.
Best,
Mostafa
On Mon, Jul 28, 2014 at 8:46 AM, Activecat active...@gmail.com wrote:
Mostafa,
I do not think you have truly run the complete codes using Qtcreator,
because that doesn't have a gnuradio runtime (the scheduler).
At the other hand, your problem sounds more like a c++ coding error rather
than gnuradio-specific.
The helpful approach is
1). Put up the OOT into github.
This should be the simplest but complete OOT.
2). Provide a big picture of what you try to accomplish.
From experience many amateur programmers write codes wrong from the
ground up, and yet expect others to troubleshoot.
When this happens, the only way to help is to start with the big
picture of what you wish to accomplish.
From previous experience you refused to reveal the big picture but
emphasize others to look at your existing buggy codes.
Please be reminded that this is an open forum and nobody get paid for
helping you.
On Mon, Jul 28, 2014 at 7:39 AM, Mostafa Alizadeh m.alizade...@gmail.com
wrote:
I forgot to say, I'm using Qtcreator to debug my GNURadio codes I do not
need any others!
The prgram is terminated at line in which I read from the input for the
first time i.e. :
y_p[i][k] = 0;
for (int j=0; jN_FS_phich(d_normal_cp); j++)
{
y_p[i][k] = y_p[i][k] + in[i*8+j][k];
}
Best,
On Mon, Jul 28, 2014 at 4:05 AM, Mostafa Alizadeh m.alizade...@gmail.com
wrote:
Yes you're right about casting between in and input_items, however,
I think this problem is somehow related to the large number input ports! I
don't why!
Here is the whole block:
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include gnuradio/io_signature.h
#include phich_grouping_impl.h
int N_FS_phich(bool normal_cp){
if(normal_cp)
return 8;
else
return 4;
}
namespace gr {
namespace my {
phich_grouping::sptr
phich_grouping::make(bool normal_cp, int N_phich_group)
{
return gnuradio::get_initial_sptr
(new phich_grouping_impl(normal_cp, N_phich_group));
}
/*
* The private constructor
*/
phich_grouping_impl::phich_grouping_impl(bool normal_cp, int
N_phich_group)
: gr::block(phich_grouping,
gr::io_signature::make(N_phich_group *
N_FS_phich(normal_cp), N_phich_group * N_FS_phich(normal_cp) ,
sizeof(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
d_normal_cp(normal_cp),
d_N_phich_group(N_phich_group)
{
set_tag_propagation_policy(TPP_DONT);
}
/*
* Our virtual destructor.
*/
phich_grouping_impl::~phich_grouping_impl()
{
}
void
phich_grouping_impl::forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
for (int i=0; id_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
ninput_items_required[i] = 12;
}
}
int
phich_grouping_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
gr_complex *out
Re: [Discuss-gnuradio] Problem with large number of inputs.
Thank you for your notes Marcus,
As you said this is unnecessary process to point to the input_items in a
for loop!!
However, this is not the problem because I checked that I have the same
number of iteration in the for loop as the number of input ports.
The problem is somewhere else. *Again I must mention that if I use, only 8
input ports, the code runs perfectly,* however, with 24 inputs, it does
something wrong! (perhaps pointing to somewhere in the memory which is not
allocated to the input as it seemed to allocated to the input!). In another
words, when I want to access the first input of the first input port, I can
write:
gr_complex **in = (gr_complex) input_items;
// for example
cout in[0][0] endl;
The program terminated with unexpected error!
Please help me, where is the problem?? :(
On Sun, Jul 27, 2014 at 4:21 AM, Marcus Müller marcus.muel...@ettus.com
wrote:
Having your complete general_work function wouldn't have hurt my
understanding much...
I really can't make out what you're trying to do without doubt.
Anyway, from the code below I think in *must at least* have the same
number of entries that your for loop has iterations; did you just try using
d_group * N_FS(d_normal) instead of d_N_phich_group *
N_FS_phich(d_normal_cp) when allocating your array?
It seems to me that having two ways to determine how many inputs there is
a likely cause for mistake. Use the size() of the input_items to determine
how many inputs you really have, and assert(input_items.size() ==
number_of_inputs_like_I_calculate_it); to make sure things line up.
Also, the whole process seems unnecessary, since you do nothing more than
copying the pointers from input_items to in; the typecast is nothing but
syntactic magic and can be done by having in = ((const gr_complex*)*)
input_items;; also, I encourage you to use the C++-style explicit cast
operators (in this case, reinterpret_cast) for their clarity, but that's
more a question of personal liking :)
Greetings,
Marcus
On 26.07.2014 21:55, Mostafa Alizadeh wrote:
Hi Marcus,
You're right. I didn't clarify the problem.
Actually in C++, I wrote:
block_impl::block_impl(bool normal, int group)
: gr::block(phich_grouping,
gr::io_signature::make(1, group * N_FS(normal), sizeof
(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
// N_FS function returns 8 or 4 depends on its input.
// in the work function :
// d_normal and d_group are defined in the .h file
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
for (int i=0; id_group * N_FS(d_normal); i++)
{
in[i] = (const gr_complex *) input_items[i];
}
when I set the group value to 3, the number of input ports would be 24.
In this case, I want to access to one element of in like this:
cout in in[0][0] endl;
I got the aforementioned error!
But when I set group = 1 which means 8 input ports, all things are
fine.
any idea please,
Best
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with large number of inputs.
Yes you're right about casting between in and input_items, however, I
think this problem is somehow related to the large number input ports! I
don't why!
Here is the whole block:
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include gnuradio/io_signature.h
#include phich_grouping_impl.h
int N_FS_phich(bool normal_cp){
if(normal_cp)
return 8;
else
return 4;
}
namespace gr {
namespace my {
phich_grouping::sptr
phich_grouping::make(bool normal_cp, int N_phich_group)
{
return gnuradio::get_initial_sptr
(new phich_grouping_impl(normal_cp, N_phich_group));
}
/*
* The private constructor
*/
phich_grouping_impl::phich_grouping_impl(bool normal_cp, int
N_phich_group)
: gr::block(phich_grouping,
gr::io_signature::make(N_phich_group *
N_FS_phich(normal_cp), N_phich_group * N_FS_phich(normal_cp) ,
sizeof(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
d_normal_cp(normal_cp),
d_N_phich_group(N_phich_group)
{
set_tag_propagation_policy(TPP_DONT);
}
/*
* Our virtual destructor.
*/
phich_grouping_impl::~phich_grouping_impl()
{
}
void
phich_grouping_impl::forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
for (int i=0; id_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
ninput_items_required[i] = 12;
}
}
int
phich_grouping_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
gr_complex *out = (gr_complex *) output_items[0];
//in = (const gr_complex *) input_items;
cout n input input_items.size() endl;
int phich_in_len[d_N_phich_group];
int x = 0;
for (int i=0; id_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
in[i] = (const gr_complex *) input_items[i];
// reading tags
vectortag_t tag_len;
get_tags_in_window(tag_len,
0,
0,
ninput_items[0],
pmt::string_to_symbol(length));
if(tag_len.size()0)
{
phich_in_len[i] = pmt::to_long(tag_len[0].value);
x++;
}
}
gr_complex y_p[d_N_phich_group][12];
gr_complex y__p_tilt[d_N_phich_group/2][12];
//cout \tin[0][0] in[0][0] endl;
if (x == d_N_phich_group * N_FS_phich(d_normal_cp)) // x ==
d_N_phich_group) is for checking all the input tags are read
{
// grouping ...
for (int i=0; id_N_phich_group ;i++)
{
for (int k=0; kphich_in_len[i]; k++)
{
y_p[i][k] = 0;
for (int j=0; jN_FS_phich(d_normal_cp); j++)
{
y_p[i][k] = y_p[i][k] + in[i*8+j][k];
}
}
}
...
...
// adding tag
add_item_tag(0,
nitems_written(0),
pmt::string_to_symbol(length),
pmt::from_long(12));
cout PHICH grouping endl;
consume_each(12);
}
else
{ // if tags didn't read
produce(0, 0);
consume_each(0);
}
return WORK_CALLED_PRODUCE;
}
} /* namespace my */
} /* namespace gr */
Input to this block is a random source and its output is a file sink. I
would be glad to see the comments on the code to improve it also finding
the problem.
Best,
Mostafa Alizadeh
On Sun, Jul 27, 2014 at 10:10 PM, Marcus Müller marcus.muel...@ettus.com
wrote:
As I said, you should use the gdb debugging approach to find the mistake.
gr_complex **in = (gr_complex) input_items; shouldn't compile, because
the types are incompatible.
I can't help you any further with the information you're offering.
Please share at least your complete general_work method, and the methods
that you use to calculate the input numbers. I stand by my opininion
that beauty lies in simplicity. If you want to make sure you don't do
more for iterations than you have inputs, iterate over the number of
inputs (input_items.size()) and not something you calculate yourself.
That's the simple approach of eliminating error sources.
Also, you're using a gr::block. If you play around with the forecast
method, you might trigger situations where you are asked to produce a
number of output items on different output streams, and have zero input
items on some input streams; I don't see you check
Re: [Discuss-gnuradio] Problem with large number of inputs.
I forgot to say, I'm using Qtcreator to debug my GNURadio codes I do not
need any others!
The prgram is terminated at line in which I read from the input for the
first time i.e. :
y_p[i][k] = 0;
for (int j=0; jN_FS_phich(d_normal_cp); j++)
{
y_p[i][k] = y_p[i][k] + in[i*8+j][k];
}
Best,
On Mon, Jul 28, 2014 at 4:05 AM, Mostafa Alizadeh m.alizade...@gmail.com
wrote:
Yes you're right about casting between in and input_items, however, I
think this problem is somehow related to the large number input ports! I
don't why!
Here is the whole block:
#ifdef HAVE_CONFIG_H
#include config.h
#endif
#include gnuradio/io_signature.h
#include phich_grouping_impl.h
int N_FS_phich(bool normal_cp){
if(normal_cp)
return 8;
else
return 4;
}
namespace gr {
namespace my {
phich_grouping::sptr
phich_grouping::make(bool normal_cp, int N_phich_group)
{
return gnuradio::get_initial_sptr
(new phich_grouping_impl(normal_cp, N_phich_group));
}
/*
* The private constructor
*/
phich_grouping_impl::phich_grouping_impl(bool normal_cp, int
N_phich_group)
: gr::block(phich_grouping,
gr::io_signature::make(N_phich_group *
N_FS_phich(normal_cp), N_phich_group * N_FS_phich(normal_cp) ,
sizeof(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
d_normal_cp(normal_cp),
d_N_phich_group(N_phich_group)
{
set_tag_propagation_policy(TPP_DONT);
}
/*
* Our virtual destructor.
*/
phich_grouping_impl::~phich_grouping_impl()
{
}
void
phich_grouping_impl::forecast (int noutput_items, gr_vector_int
ninput_items_required)
{
for (int i=0; id_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
ninput_items_required[i] = 12;
}
}
int
phich_grouping_impl::general_work (int noutput_items,
gr_vector_int ninput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
gr_complex *out = (gr_complex *) output_items[0];
//in = (const gr_complex *) input_items;
cout n input input_items.size() endl;
int phich_in_len[d_N_phich_group];
int x = 0;
for (int i=0; id_N_phich_group * N_FS_phich(d_normal_cp); i++)
{
in[i] = (const gr_complex *) input_items[i];
// reading tags
vectortag_t tag_len;
get_tags_in_window(tag_len,
0,
0,
ninput_items[0],
pmt::string_to_symbol(length));
if(tag_len.size()0)
{
phich_in_len[i] = pmt::to_long(tag_len[0].value);
x++;
}
}
gr_complex y_p[d_N_phich_group][12];
gr_complex y__p_tilt[d_N_phich_group/2][12];
//cout \tin[0][0] in[0][0] endl;
if (x == d_N_phich_group * N_FS_phich(d_normal_cp)) // x ==
d_N_phich_group) is for checking all the input tags are read
{
// grouping ...
for (int i=0; id_N_phich_group ;i++)
{
for (int k=0; kphich_in_len[i]; k++)
{
y_p[i][k] = 0;
for (int j=0; jN_FS_phich(d_normal_cp); j++)
{
y_p[i][k] = y_p[i][k] + in[i*8+j][k];
}
}
}
...
...
// adding tag
add_item_tag(0,
nitems_written(0),
pmt::string_to_symbol(length),
pmt::from_long(12));
cout PHICH grouping endl;
consume_each(12);
}
else
{ // if tags didn't read
produce(0, 0);
consume_each(0);
}
return WORK_CALLED_PRODUCE;
}
} /* namespace my */
} /* namespace gr */
Input to this block is a random source and its output is a file sink. I
would be glad to see the comments on the code to improve it also finding
the problem.
Best,
Mostafa Alizadeh
On Sun, Jul 27, 2014 at 10:10 PM, Marcus Müller marcus.muel...@ettus.com
wrote:
As I said, you should use the gdb debugging approach to find the mistake.
gr_complex **in = (gr_complex) input_items; shouldn't compile, because
the types are incompatible.
I can't help you any further with the information you're offering.
Please share at least your complete general_work method, and the methods
that you use to calculate
[Discuss-gnuradio] Problem with large number of inputs.
Hi all, I've used to have a block with large number of inputs, say 24, but I think GNURadio has a problem with memory allocation because when I use the block it's suddenly jump out of the program with The program has unexpectedly finished. (the above message isn't for GNURadio) However, when I decrease the number of inputs to 8, it's fine and works properly! This is so strange to me. Any idea? Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with large number of inputs.
Hi Marcus,
You're right. I didn't clarify the problem.
Actually in C++, I wrote:
block_impl::block_impl(bool normal, int group)
: gr::block(phich_grouping,
gr::io_signature::make(1, group * N_FS(normal), sizeof
(gr_complex)),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
// N_FS function returns 8 or 4 depends on its input.
// in the work function :
// d_normal and d_group are defined in the .h file
const gr_complex *in[d_N_phich_group * N_FS_phich(d_normal_cp)];
for (int i=0; id_group * N_FS(d_normal); i++)
{
in[i] = (const gr_complex *) input_items[i];
}
when I set the group value to 3, the number of input ports would be 24.
In this case, I want to access to one element of in like this:
cout in in[0][0] endl;
I got the aforementioned error!
But when I set group = 1 which means 8 input ports, all things are fine.
any idea please,
Best
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio dataflow, buffering and scheduling
Hello all, Yeah, I also think this topic is interesting to find out this vague and unclear scheduler! I'm waiting for further discussions. Best, Mostafa On Thu, Jul 24, 2014 at 5:50 PM, Leonardo S. Cardoso leo...@gmail.com wrote: Hello everyone, I've been asking the same questions as Anh, since we have a PhD student working on dataflow programming, specifically for GNU Radio. I think this discussion can benefit a lot of people who work with dataflow, but also the rest of us, who just want to understand what's going on under the hood. Maybe, one day we can compile all questions and answers into a nice formatted document that will serve as a reference for the rest of us... :) Best regards, Leo Leonardo S. Cardoso leo...@gmail.com On Thu, Jul 24, 2014 at 3:55 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Jul 24, 2014 at 2:56 AM, Marcus Müller marcus.muel...@ettus.com wrote: Hi! On 24.07.2014 05:22, Anh Duc Nguyen wrote: To be honest, I am studying software structures/platform for software defined radio (SDR), of which, the scheduler is one of the most crucial that I wish to analyze in detail; and in turn, gnuradio scheduler for sure draws much of my attention due to it success and popularity. I hope I could receive more support and help from you all That sounds really interesting! I think there will be lots of interest in that, so keep the questions coming :) Greetings, Marcus It does sound interesting, and Nathan West pointed out a good place to start researching this. I agree with Marcus to keep the questions coming. However, I would add that it would be better served for all of us here if you had very focused questions that we could talk about. Open ended questions like how does the scheduler work would require a lot of time to construct an answer; time that very few of us have. But a conversation like this done with the right questions could eventually turn into a nice set of discussion topics that could then be turned into something more substantive for others looking at the same questions. Tom With best regards, Nguyen Anh Duc On Thu, Jul 24, 2014 at 12:51 AM, Marcus Müller marcus.muel...@ettus.com marcus.muel...@ettus.com wrote: Hi Anh, in addition to what Nathan explained very nicely, I'd like to point out that the GNU Radio scheduler is not a static thing, it's actively being worked on. Whilst the buffer architecture dates back quite a while, things like message passing and the associated asynchronous communication between blocks are fairly new. Also, you have to realize that there were several approaches to scheduling of GNU Radio blocks over the time -- right now, it seems that GNU Radio has largely settled for the Thread-Per-Block scheduler, that has one block_executors per block that itself runs in a thread of its own. You asked: Could you please provide me with some relevant or supplement readings to that presentation? I would grateful for it. I think since you have your very own level of understanding, your very own background in data processing and scheduling, and your very own interest in details, there will be no way around reading at least block_executor and some of the tpb_ stuff in detail, with a big piece of paper/whiteboard at hand and trying to understand these concepts yourself. Although scheduling is always a bit of a convoluted task, I find the thread-per-block architecture fairly understandable, and the idea of blocks notifying their neighbors' threads when they have finished filling/reading a buffer quite intuitive. The details, however, like how the scheduler keeps record of the flowgraph, how GNU Radio allocates and manages the circular buffers, and what happens when you reconfigure a graph, are so specific, that it's hard to write a text about it that is shorter or easier to understand for the skilled reader than the code itself. I'm afraid that's the reason that only Tom (and maybe, in very simplifying attempts, some GSoC student[1]) has written relevant details on that. That being said, Explain what the scheduler does, so that beginners understand it and experts get an in-depth comprehension has been on the GNU Radio needs this list for as long as I've been meddling with GNU Radio -- and that's really not because no one else had this problem, but because it is a hard thing to understand and a harder thing to textually represent correctly. Greetings, Marcus [1]http://gsoc.hostalia.de/posts/a-measurement-toolbox-for-gnu-radio-my-google-summer-of-code-project.html#evaluating-block-performance but that barely scratches the subject On 23.07.2014 18:37, Anh Duc Nguyen wrote: Thank Vanush, I have read this presentation already; unfortunately, I found it rather hard to draw an overall picture of gnuradio scheduler to some extent of details. Perhaps, as Tom said on his webpage
Re: [Discuss-gnuradio] Error creating block with different input signature
Hi,
I don't know why you have a problem with this!
Just take a look at* fll_band_edge_cc_impl.cc* in the GNURadio tree :
.../gnuradio-3.7.3/gr-digital/lib/
Also see its grc in: .../gnuradio-3.7.3/gr-digital/grc
Best,
Mostafa
On Sun, Jun 8, 2014 at 6:02 PM, sarankumar saran...@gmail.com wrote:
Hi,
I am trying to create a C++ block with different input signatures in each
of the inputs.I tried the following 2 methods.
1) I followed the example in pfb_clock_sync_ccf and created the io
signature as:
static int ios[] = {sizeof(gr_complex)*8, sizeof(float), sizeof(float),
sizeof(float)};
static std::vectorint iosig(ios, ios+sizeof(ios)/sizeof(int));
beamforming_sum_vcc_impl::beamforming_sum_vcc_impl(int num_channels)
: gr::sync_block(beamforming_sum_vcc,
gr::io_signature::makev(1,4, iosig),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
N(num_channels)
2) I also tried the method suggested in earlier posts.
static vectorint get_input_sizes(){
std::vectorint input_sizes;
input_sizes.push_back(sizeof(gr_complex)*8);
input_sizes.push_back(sizeof(gr_complex));
input_sizes.push_back(sizeof(gr_complex));
input_sizes.push_back(sizeof(gr_complex));
return input_sizes;
}
beamforming_sum_vcc_impl::beamforming_sum_vcc_impl(int num_channels)
: gr::sync_block(beamforming_sum_vcc,
gr::io_signature::makev(1,4,get_input_sizes()),
gr::io_signature::make(1, 1, sizeof(gr_complex))),
N(num_channels)
In both the cases I am getting the following error when doing the makexml
process.
Any help?
Error: Can't parse input signature.
Traceback (most recent call last):
File ./gr_modtool, line 47, in module
main()
File ./gr_modtool, line 39, in main
modtool.run()
File
/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/modtool_makexml.py,
line 67, in run
self._make_grc_xml_from_block_data(params, iosig, blockname)
File
/usr/local/lib/python2.7/dist-packages/gnuradio/modtool/modtool_makexml.py,
line 91, in _make_grc_xml_from_block_data
if iosig[inout]['max_ports'] == '-1':
KeyError: 'in'
thanks,
Saran
___
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] a criticism to GNURadio's scheduler!
Hi, I worked on GNURadio for many hours. After all, I prepared my blocks in c++. However, the source by which I produce random bits (items with sizeof(char) ) doesn't work properly! By properly I mean, I wanted GNURadio to lead me control how it's going to call the *source.* It's crazily calling the random bit generator so many times. I think this is because of the GNURadio's strategy for executing blocks to achieve as maximum throughput as possible! So GNURadio translates it* to call the source as much as possible*.(no matter what is the source, here is the random bit generator) Am I right? If I am, what is the solution? Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a criticism to GNURadio's scheduler!
Hi Mike, No, the throttle isn't a source! It just controls the flow of items in an specific time interval. I don't want this! I want cognitively tell the source produces the random bits after some special procedures have done (a message can do this for the source). But the scheduler crazily wants the source to produce items! :) How could I deal with this problem? please. Best, On Sun, Jun 1, 2014 at 1:18 PM, Mike Jameson mike.jame...@ettus.com wrote: The Throttle block is required if you are not using any external hardware: http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1throttle.html Mike -- Mike Jameson M0MIK BSc MIET Ettus Research Technical Support Email: supp...@ettus.com Web: http://ettus.com On Sun, Jun 1, 2014 at 9:30 AM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hi, I worked on GNURadio for many hours. After all, I prepared my blocks in c++. However, the source by which I produce random bits (items with sizeof(char) ) doesn't work properly! By properly I mean, I wanted GNURadio to lead me control how it's going to call the *source.* It's crazily calling the random bit generator so many times. I think this is because of the GNURadio's strategy for executing blocks to achieve as maximum throughput as possible! So GNURadio translates it* to call the source as much as possible*.(no matter what is the source, here is the random bit generator) Am I right? If I am, what is the solution? Best, Mostafa ___ 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] a criticism to GNURadio's scheduler!
Hi Marcus,
By mentioning that I spent many hours I wanted to say I'm hardly stuck on
this problem yet! :)
You said the there is no problem that we wait on the source to produce as
long as we want! But this is not true when I have other blocks waiting for
processing!! In other word, when the source produces one packet, I want
this packet go down through blocks and amid of these blocks a message must
tells the source to produce again.
*If the source doesn't produce anything after generating some packets, the
scheduler will be locked on the source and does nothing with other blocks!!*
As you said, the *wait* will work for this source, but it's also has the
same problem I mentioned.
Here is the summary of *random bit generator:*
#include gnuradio/io_signature.h
#include stdlib.h
#include time.h
#include bitset
#include unistd.h
namespace gr {
namespace my_lte {
lte_random_bit_gen::sptr
lte_random_bit_gen::make(int packet_len) // packet_len: the size of
generating packet bits
{
return gnuradio::get_initial_sptr
(new lte_random_bit_gen_impl(packet_len));
}
/*
* The private constructor
*/
lte_random_bit_gen_impl::lte_random_bit_gen_impl(int packet_len)
: gr::sync_block(lte_random_bit_gen,
gr::io_signature::make(0, 0, 0),
gr::io_signature::make(1, 1, sizeof(char))),
packet_length(packet_len),
{
srand (time(NULL)); // randomizing the seed
set_max_noutput_items(packet_length);
}
lte_random_bit_gen_impl::~lte_random_bit_gen_impl()
{
}
int
lte_random_bit_gen_impl::work(int noutput_items,
gr_vector_const_void_star input_items,
gr_vector_void_star output_items)
{
char *out = (char *) output_items[0];
int random_val, nout_written = 0;
for (int i=0; ipacket_length; i++)
{
random_val = rand();
bitset8 b(random_val);
if (b[0] == 0)
*out = 1;
else
*out = 0;
out++;
nout_written++;
}
// add tag
add_item_tag(0,
nitems_written(0),
pmt::string_to_symbol(length),
pmt::from_long(packet_length));
cout bit generator endl ;
return nout_written;
}
On Sun, Jun 1, 2014 at 1:43 PM, Marcus Müller marcus.muel...@ettus.com
wrote:
Mostafa,
I know you've been working many hours on this :) so don't worry, you're
being heard.
Nevertheless, GNU Radio is surely not calling the asking the source
crazily to produce items.
GNU Radio is a streaming-into-buffers architecture, which means that the
runtime will ask a source to produce output when there is space in the
output buffer. I fail to see the problem with this, since your source
can just take as much time as it wants to finish a work call, can
produce less than noutput_items, and generally should just be as fast as
it could. Not a single one of the items it produced is going to waste!
It is good practice and done by *every* externally rate-limited source
to just block in work until enough items can be produced. If you need to
wait to get more random seed, well, then wait in work(). I admit, that
gets a little tricky when you want your seed to come in using a message,
because messages are not going to disturb your work due to design for
thread-safety.
But then again, before I start proposing wait-notify/condition
multithreading methods, I'd like to hear a bit about your source and why
being called often is a problem; that's usually not the case, so chances
are we might help you find a solution if we understood what's wrong with
your source ;)
Greetings,
Marcus
On 01.06.2014 10:56, Mostafa Alizadeh wrote:
Hi Mike,
No, the throttle isn't a source! It just controls the flow of items in an
specific time interval. I don't want this! I want cognitively tell the
source produces the random bits after some special procedures have done
(a
message can do this for the source). But the scheduler crazily wants the
source to produce items! :)
How could I deal with this problem?
please.
Best,
On Sun, Jun 1, 2014 at 1:18 PM, Mike Jameson mike.jame...@ettus.com
wrote:
The Throttle block is required if you are not using any external
hardware:
http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1throttle.html
Mike
--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://ettus.com
On Sun, Jun 1, 2014 at 9:30 AM, Mostafa Alizadeh
m.alizade...@gmail.com
wrote:
Hi,
I worked on GNURadio for many hours. After all, I prepared my blocks in
c++. However, the source by which I produce random bits (items with
sizeof(char) ) doesn't work properly! By properly I mean, I wanted
GNURadio
to lead me control
Re: [Discuss-gnuradio] a criticism to GNURadio's scheduler!
Hi Marcus, On Sun, Jun 1, 2014 at 2:44 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Mostafa, You said the there is no problem that we wait on the source to produce as long as we want! But this is not true when I have other blocks waiting for processing!! Not true. If your block can't produce something, it's not GNU Radio's fault your downstream blocks don't have anything to consume... This is not true because when I produce 1-3 packet of bits, the scheduler doesn't go to the other blocks while there is items for them! The scheduler calls the random bit generator for about 10 times!! In other word, when the source produces one packet, I want this packet go down through blocks and amid of these blocks a message must tells the source to produce again. This sounds like a bad design choice, why would a downstream block need to tell the source to produce again? I think we might have tried to convince you not to do this before, but I just can't find the thread where you describe your problem. I think you're right. I would control something somewhere else. :) If the source doesn't produce anything after generating some packets, the scheduler will be locked on the source and does nothing with other blocks!! Exactly. If your source doesn't produce anything, your downstream blocks can't consume anything -- there's nothing GNU Radio could do about this. I'm fairly certain that GNU Radio will not stall a flow graph if there is more than zero unprocessed items in the buffers. Haven't tested that, though. Maybe someone else might comment on this. So you have a logical deadlock, not a GNU Radio problem, if I understand you correctly. As you said, the *wait* will work for this source, but it's also has the same problem I mentioned. Sorry, still don't undertand which problem you are writing about :( I've read your code. There's absolutely no reason why the standard behaviour of GNU Radio filling the output buffer of your source wouldn't work -- these are pseudorandom numbers, and there's absolutely no difference between generating e.g. 8192 at once and producing them one at a time. Greetings, Marcus Müller marcus.muel...@ettus.com wrote: Mostafa, I know you've been working many hours on this :) so don't worry, you're being heard. Nevertheless, GNU Radio is surely not calling the asking the source crazily to produce items. GNU Radio is a streaming-into-buffers architecture, which means that the runtime will ask a source to produce output when there is space in the output buffer. I fail to see the problem with this, since your source can just take as much time as it wants to finish a work call, can produce less than noutput_items, and generally should just be as fast as it could. Not a single one of the items it produced is going to waste! It is good practice and done by *every* externally rate-limited source to just block in work until enough items can be produced. If you need to wait to get more random seed, well, then wait in work(). I admit, that gets a little tricky when you want your seed to come in using a message, because messages are not going to disturb your work due to design for thread-safety. But then again, before I start proposing wait-notify/condition multithreading methods, I'd like to hear a bit about your source and why being called often is a problem; that's usually not the case, so chances are we might help you find a solution if we understood what's wrong with your source ;) Greetings, Marcus On 01.06.2014 10:56, Mostafa Alizadeh wrote: Hi Mike, No, the throttle isn't a source! It just controls the flow of items in an specific time interval. I don't want this! I want cognitively tell the source produces the random bits after some special procedures have done (a message can do this for the source). But the scheduler crazily wants the source to produce items! :) How could I deal with this problem? please. Best, On Sun, Jun 1, 2014 at 1:18 PM, Mike Jameson mike.jame...@ettus.com wrote: The Throttle block is required if you are not using any external hardware: http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1throttle.html Mike -- Mike Jameson M0MIK BSc MIET Ettus Research Technical Support Email: supp...@ettus.com Web: http://ettus.com On Sun, Jun 1, 2014 at 9:30 AM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hi, I worked on GNURadio for many hours. After all, I prepared my blocks in c++. However, the source by which I produce random bits (items with sizeof(char) ) doesn't work properly! By properly I mean, I wanted GNURadio to lead me control how it's going to call the *source.* It's crazily calling the random bit generator so many times. I think this is because of the GNURadio's strategy for executing blocks to achieve as maximum throughput as possible! So GNURadio
Re: [Discuss-gnuradio] a criticism to GNURadio's scheduler!
Activecat, I think change my topology to get rid of this things. :) However, I still believe in that the GNURadio fails in this scenario. As we have throttle or message_strobe blocks, I need to have a source which generates items controlled by another block. I'll try to see this problem in another way to escape from it! On Sun, Jun 1, 2014 at 3:13 PM, Activecat active...@gmail.com wrote: On Sun, Jun 1, 2014 at 4:56 PM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hi Mike, No, the throttle isn't a source! It just controls the flow of items in an specific time interval. I don't want this! I want cognitively tell the source produces the random bits after some special procedures have done (a message can do this for the source). But the scheduler crazily wants the source to produce items! :) Mostafa, Why not you tell us what you are trying to accomplish using this flowgraph (not this block). Give us a big picture of what you try to accomplish, let us figure out the implementation details for you. Chances are there is no problem with gnuradio but with your knowledge about gnuradio. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] run a top block within a block!
Hi GNURadiores, I was thinking about how to change dynamically the blocks connected in my top block when it's running! After a long time, I reach to this point that I may have a top block is running within *a block*! (Also another top block runs* the block* itself. is that possible? If it is, I could change the top block which is in a block. Best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake problem
Thank you,
Yeah when I sent it, I remembered that I didn't send it to the mailing
list, excuse me.
OK, I'll find it.
On Sun, May 25, 2014 at 11:35 AM, Marcus Müller marcus.muel...@ettus.comwrote:
Hi Mostafa,
you've forgot to add the mailing list in your reply question; please
always remember to do that :)
My library is a package. I think I can find it with package config tool,
so
I don't need *Findsome_library.cmake.* Am I right?
Ok, this is getting too far away from GNU Radio. I'm referring you to
http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries
especially the introduction and the pkg-config related stuff on that page.
Hope that helps,
Greetings,
Marcus
On 25.05.2014 08:51, Mostafa Alizadeh wrote:
Thank you Marcus,
My library is a package. I think I can find it with package config tool,
so
I don't need *Findsome_library.cmake.* Am I right?
I didn't understand how could I obtain the the *variables *that pointing
to
the header files and to the linkable library as I need to add them in the
main cmake:
*include_directories(${library_include_dir})*
*link_directories(${library_dir})*
The same question is for lib/ directory cmake. What is the
name_of_library
in :
*target_link_libraries(${name_of_library})*
best,
Mostafa
On Sun, May 25, 2014 at 12:38 AM, Marcus Müller
marcus.muel...@ettus.comwrote:
Hi Mostafa,
first things first: If you're trying to use things from the GNU Radio
main
tree, refer to [1].
If you want to use external libraries, you will need to modify the
CMakeLists.txt in your module directory and in your lib/ directory.
In the main CMakeLists.txt you will find a paragraph starting with #
Find
*** build dependencies; after that you'll see lines like
find_package(some_library); some_library matches a script
Findsome_library.cmake in the cmake/Modules subdirectory.
You might need to write your own, but most probably someone else has
already done that for you, and you can use his code.
This script will set some variables pointing to the header files and to
the linkable library; you will have to add these to the
include_directories(..) variable and link_directories(..), respectively.
In the lib/CMakeLists.txt, you will need to extend the variables of the
same names, and set the target_link_libraries accordingly (for both the
main library and the test).
To see a modern implementation of this with some interesting external
dependencies, maybe take a look at
http://git.osmocom.org/gr-fosphor/tree/ (CMakeLists.txt,
lib/CMakeLists.txt, cmake/Modules/) .
Greetings,
Marcus
[1]
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig
On 24.05.2014 17:25, Mostafa Alizadeh wrote:
Hi,
I want to ask these questions about how to write cmake lists when we
making
gr-xxx projects (modules) with gr_modtool:
1- How could I add dependencies of my project! For example I'm using a
c++
library in one of my gr block, so how could I tell cmake to check the
dependency? I read GNURadio tutorial :
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig
But it's confusing! (I'm using GNURadio 3.7.3)
2- How could I merge all of my gr-xxx modules to a single project with
with
which I could cmake all the modules and *making* them? This is like
GNURadio source file which one has to cmake, make, install all the gr
modules together.
I know I must use:
*add_subdirectory(gr-xxx) *
in cmake lists but what are the other changes?
best,
mostafa
___
Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://
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] noutput_items
Hi, I'm confused about what is the return value of the work function if I have multiple output ports? I use *produce()* method to determine how many items produced on each port, so what does it mean to return again a number from work if I produced different number of items for each output port?? best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] noutput_items
Thank you so much for your complete explanation. Just the term *maximally* and WORK_CALLED_PRODUCE works for me :) best, On Sun, May 25, 2014 at 12:50 PM, Marcus Müller marcus.muel...@ettus.comwrote: Hi Mostafa, a few things: 1. work() only is meaningful for sync and interpolator/decimator blocks; then, you always have a fixed relation between consumed and produced items, and you can't have a different number of output items on different ports. 2. noutput_items is the parameter of the work function that tells you how many items you can produce *maximally*. It's not the number you produced; in the (performance-wise) best case, you return noutput_items to tell that your block consumed and produced everything GNU Radio asked it to. If you produced less, you return exactly that amount. 3. When using produce(), you should return the special value WORK_CALLED_PRODUCE. 4. If you're having different output item numbers on different ports, you're bound to use a general block with general_work. Then you'll have to consume() at each input the amount of items that you've used and produce them at each output. Also, you should implement a forecast() method just to give GNU Radio an idea how many items you need on which input port if you have to produce a certain number of output items on different ports. 5. Most of the time, blocks described by 4. are complicated. I used to write blocks like that, but nowadays I rarely do, because the message port API of GNU Radio fits my designs' needs better, most of the time. When dealing with things that are basically packets of digitally modulated data, take a look at the Tagged Stream / PDU infrastructure as described in the GNU Radio doxygen. 6. I've seen some screenshots of defunctional flowgraphs where the developer tried to implement correction loops (e.g. phase correction loop) by outputting an error/correction estimate on one output port and the corrected samples on the other, feeding back the correction to a multiplier upstream. Don't fall into that trap! In GNU Radio, you can't have sample loops, since this violates causality requirements (a block can't produce output without input, but within a loop there is no input without output). Just mentioning this because it can lead to a lot of frustration ;) Greetings, Marcus ___ 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] cmake problem
Hi, I want to ask these questions about how to write cmake lists when we making gr-xxx projects (modules) with gr_modtool: 1- How could I add dependencies of my project! For example I'm using a c++ library in one of my gr block, so how could I tell cmake to check the dependency? I read GNURadio tutorial : http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModulesConfig But it's confusing! (I'm using GNURadio 3.7.3) 2- How could I merge all of my gr-xxx modules to a single project with with which I could cmake all the modules and *making* them? This is like GNURadio source file which one has to cmake, make, install all the gr modules together. I know I must use: *add_subdirectory(gr-xxx) * in cmake lists but what are the other changes? best, mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] put a block to sleep
Hello everybody, I want to connect a source to a sink block but there must be a sort of synchronization between them. The sink block should ask the source to generate data stream on some specific instances. Between these instances, the source block must put to the sleep or be disabled. How could I do this? I thought it was possible with exchanging messages between these two blocks by which the sink block send a message to the source to disable or enable it. But this doesn't work because the scheduler will remain on the source after generating only one block of data (I need to generate just one block) at the start up of the flowgraph! best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] put a block to sleep
Hi Martin, *blocks.head* isn't appropriate for my case because this is not a test! I searched for managing a thread, I found this : http://www.boost.org/doc/libs/1_48_0/doc/html/thread/synchronization.html#thread.synchronization.condvar_ref which is a part of boost library. This is exactly what I want, but I don't know how I could use these classes in GNURadio!? The message passing mechanisms in GNURadio needs a block to be alive(as far as I know), but here I think I should put the block ( or the thread) to sleep and wake it up by a signal. On Wed, May 21, 2014 at 5:23 PM, Martin Braun martin.br...@ettus.comwrote: On 21.05.2014 11:53, Mostafa Alizadeh wrote: Hello everybody, I want to connect a source to a sink block but there must be a sort of synchronization between them. The sink block should ask the source to generate data stream on some specific instances. Between these instances, the source block must put to the sleep or be disabled. How could I do this? I thought it was possible with exchanging messages between these two blocks by which the sink block send a message to the source to disable or enable it. But this doesn't work because the scheduler will remain on the source after generating only one block of data (I need to generate just one block) at the start up of the flowgraph! If you just need one block, you can use blocks.head. To keep your block alive, you can use a heartbeat message: Give your block another message port, and use the message strobe to send it messages every N ms. Once it's alive, you can figure out if you need your source to send more data. M ___ 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] put a block to sleep
It doesn't work for me! On Wed, May 21, 2014 at 7:21 PM, Activecat active...@gmail.com wrote: Try this: On the flowgraph Options, configure the Max Number Of Output to 1. On Wed, May 21, 2014 at 9:54 PM, Mostafa Alizadeh m.alizade...@gmail.comwrote: *After producing one block of data,* the scheduler always come back to the source block if the source doesn't produce anything and the scheduler doesn't see any other blocks!!! (I don't know why) I didn't say I just want one block of data, I meant I need to mandate the source and tell it when produce data. please help me! :( best, Mostafa On Wed, May 21, 2014 at 3:18 PM, Activecat active...@gmail.com wrote: On Wed, May 21, 2014 at 5:53 PM, Mostafa Alizadeh m.alizade...@gmail.com wrote: Hello everybody, I want to connect a source to a sink block but there must be a sort of synchronization between them. The sink block should ask the source to generate data stream on some specific instances. Between these instances, the source block must put to the sleep or be disabled. How could I do this? The scheduler takes care of this. You don't need to worry this. I thought it was possible with exchanging messages between these two blocks by which the sink block send a message to the source to disable or enable it. But this doesn't work because the scheduler will remain on the source after generating only one block of data (I need to generate just one block) at the start up of the flowgraph! If you just need to generate only one block of data (one element), then you may not need 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] Facebook
Hi Martin, I must explain more about the page in order to avoid these questions. However, I'm gonna clarify. First of all, I didn't know you have similar page of GNURadio on Facebook before and I don't know why the people didn't pay attention to that. Secondly, I don't want to distract you from the mailing list, as you said there is the most attention. This is enough to have only one location for discussions and here is the best as I found. I just want to propagate GNURadio ideas and its news etc. (as a mean to attract more people). Thirdly, as you mentioned, I have to do much on this page to make it up to date from time to time. However, I may do not have enough time to do so. Currently I'm looking for someone to help me on this. Fourthly, I called the page GNURadio as it is. I also care about its verification. This is page isn't verified by Facebook. If it was verified by an original publisher, a sign of blue tick must be appeared next to the name of the page, take a look at ted page https://www.facebook.com/TED. I know if the page isn't designed carefully and interesting, it would harm the picture of GNURadio too. *For your questions:* # I just can decide on my status quo and now I can say that I handle the page but the future isn't deterministic for me. # I believe in that this page will absolutely attract more people to GNURadio. On Tue, May 20, 2014 at 5:57 PM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, as a single, small, sometimes lost, developer, I ask you: please don't open side channels on your own. A lot of us have been around this mailing list for a very long time, and we try to keep information as concentrated as possible. Already now we see a lot of people following tutorials from more-or-less dubious, most of the time totally outdated websites. We should really try to keep gnuradio.org the official page for all information on GNU Radio. I don't see why anyone of the official core team should try to update a facebook page with release info etc, if there is no question that this information can and should be found in gnuradio.org; I think you might have gone a little to far promising constant updates. Also, there's a lively community around GNU Radio, and things like conference announcements never go unnoticed on the discuss-gnuradio mailing list, so I really don't see the demand for a more communicative platform. In fact, the mailing list, the #gnuradio on freenode, the github page, the gnuradio.org wiki and of course the regular hangouts as much as conferences and hackfests are so much communication that it actually amounts to a fair amount of work to keep up with all the information exchanged. All in all, facebook is really a terrible platform for discussion if you want to make information well-searchable, well documented, self-organized; the average time until a post on the mailing list goes answered is in the order of hours; as a lot of the community earns its money with software radio related occupations, I doubt the frequency of qualified answers on facebook would ever be as high as on the mailing list. Greetings, Marcus On 20.05.2014 07:05, Mostafa Alizadeh wrote: Hi everybody, To be more communicative, we'v designed a page of GNURadio on facebook https://www.facebook.com/gnuradiodeveloper This page specially is for GNURadio developers who are following GNURadio ecosystem: ? new releases of GNURadio, ? new products of GNURadio, ? GNURadio conferences and events, ? new GNURadio-related projects and anything else related to GNURadio. We're looking for administrators for helping us on this page. Every volunteer Mail me. best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTe1hDAAoJEBQ6EdjyzlHtT5QH/1x9pBE7tQS8qBj2pSK9zyPk ktT0iCPA40lSrMsyvzjl1+JKsS8X4p9W79PQyFGtRf42g5wTjUSr0XeGGJLIZcoZ r4asiV0GFc68bbnXMVkrUYkq46wXcrm/lT66rdKbb6WgVy6SyAllyXFVHmO6/xS7 uU/k0aGO5izYlDNPNDyXjgiZ54Qpj6ySXADLaKa7tbSRkfRsUktUv/zXaNehHHGV wSn4QlCHNXUQkN09ARgTyGIQlfWnolO++ENTjeqfKQKvJrN5BtgcELPY+N+Xq4zs DACuK9VooXYtm5TQDJ3K4fObe53bziM6gGkQU1dCEcEoTklF4SRM9+37Q+ZGhDU= =r6Yx -END PGP SIGNATURE- ___ 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] Facebook
Hi dear Marcus, I didn't really want to move attention from here to other places! The GNURadio website didn't constructed informative. I mean any updates to the website do not appear for GNURadio followers. At least one of the Facebook advantages is its real-time interactions and communications. I'm not gonna compare this page with this mailing list, however, Facebook let more people engages in GNURadio. best, Mostafa On Tue, May 20, 2014 at 5:57 PM, Marcus Müller mar...@hostalia.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, as a single, small, sometimes lost, developer, I ask you: please don't open side channels on your own. A lot of us have been around this mailing list for a very long time, and we try to keep information as concentrated as possible. Already now we see a lot of people following tutorials from more-or-less dubious, most of the time totally outdated websites. We should really try to keep gnuradio.org the official page for all information on GNU Radio. I don't see why anyone of the official core team should try to update a facebook page with release info etc, if there is no question that this information can and should be found in gnuradio.org; I think you might have gone a little to far promising constant updates. Also, there's a lively community around GNU Radio, and things like conference announcements never go unnoticed on the discuss-gnuradio mailing list, so I really don't see the demand for a more communicative platform. In fact, the mailing list, the #gnuradio on freenode, the github page, the gnuradio.org wiki and of course the regular hangouts as much as conferences and hackfests are so much communication that it actually amounts to a fair amount of work to keep up with all the information exchanged. All in all, facebook is really a terrible platform for discussion if you want to make information well-searchable, well documented, self-organized; the average time until a post on the mailing list goes answered is in the order of hours; as a lot of the community earns its money with software radio related occupations, I doubt the frequency of qualified answers on facebook would ever be as high as on the mailing list. Greetings, Marcus On 20.05.2014 07:05, Mostafa Alizadeh wrote: Hi everybody, To be more communicative, we'v designed a page of GNURadio on facebook https://www.facebook.com/gnuradiodeveloper This page specially is for GNURadio developers who are following GNURadio ecosystem: ? new releases of GNURadio, ? new products of GNURadio, ? GNURadio conferences and events, ? new GNURadio-related projects and anything else related to GNURadio. We're looking for administrators for helping us on this page. Every volunteer Mail me. best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTe1hDAAoJEBQ6EdjyzlHtT5QH/1x9pBE7tQS8qBj2pSK9zyPk ktT0iCPA40lSrMsyvzjl1+JKsS8X4p9W79PQyFGtRf42g5wTjUSr0XeGGJLIZcoZ r4asiV0GFc68bbnXMVkrUYkq46wXcrm/lT66rdKbb6WgVy6SyAllyXFVHmO6/xS7 uU/k0aGO5izYlDNPNDyXjgiZ54Qpj6ySXADLaKa7tbSRkfRsUktUv/zXaNehHHGV wSn4QlCHNXUQkN09ARgTyGIQlfWnolO++ENTjeqfKQKvJrN5BtgcELPY+N+Xq4zs DACuK9VooXYtm5TQDJ3K4fObe53bziM6gGkQU1dCEcEoTklF4SRM9+37Q+ZGhDU= =r6Yx -END PGP SIGNATURE- ___ 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] Facebook
Hi everybody, To be more communicative, we'v designed a page of GNURadio on facebook https://www.facebook.com/gnuradiodeveloper This page specially is for GNURadio developers who are following GNURadio ecosystem: ✔ new releases of GNURadio, ✔ new products of GNURadio, ✔ GNURadio conferences and events, ✔ new GNURadio-related projects and anything else related to GNURadio. We're looking for administrators for helping us on this page. Every volunteer Mail me. best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to change a flowgraph in c++ dynamically
Hi Marcus, what do you mean by *run to completion *? best, Mostafa On Thu, May 15, 2014 at 10:40 AM, Mostafa Alizadeh m.alizade...@gmail.comwrote: Hi Martin, Thank you so much, :) The last example you mentioned, gr-uhd/examples/c++/tags_demo.*cc*, this will help me!! It's interesting example. Thank you. On Wed, May 14, 2014 at 2:32 PM, Martin Braun martin.br...@ettus.comwrote: On 14.05.2014 11:35, Mostafa Alizadeh wrote: It's better to say in this way: *how could I use stop(), start(), lock(), unlock() of the topblock methods? Is there any example of them?* [glados~/src/gnuradio]±(master⚡) ✭ $ ls **/examples/**/*.cc gr-audio/examples/c++/dial_tone.cc gr-fcd/examples/c++/fcd_nfm_rx.cc gr-uhd/examples/c++/tags_demo.cc Cheers, Martin Thanks, On Wed, May 14, 2014 at 1:20 PM, Martin Braun martin.br...@ettus.com mailto:martin.br...@ettus.com wrote: On 13.05.2014 15:56, Mostafa Alizadeh wrote: Thank you martin, I saw examples before, but all of them used blocks in the main of the c++ code. I wanna have a class derived from topblock of gnuradio and put the blocks' connections in it. Then in the main of the program, run or stop the topblock. Can you give a part of the code in c++ ? If it's not in the examples, I'm not sure what you exactly want. Also, please use the mailing list for these kinds of requests. M On Tue, May 13, 2014 at 5:27 PM, Martin Braun martin.br...@ettus.com mailto:martin.br...@ettus.com mailto:martin.br...@ettus.com mailto:martin.br...@ettus.com__ wrote: On 13.05.2014 11:05, Mostafa Alizadeh wrote: Hi everybody, I was wonder why I can't make a class of topblock in c++ like in python as said here: http://gnuradio.org/redmine/projects/gnuradio/wiki/ TutorialsWritePythonApplications http://gnuradio.org/redmine/__projects/gnuradio/wiki/__ TutorialsWritePythonApplicatio__ns http://gnuradio.org/redmine/__projects/gnuradio/wiki/__ TutorialsWritePythonApplicatio__ns http://gnuradio.org/redmine/projects/gnuradio/wiki/ TutorialsWritePythonApplications Then I think, I can control the flowgraph, start or stop it , disconnect or connect blocks and anything else . Any idea? It's pretty much the same, just in C++. Have a look at the c++ examples in the source tree, that'll get you started. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.__org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio https://lists.gnu.org/__mailman/listinfo/discuss-__gnuradio 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 pass a large number of items between blocks?
Hi Martin, I finally found the solution. I the method *set_align(int ), * to tell the scheduler output is multiple of a number but this is different than set_output_multiple(int ). The set_align will decrease the amount of buffer if the output number of items is less than the actual number of written output until the output buffer aligned with the number of items will written on it! This is interesting. best, On Wed, May 14, 2014 at 1:59 PM, Mostafa Alizadeh m.alizade...@gmail.comwrote: Hi Martin, Yes you're right, 75000 items isn't so large! But after passing these items through an encoder, the number of items becomes about 227000!! That's a big number! However, I skewed over the problem and till now I've reached to this point that I may use 3 or 4 inputs-ouputs ports per block (instead of actually one input-ouput port) and divide the 227000 items into 4 parallel streams and read all of them through 3/4 different input ports and put them out to the 3/4 output ports ! That seems work but I'm not sure that's the best one. If you have any idea I'll be appreciate you so much. best, On Wed, May 14, 2014 at 1:04 PM, Martin Braun martin.br...@ettus.comwrote: On 13.05.2014 19:27, Mostafa Alizadeh wrote: Hi, I recently encountered a problem with the large number of items. I wanna pass about 75000 items from one block to the another. I thought that I could do this with setting the min of output items in the constructor of the block but I got the following error by runtime: thread[thread-per-block[1]: block crc (1)]: Buffer too small for min_noutput_items I searched around but I couldn't find a cogent response. please help me! You could use your own version of tagged streams to indicate boundaries... regular tagged stream blocks also suffer from buffer limitations. That said, 75000 items doesn't seem all that large. What's your item size, is it sizeof(gr_complex)? Did you set your kernel.shmmax = 2147483648? M ___ 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 change a flowgraph in c++ dynamically
Hi Marcus, Thank you, On Thu, May 15, 2014 at 11:58 AM, Marcus Müller marcus.muel...@ettus.comwrote: Hi Mostafa, I mean the run option run to completion in the GRC. GRC is like LEGO for communication engineers, if you play around with it, you'll soon be having fun and have an easier time understanding hints like this ;) See http://imgur.com/YPUvyzm Greetings, Marcus On Thu, May 15, 2014 at 8:11 AM, Mostafa Alizadeh m.alizade...@gmail.comwrote: Hi Marcus, what do you mean by *run to completion *? best, Mostafa ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to pass a large number of items between blocks?
Hi Martin, Yes you're right, 75000 items isn't so large! But after passing these items through an encoder, the number of items becomes about 227000!! That's a big number! However, I skewed over the problem and till now I've reached to this point that I may use 3 or 4 inputs-ouputs ports per block (instead of actually one input-ouput port) and divide the 227000 items into 4 parallel streams and read all of them through 3/4 different input ports and put them out to the 3/4 output ports ! That seems work but I'm not sure that's the best one. If you have any idea I'll be appreciate you so much. best, On Wed, May 14, 2014 at 1:04 PM, Martin Braun martin.br...@ettus.comwrote: On 13.05.2014 19:27, Mostafa Alizadeh wrote: Hi, I recently encountered a problem with the large number of items. I wanna pass about 75000 items from one block to the another. I thought that I could do this with setting the min of output items in the constructor of the block but I got the following error by runtime: thread[thread-per-block[1]: block crc (1)]: Buffer too small for min_noutput_items I searched around but I couldn't find a cogent response. please help me! You could use your own version of tagged streams to indicate boundaries... regular tagged stream blocks also suffer from buffer limitations. That said, 75000 items doesn't seem all that large. What's your item size, is it sizeof(gr_complex)? Did you set your kernel.shmmax = 2147483648? M ___ 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
