Re: [Discuss-gnuradio] gr-ieee802-11 wifi signal bitrate
Hi Bastian, IIRC, it shows the autocorrelation of the signal. If you add a trigger to > the default plot (level ~0.56) you should see the characteristic plateau of > the short training sequence at the beginning of frames (this is used for > frame detection). Ok that's right? But I don't understand very well the signification of the "plateau" Thx Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-ieee802-11 wifi signal bitrate
Hi, > On 8. May 2017, at 09:00, Thom L wrote: > > IIRC, it shows the autocorrelation of the signal. If you add a trigger to the > default plot (level ~0.56) you should see the characteristic plateau of the > short training sequence at the beginning of frames (this is used for frame > detection). > > Ok that's right? But I don't understand very well the signification of the > “plateau” The characteristic plateau of the autocorrelation is used for frame detection by the Sync Short block. The plot can sometimes help to debug issues with it. For example, it can be used to - roughly adjust the gain even if synchronization / decoding does not work (i.e. if there are no subcarrier constellations) - often people experience a DC offset or LO leakage. In that case the autocorrelation is always high, which is directly visible in the plot. - determine a threshold for frame detection Also, I hoped, it might be helpful to better understand what the Sync Short block is locking for. Best, Bastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Major OpenCL Updates
Looks like the last batch of filter updates missed uploading that file. It's in the repo now in the lib directory. If you download it into your lib directory give it another shot. And I'll definitely take a look at the header magic in gr-fosphor and see if I can include it. On Mon, May 8, 2017 at 12:57 AM, Anon Lister wrote: > Ubuntu 16.04. I followed the notes for the nvidia install. Got me past > the incompatible headers. Would be cool to steal the cmake opencl > magic they use in gr-phosfor so it picks up the right includes and > whatnot paths. Anywho, now I get: > > home/anon/gr-clenabled/lib/clFilter_impl.h:26:24: fatal error: > fir_filter.h: No such file or directory > > I didn't poke around to see if this is auto-generated somehow, but > given the recent commits relating to the topic, is it possible it just > got missed in a commit? It is, indeed, not there: > > anon@anon:~/gr-clenabled$ find . -name "fir_filter.h" > anon@anon:~/gr-clenabled$ > > On Sun, May 7, 2017 at 5:44 PM, GhostOp14 wrote: > > Hi Anon. I set it up for 1.2. The biggest gotcha I've run into in the > > build process is missing the cl.hpp file, but how to get it can vary by > OS. > > There's some setup notes in the setup_help directory for debian and > Ubuntu > > that may help you out. What OS are you running it on? > > > > On Sun, May 7, 2017 at 4:35 PM, Anon Lister > wrote: > >> > >> Neat. What opencl implementation are you building against? > >> > >> I get errors related to _svm_ parts of code. I.e. > >> cl_device_svm_capabilities was not declared in this scope. Trying to > use the > >> Nvidia cuda sdk, just downloaded from their developer site (ver 8.0). > >> > >> > >> > >> On May 6, 2017 8:59 AM, "Ghost Op" wrote: > >>> > >>> Hi everyone. A number of you have asked me to keep you informed of > >>> any major updates on the OpenCL gr-clenabled project and the past > >>> couple of weeks have been pretty active. There's now a version up in > >>> the repo with a significant number of updates and all blocks have been > >>> validated (at least in their basic modes). > >>> > >>> So here's the major updates: > >>> > >>> Validation flowgraphs - Almost all test flowgraphs have been posted in > >>> the examples directory. You can run the comparisons on your own > >>> hardware for comparison. This is important on older cards that don't > >>> support double precision (you can check with the included clview > >>> command-line tool). > >>> > >>> Signal Source Block - A discrepancy in the output was due to an > >>> OpenCL issue. Turns out single/float precision wasn't producing > >>> accurate enough numbers. This block now uses double precision if the > >>> hardware supports it (most new hardware will) for an even cleaner > >>> signal than the native block (no secondary nodes). > >>> > >>> Quad Demod - Same single/double trig discrepancy due to precision > >>> which was corrected. > >>> > >>> Filters - A lot of work this week has been spent on filter validation > >>> (hence the few emails about TD vs. FD from yesterday) > >>> - Both FIR and FFT implementations are now implemented and > >>> producing correct output > >>> - A generic tap-based block was added for more flexibility > >>> - A test-clfilter command-line tool was added to test performance > >>> given a number of taps across OpenCL FIR, GNURadio FIR, OpenCL FFT, > >>> and GNURadio FFT so you can pick the best performing filter given your > >>> implementation. > >>> > >>> Costas Loop - A Costas Loop was added, however the performance on a > >>> GPU kernel is horrible. Because of the sequential calculations, it > >>> couldn't be SIMD parallel processed so it was written as an OpenCL > >>> task-based kernel. This means it just runs single-threaded on a > >>> single core, which is why the performance is so bad. However if > >>> anyone has an OpenCL-capable FPGA card like an Altera I'd love to see > >>> the result of running the included test-clenabled timing tool and see > >>> how the Costas Loop performs. I just don't have access to one. > >>> > >>> Performance - Code was added to detect if the hardware supports Fused > >>> Multiply/Add functionality for added kernel performance. If it's > >>> available it's used. > >>> > >>> OpenCL Setup Instructions - For those that may not have OpenCL set up, > >>> I added some installation guides in the setup_help directory for > >>> Ubuntu and Debian with step-by-steps on getting it up and running. > >>> I've taken both of those processes on several systems and been up and > >>> running pretty quickly. I also pulled some of the important points > >>> into the main page's README, since in my experience that's generally > >>> all I look through too. > >>> > >>> Study - Based on the filter updates, the filter section in the study > >>> in the docs directory was completely rewritten. The report was noted > >>> as updated. > >>> > >>> I think that's the biggest updates for now. As always let me know if > >>> anyon
Re: [Discuss-gnuradio] OOT Module using external function
I don't know what a .obj file from matlab coder is but completely
ingoring that file it sounds like you need to tell cmake that the .cpp file
from matlab needs to be built.
On Fri, May 5, 2017 at 9:38 AM, Ali <03do...@gmail.com> wrote:
> Hi,
>
> Under gr-TUTORIAL/lib there is myfunction_impl and myfunction_impl.cc
> files which gr_modtool itself created.
> MATLAB Coder gives .h, .cpp and .obj files. I put them under the same
> directory(gr-TUTORIAL/lib).
> Then what I do is including all .h files that MATLAB generated inside two
> files that gr_modtool generated(I wrote #include ... in both .h and .cc
> file).
>
> In the following part of the .cc file I tried to use the function that
> MATLAB generated.
>
> --
>
> int myfunction_impl::*general_work*(...)
> {
> const float *input1 = ..
> ..
>
> for (int i=; i {
> *my_function*(...)
> }
>
> consume_each(noutput_items);
> return noutput_items;
> }
>
>
>
> I don't know how to link .obj files to my module? Could you suggest a
> piece of code?
>
> Or after the things that I told now, is there any major mistake that I am
> doing?
>
> Thanks,
> Ali
>
>
>
>
>
> 2017-05-04 17:12 GMT+03:00 West, Nathan :
>
>> You have an external object that you need to link your module to. That
>> cpp file from matlab gets compiled to an object file somehow-- you haven't
>> specified how. Then you need to link your block to that object.
>>
>> On Wed, May 3, 2017 at 2:39 AM, do ber <03do...@gmail.com> wrote:
>>
>>> Hi to all,
>>>
>>> I am trying to create my own GNURadio block(OOT). I will use an external
>>> function generated by MATLAB Coder. MATLAB Coder gives the necessary .cpp
>>> and .h files. In the main module .cc file, which gr_modtool automatically
>>> creates I am including all the header files created by MATLAB Coder. Then
>>> under the work function of module I am just using my main function
>>> generated from MATLAB.
>>>
>>> Input/output declarations are ok, so there is no error during make,
>>> cmake, make install processes. When I open the GNURadio I see my block. Bu
>>> there are some problems:
>>>
>>> When I comment my external function (i.e. when I did not use my external
>>> function) block works(do nothing but works) and there is information in
>>> "Documentation tab" as all the normal blocks have.
>>> But when I uncomment my external function (i.e. when I used my external
>>> function under work function) I get the following error in GNURadio and
>>> there is no information on "Documentation page", there is only a blank page.
>>>
>>> self.TUTORIAL_myblock_0 = TUTORIAL.myblock(6)
>>> AttributeError:'module' object has no attribute 'myblock'
>>>
>>> Here, 6 is the antenna number in my project. It is the only argument
>>> that I enter into my block.
>>>
>>> So, I searched the literature but* I could not find any project using
>>> functions from external file.* For example, there is an example
>>> "My_QPSK_Demodulator" which is using get_minimum_distance function but it
>>> is a small function and is also defined inside the main module code.
>>>
>>> ** In short, I have myblock.cc and myblock.h files. Also, I have
>>> function .cpp and .h files. I want to use that function inside myblock.cc
>>>
>>> What are your suggestions? Is there any example using this approach?
>>> That would be awesome.
>>>
>>> Regards,
>>> Ali
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Major OpenCL Updates
Took your advice on the cmake OpenCL magic and incorporated it. Let me know how it works for you. Verified it worked correctly on Ubuntu 16.04 and debian. On Mon, May 8, 2017 at 6:18 AM, GhostOp14 wrote: > Looks like the last batch of filter updates missed uploading that file. > It's in the repo now in the lib directory. If you download it into your > lib directory give it another shot. > > And I'll definitely take a look at the header magic in gr-fosphor and see > if I can include it. > > On Mon, May 8, 2017 at 12:57 AM, Anon Lister wrote: > >> Ubuntu 16.04. I followed the notes for the nvidia install. Got me past >> the incompatible headers. Would be cool to steal the cmake opencl >> magic they use in gr-phosfor so it picks up the right includes and >> whatnot paths. Anywho, now I get: >> >> home/anon/gr-clenabled/lib/clFilter_impl.h:26:24: fatal error: >> fir_filter.h: No such file or directory >> >> I didn't poke around to see if this is auto-generated somehow, but >> given the recent commits relating to the topic, is it possible it just >> got missed in a commit? It is, indeed, not there: >> >> anon@anon:~/gr-clenabled$ find . -name "fir_filter.h" >> anon@anon:~/gr-clenabled$ >> >> On Sun, May 7, 2017 at 5:44 PM, GhostOp14 wrote: >> > Hi Anon. I set it up for 1.2. The biggest gotcha I've run into in the >> > build process is missing the cl.hpp file, but how to get it can vary by >> OS. >> > There's some setup notes in the setup_help directory for debian and >> Ubuntu >> > that may help you out. What OS are you running it on? >> > >> > On Sun, May 7, 2017 at 4:35 PM, Anon Lister >> wrote: >> >> >> >> Neat. What opencl implementation are you building against? >> >> >> >> I get errors related to _svm_ parts of code. I.e. >> >> cl_device_svm_capabilities was not declared in this scope. Trying to >> use the >> >> Nvidia cuda sdk, just downloaded from their developer site (ver 8.0). >> >> >> >> >> >> >> >> On May 6, 2017 8:59 AM, "Ghost Op" wrote: >> >>> >> >>> Hi everyone. A number of you have asked me to keep you informed of >> >>> any major updates on the OpenCL gr-clenabled project and the past >> >>> couple of weeks have been pretty active. There's now a version up in >> >>> the repo with a significant number of updates and all blocks have been >> >>> validated (at least in their basic modes). >> >>> >> >>> So here's the major updates: >> >>> >> >>> Validation flowgraphs - Almost all test flowgraphs have been posted in >> >>> the examples directory. You can run the comparisons on your own >> >>> hardware for comparison. This is important on older cards that don't >> >>> support double precision (you can check with the included clview >> >>> command-line tool). >> >>> >> >>> Signal Source Block - A discrepancy in the output was due to an >> >>> OpenCL issue. Turns out single/float precision wasn't producing >> >>> accurate enough numbers. This block now uses double precision if the >> >>> hardware supports it (most new hardware will) for an even cleaner >> >>> signal than the native block (no secondary nodes). >> >>> >> >>> Quad Demod - Same single/double trig discrepancy due to precision >> >>> which was corrected. >> >>> >> >>> Filters - A lot of work this week has been spent on filter validation >> >>> (hence the few emails about TD vs. FD from yesterday) >> >>> - Both FIR and FFT implementations are now implemented and >> >>> producing correct output >> >>> - A generic tap-based block was added for more flexibility >> >>> - A test-clfilter command-line tool was added to test performance >> >>> given a number of taps across OpenCL FIR, GNURadio FIR, OpenCL FFT, >> >>> and GNURadio FFT so you can pick the best performing filter given your >> >>> implementation. >> >>> >> >>> Costas Loop - A Costas Loop was added, however the performance on a >> >>> GPU kernel is horrible. Because of the sequential calculations, it >> >>> couldn't be SIMD parallel processed so it was written as an OpenCL >> >>> task-based kernel. This means it just runs single-threaded on a >> >>> single core, which is why the performance is so bad. However if >> >>> anyone has an OpenCL-capable FPGA card like an Altera I'd love to see >> >>> the result of running the included test-clenabled timing tool and see >> >>> how the Costas Loop performs. I just don't have access to one. >> >>> >> >>> Performance - Code was added to detect if the hardware supports Fused >> >>> Multiply/Add functionality for added kernel performance. If it's >> >>> available it's used. >> >>> >> >>> OpenCL Setup Instructions - For those that may not have OpenCL set up, >> >>> I added some installation guides in the setup_help directory for >> >>> Ubuntu and Debian with step-by-steps on getting it up and running. >> >>> I've taken both of those processes on several systems and been up and >> >>> running pretty quickly. I also pulled some of the important points >> >>> into the main page's README, since in my experience th
Re: [Discuss-gnuradio] crash when placing osmocom source + osmocon sink
You can only have 1 installation of gnuradio at time. Since you're using the osmosdr source and sink, do you have permissions to access the device? Which device are you trying to use? -- Cinaed On 05/07/2017 11:15 AM, Fernando wrote: > Using Opensuse 42.2 > > Gnuradio from repository home:dl8fcl:branches:hamradio > > i | gnuradio | package| 3.7.11-10.2 | > x86_64 | home:dl8fcl:branches:hamradio > > I have tried it with repository hamradio and it failed too. > > When I place both blocks on a diagram (I can even play the diagram), GRC > crash. > > When I open it again this is the log: > > fernando@andromeda:~> gnuradio-companion > Warning: restarting the docstring loader (crashed while loading > 'osmosdr_sink') > Warning: restarting the docstring loader (crashed while loading > 'osmosdr_source') > /usr/lib64/python2.7/site-packages/gnuradio/grc/gui/BlockTreeWindow.py:102: > GtkWarning: Theme directory base/ of theme oxygen has no size field > > self.search_entry.set_icon_from_stock(gtk.ENTRY_ICON_PRIMARY, > gtk.STOCK_FIND) > <<< Welcome to GNU Radio Companion 3.7.11 >>> > > Block paths: > /home/fernando/.grc_gnuradio > /usr/share/gnuradio/grc/blocks > Warning: restarting the docstring loader (crashed while loading > 'uhd_amsg_source') > Warning: restarting the docstring loader (crashed while loading > 'uhd_usrp_sink') > Warning: restarting the docstring loader (crashed while loading > 'uhd_usrp_source') > Warning: docstring loader crashed too often > > > Any help? > > > regards > > > > > > ___ > 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] tutorial 7
I was just looking at the flow graph for tutorial 7 yesterday. Why does the transmitter - or the Constellation Modulator - have a different symbol map from the receiver? -- Cinaed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Companion Extensions: Output C++ Code
Dear Sandeep, hi, and welcome! We've already got a contribution for that project aspect. Which certainly doesn't mean we don't want your help! So, if you want to contribute to GNU Radio, I think a great way to contribute is actually to improve some documentation. So, judging from your email, I'd say you'd be exactly the entry-level user that I'd ask to give feedback about the Guided Tutorials on http://tutorials.gnuradio.org by writing a critical mail to tutori...@gnuradio.org . Best regards, Marcus On 05/06/2017 09:32 PM, sandeep chauhan wrote: > Hi > Myself Sandeep and I want to contribute to the GNURadio. > my project is "GNU Radio Companion Extensions: Output C++ Code" > I have good coding skills in C,C++,and python. > I also familiar or have understanding about the grc's blocks (signal > source,audio source, WX GUIs and QT GUIs audiosink,and etc..) and also > about the types (complex and float). > So, suggest me the right way to do this project > Now I want the origin for this project > > > > ___ > 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] ImportError: No module named _osmosdr_swig
My GRC crashes when I place a osmocom source and osmocon sink.
Doing some research I have found that is a python problem with _osmosdr_swig
fernando@andromeda:~> python -c 'import osmosdr' Traceback (most recent
call last): File "", line 1, inFile
"/usr/lib64/python2.7/site-packages/osmosdr/__init__.py", line 26, in
from osmosdr_swig import * File
"/usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py", line 21,
in _osmosdr_swig = swig_import_helper() File
"/usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py", line 20,
in swig_import_helper return
importlib.import_module('_osmosdr_swig') File
"/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name) ImportError: No module named _osmosdr_swig
fernando@andromeda:~>
I am using Opensuse 42.2, and it have been reported taht it works fine
for other people with the same OS.
there is a package called python-gr-osmosdr wich contains
/usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py
what more can I test?
regards
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 64QAM Repack Bits Misalignment
Hi everyone, I am using the *Repack Bits *block to unpack bytes into 6 bits (aka. k=8 to l=6) and then repack this output back into full bytes (aka. k=6 to l=8). The input is a stream of tagged packets, say of length 5 bytes (6.667 64QAM symbols), meaning the number of bits isn't exactly divisible by 6. As such I have the block doing the unpacking aligned to the input, while the block doing the packing is aligned to the output (as per doco). What I find - both in LSB and MSB modes - is that the first packet is recovered correctly while every second one is misaligned and incorrect. If the packet length was 7 (9.333 symbols), I can expect every 3rd packet to be correct. A similar thing occurs with 8PSK which unpacks 8bits to 3bits and vice versa. How do I fix this alignment issue to get 64QAM/8PSK repacking working? Thanks! Regards, Justin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ImportError: No module named _osmosdr_swig
On 05/08/2017 03:44 PM, Fernando wrote:
> My GRC crashes when I place a osmocom source and osmocon sink.
>
> Doing some research I have found that is a python problem with _osmosdr_swig
>
> fernando@andromeda:~> python -c 'import osmosdr' Traceback (most recent
> call last): File "", line 1, inFile
> "/usr/lib64/python2.7/site-packages/osmosdr/__init__.py", line 26, in
> from osmosdr_swig import * File
> "/usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py", line 21,
> in _osmosdr_swig = swig_import_helper() File
> "/usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py", line 20,
> in swig_import_helper return
> importlib.import_module('_osmosdr_swig') File
> "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
> __import__(name) ImportError: No module named _osmosdr_swig
> fernando@andromeda:~>
>
> I am using Opensuse 42.2, and it have been reported taht it works fine
> for other people with the same OS.
>
> there is a package called python-gr-osmosdr wich contains
> /usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py
Remove the directory
/home/fernando/.grc_gnuradio
Check to ensure there's a shared library
_osmosdr_swig.so
in the same directory.
Check to ensure the installation of gnuradio was added to your python path
python -c "import os; print(os.environ.get('PYTHONPATH', ''))"
Check to ensure there's only one installation of gnuradio.
-- Cinaed
>
> regards
>
>
>
> ___
> 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
