from:"Sumit Kumar"

Re: Pendrive not visible

2020-05-20 Thread sumit kumar

dmesg can give you some info if the system detects your pendrive.

On Wed, 20 May 2020 at 23:48, Vincenzo Mone  wrote:

> Hello to the list,
> I have installed in dual boot With Windows 10, Ubuntu 20.04. Booted into
> Ubuntu and ha plugged a pendrive I have noticed that it is not visible. I
> mean I do not see it.
> Please anybody can help me?
> Thanks
>
>
> 73's de Enzo IK8OZV
> EasyLog 5 BetaTester
> EasyLog PDA BetaTester
> WinBollet BetaTester
> D.C.I. CheckPoint Regione Campania
> Skype: ik8ozv8520
>
>
>
>
>  ***
>  ***GSM  +39 328 7110193 <+39%20328%207110193>***
>  **   SMS  +39 328 7110193 <+39%20328%207110193>    ***
>  
>


-- 
Sumit Kumar

Re: Real-time video streaming

2020-03-07 Thread sumit kumar

Hello Ahmet,
If can make tunnel script working , then video transmission using vlc will
be very straightforward.
We did this long back
https://youtu.be/bKF67pFQy1k
Regards
Sumit

On Sat, Mar 7, 2020, 9:54 AM Ahmet DEMIR  wrote:

> Hi,
> Thanks for the help.
> I am trying to stream a real time video taken from a camera. I know that I
> will use gstreamer to take and encode the video. And then pass it to the
> gnuradio and do some digital processing operations on it. And lastly by
> using a usrp, I will transmit it in radio frequency range. Can I use
> uhd_packet_tx.grc example which is used to message passing for this aim? Or
> how can I find the flowgraph of video transmitter? I am using Gnuradio3.8
> version and linux OS. I will be very happy if you help me.
> Regards.
>

Re: [Discuss-gnuradio] Packet transmission questions from a newb

2019-10-28 Thread sumit kumar

" but my wi-fi packet receiver works just dandy without any OFDM blocks"
--> Can you check the standard which your wifi receiver is following ? If
it is 802.11b, then it wont work with gr-ieee 80211 because gr-ieee 80211
is based on OFDM based WiFi.

You cannot use .pcap file as file source for the wifi_tx.grc.

May I know your final aim for this experiment so that I can put my
suggestions ?

Regards
Sumit

On Sun, 27 Oct 2019 at 20:10, Eamon Heaney  wrote:

> Hi,
>
> I'm trying to create a wi-fi transmitter in GNURadio that can take a file
> source and transmit it as an 802.11 packet. I'm using this
> <https://github.com/bastibl/gr-ieee802-11/blob/maint-3.8/examples/wifi_tx.grc>
> example as a basis, and trying to follow the guides here
> <https://www.gnuradio.org/doc/doxygen/page_packet_data.html>.
>
> Frankly, though, a lot of what's in that guide goes way over my head. I
> have a general understanding of what OFDM is, but my wi-fi packet receiver
> works just dandy without any OFDM blocks. So is it still necessary to
> incorporate such blocks into a transmitter?
>
> Secondly, I can't just plug a .pcap file source into the transmitter; it
> doesn't generate, and I get the feeling that .pcap isn't the proper format
> for transmission anyways. How can I figure out which blocks to put after
> the file source to make it gel with the next block in the example (WiFi
> MAC)?
>
> Thanks!
>
> --
> Eamon Heaney
> *Fleet Commander*
> *President, Model UN at Virginia Tech*
>


-- 
Sumit Kumar

Re: [Discuss-gnuradio] undefined reference to `pthread_create' while pybombs installation

2019-09-25 Thread sumit kumar

Ahh sorry, that was not an error. Looks like new version does not assigns a
default id (previously it did) and user have to do by itself.
Sorry for spamming.


On Wed, 25 Sep 2019 at 21:52, sumit kumar  wrote:

> Ok I managed to fix it but exporting the python path to dist-packages of
> python 3.6 (I never needed to do this when I used pybombs),
> But now I see a new thing
> When I open GNU Radio companion and try to make an example
> I see "ID "default" is blacklisted." Figure attached.
> So many new things today!
>
>
>
> On Wed, 25 Sep 2019 at 21:41, sumit kumar  wrote:
>
>> Hi Vasil,
>> Thanks for detailed info. I did that straight away as you suggested.
>> Installation was smooth, but now I am getting "Cannot import gnuradio"
>> error! when I start gnuradio-companion.
>> I have attached the screenshot and logs
>>
>> ubadmin@ub-exotic02:~$ cd prefix/
>> ubadmin@ub-exotic02:~/prefix$ source setup_env.sh
>> ubadmin@ub-exotic02:~/prefix$ gnuradio-companion
>> Gtk-Message: 21:39:40.832: GtkDialog mapped without a transient parent.
>> This is discouraged.
>> ubadmin@ub-exotic02:~/prefix$ echo $LD_LIBRARY_PATH
>> /home/ubadmin/prefix/lib:/home/ubadmin/prefix/lib64/:
>> ubadmin@ub-exotic02:~/prefix$
>>
>>
>>
>>
>> On Wed, 25 Sep 2019 at 21:15, Vasil Velichkov 
>> wrote:
>>
>>> Hi Sumit,
>>>
>>> On 25/09/2019 21.25, sumit kumar wrote:
>>> > Attaching output of Configuration (which failed)
>>> >
>>> > On Wed, 25 Sep 2019 at 20:12, sumit kumar  wrote:
>>> >
>>> >> Hi,
>>> >> I am getting undefined reference to `pthread_create' when I am
>>> >> installing GNU Radio using pybombs. The desktop has fresh install of
>>> ubuntu
>>> >> 18.04.
>>> >> Error and Output log files are attached.
>>>
>>> The problem is that cmake cannot find numpy.
>>>
>>> > -- Python checking for numpy - not found
>>> > --
>>> > -- Configuring gnuradio-companion support...
>>> > --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>>> > --   Dependency ENABLE_PYTHON = ON
>>> > --   Dependency PYTHON_MIN_VER_FOUND = TRUE
>>> > --   Dependency PYYAML_FOUND = TRUE
>>> > --   Dependency MAKO_FOUND = TRUE
>>> > --   Dependency PYGI_FOUND = TRUE
>>> > --   Dependency GTK_GI_FOUND = TRUE
>>> > --   Dependency CAIRO_GI_FOUND = TRUE
>>> > --   Dependency PANGOCAIRO_GI_FOUND = TRUE
>>> > --   Dependency NUMPY_FOUND = FALSE
>>> > CMake Error at cmake/Modules/GrComponent.cmake:75 (message):
>>> >   user force-enabled gnuradio-companion but configuration checked
>>> failed
>>>
>>> It should have been installed by pybombs as the gnuradio recipe contains
>>> numpy as dependency [1] and numpy recipe contains deb packages for both
>>> python2 [2] and python3 [3].
>>>
>>> > ubadmin@ub-exotic02:~$ pybombs prefix init -a default prefix/default/
>>> -R gnuradio-default
>>> > PyBOMBS.ConfigManager - INFO - Prefix Python version is: 2.7.15
>>>
>>> You have used pip to install pybombs and currently in ubuntu 18.04 pip
>>> uses python2 while pip3 uses python3.
>>>
>>> > -- User set python executable /usr/bin/python3.6
>>> > -- Found PythonInterp: /usr/bin/python3.6 (found suitable version
>>> "3.6.8", minimum required is "2.7.6")
>>> > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so
>>> (found suitable exact version "3.6.8")
>>> > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so
>>> (found suitable version "3.6.8", minimum required is "2.7.6")
>>>
>>> When both python3 and python2 are available gnuradio's cmake will choose
>>> python3 and mixing python2 (the one used by pybombs) with python3 (the one
>>> used by cmake) could lead to many hard to debug problems.
>>>
>>> My advice is to remove the pybombs that is using python2, then install
>>> it using pip3, remove your prefix directory and ~/.pybombs (or use another
>>> directory) and start from scratch. It should be something like:
>>>
>>>pip uninstall pybombs
>>>pip3 install pybombs
>>>rm -rf prefix/default/
>>>rm -rf ~/.pybombs
>>>    pybombs auto-config
>>>pybombs add-defaults
>>>pybombs prefix init -a default prefix/defaul

Re: [Discuss-gnuradio] undefined reference to `pthread_create' while pybombs installation

2019-09-25 Thread sumit kumar

Ok I managed to fix it but exporting the python path to dist-packages of
python 3.6 (I never needed to do this when I used pybombs),
But now I see a new thing
When I open GNU Radio companion and try to make an example
I see "ID "default" is blacklisted." Figure attached.
So many new things today!



On Wed, 25 Sep 2019 at 21:41, sumit kumar  wrote:

> Hi Vasil,
> Thanks for detailed info. I did that straight away as you suggested.
> Installation was smooth, but now I am getting "Cannot import gnuradio"
> error! when I start gnuradio-companion.
> I have attached the screenshot and logs
>
> ubadmin@ub-exotic02:~$ cd prefix/
> ubadmin@ub-exotic02:~/prefix$ source setup_env.sh
> ubadmin@ub-exotic02:~/prefix$ gnuradio-companion
> Gtk-Message: 21:39:40.832: GtkDialog mapped without a transient parent.
> This is discouraged.
> ubadmin@ub-exotic02:~/prefix$ echo $LD_LIBRARY_PATH
> /home/ubadmin/prefix/lib:/home/ubadmin/prefix/lib64/:
> ubadmin@ub-exotic02:~/prefix$
>
>
>
>
> On Wed, 25 Sep 2019 at 21:15, Vasil Velichkov 
> wrote:
>
>> Hi Sumit,
>>
>> On 25/09/2019 21.25, sumit kumar wrote:
>> > Attaching output of Configuration (which failed)
>> >
>> > On Wed, 25 Sep 2019 at 20:12, sumit kumar  wrote:
>> >
>> >> Hi,
>> >> I am getting undefined reference to `pthread_create' when I am
>> >> installing GNU Radio using pybombs. The desktop has fresh install of
>> ubuntu
>> >> 18.04.
>> >> Error and Output log files are attached.
>>
>> The problem is that cmake cannot find numpy.
>>
>> > -- Python checking for numpy - not found
>> > --
>> > -- Configuring gnuradio-companion support...
>> > --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>> > --   Dependency ENABLE_PYTHON = ON
>> > --   Dependency PYTHON_MIN_VER_FOUND = TRUE
>> > --   Dependency PYYAML_FOUND = TRUE
>> > --   Dependency MAKO_FOUND = TRUE
>> > --   Dependency PYGI_FOUND = TRUE
>> > --   Dependency GTK_GI_FOUND = TRUE
>> > --   Dependency CAIRO_GI_FOUND = TRUE
>> > --   Dependency PANGOCAIRO_GI_FOUND = TRUE
>> > --   Dependency NUMPY_FOUND = FALSE
>> > CMake Error at cmake/Modules/GrComponent.cmake:75 (message):
>> >   user force-enabled gnuradio-companion but configuration checked failed
>>
>> It should have been installed by pybombs as the gnuradio recipe contains
>> numpy as dependency [1] and numpy recipe contains deb packages for both
>> python2 [2] and python3 [3].
>>
>> > ubadmin@ub-exotic02:~$ pybombs prefix init -a default prefix/default/
>> -R gnuradio-default
>> > PyBOMBS.ConfigManager - INFO - Prefix Python version is: 2.7.15
>>
>> You have used pip to install pybombs and currently in ubuntu 18.04 pip
>> uses python2 while pip3 uses python3.
>>
>> > -- User set python executable /usr/bin/python3.6
>> > -- Found PythonInterp: /usr/bin/python3.6 (found suitable version
>> "3.6.8", minimum required is "2.7.6")
>> > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so (found
>> suitable exact version "3.6.8")
>> > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so (found
>> suitable version "3.6.8", minimum required is "2.7.6")
>>
>> When both python3 and python2 are available gnuradio's cmake will choose
>> python3 and mixing python2 (the one used by pybombs) with python3 (the one
>> used by cmake) could lead to many hard to debug problems.
>>
>> My advice is to remove the pybombs that is using python2, then install it
>> using pip3, remove your prefix directory and ~/.pybombs (or use another
>> directory) and start from scratch. It should be something like:
>>
>>pip uninstall pybombs
>>pip3 install pybombs
>>rm -rf prefix/default/
>>rm -rf ~/.pybombs
>>pybombs auto-config
>>pybombs add-defaults
>>pybombs prefix init -a default prefix/default/ -R gnuradio-default
>>
>> An alternative approach could be to modify the gnuradio recipe
>> (~/.pybombs/recipes/gr-recipes/gnuradio.lwr) and add
>> "-DPYTHON_EXECUTABLE=/usr/bin/python2" at the end of config_opt string
>>
>>  config_opt: " -DENABLE_DOXYGEN=$builddocs -DENABLE_GR_AUDIO=ON
>> -DENABLE_GR_BLOCKS=ON -DENABLE_GR_DIGITAL=ON -DENABLE_GR_FEC=ON
>> -DENABLE_GR_FFT=ON -DENABLE_GR_FILTER=ON -DENABLE_GR_QTGUI=ON
>> -DENABLE_GR_UHD=ON -DENABLE_PYTHON=ON -DENABLE_VOLK=ON -DENABLE_GRC=ON
>> -DPYTHON_EXECUTABLE=/usr/bin/python2"
>>
>> [1] https://github.com/gnuradio/gr-recipes/blob/deb170d/gnuradio.lwr#L30
>> [2] https://github.com/gnuradio/gr-recipes/blob/deb170d/numpy.lwr#L27
>> [3] https://github.com/gnuradio/gr-recipes/blob/deb170d/numpy.lwr#L34
>>
>> Regards,
>> Vasil
>>
>
>
> --
> Sumit Kumar
>
>
>

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

Re: [Discuss-gnuradio] undefined reference to `pthread_create' while pybombs installation

2019-09-25 Thread sumit kumar

Hi Michael,

Yes I tried installing numpy, but it is already there.
Further, I deleted the build directory and ran pybombs again, but still it
cannot find numpy!
Did system reboot also.
Even orc 0.4 is there but installer cannot find it.

I got a fresh i9 CPU and GNU Radio doesn't install.

ubadmin@ub-exotic02:~$ sudo apt install python-numpy
[sudo] password for ubadmin:
Reading package lists... Done
Building dependency tree
Reading state information... Done
python-numpy is already the newest version (1:1.13.3-2ubuntu1).
The following package was automatically installed and is no longer required:
  libllvm7
Use 'sudo apt autoremove' to remove it.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

ubadmin@ub-exotic02:~$ python
Python 2.7.15+ (default, Jul  9 2019, 16:51:35)
[GCC 7.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>>

On Wed, 25 Sep 2019 at 20:50, Michael Dickens 
wrote:

> Hi Sumit - According to your last log, your install is missing NumPy.
> Since PyBOMBS force-enabled GRC and not all dependencies were met, CMake
> errored out. Clearly PyBOMBS didn't catch that dependency. Maybe just
> install it manually and create an issue in PyBOMBS github noting it? - MLD
>
> On Wed, Sep 25, 2019 at 2:27 PM sumit kumar  wrote:
>
>> Attaching output of Configuration (which failed)
>>
>> On Wed, 25 Sep 2019 at 20:12, sumit kumar  wrote:
>>
>>> Hi,
>>> I am getting undefined reference to `pthread_create' when I am
>>> installing GNU Radio using pybombs. The desktop has fresh install of ubuntu
>>> 18.04.
>>> Error and Output log files are attached.
>>> Regards
>>> Sumit
>>>
>>
>>
>> --
>> Sumit Kumar
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> --
> Michael Dickens, Mac OS X Programmer
>
> Ettus Research Technical Support
>
> Email: supp...@ettus.com
>
> Web: http://www.ettus.com
>

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

Re: [Discuss-gnuradio] undefined reference to `pthread_create' while pybombs installation

2019-09-25 Thread sumit kumar

Ok so I did
sudo apt install python3-pip
pip3 install numpy

And configuration is correct now.. it building!
Will wait in office till it builds or wont be ale to sleep today :P

On Wed, 25 Sep 2019 at 21:02, Michael Dickens 
wrote:

> Yes, but PyBOMBS is using Py36, not Py27 ...
>
> On Wed, Sep 25, 2019 at 3:00 PM sumit kumar  wrote:
>
>> Hi Michael,
>>
>> Yes I tried installing numpy, but it is already there.
>> Further, I deleted the build directory and ran pybombs again, but still
>> it cannot find numpy!
>> Did system reboot also.
>> Even orc 0.4 is there but installer cannot find it.
>>
>> I got a fresh i9 CPU and GNU Radio doesn't install.
>>
>>
>> ubadmin@ub-exotic02:~$ sudo apt install python-numpy
>> [sudo] password for ubadmin:
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> python-numpy is already the newest version (1:1.13.3-2ubuntu1).
>> The following package was automatically installed and is no longer
>> required:
>>   libllvm7
>> Use 'sudo apt autoremove' to remove it.
>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>>
>> ubadmin@ub-exotic02:~$ python
>> Python 2.7.15+ (default, Jul  9 2019, 16:51:35)
>> [GCC 7.4.0] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import numpy
>> >>>
>>
>> On Wed, 25 Sep 2019 at 20:50, Michael Dickens 
>> wrote:
>>
>>> Hi Sumit - According to your last log, your install is missing NumPy.
>>> Since PyBOMBS force-enabled GRC and not all dependencies were met, CMake
>>> errored out. Clearly PyBOMBS didn't catch that dependency. Maybe just
>>> install it manually and create an issue in PyBOMBS github noting it? - MLD
>>>
>>> On Wed, Sep 25, 2019 at 2:27 PM sumit kumar  wrote:
>>>
>>>> Attaching output of Configuration (which failed)
>>>>
>>>> On Wed, 25 Sep 2019 at 20:12, sumit kumar  wrote:
>>>>
>>>>> Hi,
>>>>> I am getting undefined reference to `pthread_create' when I am
>>>>> installing GNU Radio using pybombs. The desktop has fresh install of 
>>>>> ubuntu
>>>>> 18.04.
>>>>> Error and Output log files are attached.
>>>>> Regards
>>>>> Sumit
>>>>>
>>>>
>>>>
>>>> --
>>>> Sumit Kumar
>>>>
>>>>
>>>> ___
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>
>>>
>>> --
>>> Michael Dickens, Mac OS X Programmer
>>>
>>> Ettus Research Technical Support
>>>
>>> Email: supp...@ettus.com
>>>
>>> Web: http://www.ettus.com
>>>
>>
>>
>> --
>> Sumit Kumar
>>
>>
>>
>
> --
> Michael Dickens, Mac OS X Programmer
>
> Ettus Research Technical Support
>
> Email: supp...@ettus.com
>
> Web: http://www.ettus.com
>


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

Re: [Discuss-gnuradio] undefined reference to `pthread_create' while pybombs installation

2019-09-25 Thread sumit kumar

Attaching output of Configuration (which failed)

On Wed, 25 Sep 2019 at 20:12, sumit kumar  wrote:

> Hi,
> I am getting undefined reference to `pthread_create' when I am
> installing GNU Radio using pybombs. The desktop has fresh install of ubuntu
> 18.04.
> Error and Output log files are attached.
> Regards
> Sumit
>


-- 
Sumit Kumar
ubadmin@ub-exotic02:~$ pybombs prefix init -a default prefix/default/ -R 
gnuradio-default
PyBOMBS.ConfigManager - INFO - Prefix Python version is: 2.7.15
PyBOMBS - INFO - PyBOMBS Version 2.3.3
PyBOMBS.prefix - WARNING - There already is a prefix in 
`/home/ubadmin/prefix/default'.
Continue using this path Y/[N]? y
PyBOMBS.ConfigManager - INFO - Prefix Python version is: 2.7.15
Alias `default' already exists, overwrite Y/[N]? y
PyBOMBS.ConfigManager - INFO - Prefix Python version is: 2.7.15
PyBOMBS.prefix - INFO - Installing default packages for prefix...
PyBOMBS.prefix - INFO - 
  - gnuradio
PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and installing 
binary packages:
Install tree:
|
\- gnuradio
PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source 
packages to prefix:
PyBOMBS.install_manager - INFO - Installing package: gnuradio
Configuring: (100%) 
[=]
PyBOMBS.Packager.source - WARNING - Configuration failed. Re-trying with higher 
verbosity.
-- Build type set to RelWithDebInfo.
-- Extracting version information from git describe...
-- Compiler Version: cc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- Compiler Flags: /usr/bin/cc:::-O2 -g -DNDEBUG  -fvisibility=hidden 
-Wsign-compare -Wall -Wno-uninitialized
/usr/bin/c++:::-O2 -g -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall 
-Wno-uninitialized
-- ADDING PERF COUNTERS
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   date_time
--   program_options
--   filesystem
--   system
--   regex
--   thread
--   unit_test_framework
--   chrono
--   atomic
-- User set python executable /usr/bin/python3.6
-- Found PythonInterp: /usr/bin/python3.6 (found suitable version "3.6.8", 
minimum required is "2.7.6") 
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so (found suitable 
exact version "3.6.8") 
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so (found suitable 
version "3.6.8", minimum required is "2.7.6") 
-- Python checking for six - python 2 and 3 compatibility library - found
-- 
-- Checking for module SWIG
-- Found SWIG version 3.0.12.
-- 
-- The build system will automatically enable all components.
-- Use -DENABLE_DEFAULT=OFF to disable components by default.
-- 
-- Configuring python-support support...
--   Dependency PYTHONLIBS_FOUND = TRUE
--   Dependency SWIG_FOUND = TRUE
--   Dependency SWIG_VERSION_CHECK = TRUE
--   Dependency SIX_FOUND = TRUE
--   Enabling python-support support.
--   Override with -DENABLE_PYTHON=ON/OFF
-- 
-- Configuring testing-support support...
--   Dependency Boost_FOUND = 1
--   Enabling testing-support support.
--   Override with -DENABLE_TESTING=ON/OFF
-- 
-- Configuring VOLK support...
-- Build type set to RelWithDebInfo.
-- Extracting version information from git describe...
-- 
-- Python checking for python >= 2.7
-- Python checking for python >= 2.7 - found
-- 
-- Python checking for mako >= 0.4.2
-- Python checking for mako >= 0.4.2 - found
-- 
-- Python checking for six - python 2 and 3 compatibility library
-- Python checking for six - python 2 and 3 compatibility library - found
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   filesystem
--   system
-- Checking for module 'orc-0.4 > 0.4.11'
--   No package 'orc-0.4' found
-- orc files (missing: ORC_LIBRARY ORC_INCLUDE_DIR ORCC_EXECUTABLE) 
-- QA Testing is enabled.
--   Modify using: -DENABLE_TESTING=ON/OFF
-- System profiling is disabled.
--   Modify using: -DENABLE_PROFILING=ON/OFF
-- Compiler name: GNU
-- x86* CPU detected
-- Compiler doesn't support NEON, Overruled arch neon
-- Compiler doesn't support NEON, Overruled arch neonv7
-- Compiler doesn't support NEON, Overruled arch neonv8
-- ORC support not found, Overruled arch orc
-- CPU width is 64 bits, Overruled arch 32
-- Available architectures: 
generic;64;3dnow;abm;popcount;mmx;fma;sse;sse2;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx;avx2;avx512f;avx512cd
-- Available machines: 
generic;sse2_64_mmx;sse3_64_mmx;ssse3_64_mmx;sse4_a_64_mmx;sse4_1_64_mmx;sse4_2_64_mmx;avx_64_mmx;avx2_64_mmx;avx512f_64_mmx;avx512cd_64_mmx
-- BUILD TYPE = RELWITHDEBINFO
-- Bas

[Discuss-gnuradio] Internet connectivity; forward link over air, reverse link over cable?

2019-08-19 Thread sumit kumar

Hi,
We have a forward DVB-S2 link between two nodes in our lab. This has been
implemented using USRP. Right now its a unidirectional link, so that we can
do UDP broadcasts.

We want to establish internet connection using this link but we do not have
reverse connection, i.e., the receiver cannot send data back to the
transmitter.
In my understanding any internet protocol will need a reverse link also.

Is it possible to have the reverse link via other medium, for example an
ethernet cable. This is solely for demo purpose. Is this idea remotely
possible ?

I have shown this in the picture attached. The red line is forward link
which is implemented. The idea is to provide internet connection from the
CPU A to the CPU B or may be simple SSH from A to B and file transfer. Is
the reverse link possible by connecting an Ethernet cable from B to A.

Its a very crude idea and I have limited knowledge of networking, so before
digging blindly on internet it will be very helpful if I get some useful
suggestions here.

Regards
Sumit


Internet.pdf
Description: Adobe PDF document
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

2019-07-25 Thread Sumit Kumar

Hi Johannes,
Thanks, it works now, but the input will be without quotes, i.e., False not
`False`.
Regards
Sumit

On Thu, Jul 25, 2019 at 10:22 AM Johannes Demel 
wrote:

> Hi Sumit,
>
> this is not an installation error. Your configuration is wrong. The
> argument `enb` must be of type bool but it is a string in your case.
> I assume you use GRC to generate this flowgraph.
> Open your USRP source block. Go to the `FE Corrections` tab and put in
> `False` in both fields. No `, ' or ". This will generate a line that says:
> `self.uhd_usrp_source_0.set_auto_dc_offset(False, 0)`
> instead of
> `self.uhd_usrp_source_0.set_auto_dc_offset("False", 0)`.
> This should fix your issue.
>
> Cheers
> Johannes
>
> Am 24.07.19 um 19:33 schrieb Sumit Kumar:
> > Hi Michael,
> > Any update on this? I downgraded my install of uhd and gnuradio as
> > follows but I have the same error.
> >
> > Traceback (most recent call last):
> >File "/home/sumit/Desktop/top_block.py", line 122, in 
> >  main()
> >File "/home/sumit/Desktop/top_block.py", line 110, in main
> >  tb = top_block_cls()
> >File "/home/sumit/Desktop/top_block.py", line 78, in __init__
> >  self.uhd_usrp_source_0.set_auto_dc_offset("False", 0)
> >File
> >
> "/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> > line 3499, in set_auto_dc_offset
> >  return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb,
> chan)
> > TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2
> > of type 'bool'
> >
> > sumit@PP0380:~/gradio/src/gnuradio$ uhd_find_devices
> > [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> > *UHD_3.14.1.HEAD-0-g5491b80e*
> > --
> > -- UHD Device 0
> > --
> > Device Address:
> >  serial: 317DD1E
> >  addr: 192.168.10.2
> >  fpga: HG
> >  name:
> >  product: X310
> >  type: x300
> >
> >
> > sumit@PP0380:~/gradio/src/gnuradio$ gnuradio-companion --version
> > *GNU Radio Companion 3.7.13.5
> > *
> > This program is part of GNU Radio
> > GRC comes with ABSOLUTELY NO WARRANTY.
> > This is free software, and you are welcome to redistribute it.
> >
> > sumit@PP0380:~/gradio/src/gnuradio$ git status
> > On branch maint-3.7
> > *Your branch is up to date with 'origin/maint-3.7'.*
> > *
> > *
> > Regards
> > Sumit
> >
> > On Thu, Jun 27, 2019 at 8:07 PM Michael Dickens
> > mailto:michael.dick...@ettus.com>> wrote:
> >
> > __
> > I guess for your need so long as it works that's what matters, yes?
> >
> > We'll work on fixing the issue you found anyway ... seems like it's
> > legit & undesirable LOL.
> >
> > Good luck with your demo! - MLD
> >
> > On Thu, Jun 27, 2019, at 2:01 PM, sumit kumar wrote:
> >> Well it worked after compiling old checkouts (but not giving me
> >> the usual satisfaction of a fresh install... but anyways)
> >>
> >> On Thu, 27 Jun 2019 at 19:45, sumit kumar  >> <mailto:sumits...@gmail.com>> wrote:
> >>
> >> Its overwhelming :D, I have a demo on Monday and I was 100%
> >> assured gr-ieee-80211 will work as usual.
> >>
> >> Before I saw your mail, I already checked out GR to 3.7.12,
> >> UHD to 003 009 006 and compiling now.
> >> Yes I used pybombs for installation.
> >>
> >> I have a USB with gnuradio installed into it. It works good
> >> and it has GR 3.7.11, uhd 003 009 006 and gr-ieee-80211
> >> version I dint check.
> >
> >
> >
> > --
> > --
> > Sumit kumar
> > Postdoc
> > SnT, Luxembourg
> >
> >
> >
> > ___
> > 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
>


-- 
-- 
Sumit kumar
Postdoc
SnT, Luxembourg
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

2019-07-24 Thread Sumit Kumar

Hi Michael,
Any update on this? I downgraded my install of uhd and gnuradio as follows
but I have the same error.

Traceback (most recent call last):
  File "/home/sumit/Desktop/top_block.py", line 122, in 
main()
  File "/home/sumit/Desktop/top_block.py", line 110, in main
tb = top_block_cls()
  File "/home/sumit/Desktop/top_block.py", line 78, in __init__
self.uhd_usrp_source_0.set_auto_dc_offset("False", 0)
  File
"/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3499, in set_auto_dc_offset
return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
type 'bool'

sumit@PP0380:~/gradio/src/gnuradio$ uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
*UHD_3.14.1.HEAD-0-g5491b80e*
--
-- UHD Device 0
--
Device Address:
serial: 317DD1E
addr: 192.168.10.2
fpga: HG
name:
product: X310
type: x300


sumit@PP0380:~/gradio/src/gnuradio$ gnuradio-companion --version

*GNU Radio Companion 3.7.13.5*
This program is part of GNU Radio
GRC comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it.

sumit@PP0380:~/gradio/src/gnuradio$ git status
On branch maint-3.7
*Your branch is up to date with 'origin/maint-3.7'.*

Regards
Sumit

On Thu, Jun 27, 2019 at 8:07 PM Michael Dickens 
wrote:

> I guess for your need so long as it works that's what matters, yes?
>
> We'll work on fixing the issue you found anyway ... seems like it's legit
> & undesirable LOL.
>
> Good luck with your demo! - MLD
>
> On Thu, Jun 27, 2019, at 2:01 PM, sumit kumar wrote:
>
> Well it worked after compiling old checkouts (but not giving me the usual
> satisfaction of a fresh install... but anyways)
>
> On Thu, 27 Jun 2019 at 19:45, sumit kumar  wrote:
>
> Its overwhelming :D, I have a demo on Monday and I was 100% assured
> gr-ieee-80211 will work as usual.
>
> Before I saw your mail, I already checked out GR to 3.7.12, UHD to 003 009
> 006 and compiling now.
> Yes I used pybombs for installation.
>
> I have a USB with gnuradio installed into it. It works good and it has GR
> 3.7.11, uhd 003 009 006 and gr-ieee-80211 version I dint check.
>
>
>

-- 
-- 
Sumit kumar
Postdoc
SnT, Luxembourg
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] pybombs gnuradio install and sudo

2019-07-22 Thread sumit kumar

Hi,
When I try to run any gnuradio program with sudo (inside pybombs
environment), it simply throws the error

*ImportError: No module named gnuradio*

For example when I try to run tunnel based programs, which need ioctl calls
and hence sudo or root.

Without sudo it says operation not permitted and with sudo it says
ImportError: No module named gnuradio

Solution ? :-/




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

Re: [Discuss-gnuradio] USRP GNU radio receiver

2019-07-16 Thread sumit kumar

Ok, so for a constant source, in the time domain you will see a flat signal
only! Try connecting a spectrum analyzer and you shud see a peak at DC becz
Fourier transform of constant signal is impulse.
And yes, as Marcus said, increase the sampling rate!
[image: Screenshot from 2019-07-16 18-29-17.png]

On Tue, 16 Jul 2019 at 18:06, Simona Sibio  wrote:

> Thank you for the assistance.
>
> I put the module "constant source" in my flow grap.
> With this module, I can choose witch amplitude I want to send.
> I attached the flow graph.
> And, I would want to read these values in the receiver.
>
> Simona
>
> Il giorno mar 16 lug 2019 alle ore 16:58 sumit kumar 
> ha scritto:
>
>> Hi Simona, what is the "constant signal" here ?
>>
>> On Tue, 16 Jul 2019 at 17:54, Simona Sibio  wrote:
>>
>>> Hi all,
>>>
>>> I want to use GNU radio to measure the amplitude and the phase of a
>>> signal.
>>> I send a constant signal with the transmitter USRP but in the receiver
>>> there is a flat signal with amplitude 0 and offset 0.
>>> I tried to send a sine signal and the receveir works fine.
>>> How can I do to send only a constant and measure the amplitude?
>>>
>>> Thank you for your time.
>>>
>>> Simona
>>>
>>> _______
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> --
>> Sumit Kumar
>>
>>
>>

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

Re: [Discuss-gnuradio] USRP GNU radio receiver

2019-07-16 Thread sumit kumar

Hi Simona, what is the "constant signal" here ?

On Tue, 16 Jul 2019 at 17:54, Simona Sibio  wrote:

> Hi all,
>
> I want to use GNU radio to measure the amplitude and the phase of a signal.
> I send a constant signal with the transmitter USRP but in the receiver
> there is a flat signal with amplitude 0 and offset 0.
> I tried to send a sine signal and the receveir works fine.
> How can I do to send only a constant and measure the amplitude?
>
> Thank you for your time.
>
> Simona
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


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

Re: [Discuss-gnuradio] PyBOMBS.install_manager - Error installing package uhd.

2019-06-30 Thread sumit kumar

Not sure about that but I had the same problem 2 days back and solved it by
installing packages manually.  I had ubuntu 18.04.

On Mon, Jul 1, 2019, 2:34 AM Barry Duggan  wrote:

> Thanks, but that didn't work either:
> pi@raspberrypi:~ $ sudo apt install python-mako
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> python-mako is already the newest version (1.0.7+ds1-1).
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>
> and I still got the same errors:
> -- Python checking for Mako templates 0.4.2 or greater
> -- Python checking for Mako templates 0.4.2 or greater - "import mako"
> failed
> etc.
>
> Would I have better luck if I cloned gnuradio and built it from scratch?
>
> ---
> Barry Duggan
>
>
> On 2019-06-30 18:38, sumit kumar wrote:
> > sudo apt install python-mako will work.
> > After this you will get some more errors on python related
> > dependencies,
> > like python-six etc , so manually install them.
> >
> >
> > On Sun, 30 Jun 2019 at 13:55, Barry Duggan  wrote:
> >
> >> Last evening I:
> >> -   downloaded Rasbian 'buster' using Torrent
> >> -   built new SD card with Raspian
> >> on raspberryPi, I followed instructions from
> >> https://wiki.gnuradio.org/index.php/InstallingGR#Using_PyBOMBS :
> >>sudo apt-get install python-pip
> >>sudo pip install pybombs
> >>pybombs auto-config
> >>pybombs recipes add-defaults
> >>pybombs prefix init ~/gnuradio -R gnuradio-default
> >>
> >> and got the following errors:
> >> -- Python checking for Python version 2.7 or greater
> >> -- Python checking for Python version 2.7 or greater - found
> >> --
> >> -- Python checking for Mako templates 0.4.2 or greater
> >> -- Python checking for Mako templates 0.4.2 or greater - "import mako"
> >> failed
> >> --
> >> -- Python checking for requests 2.0 or greater
> >> -- Python checking for requests 2.0 or greater - found
> >> --
> >> -- Python checking for numpy 1.7 or greater
> >> -- Python checking for numpy 1.7 or greater - found
> >> --
> >> -- Configuring LibUHD support...
> >> --   Dependency Boost_FOUND = 1
> >> --   Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
> >> --   Dependency HAVE_PYTHON_MODULE_MAKO = FALSE
> >> CMake Error at cmake/Modules/UHDComponent.cmake:59 (message):
> >>Dependencies for required component LibUHD not met.
> >> Call Stack (most recent call first):
> >>CMakeLists.txt:392 (LIBUHD_REGISTER_COMPONENT)
> >>
> >> -- Configuring incomplete, errors occurred!
> >> See also
> >> "/home/pi/gnuradio/src/uhd/host/build/CMakeFiles/CMakeOutput.log".
> >> See also
> >> "/home/pi/gnuradio/src/uhd/host/build/CMakeFiles/CMakeError.log".
> >> PyBOMBS.Packager.source - ERROR - Configuration failed after running
> >> at
> >> least twice.
> >> PyBOMBS.Packager.source - ERROR - Problem occurred while building
> >> package uhd:
> >> Configuration failed
> >> PyBOMBS.install_manager - ERROR - Error installing package uhd.
> >> Aborting.
> >>
> >> What is 'Mako'? Is that something I should download?
> >>
> >> Thanks,
> >> --
> >> Barry Duggan
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>
> >
> >
> > --
> > Sumit Kumar
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PyBOMBS.install_manager - Error installing package uhd.

2019-06-30 Thread sumit kumar

sudo apt install python-mako will work.
After this you will get some more errors on python related dependencies,
like python-six etc , so manually install them.


On Sun, 30 Jun 2019 at 13:55, Barry Duggan  wrote:

> Last evening I:
> -   downloaded Rasbian 'buster' using Torrent
> -   built new SD card with Raspian
> on raspberryPi, I followed instructions from
> https://wiki.gnuradio.org/index.php/InstallingGR#Using_PyBOMBS :
>sudo apt-get install python-pip
>sudo pip install pybombs
>pybombs auto-config
>pybombs recipes add-defaults
>pybombs prefix init ~/gnuradio -R gnuradio-default
>
> and got the following errors:
> -- Python checking for Python version 2.7 or greater
> -- Python checking for Python version 2.7 or greater - found
> --
> -- Python checking for Mako templates 0.4.2 or greater
> -- Python checking for Mako templates 0.4.2 or greater - "import mako"
> failed
> --
> -- Python checking for requests 2.0 or greater
> -- Python checking for requests 2.0 or greater - found
> --
> -- Python checking for numpy 1.7 or greater
> -- Python checking for numpy 1.7 or greater - found
> --
> -- Configuring LibUHD support...
> --   Dependency Boost_FOUND = 1
> --   Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
> --   Dependency HAVE_PYTHON_MODULE_MAKO = FALSE
> CMake Error at cmake/Modules/UHDComponent.cmake:59 (message):
>Dependencies for required component LibUHD not met.
> Call Stack (most recent call first):
>CMakeLists.txt:392 (LIBUHD_REGISTER_COMPONENT)
>
> -- Configuring incomplete, errors occurred!
> See also
> "/home/pi/gnuradio/src/uhd/host/build/CMakeFiles/CMakeOutput.log".
> See also
> "/home/pi/gnuradio/src/uhd/host/build/CMakeFiles/CMakeError.log".
> PyBOMBS.Packager.source - ERROR - Configuration failed after running at
> least twice.
> PyBOMBS.Packager.source - ERROR - Problem occurred while building
> package uhd:
> Configuration failed
> PyBOMBS.install_manager - ERROR - Error installing package uhd.
> Aborting.
>
> What is 'Mako'? Is that something I should download?
>
> Thanks,
> --
> Barry Duggan
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


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

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

2019-06-27 Thread sumit kumar

Thats true, thanks. meanwhile the UDP problem is solved. I had to run the
command as root :D not sudo.

On Thu, 27 Jun 2019 at 20:07, Michael Dickens 
wrote:

> I guess for your need so long as it works that's what matters, yes?
>
> We'll work on fixing the issue you found anyway ... seems like it's legit
> & undesirable LOL.
>
> Good luck with your demo! - MLD
>
> On Thu, Jun 27, 2019, at 2:01 PM, sumit kumar wrote:
>
> Well it worked after compiling old checkouts (but not giving me the usual
> satisfaction of a fresh install... but anyways)
>
> On Thu, 27 Jun 2019 at 19:45, sumit kumar  wrote:
>
> Its overwhelming :D, I have a demo on Monday and I was 100% assured
> gr-ieee-80211 will work as usual.
>
> Before I saw your mail, I already checked out GR to 3.7.12, UHD to 003 009
> 006 and compiling now.
> Yes I used pybombs for installation.
>
> I have a USB with gnuradio installed into it. It works good and it has GR
> 3.7.11, uhd 003 009 006 and gr-ieee-80211 version I dint check.
>
>
>

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

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

2019-06-27 Thread sumit kumar

Well it worked after compiling old checkouts (but not giving me the usual
satisfaction of a fresh install... but anyways)

On Thu, 27 Jun 2019 at 19:45, sumit kumar  wrote:

> Its overwhelming :D, I have a demo on Monday and I was 100% assured
> gr-ieee-80211 will work as usual.
>
> Before I saw your mail, I already checked out GR to 3.7.12, UHD to 003 009
> 006 and compiling now.
> Yes I used pybombs for installation.
>
> I have a USB with gnuradio installed into it. It works good and it has GR
> 3.7.11, uhd 003 009 006 and gr-ieee-80211 version I dint check.
>
>
>
> On Thu, 27 Jun 2019 at 19:31, Michael Dickens 
> wrote:
>
>> Hmmm ... well the current UHD API for "set_auto_dc_offset" is
>> "(bool, size_t)". Looks like the generated Python from gr-ieee-80211 is
>> "set_auto_dc_offset("", 0)", which isn't compatible with the current UHD
>> API for this method.
>>
>> Hmmm ... here's my best bet: gr-ieee802-11 uses the GR-provided GRC
>> blocks (whether XML or YML). Guessing you're using some reasonably recently
>> (e.g., 2019) GR 3.8-tech-preview commit. If that's the case, then here's
>> what seems to be the issue ... In this commit <
>> https://github.com/gnuradio/gnuradio/commit/4804d1fdb6950d2b2ec5707cd8a362f01ed2cf90
>>  >,
>> then file "gr-uhd/grc/gen_uhd_usrp_blocks.py" was dramatically changed to
>> generate the YML required by the 3.8 GRC. The API for
>> "set_auto_dc_offset" was removed entirely ... not sure why ... but somehow
>> GRC when "compiling" the flowgraph from YML into Python generates that
>> command improperly.
>>
>> You said you used PyBOMBS to install everything ... yes? The UHD is the
>> current GIT master, so bleeding edge LOL.
>>
>> Any way you can figure out which commit of GNU Radio and gr-ieee-80211
>> were used? The latter was recently updated such that the GIT master
>> corresponds to GR 3.8, while "main-3.7" is for the current GR "maint-3.7"
>> branch ... - MLD
>>
>> On Thu, Jun 27, 2019, at 12:59 PM, sumit kumar wrote:
>>
>> Sure I will try that, meanwhile any tip on the other issue, i.e.,
>>
>> *TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2
>> of type 'bool'*
>>
>> Regards
>> Sumit
>>
>>
>>
>
> --
> Sumit Kumar
>
>
>

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

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

2019-06-27 Thread sumit kumar

Its overwhelming :D, I have a demo on Monday and I was 100% assured
gr-ieee-80211 will work as usual.

Before I saw your mail, I already checked out GR to 3.7.12, UHD to 003 009
006 and compiling now.
Yes I used pybombs for installation.

I have a USB with gnuradio installed into it. It works good and it has GR
3.7.11, uhd 003 009 006 and gr-ieee-80211 version I dint check.



On Thu, 27 Jun 2019 at 19:31, Michael Dickens 
wrote:

> Hmmm ... well the current UHD API for "set_auto_dc_offset" is
> "(bool, size_t)". Looks like the generated Python from gr-ieee-80211 is
> "set_auto_dc_offset("", 0)", which isn't compatible with the current UHD
> API for this method.
>
> Hmmm ... here's my best bet: gr-ieee802-11 uses the GR-provided GRC blocks
> (whether XML or YML). Guessing you're using some reasonably recently (e.g.,
> 2019) GR 3.8-tech-preview commit. If that's the case, then here's what
> seems to be the issue ... In this commit <
> https://github.com/gnuradio/gnuradio/commit/4804d1fdb6950d2b2ec5707cd8a362f01ed2cf90
>  >,
> then file "gr-uhd/grc/gen_uhd_usrp_blocks.py" was dramatically changed to
> generate the YML required by the 3.8 GRC. The API for
> "set_auto_dc_offset" was removed entirely ... not sure why ... but somehow
> GRC when "compiling" the flowgraph from YML into Python generates that
> command improperly.
>
> You said you used PyBOMBS to install everything ... yes? The UHD is the
> current GIT master, so bleeding edge LOL.
>
> Any way you can figure out which commit of GNU Radio and gr-ieee-80211
> were used? The latter was recently updated such that the GIT master
> corresponds to GR 3.8, while "main-3.7" is for the current GR "maint-3.7"
> branch ... - MLD
>
> On Thu, Jun 27, 2019, at 12:59 PM, sumit kumar wrote:
>
> Sure I will try that, meanwhile any tip on the other issue, i.e.,
>
> *TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
> type 'bool'*
>
> Regards
> Sumit
>
>
>

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

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

2019-06-27 Thread sumit kumar

Sure I will try that, meanwhile any tip on the other issue, i.e.,

*TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
type 'bool'*

Regards
Sumit



On Thu, 27 Jun 2019 at 18:54, Michael Dickens 
wrote:

> I'm no expert on what to change here, but I'd guess there's another
> setting that's the correct one for your specific OS & version, and that
> "net.core.rmem_max" is the correct one for some other OS and/or version.
> Maybe do a quick internet search for how to change the UDP buffer size on
> your OS and version? Maybe someone else in GR-land has seen this issue &
> knows what to do? - MLD
>
> On Thu, Jun 27, 2019, at 12:43 PM, sumit kumar wrote:
>
> This happens after running *sudo sysctl -w net.core.rmem_max=5000*
>
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.15.0.git-1-gf83faf28
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> [WARNING] [UDP] The recv buffer could not be resized sufficiently.
> Target sock buff size: 5000 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=5000
> [WARNING] [UDP] The current recv_buff_size of 212992 is less than the
> minimum recommended size of 307200 and may result in dropped packets on
> some NICs
> [WARNING] [UDP] The recv buffer could not be resized sufficiently.
> Target sock buff size: 5000 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=5000
> [WARNING] [UDP] The current recv_buff_size of 212992 is less than the
> minimum recommended size of 307200 and may result in dropped packets on
> some NICs
> [WARNING] [UDP] The recv buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=250
> [WARNING] [UDP] The current recv_buff_size of 212992 is less than the
> minimum recommended size of 307200 and may result in dropped packets on
> some NICs
> [WARNING] [UDP] The recv buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=250
> [WARNING] [UDP] The current recv_buff_size of 212992 is less than the
> minimum recommended size of 307200 and may result in dropped packets on
> some NICs
> [WARNING] [UHD] Unable to set the thread priority. Performance may be
> negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> Traceback (most recent call last):
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 374, in 
> main()
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 362, in main
> tb = top_block_cls()
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 151, in __init__
> self.uhd_usrp_source_0.set_auto_dc_offset("", 0)
>   File
> "/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 3499, in set_auto_dc_offset
> return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
> TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
> type 'bool'
>
>
>

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

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

2019-06-27 Thread sumit kumar

This happens after running *sudo sysctl -w net.core.rmem_max=5000*

[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.15.0.git-1-gf83faf28
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
[WARNING] [UDP] The recv buffer could not be resized sufficiently.
Target sock buff size: 5000 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=5000
[WARNING] [UDP] The current recv_buff_size of 212992 is less than the
minimum recommended size of 307200 and may result in dropped packets on
some NICs
[WARNING] [UDP] The recv buffer could not be resized sufficiently.
Target sock buff size: 5000 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=5000
[WARNING] [UDP] The current recv_buff_size of 212992 is less than the
minimum recommended size of 307200 and may result in dropped packets on
some NICs
[WARNING] [UDP] The recv buffer could not be resized sufficiently.
Target sock buff size: 250 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=250
[WARNING] [UDP] The current recv_buff_size of 212992 is less than the
minimum recommended size of 307200 and may result in dropped packets on
some NICs
[WARNING] [UDP] The recv buffer could not be resized sufficiently.
Target sock buff size: 250 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=250
[WARNING] [UDP] The current recv_buff_size of 212992 is less than the
minimum recommended size of 307200 and may result in dropped packets on
some NICs
[WARNING] [UHD] Unable to set the thread priority. Performance may be
negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
Traceback (most recent call last):
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
374, in 
main()
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
362, in main
tb = top_block_cls()
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
151, in __init__
self.uhd_usrp_source_0.set_auto_dc_offset("", 0)
  File
"/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3499, in set_auto_dc_offset
return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
type 'bool'

On Thu, 27 Jun 2019 at 18:34, sumit kumar  wrote:

> Hi Michael, Yes indeed, tried till  500, still no luck.
>
> Regards
> Sumit
>
> On Thu, 27 Jun 2019 at 18:30, Michael Dickens 
> wrote:
>
>> Hi Sumit - Just out of curiosity, have you tried the command the warning
>> asks you to execute?
>> {{{
>> sudo sysctl -w net.core.wmem_max=2500000
>> }}}
>> If not then please try it & see if that helps. - MLD
>>
>> On Thu, Jun 27, 2019, at 12:27 PM, sumit kumar wrote:
>>
>> OS: Ubuntu 18.04
>> Laptop: Dell Latitude 5490
>> GNU Radio : 3.7.13.5
>> UHD : UHD_3.15.0.git-1-gf83faf28
>> SDR: Ettus N200
>>
>> I did a fresh install today using pybombs.
>>
>> Then tried running wifi_rx.grc from gr-ieee-80211 package and flooded
>> with errors. Never seen them before. Bold marked part is coming with all
>> the programs where I am connected to USRP such as uhd_fft while the rest
>> happens with wifi_rx.grc (this is what I have observed so far).
>>
>> However, all the programs are working flawlessly with older version.
>>
>> Any tips to solve it.
>>
>> Regards
>> Sumit
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
>> UHD_3.15.0.git-1-gf83faf28[INFO] [USRP2] Opening a USRP2/N-Series
>> device...[INFO] [USRP2] Current recv frame size: 1472 bytes[INFO] [USRP2]
>> Current send frame size: 1472 bytes[WARNING] [UDP] The send buffer could
>> not be resized sufficiently.Target sock buff size: 250 bytes.Actual
>> sock buff size: 212992 bytes.See the transport application notes on buffer
>> resizing.Please run: sudo sysctl -w net.core.wmem_max=250[WARNING]
>> [UDP] The current se

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

2019-06-27 Thread sumit kumar

Hi Michael, Yes indeed, tried till  500, still no luck.

Regards
Sumit

On Thu, 27 Jun 2019 at 18:30, Michael Dickens 
wrote:

> Hi Sumit - Just out of curiosity, have you tried the command the warning
> asks you to execute?
> {{{
> sudo sysctl -w net.core.wmem_max=250
> }}}
> If not then please try it & see if that helps. - MLD
>
> On Thu, Jun 27, 2019, at 12:27 PM, sumit kumar wrote:
>
> OS: Ubuntu 18.04
> Laptop: Dell Latitude 5490
> GNU Radio : 3.7.13.5
> UHD : UHD_3.15.0.git-1-gf83faf28
> SDR: Ettus N200
>
> I did a fresh install today using pybombs.
>
> Then tried running wifi_rx.grc from gr-ieee-80211 package and flooded with
> errors. Never seen them before. Bold marked part is coming with all the
> programs where I am connected to USRP such as uhd_fft while the rest
> happens with wifi_rx.grc (this is what I have observed so far).
>
> However, all the programs are working flawlessly with older version.
>
> Any tips to solve it.
>
> Regards
> Sumit
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.15.0.git-1-gf83faf28[INFO] [USRP2] Opening a USRP2/N-Series
> device...[INFO] [USRP2] Current recv frame size: 1472 bytes[INFO] [USRP2]
> Current send frame size: 1472 bytes[WARNING] [UDP] The send buffer could
> not be resized sufficiently.Target sock buff size: 250 bytes.Actual
> sock buff size: 212992 bytes.See the transport application notes on buffer
> resizing.Please run: sudo sysctl -w net.core.wmem_max=250[WARNING]
> [UDP] The current send_buff_size of 212992 is less than the minimum
> recommended size of 307200 and may result in dropped packets on some
> NICs[WARNING] [UDP] The send buffer could not be resized
> sufficiently.Target sock buff size: 250 bytes.Actual sock buff size:
> 212992 bytes.See the transport application notes on buffer resizing.Please
> run: sudo sysctl -w net.core.wmem_max=250[WARNING] [UDP] The current
> send_buff_size of 212992 is less than the minimum recommended size of
> 307200 and may result in dropped packets on some NICs[WARNING] [UDP] The
> send buffer could not be resized sufficiently.Target sock buff size:
> 1048576 bytes.Actual sock buff size: 212992 bytes.See the transport
> application notes on buffer resizing.Please run: sudo sysctl -w
> net.core.wmem_max=1048576[WARNING] [UDP] The current send_buff_size of
> 212992 is less than the minimum recommended size of 307200 and may result
> in dropped packets on some NICs[WARNING] [UDP] The send buffer could not be
> resized sufficiently.Target sock buff size: 250 bytes.Actual sock buff
> size: 212992 bytes.See the transport application notes on buffer
> resizing.Please run: sudo sysctl -w net.core.wmem_max=250[WARNING]
> [UDP] The current send_buff_size of 212992 is less than the minimum
> recommended size of 307200 and may result in dropped packets on some
> NICs[WARNING] [UHD] Unable to set the thread priority. Performance may be
> negatively affected.Please see the general application notes in the manual
> for instructions.EnvironmentError: OSError: error in pthread_setschedparam*
>
> Traceback (most recent call last):
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 374, in 
> main()
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 362, in main
> tb = top_block_cls()
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 151, in __init__
> self.uhd_usrp_source_0.set_auto_dc_offset("false", 0)
>   File
> "/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 3499, in set_auto_dc_offset
> return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
> TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
> type 'bool'
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>

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

[Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

2019-06-27 Thread sumit kumar

OS: Ubuntu 18.04
Laptop: Dell Latitude 5490
GNU Radio : 3.7.13.5
UHD : UHD_3.15.0.git-1-gf83faf28
SDR: Ettus N200

I did a fresh install today using pybombs.

Then tried running wifi_rx.grc from gr-ieee-80211 package and flooded with
errors. Never seen them before. Bold marked part is coming with all the
programs where I am connected to USRP such as uhd_fft while the rest
happens with wifi_rx.grc (this is what I have observed so far).

However, all the programs are working flawlessly with older version.

Any tips to solve it.

Regards
Sumit































*[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.15.0.git-1-gf83faf28[INFO] [USRP2] Opening a USRP2/N-Series
device...[INFO] [USRP2] Current recv frame size: 1472 bytes[INFO] [USRP2]
Current send frame size: 1472 bytes[WARNING] [UDP] The send buffer could
not be resized sufficiently.Target sock buff size: 250 bytes.Actual
sock buff size: 212992 bytes.See the transport application notes on buffer
resizing.Please run: sudo sysctl -w net.core.wmem_max=250[WARNING]
[UDP] The current send_buff_size of 212992 is less than the minimum
recommended size of 307200 and may result in dropped packets on some
NICs[WARNING] [UDP] The send buffer could not be resized
sufficiently.Target sock buff size: 250 bytes.Actual sock buff size:
212992 bytes.See the transport application notes on buffer resizing.Please
run: sudo sysctl -w net.core.wmem_max=250[WARNING] [UDP] The current
send_buff_size of 212992 is less than the minimum recommended size of
307200 and may result in dropped packets on some NICs[WARNING] [UDP] The
send buffer could not be resized sufficiently.Target sock buff size:
1048576 bytes.Actual sock buff size: 212992 bytes.See the transport
application notes on buffer resizing.Please run: sudo sysctl -w
net.core.wmem_max=1048576[WARNING] [UDP] The current send_buff_size of
212992 is less than the minimum recommended size of 307200 and may result
in dropped packets on some NICs[WARNING] [UDP] The send buffer could not be
resized sufficiently.Target sock buff size: 250 bytes.Actual sock buff
size: 212992 bytes.See the transport application notes on buffer
resizing.Please run: sudo sysctl -w net.core.wmem_max=250[WARNING]
[UDP] The current send_buff_size of 212992 is less than the minimum
recommended size of 307200 and may result in dropped packets on some
NICs[WARNING] [UHD] Unable to set the thread priority. Performance may be
negatively affected.Please see the general application notes in the manual
for instructions.EnvironmentError: OSError: error in pthread_setschedparam*

Traceback (most recent call last):
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
374, in 
main()
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
362, in main
tb = top_block_cls()
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
151, in __init__
self.uhd_usrp_source_0.set_auto_dc_offset("false", 0)
  File
"/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3499, in set_auto_dc_offset
return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
type 'bool'
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Companion crashes without any error.

2019-01-28 Thread Sumit Kumar

Hi,

I am having this issue on a freshly installed Ubuntu 16.04 machine.

I installed GNU Radio using apt-get and then gr-ieee 80211. While running
an example of gr-ieee 80211 (wifi_loopback.grc), it runs for a while and
stops -- no error or any log on the terminal at all.

Here is a video: https://www.youtube.com/watch?v=vmpb0_G6DBc

In an another case, while running ofdm_loopback.grc located in
*/usr/share/gnuradio/examples/digital/ofdm/*

, the ofdm_loopback generates 39 packets correctly, before exiting with the
error "std::bad_alloc" for packet 40 and 41.

It is a formatted new laptop, and everything is clean, no residue of the
previous install, etc. Could anyone please give me a clue to debug it.

Let me know if more information is needed.

Regards

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

Re: [Discuss-gnuradio] can USRP 2901 be interfaced with GNU radio

2018-10-04 Thread sumit kumar

Did you install uhd also. Before running flowgraph can you do
uhd_find_device.
I am using USRP 2901 with gnuradio without any issue.

On Thu, 4 Oct 2018, 14:34 Christopher Clement J, <
christopher.clem...@vit.ac.in> wrote:

> Hi,
>
> I have installed GNU radio using PyBombs in Ubuntu 18.04.
>
> I am interfacing NI USRP 2901 with GNU radio. But when I run the flow
> graph, it says that, "No devices found for" so and so device address.
>
> What should I give in the "device address" field of UHD:USRP Sink
> properties, also, what should I give in the device arguments field? Could
> somebody help me in this?
>
> Is there a different firmware for this support?, please let me know.
>
> Regards
> J. Chris Clement
>
>
> ___
> 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] SNR of BPSK

2018-09-25 Thread Sumit Kumar


Hello Suresh,

Dump the SNR values in a file. Then read the file using 
read_float_binary.m utility available in gr-utils/octave.


Hope this helps

Regards

Sumit


On 25/09/2018 18:43, tadikondasuresh wrote:
Good evening Sir, ..Sir i am working on GNURADIO tool..and i am 
developing BPSK modulation and i tried SNR calculation in that and i 
already calculated the  SNR value and i want to send that value in to 
text file,but i could not able to send that value in to file.. please 
help me sir..please find outthe grc file attached



Thanks & Regards,
Suresh T,
Navstar Integrated Systems Pvt ltd,
9866212494


___
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] port number 1 exceeds max of 0

2018-09-25 Thread Sumit Kumar


Hi,

I have made a block with take two streams of input and produces four 
stream of outputs.


The*impl.cc* file has the following declaration:

static int ios1[] = {48, 48*sizeof(float), 48, 48*sizeof(float)};
static std::vector iosig1(ios1, ios1+sizeof(ios1)/sizeof(int));

soft_frame_equalizer_impl_dc::soft_frame_equalizer_impl_dc(Equalizer_soft_dc 
algo, double freq, double bw, int scaling, int threshold, bool log, bool 
debug) :

    gr::block("soft_frame_equalizer_dc",
            gr::io_signature::make2(2, 2, 64 * sizeof(gr_complex), 64 * 
sizeof(gr_complex)),

            gr::io_signature::makev(4, 4, iosig1)),

I made the corresponding xml file also. No error during compiling but 
when I connect my block and run I get the error:


  File 
"/home/john/myprefix/src/gr-ieee-80211/examples/sbmrc_testing.py", line 
555, in 

    main()
  File 
"/home/john/myprefix/src/gr-ieee-80211/examples/sbmrc_testing.py", line 
543, in main
    tb = top_block_cls(bandwidth=options.bandwidth, 
encoding=options.encoding, frequency=options.frequency, 
sensitivity=options.sensitivity)
  File 
"/home/john/myprefix/src/gr-ieee-80211/examples/sbmrc_testing.py", line 
350, in __init__
    self.connect((self.fft_vxx_0_1, 0), 
(self.ieee802_11_soft_frame_equalizer_dc_0, 1))
  File 
"/home/john/myprefix/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", 
line 47, in wrapped

    func(self, src, src_port, dst, dst_port)
  File 
"/home/john/myprefix/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", 
line 110, in connect

    self.primitive_connect(*args)
  File 
"/home/john/myprefix/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", 
line 4574, in primitive_connect

    return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
*ValueError: port number 1 exceeds max of 0*

I am attaching the xml file. Can anyone help me figuring out the mistake :)

Regards

Sumit




  Soft frame equalizer DC
  ieee802_11_soft_frame_equalizer_dc
  [IEEE802.11]
  import ieee802_11
  ieee802_11.soft_frame_equalizer($algo, $freq, $bw, $scaling, $threshold, $log, $debug)
	set_algorithm($algo)
	set_frequency($freq)
	set_bandwidth($bw)

	
		Algorithm
		algo
		ieee802_11.LS
		int

		
			LS
			ieee802_11.LS
		
		
			LMS
			ieee802_11.LMS
		
		
			Comb
			ieee802_11.COMB
		
		
			STA
			ieee802_11.STA
		
	

	
		Frequency
		freq
		5.89e9
		real
	

	
		Bandwidth
		bw
		10e6
		real
	

	
		Scaling
		scaling
		0
		real
	

	
		Threshold
		threshold
		0
		real
	

	
		Log
		log
		False
		bool

		
			Enable
			True
		
		
			Disable
			False
		
	

	
		Debug
		debug
		False
		bool

		
			Enable
			True
		
		
			Disable
			False
		
	

	
		in
		complex
		64
		1
	

	
		in_1
		complex
		64
		1
	

	
		out
		byte
		48
		1
	

	
		llr_out
		float
		48
		1
	

	
		out_1
		byte
		48
		1
	

	
		llr_out_1
		float
		48
		1
	

	
		symbols
		message
1
	


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

Re: [Discuss-gnuradio] how to read .dat file saved via the file sink

2018-07-31 Thread sumit kumar

There is an octave script in gnuradio utilities. read_complex_binary.m
It will show you the IQ data

On Tue, 31 Jul 2018, 19:22 Linda20071,  wrote:

> I saved the transmitted complex signal (I/Q data) in a .dat file using the
> file sink. How could I read the I/Q data in this saved .dat file?
>
> Thanks in advance!
> ___
> 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] Resetting the packet counter in gr-ieee 802.11

2018-06-26 Thread Sumit Kumar


Hi,

(The question is not very specific to gr-ieee 802.11 :) )

I have made a pdu frame counter in gr-ieee 802.11. For that I have done 
some modifications in parse_mac.cc (line 272, file attached). Its very 
small change where I do


*d_total_packets += 1;*

after every successful wfi frame reception.

And then I pass *d_total_packets *thru message port for display and I 
see total packets received like this :




Now I need to reset this frame counter at run time to zero when I check 
a qt-gui-check box. But I am not getting the idea for doing that.


In qt-gui-check box I can make a variable to go true or false. But then 
how to convey this information to the parse_data() function in the 
attached file at run time. A kind of flag which resets d_total_packets 
to 0 without killing the flow graph.


I have attached the parse_mac.cc (line 191) for reference.

Regards

Sumit

/*
 * Copyright (C) 2013, 2016 Bastian Bloessl 
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see .
 */
#include 
#include "utils.h"

#include 
#include 
#include 

using namespace gr::ieee802_11;

class parse_mac_impl : public parse_mac {

public:

parse_mac_impl(bool log, bool debug) :
		block("parse_mac",
gr::io_signature::make(0, 0, 0),
gr::io_signature::make(0, 0, 0)),
		d_log(log), d_last_seq_no(-1), d_total_packets(0),
		d_debug(debug) {

	message_port_register_in(pmt::mp("in"));
	set_msg_handler(pmt::mp("in"), boost::bind(&parse_mac_impl::parse, this, _1));

	message_port_register_out(pmt::mp("fer"));
	message_port_register_out(pmt::mp("tpr"));
}

~parse_mac_impl() {

}

void parse(pmt::pmt_t msg) {

	if(pmt::is_eof_object(msg)) {
		detail().get()->set_done(true);
		return;
	} else if(pmt::is_symbol(msg)) {
		return;
	}

	msg = pmt::cdr(msg);

	int data_len = pmt::blob_length(msg);
	mac_header *h = (mac_header*)pmt::blob_data(msg);

	mylog(boost::format("length: %1%") % data_len );

	dout << std::endl << "new mac frame  (length " << data_len << ")" << std::endl;
	dout << "=" << std::endl;
	if(data_len < 20) {
		dout << "frame too short to parse (<20)" << std::endl;
		return;
	}
	#define HEX(a) std::hex << std::setfill('0') << std::setw(2) << int(a) << std::dec
	dout << "duration: " << HEX(h->duration >> 8) << " " << HEX(h->duration  & 0xff) << std::endl;
	dout << "frame control: " << HEX(h->frame_control >> 8) << " " << HEX(h->frame_control & 0xff);

switch((h->frame_control >> 2) & 3) {

		case 0:
			dout << " (MANAGEMENT)" << std::endl;
			parse_management((char*)h, data_len);
			break;
		case 1:
			dout << " (CONTROL)" << std::endl;
			parse_control((char*)h, data_len);
			break;

		case 2:
			dout << " (DATA)" << std::endl;
			parse_data((char*)h, data_len);
			break;

		default:
			dout << " (unknown)" << std::endl;
			break;
	}

	char *frame = (char*)pmt::blob_data(msg);

	// DATA
	ifh->frame_control) >> 2) & 63) == 2) {
		print_ascii(frame + 24, data_len - 24);
	// QoS Data
	} else ifh->frame_control) >> 2) & 63) == 34) {
		print_ascii(frame + 26, data_len - 26);
	}
}

void parse_management(char *buf, int length) {
	mac_header* h = (mac_header*)buf;

	if(length < 24) {
		dout << "too short for a management frame" << std::endl;
		return;
	}

	dout << "Subtype: ";
	switch(((h->frame_control) >> 4) & 0xf) {
		case 0:
			dout << "Association Request";
			break;
		case 1:
			dout << "Association Response";
			break;
		case 2:
			dout << "Reassociation Request";
			break;
		case 3:
			dout << "Reassociation Response";
			break;
		case 4:
			dout << "Probe Request";
			break;
		case 5:
			dout << "Probe Response";
			break;
		case 6:
			dout << "Timing Advertisement";
			break;
		case 7:
			dout << "Reserved";
			break;
		case 8:
			dout << "Beacon" << std::endl;
			if(length < 38) {
return;
			}
			{
			uint8_t* len = (uint8_t*) (buf + 24 + 13);
			if(length < 38 + *len) {
return;
			}
			std::string s(buf + 24 + 14, *len);
			dout << "SSID: " << s;
			}
			break;
		case 9:
			dout << "ATIM";
			break;
		case 10:
			dout << "Disassociation";
			break;
		case 11:
			dout << "Authentication";
			break;
		case 12:
			dout << "Deauthentication";
			break;
		case 13:
			dout << "Action";
			break;
		case 14:
			dout << "Action No ACK";
			break;
		case 15:
			dout << "Reserved";
			break;
		default:
			break;
	}
	dout << std::endl;

	dout << "seq nr: " << int(h->seq_nr >> 4)

Re: [Discuss-gnuradio] Correct way to add constructor parameter

2018-06-07 Thread Sumit Kumar

Ok this was very useful indeed :) Gives me lots of ideas to optimize my 
current flow graph.


Thanks

Sumit

On 06/06/2018 18:47, Müller, Marcus (CEL) wrote:

Also, while you're at it: If you have parameters (like potentially your
scaling) that you'd like to update externally, for example from a
different block, it's not that bad an idea to add a "command" message
port, with a message handler that does the setting.

I mention this because messages are handled only when the
[general_]work() is not currently running – and that means that
changing a property of the block through a message handler is
inherently thread-safe, which is important in the context of GNU Radio.
For examples, in cases where you could change the length of a tap
vector, you wouldn't want to do that in the middle of a convolution of
that tap vector, but another block (let's say a channel estimator that
has calculated a new set of equalizer taps) can't know whether you're
currently working with the taps or not.

Best regards,
Marcus

On Wed, 2018-06-06 at 18:33 +0200, Sumit Kumar wrote:

Oops.. missed that. Thanks, its done now :)
Sumit

On 06/06/2018 18:28, Ron Economos wrote:

You have to add the variable in the . line of the .xml file.
Ron
On 06/06/2018 09:08 AM, Sumit Kumar wrote:

I am adding additional option in a GRC block. Its Soft Frame Equalizer


As you see in the figure, the block has options for Algorithm, Frequency, Bandwidth, Log 
and Debug. I added my own variable "Scaling".

For this, first I edited in soft_frame_equalizer_impl.cc as follows :

soft_frame_equalizer::sptr
soft_frame_equalizer::make(Equalizer_soft algo, double freq, double bw, int 
scaling, bool log, bool debug) {
 return gnuradio::get_initial_sptr
 (new soft_frame_equalizer_impl(algo, freq, bw, scaling, log, debug));
}


soft_frame_equalizer_impl::soft_frame_equalizer_impl(Equalizer_soft algo, 
double freq, double bw, int scaling, bool log, bool debug) :
 gr::block("soft_frame_equalizer",
 gr::io_signature::make(1, 1, 64 * sizeof(gr_complex)),
 gr::io_signature::make2(2, 2, 48, 48 * sizeof(float))),
 d_current_symbol(0), d_log(log), d_debug(debug), d_equalizer(NULL),
 d_freq(freq), d_bw(bw), d_scaling(scaling), d_frame_bytes(0), 
d_frame_symbols(0),
 d_freq_offset_from_synclong(0.0)

void
soft_frame_equalizer_impl::set_scaling(int scaling) {
 d_scaling = scaling;
}

And then in soft_frame_equalizer_impl.h as follows :

public:
 soft_frame_equalizer_impl(Equalizer_soft algo, double freq, double bw, int 
scaling, bool log, bool debug);
 ~soft_frame_equalizer_impl();

 void set_algorithm(Equalizer_soft algo);
 void set_bandwidth(double bw);
 void set_frequency(double freq);
 void set_scaling(int scaling);

private:

int d_scaling;

And then in soft_frame_equalizer.h from the include directory as follows :

public:
 typedef boost::shared_ptr sptr;
 static sptr make(Equalizer_soft algo, double freq, double bw, int scaling,
 bool log, bool debug);
 virtual void set_algorithm(Equalizer_soft algo) = 0;
 virtual void set_bandwidth(double bw) = 0;
 virtual void set_frequency(double freq) = 0;
 virtual void set_scaling(int scaling) = 0;

And finally in the xml file as follows :

 
 Scaling
 scaling
 0
 real
 

It compiles well, but when I execute the program, it throws following error:

sender started
Traceback (most recent call last):
   File 
"/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py",
 line 569, in 
 main()
   File 
"/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py",
 line 557, in main
 tb = top_block_cls(bandwidth=options.bandwidth, encoding=options.encoding, 
frequency=options.frequency, sensitivity=options.sensitivity)
   File 
"/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py",
 line 282, in __init__
 self.ieee802_11_soft_frame_equalizer_0 = 
ieee802_11.soft_frame_equalizer(ieee802_11.LS, 2.437e9, 20e6, False, False)
   File 
"/home/john/myprefix/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py",
 line 644, in make
 return _ieee802_11_swig.soft_frame_equalizer_make(*args, **kwargs)
TypeError: Required argument 'debug' (pos 6) not found

What I am missing ? Where else I need to edit ?

Regards
Sumit


___
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] Correct way to add constructor parameter

2018-06-06 Thread Sumit Kumar


Oops.. missed that. Thanks, its done now :)

Sumit


On 06/06/2018 18:28, Ron Economos wrote:


You have to add the variable in the . line of the 
.xml file.


Ron

On 06/06/2018 09:08 AM, Sumit Kumar wrote:



I am adding additional option in a GRC block. Its Soft Frame Equalizer



As you see in the figure, the block has options for Algorithm, 
Frequency, Bandwidth, Log and Debug. I added my own variable 
"*Scaling*".


For this, first I edited in soft_frame_equalizer_impl.cc as follows :

soft_frame_equalizer::sptr
soft_frame_equalizer::make(Equalizer_soft algo, double freq, double 
bw,*int scaling*, bool log, bool debug) {

    return gnuradio::get_initial_sptr
        (new soft_frame_equalizer_impl(algo, freq, bw, scaling, log, 
debug));

}


soft_frame_equalizer_impl::soft_frame_equalizer_impl(Equalizer_soft 
algo, double freq, double bw, *int scaling*, bool log, bool debug) :

    gr::block("soft_frame_equalizer",
            gr::io_signature::make(1, 1, 64 * sizeof(gr_complex)),
            gr::io_signature::make2(2, 2, 48, 48 * sizeof(float))),
    d_current_symbol(0), d_log(log), d_debug(debug), d_equalizer(NULL),
    d_freq(freq), d_bw(bw), *d_scaling(scaling)*, d_frame_bytes(0), 
d_frame_symbols(0),

    d_freq_offset_from_synclong(0.0)

*void**
**soft_frame_equalizer_impl::set_scaling(int scaling) {**
**    d_scaling = scaling;**
**}*

And then in soft_frame_equalizer_impl.h as follows :

public:
    soft_frame_equalizer_impl(Equalizer_soft algo, double freq, 
double bw, *int scaling*, bool log, bool debug);

    ~soft_frame_equalizer_impl();

    void set_algorithm(Equalizer_soft algo);
    void set_bandwidth(double bw);
    void set_frequency(double freq);
*void set_scaling(int scaling);

*private:*

int d_scaling;
*
And then in soft_frame_equalizer.h from the include directory as 
follows :


public:
    typedef boost::shared_ptr sptr;
    static sptr make(Equalizer_soft algo, double freq, double bw, 
*int scaling,*

            bool log, bool debug);
    virtual void set_algorithm(Equalizer_soft algo) = 0;
    virtual void set_bandwidth(double bw) = 0;
    virtual void set_frequency(double freq) = 0;
*virtual void set_scaling(int scaling) = 0;

*And finally in the xml file as follows : *

    
        Scaling
        scaling
        0
        real
    

*It compiles well, but when I execute the program, it throws 
following error:


sender started
Traceback (most recent call last):
  File 
"/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py", 
line 569, in 

    main()
  File 
"/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py", 
line 557, in main
    tb = top_block_cls(bandwidth=options.bandwidth, 
encoding=options.encoding, frequency=options.frequency, 
sensitivity=options.sensitivity)
  File 
"/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py", 
line 282, in __init__
    self.ieee802_11_soft_frame_equalizer_0 = 
ieee802_11.soft_frame_equalizer(ieee802_11.LS, 2.437e9, 20e6, False, 
False)
  File 
"/home/john/myprefix/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py", 
line 644, in make

    return _ieee802_11_swig.soft_frame_equalizer_make(*args, **kwargs)
TypeError: Required argument 'debug' (pos 6) not found

What I am missing ? Where else I need to edit ?

Regards
Sumit


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




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


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

[Discuss-gnuradio] Correct way to add constructor parameter

2018-06-06 Thread Sumit Kumar



I am adding additional option in a GRC block. Its Soft Frame Equalizer



As you see in the figure, the block has options for Algorithm, 
Frequency, Bandwidth, Log and Debug. I added my own variable "*Scaling*".


For this, first I edited in soft_frame_equalizer_impl.cc as follows :

soft_frame_equalizer::sptr
soft_frame_equalizer::make(Equalizer_soft algo, double freq, double 
bw,*int scaling*, bool log, bool debug) {

    return gnuradio::get_initial_sptr
        (new soft_frame_equalizer_impl(algo, freq, bw, scaling, log, 
debug));

}


soft_frame_equalizer_impl::soft_frame_equalizer_impl(Equalizer_soft 
algo, double freq, double bw, *int scaling*, bool log, bool debug) :

    gr::block("soft_frame_equalizer",
            gr::io_signature::make(1, 1, 64 * sizeof(gr_complex)),
            gr::io_signature::make2(2, 2, 48, 48 * sizeof(float))),
    d_current_symbol(0), d_log(log), d_debug(debug), d_equalizer(NULL),
    d_freq(freq), d_bw(bw), *d_scaling(scaling)*, d_frame_bytes(0), 
d_frame_symbols(0),

    d_freq_offset_from_synclong(0.0)

*void**
**soft_frame_equalizer_impl::set_scaling(int scaling) {**
**    d_scaling = scaling;**
**}*

And then in soft_frame_equalizer_impl.h as follows :

public:
    soft_frame_equalizer_impl(Equalizer_soft algo, double freq, double 
bw, *int scaling*, bool log, bool debug);

    ~soft_frame_equalizer_impl();

    void set_algorithm(Equalizer_soft algo);
    void set_bandwidth(double bw);
    void set_frequency(double freq);
*void set_scaling(int scaling);

*private:*

int d_scaling;
*
And then in soft_frame_equalizer.h from the include directory as follows :

public:
    typedef boost::shared_ptr sptr;
    static sptr make(Equalizer_soft algo, double freq, double bw, *int 
scaling,*

            bool log, bool debug);
    virtual void set_algorithm(Equalizer_soft algo) = 0;
    virtual void set_bandwidth(double bw) = 0;
    virtual void set_frequency(double freq) = 0;
*virtual void set_scaling(int scaling) = 0;

*And finally in the xml file as follows : *

    
        Scaling
        scaling
        0
        real
    

*It compiles well, but when I execute the program, it throws following 
error:


sender started
Traceback (most recent call last):
  File 
"/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py", 
line 569, in 

    main()
  File 
"/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py", 
line 557, in main
    tb = top_block_cls(bandwidth=options.bandwidth, 
encoding=options.encoding, frequency=options.frequency, 
sensitivity=options.sensitivity)
  File 
"/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py", 
line 282, in __init__
    self.ieee802_11_soft_frame_equalizer_0 = 
ieee802_11.soft_frame_equalizer(ieee802_11.LS, 2.437e9, 20e6, False, False)
  File 
"/home/john/myprefix/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py", 
line 644, in make

    return _ieee802_11_swig.soft_frame_equalizer_make(*args, **kwargs)
TypeError: Required argument 'debug' (pos 6) not found

What I am missing ? Where else I need to edit ?

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

[Discuss-gnuradio] Template Error

2018-05-17 Thread Sumit Kumar


Hi,

I was converting the single channel FFT block to dual channel FFT block. 
I took the fft_vcc_fftw.cc code and tailored it for dual channel. Also I 
edited the corresponding xml file.


But when I try to run it in any application from GRC, it says

self.fft_vxx_0_0 = Template error: #if $type() == "complex"
    ^
SyntaxError: invalid syntax

Name of the GRC block is FFT DC and the corresponding c++ file is inside 
gr-fft, named : fft_vcc_fftw.cc & fft_vcc_fftw.h


The xml file name is fft_fft_vxx_dc.xml

I have pushed the code here https://github.com/sumitstop/MTSDR-gnuradio

Only last three commits are relevant.

Regards

Sumit



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

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

2018-05-11 Thread Sumit Kumar


Hi bastian,

To solve the following issue (as you predicted):

*"Consider what happens if one branch receives frames while the other 
one doesn't,Consider what happens if one branch receives frames while 
the other one doesn't."


*I combine the LLR of the SIGNAL fields from two branches and use that 
to decode the SIGNAL filed. The decision is used to decode both the 
branches. As of now it works, I mean doesn't crash at all! *




*Could you comment on this configuration.

Regards

Sumit
*

*
On 27/04/2018 10:41, Bastian Bloessl wrote:

Hi,

I'm not sure if I get it, but don't you need some synchronization 
logic between the branches. Consider what happens if one branch 
receives frames while the other one doesn't, then data queues up in 
the add block, which will sooner or later lead to overruns, 
independent from the buffer size.


Best,
Bastian

On 04/27/2018 09:54 AM, Sumit Kumar wrote:

Hi,

I am working on soft bit maximal ratio combiner (SBMRC). It's 
basically a MRC but instead of combining the actual signals according 
to their SNR, we combine the LLRs from separate branches and send 
them to Soft Decision Viterbi Decoder (SDVD). For this, I have 
modified gr-ieee 80211 which generates soft bits and integrated a 
SDVD with it. It works good when I use either single branch or both 
branch separately.


In order to implement SBMRC, for every OFDM symbol decoded, a vector 
of LLR (size 48 X 1) is generated from both the receiver branches. 
These two vectors of LLR are further added and sent to SDVD. I 
configured the ADD block to take 48 floats as input.


First I made a simulator for SBMRC, but even after increasing the 
output buffer size to 50, warnings of buffer over flow kept coming.


Then I used USRP, it simply refuses to work. I am using NI 2901 Tx/Rx 
A and Tx/Rx B ports as my receive branches. The LEDs go green for a 
second then stop. No error no warning.


Looks like the *ADD *block is the cause. I have never seen this, so I 
am clueless where to debug. Am I missing something fundamental here ?


The attached picture *usrp_sbmrc* says details of my schematic and 
the results when I use USRP.


The attached picture *sbmrc_sim* says details of my schematic and the 
results when I use simulations.






___
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] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

2018-05-02 Thread Sumit Kumar


Hi Bastian,

Yes thats correct. I believe this problem will be there if I do soft bit 
MRC i.e. independent decoding of the two branches. Just combining the 
long sync is not the solution :(


On an other note I have following question :

Inside the general_work in sync_long.cc, *ninput* is computed as follows.

*    int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
8192);*


This is the case when there are two inputs to sync_long i.e. *in* and 
*in_delayed*.


How shall I compute *ninput* when I have another branch coming say *in1* 
and *in1_delayed*.


In sync_short I faced the same issue when I input another branch. There 
I modified as follows :


*int ninput = std::min(std::min(ninput_items[2] 
,std::min(ninput_items[0], ninput_items[1])), std::min(ninput_items[4], 
ninput_items[3]));*


where previously it was

*int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
ninput_items[2]);*


Regards
Sumit
**
On 02/05/2018 08:26, Bastian Bloessl wrote:
The problem with this configuration is that the "Soft frame equalizer" 
blocks  are not synced. It's the same problem as with the Sync Short 
block, just at a later stage. Consider what happens, if one branch 
manages to decode the signal field and one doesn't. Or one thinks it's 
a 100 Byte BPSK 1/2 and the other thinks it's a 200 Byte 64-QAM 3/4


Best,
Bastian



On 04/29/2018 03:30 PM, Sumit Kumar wrote:
"In essence, you have to make sure that all branches start the 
synchronization process if one branch detects a frame."


I am doing only slightly different from above. Frame detection is 
happening with the combined value of correlation. And once frame is 
detected, both of the branches start the synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making 
it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

Hi,


On 28. Apr 2018, at 17:02, Sumit Kumar  wrote:
So basically I will be combining the correlation values from all 
antennas to find the start of WiFi frame. With this approach, I 
believe, there wont be any need of synchronization between 
branches. Let me know your view on this.
That depends at what stage you want to combine the signal. I’d do it 
at a later stage, i.e., do frame detection and synchronization in 
each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine correlations 
values. In essence, you have to make sure that all branches start 
the synchronization process if one branch detects a frame.


Best,
Bastian


Regards
Sumit



On 27/04/2018 11:25, Bastian Bloessl wrote:
I don't know about such an implementation. IIRC, in the paper, we 
recorded the IQ samples and processed the data offline.


If you are interested in the code you could write the first 
author, but since it was not real-time and for a single-carrier 
scheme, it might not be too helpful for your project.


If you come up with a solution, let me know.

Best,
Bastian


On 04/27/2018 11:15 AM, Sumit Kumar wrote:
Ok I understand now. Could you point me how to approach for such 
synchronization between the two branches. Or if there are any 
existing open source example if you know.


For this implementation, I was following one of your recently 
co-authored paper "Low-Complexity Soft-Bit Diversity Combining 
for Ultra-Low Power Wildlife Monitoring". However it seems that 
the source code is not open yet.


Sumit


On 27/04/2018 11:00, Sumit Kumar wrote:

Yes indeed, this could also happen! I note this in my to-do list.

But as of now there are no warnings of overruns etc. I recorded 
it. What is making USRP to stop receiving.


https://www.youtub

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

2018-04-29 Thread Sumit Kumar


Hi Jeff,

Ok now I print nitems_written(portnum) after every general_work call. 
But what should I check for. ( I am sorry, I never did such debugs before. )


Can you please explain this in a little more detail *"you have 2 
parallel paths with the word "sync" in them, and the blocks use 
general_work, that they won't output the same number of bytes."*


Regards

Sumit


On 29/04/2018 18:17, Jeff Long wrote:
If you can get the ctrlport monitor/profiling code working (I can't at 
the moment), you can watch the buffers fill. Or, you could have the 
sync_long blocks print out nitems_written(portnum) after every 
general_work call.


It seems likely that if you have 2 parallel paths with the word "sync" 
in them, and the blocks use general_work, that they won't output the 
same number of bytes. But, I'm not familiar with what you're trying to 
do, and haven't played with the 80211 code.


On 04/29/2018 10:10 AM, Sumit Kumar wrote:

Hi Jeff,

Ok I understand that. But how to verify this lock-up ?

Similar to dual_channel short sync if I make a new block i .e dual 
channel long sync, will it force this block to produce same number of 
outputs on two output ports ?


I am attaching the grc file for reference.

Regards

Sumit


On 29/04/2018 15:49, Jeff Long wrote:
I don't know the 802.11 code, but if the 2 sync_long blocks produce 
different amounts of output, eventually the "add" block will lock up.


On 04/29/2018 09:30 AM, Sumit Kumar wrote:
"In essence, you have to make sure that all branches start the 
synchronization process if one branch detects a frame."


I am doing only slightly different from above. Frame detection is 
happening with the combined value of correlation. And once frame is 
detected, both of the branches start the synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on 
both the branches by calling a modified *insert_tag *function as 
follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item 
% input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch 
-2**

**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP 
it works good. But after some time, say 2-3 minutes or so, USRP 
stops receiving signal. There is no warning or error or overruns 
etc making it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

Hi,

On 28. Apr 2018, at 17:02, Sumit Kumar  
wrote:
So basically I will be combining the correlation values from all 
antennas to find the start of WiFi frame. With this approach, I 
believe, there wont be any need of synchronization between 
branches. Let me know your view on this.
That depends at what stage you want to combine the signal. I’d do 
it at a later stage, i.e., do frame detection and synchronization 
in each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine 
correlations values. In essence, you have to make sure that all 
branches start the synchronization process if one branch detects a 
frame.


Best,
Bastian


Regards
Sumit



On 27/04/2018 11:25, Bastian Bloessl wrote:
I don't know about such an implementation. IIRC, in the paper, 
we recorded the IQ samples and processed the data offline.


If you are interested in the code you could write the first 
author, but since it was not real-time and for a single-carrier 
scheme, it might not be too helpful for your project.


If you come up with a solution, let me know.

Best,
Bastian


On 04/27/2018 11:15 AM, Sumit Kumar wrote:
Ok I understand now. Could you point me how to approach for 
such synchronization between the two branches. Or if there are 
any existing open source example if you know.


For this implementation, I was following one of your recently 
co-authored paper "Low-Complexity Soft-Bit Diversity Combining 
for Ultra-Low Power Wildlife Monitoring". However it seems that 
the source code is not open yet.


Sumit


On 27/04/2018 11:00, Sumit Kumar wrote:

Yes indeed, this could also happen! I note this in my to-do list.

But as of now there a

Re: [Discuss-gnuradio] Correct usage of gr::io_signature::makev

2018-04-29 Thread Sumit Kumar


Hi Marcus,

Ok I did that as you said and it work :)

Also I found another way. I made a separate method in the class short_sync

static std::vector get_input_sizes(){
    std::vector input_sizes;
    input_sizes.push_back(sizeof(gr_complex));
    input_sizes.push_back(sizeof(gr_complex));
    input_sizes.push_back(sizeof(gr_complex));
    input_sizes.push_back(sizeof(gr_complex));
    input_sizes.push_back(sizeof(float));

    return input_sizes;
    }

and then call it like this

gr::io_signature::makev(5, 5, get_input_sizes())

So both of them work!

Thanks

Sumit


On 28/04/2018 19:13, Marcus Müller wrote:

Ah, I got that wrong,

The difference is that fll_band_edge_cc_impl.cc doesn't declare that
static variable as class member, but you do – that leads to a problem,
because that way, the C++ type sync_short_impl as defined in your
_impl.cc differs from the one in the _impl.h, but requires that an
object be allocated in memory before the first instance of that type
can be allocated. Therefore, in-class defined static members can only
be integral types. (And if you didn't understand much of that, don't
worry, it only happened to cross my horizon because I introduced a
strange bug when I tried to fix PMT usage in GNU Radio, and had to go
back, understand a static initialization problem, which took hours, and
fix my changes.)

Workaround: don't make ios and iosig a part of the class, but only of
the gr::ieee802_11 namespace (and maybe give them more unique names
when doing so).

Best regards,
Marcus

On Sat, 2018-04-28 at 17:39 +0200, Sumit Kumar wrote:

Hi Marcus,

Actually I din't do that since the reference code which I was
following,
i.e.,

fll_band_edge_cc_impl.cc, has no such declaration in the
corresponding
header fll_band_edge_cc_impl.h

Sumit

On 28/04/2018 17:28, Marcus Müller wrote:

Hi Sumit,

I don't see where `ios` is being declared constantly and/or
statically
before line 31? Does that happen in the header?

Best regards,
Marcus
On Sat, 2018-04-28 at 16:51 +0200, Sumit Kumar wrote:

Hi,
In order to look for correct usage of gr::io_signature::makev, I
checked this example https://github.com/gnuradio/gnuradio/blob/ma
ster
/gr-digital/lib/fll_band_edge_cc_impl.cc
and found
static int ios[] = {sizeof(gr_complex), sizeof(gr_complex),
sizeof(gr_complex), sizeof(float)};
static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));
and then use as io_signature::makev(1, 4, iosig))
Basically I have to use it in sync_short.cc from gr-ieee 80211 in
order to create more inputs.
But if I use the above two lines inside the class i.e.
sync_short_impl, I get lots of error. I have attached the file
for
reference. Could you please suggest me correct usage. I can give
more
information if needed.
~

~~~
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:31:84:
error:
in-class initialization of static data member ‘int
sync_short_impl::ios []’ of incomplete type
   tic int ios[] = {sizeof(gr_complex), sizeof(float),
sizeof(float),
sizeof(float)};
  
  
  ^

/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:32:31:
error:
‘ios’ is not a type
   static std::vector iosig(ios,
ios+sizeof(ios)/sizeof(int));
 ^
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:32:36:
error:
‘ios’ is not a type
   static std::vector iosig(ios,
ios+sizeof(ios)/sizeof(int));
  ^
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:32:39:
error:
expected ‘,’ or ‘...’ before ‘+’ token
   static std::vector iosig(ios,
ios+sizeof(ios)/sizeof(int));
 ^
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc: In
constructor ‘sync_short_impl::sync_short_impl(double, unsigned
int,
bool, bool)’:
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:35:39:
error:
no matching function for call to ‘gr::io_signature::makev(int,
int,
std::vector (&)(int, int))’
  gr::io_signature::makev(4, 4, iosig),
 ^
In file included from
/home/john/myprefix/include/gnuradio/basic_block.h:30:0,
   from
/home/john/myprefix/include/gnuradio/block.h:27,
   from /home/john/myprefix/src/gr-ieee-
80211/include/ieee802-11/sync_short.h:21,
   from /home/john/myprefix/src/gr-ieee-
80211/lib/sync_short.cc:17:
/home/john/myprefix/include/gnuradio/io_signature.h:100:17: note:
candidate: static gr::io_signature::sptr
gr::io_signature::makev(int,
int, const std::vector&)
   static sptr makev(int min_streams, int max_streams,
   ^
/home/john/myprefix/include/gnuradio/io_signature.h:100:17: note:
no known conversion for argument 3 from ‘std::vector(int,
int)’
to ‘const std::vector&’
lib/CMakeFiles/gnuradio-ieee802_11.dir/build.make:584: recipe for
targ

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

2018-04-29 Thread Sumit Kumar


Hi Jeff,

Ok I understand that. But how to verify this lock-up ?

Similar to dual_channel short sync if I make a new block i .e dual 
channel long sync, will it force this block to produce same number of 
outputs on two output ports ?


I am attaching the grc file for reference.

Regards

Sumit


On 29/04/2018 15:49, Jeff Long wrote:
I don't know the 802.11 code, but if the 2 sync_long blocks produce 
different amounts of output, eventually the "add" block will lock up.


On 04/29/2018 09:30 AM, Sumit Kumar wrote:
"In essence, you have to make sure that all branches start the 
synchronization process if one branch detects a frame."


I am doing only slightly different from above. Frame detection is 
happening with the combined value of correlation. And once frame is 
detected, both of the branches start the synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making 
it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

Hi,


On 28. Apr 2018, at 17:02, Sumit Kumar  wrote:
So basically I will be combining the correlation values from all 
antennas to find the start of WiFi frame. With this approach, I 
believe, there wont be any need of synchronization between 
branches. Let me know your view on this.
That depends at what stage you want to combine the signal. I’d do it 
at a later stage, i.e., do frame detection and synchronization in 
each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine correlations 
values. In essence, you have to make sure that all branches start 
the synchronization process if one branch detects a frame.


Best,
Bastian


Regards
Sumit



On 27/04/2018 11:25, Bastian Bloessl wrote:
I don't know about such an implementation. IIRC, in the paper, we 
recorded the IQ samples and processed the data offline.


If you are interested in the code you could write the first 
author, but since it was not real-time and for a single-carrier 
scheme, it might not be too helpful for your project.


If you come up with a solution, let me know.

Best,
Bastian


On 04/27/2018 11:15 AM, Sumit Kumar wrote:
Ok I understand now. Could you point me how to approach for such 
synchronization between the two branches. Or if there are any 
existing open source example if you know.


For this implementation, I was following one of your recently 
co-authored paper "Low-Complexity Soft-Bit Diversity Combining 
for Ultra-Low Power Wildlife Monitoring". However it seems that 
the source code is not open yet.


Sumit


On 27/04/2018 11:00, Sumit Kumar wrote:

Yes indeed, this could also happen! I note this in my to-do list.

But as of now there are no warnings of overruns etc. I recorded 
it. What is making USRP to stop receiving.


https://www.youtube.com/watch?v=SPXLJ3iEWg8&feature=youtu.be
Sumit


On 27/04/2018 10:41, Bastian Bloessl wrote:

Hi,

I'm not sure if I get it, but don't you need some 
synchronization logic between the branches. Consider what 
happens if one branch receives frames while the other one 
doesn't, then data queues up in the add block, which will 
sooner or later lead to overruns, independent from the buffer 
size.


Best,
Bastian

On 04/27/2018 09:54 AM, Sumit Kumar wrote:

Hi,

I am working on soft bit maximal ratio combiner (SBMRC). It's 
basically a MRC but instead of combining the actual signals 
according to their SNR, we combine the LLRs from separate 
branches and send them to Soft Decision Viterbi Decoder 
(SDVD). For this, I have modified gr-ieee 80211 which 
generates soft bits and integrated a SDVD with it. It works 
good when I use either single branch or both branch separat

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

2018-04-29 Thread Sumit Kumar

"In essence, you have to make sure that all branches start the 
synchronization process if one branch detects a frame."


I am doing only slightly different from above. Frame detection is 
happening with the combined value of correlation. And once frame is 
detected, both of the branches start the synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
    mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
    const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
    add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed to 
the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making it 
difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

Hi,


On 28. Apr 2018, at 17:02, Sumit Kumar  wrote:
So basically I will be combining the correlation values from all antennas to 
find the start of WiFi frame. With this approach, I believe, there wont be any 
need of synchronization between branches. Let me know your view on this.

That depends at what stage you want to combine the signal. I’d do it at a later 
stage, i.e., do frame detection and synchronization in each branch 
independently and combine the subcarriers after equalization. With that 
approach, you wouldn’t combine correlations values. In essence, you have to 
make sure that all branches start the synchronization process if one branch 
detects a frame.

Best,
Bastian


Regards
Sumit



On 27/04/2018 11:25, Bastian Bloessl wrote:

I don't know about such an implementation. IIRC, in the paper, we recorded the 
IQ samples and processed the data offline.

If you are interested in the code you could write the first author, but since 
it was not real-time and for a single-carrier scheme, it might not be too 
helpful for your project.

If you come up with a solution, let me know.

Best,
Bastian


On 04/27/2018 11:15 AM, Sumit Kumar wrote:

Ok I understand now. Could you point me how to approach for such 
synchronization between the two branches. Or if there are any existing open 
source example if you know.

For this implementation, I was following one of your recently co-authored paper 
"Low-Complexity Soft-Bit Diversity Combining for Ultra-Low Power Wildlife 
Monitoring". However it seems that the source code is not open yet.

Sumit


On 27/04/2018 11:00, Sumit Kumar wrote:

Yes indeed, this could also happen! I note this in my to-do list.

But as of now there are no warnings of overruns etc. I recorded it. What is 
making USRP to stop receiving.

https://www.youtube.com/watch?v=SPXLJ3iEWg8&feature=youtu.be

Sumit


On 27/04/2018 10:41, Bastian Bloessl wrote:

Hi,

I'm not sure if I get it, but don't you need some synchronization logic between 
the branches. Consider what happens if one branch receives frames while the 
other one doesn't, then data queues up in the add block, which will sooner or 
later lead to overruns, independent from the buffer size.

Best,
Bastian

On 04/27/2018 09:54 AM, Sumit Kumar wrote:

Hi,

I am working on soft bit maximal ratio combiner (SBMRC). It's basically a MRC 
but instead of combining the actual signals according to their SNR, we combine 
the LLRs from separate branches and send them to Soft Decision Viterbi Decoder 
(SDVD). For this, I have modified gr-ieee 80211 which generates soft bits and 
integrated a SDVD with it. It works good when I use either single branch or 
both branch separately.

In order to implement SBMRC, for every OFDM symbol decoded, a vector of LLR 
(size 48 X 1) is generated from both the receiver branches. These two vectors 
of LLR are further added and sent to SDVD. I configured the ADD block to take 
48 floats as input.

First I made a simulator for SBMRC, but even after increasing the output buffer 
size to 50, warnings of buffer over flow kept coming.

Then I used USRP, it simply refuses to work. I am using NI 2901 Tx/Rx A and 
Tx/Rx B ports as my receive branches. The LEDs go green for a second

Re: [Discuss-gnuradio] Correct usage of gr::io_signature::makev

2018-04-28 Thread Sumit Kumar


Hi Marcus,

Actually I din't do that since the reference code which I was following, 
i.e.,


fll_band_edge_cc_impl.cc, has no such declaration in the corresponding 
header fll_band_edge_cc_impl.h


Sumit

On 28/04/2018 17:28, Marcus Müller wrote:

Hi Sumit,

I don't see where `ios` is being declared constantly and/or statically
before line 31? Does that happen in the header?

Best regards,
Marcus
On Sat, 2018-04-28 at 16:51 +0200, Sumit Kumar wrote:

Hi,
In order to look for correct usage of gr::io_signature::makev, I
checked this example https://github.com/gnuradio/gnuradio/blob/master
/gr-digital/lib/fll_band_edge_cc_impl.cc
and found
static int ios[] = {sizeof(gr_complex), sizeof(gr_complex),
sizeof(gr_complex), sizeof(float)};
static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));
and then use as io_signature::makev(1, 4, iosig))
Basically I have to use it in sync_short.cc from gr-ieee 80211 in
order to create more inputs.
But if I use the above two lines inside the class i.e.
sync_short_impl, I get lots of error. I have attached the file for
reference. Could you please suggest me correct usage. I can give more
information if needed.
~
~~~
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:31:84: error:
in-class initialization of static data member ‘int
sync_short_impl::ios []’ of incomplete type
  tic int ios[] = {sizeof(gr_complex), sizeof(float), sizeof(float),
sizeof(float)};
  
 ^

/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:32:31: error:
‘ios’ is not a type
  static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));
^
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:32:36: error:
‘ios’ is not a type
  static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));
 ^
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:32:39: error:
expected ‘,’ or ‘...’ before ‘+’ token
  static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));
^
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc: In
constructor ‘sync_short_impl::sync_short_impl(double, unsigned int,
bool, bool)’:
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:35:39: error:
no matching function for call to ‘gr::io_signature::makev(int, int,
std::vector (&)(int, int))’
 gr::io_signature::makev(4, 4, iosig),
^
In file included from
/home/john/myprefix/include/gnuradio/basic_block.h:30:0,
  from
/home/john/myprefix/include/gnuradio/block.h:27,
  from /home/john/myprefix/src/gr-ieee-
80211/include/ieee802-11/sync_short.h:21,
  from /home/john/myprefix/src/gr-ieee-
80211/lib/sync_short.cc:17:
/home/john/myprefix/include/gnuradio/io_signature.h:100:17: note:
candidate: static gr::io_signature::sptr gr::io_signature::makev(int,
int, const std::vector&)
  static sptr makev(int min_streams, int max_streams,
  ^
/home/john/myprefix/include/gnuradio/io_signature.h:100:17: note:
no known conversion for argument 3 from ‘std::vector(int, int)’
to ‘const std::vector&’
lib/CMakeFiles/gnuradio-ieee802_11.dir/build.make:584: recipe for
target 'lib/CMakeFiles/gnuradio-ieee802_11.dir/sync_short.cc.o'
failed
make[2]: *** [lib/CMakeFiles/gnuradio-ieee802_11.dir/sync_short.cc.o]
Error 1
CMakeFiles/Makefile2:200: recipe for target 'lib/CMakeFiles/gnuradio-
ieee802_11.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-ieee802_11.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
___
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] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

2018-04-28 Thread Sumit Kumar

Following your article "An IEEE 802.11a/g/p OFDM Receiver for GNU Radio" 
, I plan to add


a[n] (as in Eq-1) from the two antenna branches. Also add p[n] (as in 
Eq-2) from two antenna branches.


Finally use them as numerator and denominator respectively for Eq-3.

So basically I will be combining the correlation values from all 
antennas to find the start of WiFi frame. With this approach, I believe, 
there wont be any need of synchronization between branches. Let me know 
your view on this.


Regards

Sumit
**



On 27/04/2018 11:25, Bastian Bloessl wrote:
I don't know about such an implementation. IIRC, in the paper, we 
recorded the IQ samples and processed the data offline.


If you are interested in the code you could write the first author, 
but since it was not real-time and for a single-carrier scheme, it 
might not be too helpful for your project.


If you come up with a solution, let me know.

Best,
Bastian


On 04/27/2018 11:15 AM, Sumit Kumar wrote:
Ok I understand now. Could you point me how to approach for such 
synchronization between the two branches. Or if there are any 
existing open source example if you know.


For this implementation, I was following one of your recently 
co-authored paper "Low-Complexity Soft-Bit Diversity Combining for 
Ultra-Low Power Wildlife Monitoring". However it seems that the 
source code is not open yet.


Sumit


On 27/04/2018 11:00, Sumit Kumar wrote:

Yes indeed, this could also happen! I note this in my to-do list.

But as of now there are no warnings of overruns etc. I recorded it. 
What is making USRP to stop receiving.


https://www.youtube.com/watch?v=SPXLJ3iEWg8&feature=youtu.be

Sumit


On 27/04/2018 10:41, Bastian Bloessl wrote:

Hi,

I'm not sure if I get it, but don't you need some synchronization 
logic between the branches. Consider what happens if one branch 
receives frames while the other one doesn't, then data queues up in 
the add block, which will sooner or later lead to overruns, 
independent from the buffer size.


Best,
Bastian

On 04/27/2018 09:54 AM, Sumit Kumar wrote:

Hi,

I am working on soft bit maximal ratio combiner (SBMRC). It's 
basically a MRC but instead of combining the actual signals 
according to their SNR, we combine the LLRs from separate branches 
and send them to Soft Decision Viterbi Decoder (SDVD). For this, I 
have modified gr-ieee 80211 which generates soft bits and 
integrated a SDVD with it. It works good when I use either single 
branch or both branch separately.


In order to implement SBMRC, for every OFDM symbol decoded, a 
vector of LLR (size 48 X 1) is generated from both the receiver 
branches. These two vectors of LLR are further added and sent to 
SDVD. I configured the ADD block to take 48 floats as input.


First I made a simulator for SBMRC, but even after increasing the 
output buffer size to 50, warnings of buffer over flow kept 
coming.


Then I used USRP, it simply refuses to work. I am using NI 2901 
Tx/Rx A and Tx/Rx B ports as my receive branches. The LEDs go 
green for a second then stop. No error no warning.


Looks like the *ADD *block is the cause. I have never seen this, 
so I am clueless where to debug. Am I missing something 
fundamental here ?


The attached picture *usrp_sbmrc* says details of my schematic and 
the results when I use USRP.


The attached picture *sbmrc_sim* says details of my schematic and 
the results when I use simulations.






___
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] Correct usage of gr::io_signature::makev

2018-04-28 Thread Sumit Kumar


Hi,

In order to look for correct usage of *gr::io_signature::makev*, I 
checked this example 
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/fll_band_edge_cc_impl.cc


and found

*static int ios[] = {sizeof(gr_complex), sizeof(***gr_complex*), 
sizeof(***gr_complex*), sizeof(float)}; *


*static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));*

and then use as *io_signature::makev(1, 4, iosig))*

Basically I have to use it in sync_short.cc from gr-ieee 80211 in order 
to create more inputs.


But if I use the above two lines inside the class i.e. sync_short_impl, 
I get lots of error. I have attached the file for reference. Could you 
please suggest me correct usage. I can give more information if needed.




/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:31:84: error: 
in-class initialization of static data member ‘int sync_short_impl::ios 
[]’ of incomplete type
 tic int ios[] = {sizeof(gr_complex), sizeof(float), sizeof(float), 
sizeof(float)};

^
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:32:31: error: 
‘ios’ is not a type

 static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));
   ^
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:32:36: error: 
‘ios’ is not a type

 static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));
    ^
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:32:39: error: 
expected ‘,’ or ‘...’ before ‘+’ token

 static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));
   ^
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc: In constructor 
‘sync_short_impl::sync_short_impl(double, unsigned int, bool, bool)’:
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:35:39: error: no 
matching function for call to ‘gr::io_signature::makev(int, int, 
std::vector (&)(int, int))’

    gr::io_signature::makev(4, 4, iosig),
   ^
In file included from 
/home/john/myprefix/include/gnuradio/basic_block.h:30:0,

 from /home/john/myprefix/include/gnuradio/block.h:27,
 from 
/home/john/myprefix/src/gr-ieee-80211/include/ieee802-11/sync_short.h:21,
 from 
/home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:17:
/home/john/myprefix/include/gnuradio/io_signature.h:100:17: note: 
candidate: static gr::io_signature::sptr gr::io_signature::makev(int, 
int, const std::vector&)

 static sptr makev(int min_streams, int max_streams,
 ^
/home/john/myprefix/include/gnuradio/io_signature.h:100:17: note:   no 
known conversion for argument 3 from ‘std::vector(int, int)’ to 
‘const std::vector&’
lib/CMakeFiles/gnuradio-ieee802_11.dir/build.make:584: recipe for target 
'lib/CMakeFiles/gnuradio-ieee802_11.dir/sync_short.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-ieee802_11.dir/sync_short.cc.o] 
Error 1
CMakeFiles/Makefile2:200: recipe for target 
'lib/CMakeFiles/gnuradio-ieee802_11.dir/all' failed

make[1]: *** [lib/CMakeFiles/gnuradio-ieee802_11.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

/*
 * Copyright (C) 2013, 2016 Bastian Bloessl 
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see .
 */
#include 
#include 
#include "utils.h"

#include 

using namespace gr::ieee802_11;

static const int MIN_GAP = 480;
static const int MAX_SAMPLES = 540 * 80;

class sync_short_impl : public sync_short {

public:
static int ios[] = {sizeof(gr_complex), sizeof(gr_complex), sizeof(gr_complex), sizeof(float)};
static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));
sync_short_impl(double threshold, unsigned int min_plateau, bool log, bool debug) :
		block("sync_short",
			gr::io_signature::makev(4, 4, iosig),
			gr::io_signature::make2(2, 2, sizeof(gr_complex), sizeof(gr_complex))),
		d_log(log),
		d_debug(debug),
		d_state(SEARCH),
		d_plateau(0),
		d_freq_offset(0),
		d_copied(0),
		MIN_PLATEAU(min_plateau),
		d_threshold(threshold) {

	set_tag_propagation_policy(block::TPP_DONT);
}

int 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 = (const gr_complex*)input_items[0];
	const gr_complex *in_1 = (const gr_complex*)input_item

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

2018-04-27 Thread Sumit Kumar

Ok I understand now. Could you point me how to approach for such 
synchronization between the two branches. Or if there are any existing 
open source example if you know.


For this implementation, I was following one of your recently 
co-authored paper "Low-Complexity Soft-Bit Diversity Combining for 
Ultra-Low Power Wildlife Monitoring". However it seems that the source 
code is not open yet.


Sumit


On 27/04/2018 11:00, Sumit Kumar wrote:

Yes indeed, this could also happen! I note this in my to-do list.

But as of now there are no warnings of overruns etc. I recorded it. 
What is making USRP to stop receiving.


https://www.youtube.com/watch?v=SPXLJ3iEWg8&feature=youtu.be

Sumit


On 27/04/2018 10:41, Bastian Bloessl wrote:

Hi,

I'm not sure if I get it, but don't you need some synchronization 
logic between the branches. Consider what happens if one branch 
receives frames while the other one doesn't, then data queues up in 
the add block, which will sooner or later lead to overruns, 
independent from the buffer size.


Best,
Bastian

On 04/27/2018 09:54 AM, Sumit Kumar wrote:

Hi,

I am working on soft bit maximal ratio combiner (SBMRC). It's 
basically a MRC but instead of combining the actual signals 
according to their SNR, we combine the LLRs from separate branches 
and send them to Soft Decision Viterbi Decoder (SDVD). For this, I 
have modified gr-ieee 80211 which generates soft bits and integrated 
a SDVD with it. It works good when I use either single branch or 
both branch separately.


In order to implement SBMRC, for every OFDM symbol decoded, a vector 
of LLR (size 48 X 1) is generated from both the receiver branches. 
These two vectors of LLR are further added and sent to SDVD. I 
configured the ADD block to take 48 floats as input.


First I made a simulator for SBMRC, but even after increasing the 
output buffer size to 50, warnings of buffer over flow kept coming.


Then I used USRP, it simply refuses to work. I am using NI 2901 
Tx/Rx A and Tx/Rx B ports as my receive branches. The LEDs go green 
for a second then stop. No error no warning.


Looks like the *ADD *block is the cause. I have never seen this, so 
I am clueless where to debug. Am I missing something fundamental here ?


The attached picture *usrp_sbmrc* says details of my schematic and 
the results when I use USRP.


The attached picture *sbmrc_sim* says details of my schematic and 
the results when I use simulations.






___
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] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

2018-04-27 Thread Sumit Kumar


Yes indeed, this could also happen! I note this in my to-do list.

But as of now there are no warnings of overruns etc. I recorded it. What 
is making USRP to stop receiving.


https://www.youtube.com/watch?v=SPXLJ3iEWg8&feature=youtu.be

Sumit


On 27/04/2018 10:41, Bastian Bloessl wrote:

Hi,

I'm not sure if I get it, but don't you need some synchronization 
logic between the branches. Consider what happens if one branch 
receives frames while the other one doesn't, then data queues up in 
the add block, which will sooner or later lead to overruns, 
independent from the buffer size.


Best,
Bastian

On 04/27/2018 09:54 AM, Sumit Kumar wrote:

Hi,

I am working on soft bit maximal ratio combiner (SBMRC). It's 
basically a MRC but instead of combining the actual signals according 
to their SNR, we combine the LLRs from separate branches and send 
them to Soft Decision Viterbi Decoder (SDVD). For this, I have 
modified gr-ieee 80211 which generates soft bits and integrated a 
SDVD with it. It works good when I use either single branch or both 
branch separately.


In order to implement SBMRC, for every OFDM symbol decoded, a vector 
of LLR (size 48 X 1) is generated from both the receiver branches. 
These two vectors of LLR are further added and sent to SDVD. I 
configured the ADD block to take 48 floats as input.


First I made a simulator for SBMRC, but even after increasing the 
output buffer size to 50, warnings of buffer over flow kept coming.


Then I used USRP, it simply refuses to work. I am using NI 2901 Tx/Rx 
A and Tx/Rx B ports as my receive branches. The LEDs go green for a 
second then stop. No error no warning.


Looks like the *ADD *block is the cause. I have never seen this, so I 
am clueless where to debug. Am I missing something fundamental here ?


The attached picture *usrp_sbmrc* says details of my schematic and 
the results when I use USRP.


The attached picture *sbmrc_sim* says details of my schematic and the 
results when I use simulations.






___
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] Issue with Pybombs installation

2018-04-26 Thread Sumit Kumar


Ok it works!

Thanks

Sumit


On 25/04/2018 20:05, Ravi Sharan wrote:

Hi Sumit,

Q1 - You might have installed libuhd-dev as a system-wide package
using apt-get (if you're using ubuntu). Removing/uninstalling that
should work.

Q2 - To install other tags/releases of a package in your desired
prefix (in your case uhd):

0) Check if the package is already installed and uninstall it using pybombs

1) Find the commit associated with the release
 - In your case it is f072067

2) Edit the following lines in the ~/.pybombs/recipes/gr-recipes/uhd.lwr
 #gnuradio: master
 gitrev: f072067

3) Install the package using:
  pybombs -p  install 

Cheers,
R

___
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] Issue with Pybombs installation

2018-04-25 Thread Sumit Kumar


Hi,

*Qn-1 When I execute the following : **
*

*pybombs prefix init !/tique_radio -a demo -R gnuradio-default*

*After 87% of the compilation, I get this error : *

[ 87%] Building CXX object 
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.


cxx.o
/home/tique/tique_radio/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function ‘PyObject* _wrap_time_spec_t_get_system_time(PyObject*, 
PyObject*)’:
/home/tique/tique_radio/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:19511:16: 
error: ‘get_system_time’ is not a member of ‘uhd::time_spec_t’

   result = uhd::time_spec_t::get_system_time();
    ^
/home/tique/tique_radio/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function ‘PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*, 
PyObject*, PyObject*)’:
/home/tique/tique_radio/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:27597:15: 
error: ‘class uhd::usrp::dboard_iface’ has no member named ‘set_gpio_debug’

   (arg1)->set_gpio_debug(arg2,arg3);
   ^
/home/tique/tique_radio/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function ‘PyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*, 
PyObject*, PyObject*)’:
/home/tique/tique_radio/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:28960:16: 
error: ‘class uhd::usrp::dboard_iface’ has no member named ‘set_gpio_debug’

   (*arg1)->set_gpio_debug(arg2,arg3);
    ^
/home/tique/tique_radio/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function ‘void init_uhd_swig()’:
/home/tique/tique_radio/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48264:91: 
error: ‘ATR_REG_IDLE’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::A

^
/home/tique/tique_radio/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48265:94: 
error: ‘ATR_REG_TX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface

^
/home/tique/tique_radio/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48266:94: 
error: ‘ATR_REG_RX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface

^
/home/tique/tique_radio/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48267:98: 
error: ‘ATR_REG_FULL_DUPLEX’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_i

^
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/build.make:70: recipe for target 
'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o' failed
make[2]: *** 
[gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Error 1
CMakeFiles/Makefile2:13348: recipe for target 
'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all' failed

make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2

*Qn-2 When installing using pybombs can I choose uhd version. I believe 
it is using 3.10 but I need 3.009.003 *


Thanks

Sumit

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

[Discuss-gnuradio] Fwd: Using Dual Rx Channel B210 from GRC

2018-02-19 Thread sumit kumar

I am using a UHD source in GRC. I configured it to stream from both the RX
ports.
The first port is tuned to 2.437 GHz and the another to 2.435 by providing
a lo_offset of 2MHz.

Samples from first port go under some processing and then have to be added
to samples coming from the second port. When I run my set up, the green
LEDs of the ports blink for once and stop receiving any more.

I am attaching the grc file for reference.

When I run it without the "ADD" block, it streams fine with both the
channels streaming. What I am missing here ?

Regards

-- 
Sumit Kumar


soft_decision_receiver_testing_copy.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Triggering between two transmitters

2018-02-02 Thread sumit kumar

Hi,

I want to create a deterministic collision scenario between wifi and
zigbee. I am using gr-ieee 80211 and gr-ieee 802154 along with USRP B210.

I have a constraint that my wifi preambles should always collide with an
ongoing zigbee transmission.

In order to do that, I am thinking of synchronizing the wifi transmitter
and zigbee transmitter (both connected in the same laptop) in such a way
that wifi transmits its frame only when zigbee transmission is ongoing.

Is there any way that zigbee transmitter triggers the wifi transmitter
whenever a zigbee frame is transmitted.

Air time of zigbee is very high compared to wifi, so I am sure if zigbee
transmitter triggers wifi transmitter, wifi preambles will collide with
zigbee for sure.

Both wifi transmitter and zigbee transmitter are connected to the same
laptop and using different USRP B210.

I am not sure if the solution lies in gnuradio or uhd hence posting at both
places :)

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

Re: [Discuss-gnuradio] Performance Counters

2018-01-26 Thread Sumit Kumar

I had almost the same problem, then I used pybombs to install GNU Radio 
and everything. It installed apache-thrift smoothly.


After that I have built apache-thrift many times under pybombs 
environment, and it never gave any more pain(touch wood).


Sumit


On 26/01/2018 16:47, larafe...@web.de wrote:

Hello gnuradio-community,
I'm trying to use performance counters for my flowgraph which consists 
of some gnuradio blocks and some of my own oot blocks. In order to do 
so I need to install 'thrift'.

I have tried everything, but it does not work.
1) I installed thrift accoding to 
"https://wiki.gnuradio.org/index.php/ControlPort";. I have installed 
python-twisted and libssl-dev.

2) 'thrift -version' gives me 0.11.0. So it is installed.
2) Then I enter the build-folder of my gnuradio installation.
3) I do 'cmake ../'.
4) I get an error 'thrift not found'.
Gnuradio or python or both are unable to find thrift. I'm frustrated 
and I have no idea where to start.

My OS: Ubuntu 16.04
Gnuradio: 3.7.11.1
In case I'm not able to solve the problem: Is there a way to query 
performance counters from python with the flowgraph running?

Thank you,
Lara


___
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] Using Extern variables in GNURadio

2018-01-23 Thread sumit kumar

Hi Marcus,

I am well aware of the usage of extern in C :)

Probably I should have put the question in another way. It was a question
about initializing some variables at the beginning and to be used later.

I am fixing my issue by initializing arrays in the class constructor call.

Thanks

Sumit





On 23 January 2018 at 17:48, Müller, Marcus (CEL)  wrote:

> Dear Sumit,
>
> this is by no means a GNU Radio question – it's not even a C++
> question, it's quintessentially a question about what the "extern"
> keyword in C means. I'm not sure I should be giving you an intro to C
> visibility, object linking and storage, because that will quickly
> exceed the scope of both this list and what you're trying to solve.
>
> So, with you being the only one that actually has that code in front of
> you, knowing what it does and knowing how you want to structure your
> C++ GNU Radio program, I'd like to refer you to the usual sources
> (wikipedia "External Variable", isocpp.org "Mixing C and C++") for your
> own reading pleasure!
>
> Best regards,
> Marcus
>
> On Tue, 2018-01-23 at 16:00 +0100, sumit kumar wrote:
> > I am translating one program C program to GNU Radio. In that C program,
> in the main(), at the very beginning, some initializer functions were
> called which populated some arrays.
> >
> > These arrays were then used in other function using extern
> >
> > How should I do this in GNU radio ?
> >
> > Sumit
> >
> > _______
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




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

[Discuss-gnuradio] Using Extern variables in GNURadio

2018-01-23 Thread sumit kumar

I am translating one program C program to GNU Radio. In that C program, in
the main(), at the very beginning, some initializer functions were called
which populated some arrays.

These arrays were then used in other function using *extern *

How should I do this in GNU radio ?

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

Re: [Discuss-gnuradio] oot modules in grc

2018-01-22 Thread sumit kumar

Are you using gr_modtool makexml command. Sometimes its not very much
helpful(it also says so). I always take any example xml from the existing
libraries and then paste my stuff over them.

On 22 January 2018 at 22:57, Volker Schroer  wrote:

> For some times oot modules are sorted into a subtree (no module specified
> ). On 'mouse over' the developers are asked to update their xml - files
> with module names.
>
> If I look into the gnuradio xml files the module name always seems to be
> [core].
>
> Are there recommendations for oot- modules or should it always be [OOT] ?
>
> I found nothing about this in the tutorials.
>
> Any hints are welcome.
> Thanks
> -- Volker
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



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

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

2018-01-21 Thread sumit kumar

On 21 January 2018 at 20:15, Michael Dickens 
wrote:

> So we mean adding "virtual" in the GR header here < https://github.com/
> sumitstop/MTSDR-gnuradio/commit/778b6d095517b87c338169e3efc84b
> ac9fcf37ea#diff-96726df785ba7d3bf9493c8830d5a1d0R79 >, just like the
> "decision_maker" method is. And you'll probably want to declare its
> function there too as "{}", so that there is a default provided in the base
> class & hence any inheriting class doesn't have to declare that method (as
> they do for "decision_maker").
>
> Then when you overload the method in your gr-ieee-802.11 OOT you are not
> required to declare that method as virtual, but it doesn't hurt to do so &
> there are some who prefer that style of programming (making it explicit
> that the method is overloading a base class virtual method).
>
> Because the gr-ieee-802.11 OOT constellation inherits from
> gr::digital::constellation (the "global" base class), you do have to modify
> both the GR header for constellation.h as well as the OOT
> "constellation_impl" header and c++ source to add in new methods. You also,
> of course, have to rebuild and reinstall (at least) GR, possibly also the
> OOT depending on how you're loading libraries etc.
>
> * Hence I think overloading the "calc_soft_dec" method would be a better
> way to go, since it doesn't require you to modify GR. - MLD*
>

This worked ! So smooth, thanks much. I will pursue the modification issue
of GR once my deadline is over :P







>
> On Sun, Jan 21, 2018, at 1:48 PM, sumit kumar wrote:
> > Believe me I tried that declaring decision_maker_soft as a virtual
> function(only virtual not pure virtual), but that din't work. I am trying
> that now again.
>



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

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

2018-01-21 Thread sumit kumar

Believe me I tried that declaring decision_maker_soft as a virtual
function(only virtual not pure virtual), but that din't work. I am trying
that now again.



On 21 January 2018 at 19:23, Michael Dickens 
wrote:

> Yes that's correct: the base class's method declaration must be "virtual"
> for the inheriting class' overloaded method to be usable correctly within
> SWIG. Good catch! - MLD
>
> On Sun, Jan 21, 2018, at 5:42 AM, Bastian Bloessl wrote:
> > On 01/19/2018 10:30 PM, sumit kumar wrote:
> > > Hi Michael, Yes I just made one and pushed everything.
> > >
> > > https://github.com/sumitstop/MTSDR-gnuradio/commits/master
> > >
> > > https://github.com/sumitstop/MTSDR-gr-ieee-80211/commits/master
> >
> > I didn't test it, but I think you should declare the function virtual.
>



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

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

2018-01-21 Thread sumit kumar

On 20 January 2018 at 18:06, Michael Dickens 
wrote:

> Hi Sumit - OK good I'll take a look when I get a chance. In the meantime,
> 3 thoughts come to mind:
>
> 1) If done correctly, you don't need to modify GR at all. Your new
> constellation class is purely in your OOT (or, gr-ieee-802.11 in this
> case). You create the base class in your OOT & inherit from it in your OOT
> too. All is done in the OOT; easier that way, and you can add special
> methods as you see fit, and/or fix issues.
>

Yes I also believe so i.e. I mostly have to be inside OOT. May be to save
your time, I share this link with you where the author has discussed the
hacks he did with constellation class of gnuradio and made his own. I just
replicated them step by step. https://www.bastibl.net/constellation-objects/


>
> 2) In order for SWIG to do it's magic on a non-block base class &
> inheriting class, you need some special SWIG sauce. This might already be
> done in gr-ieee-802.11; I'll check when I get there. GR does it via a
> special file that's included into one of the main gr-digital .i SWIG files;
> for specifics see this file < https://github.com/gnuradio/
> gnuradio/blob/master/gr-digital/swig/constellation.i > & the top-level
> SWIG file for gr-digital here (at the very end) <
> https://github.com/gnuradio/gnuradio/blob/master/gr-
> digital/swig/digital_swig0.i >.
>
> 3) There is already a method for handling soft decoding that you can
> overload if you want to: "calc_soft_dec" < https://github.com/gnuradio/
> gnuradio/blob/master/gr-digital/include/gnuradio/
> digital/constellation.h#L163 >. You might want to check it out instead of
> creating a new method.
>

Yes indeed, I know. I was thinking to get this issue solve. Doing so will
save me sending 10 more queries to the mailing list :)

>
> If you succeed over the weekend, please do let us know. If I get some
> spare time to look into this over the weekend I'll let you know. Cheers! -
> MLD
>
> On Fri, Jan 19, 2018, at 5:30 PM, sumit kumar wrote:
> > Yes I just made one and pushed everything.
> >
> > https://github.com/sumitstop/MTSDR-gnuradio/commits/master
> >
> > https://github.com/sumitstop/MTSDR-gr-ieee-80211/commits/master
> >
> > My changes are in latest commit.
>



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

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

2018-01-19 Thread sumit kumar

Ok a correction

I declared it like this inside the constellations.h , now I am waiting for
the compilation to finish

class DIGITAL_API constellation_bpsk : public constellation
{
public:
  typedef boost::shared_ptr sptr;

  // public constructor
  static sptr make();

  ~constellation_bpsk();

  unsigned int decision_maker(const gr_complex *sample);
 * float decision_maker_soft(const gr_complex *sample);*

protected:
  constellation_bpsk();
};

On 19 January 2018 at 15:08, sumit kumar  wrote:

> Ok, so shall I do like this :
>
> In the file /gnuradio/gr-digital/include/gnuradio/digital/constellations.h
> under public section I declare my function as follows
>
> *class DIGITAL_API constellation*
> *  : public boost::enable_shared_from_this*
> *{*
> *public:*
>
> *float decision_maker_soft(const gr_complex *sample) = 0;*
>
> *}*
>
> and In the file /gnuradio/gr-digital/lib/constellations.cc I add this
>
> *float*
> *constellation_bpsk::decision_maker_soft(const gr_complex *sample)*
> *{*
> *  return (-4*real(*sample)); // LLR for BPSK*
> *}*
>
>
> After this I recompile gnuradio and then recompile gr-ieee-80211.. right ?
>
> On 19 January 2018 at 14:51, Michael Dickens 
> wrote:
>
>> The GR constellation programming uses a base class that defines the API
>> that will be SWIG-ified back into Python. So the base class must contain
>> your "*decision_maker_soft" *method. Then you overload it for any
>> inheriting class such as "constellation_bpsk". Hope this helps! - MLD
>>
>> On Fri, Jan 19, 2018, at 8:43 AM, sumit kumar wrote:
>>
>> Actually I have to test it in a interference limited environment, I guess
>> the soft demodulate will be needed. I saw your blog post about how you
>> cleverly used your won constellations https://www.bas
>> tibl.net/constellation-objects/
>>
>> However when I try doing something like that, I get errors.
>>
>> For example, I defined my own function decision_maker_soft inside
>> constellations_impl.h as follows
>>
>> class constellation_bpsk_impl : public constellation_bpsk
>> {
>> public:
>> constellation_bpsk_impl();
>> ~constellation_bpsk_impl();
>>
>> unsigned int decision_maker(const gr_complex *sample);
>> *float decision_maker_soft(const gr_complex *sample);*
>> };
>>
>> and then defined it in constellation_impl.cc as
>>
>> float
>> constellation_bpsk_impl::decision_maker_soft(const gr_complex *sample) {
>> return (-4*real(*sample));
>> }
>>
>> But when I call my function like this
>>
>> mod->decision_maker_soft from ls.cc (least square equalizer cc file), it
>> says mod object has no member decision_maker_soft
>>
>> Why does *mod* object not look my decision_maker_soft as it is a method
>> of constellation_bpsk_impl ??
>>
>> What am I missing here ?
>>
>> I thought that mod object is looking your decision_maker inside
>> constellations_impl, it shud see mine too...
>>
>>
>>
>
>
> --
> Sumit Kumar
>
>
>


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

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

2018-01-19 Thread sumit kumar

Ok, so shall I do like this :

In the file /gnuradio/gr-digital/include/gnuradio/digital/constellations.h
under public section I declare my function as follows

*class DIGITAL_API constellation*
*  : public boost::enable_shared_from_this*
*{*
*public:*

*float decision_maker_soft(const gr_complex *sample) = 0;*

*}*

and In the file /gnuradio/gr-digital/lib/constellations.cc I add this

*float*
*constellation_bpsk::decision_maker_soft(const gr_complex *sample)*
*{*
*  return (-4*real(*sample)); // LLR for BPSK*
*}*


After this I recompile gnuradio and then recompile gr-ieee-80211.. right ?

On 19 January 2018 at 14:51, Michael Dickens 
wrote:

> The GR constellation programming uses a base class that defines the API
> that will be SWIG-ified back into Python. So the base class must contain
> your "*decision_maker_soft" *method. Then you overload it for any
> inheriting class such as "constellation_bpsk". Hope this helps! - MLD
>
> On Fri, Jan 19, 2018, at 8:43 AM, sumit kumar wrote:
>
> Actually I have to test it in a interference limited environment, I guess
> the soft demodulate will be needed. I saw your blog post about how you
> cleverly used your won constellations https://www.bas
> tibl.net/constellation-objects/
>
> However when I try doing something like that, I get errors.
>
> For example, I defined my own function decision_maker_soft inside
> constellations_impl.h as follows
>
> class constellation_bpsk_impl : public constellation_bpsk
> {
> public:
> constellation_bpsk_impl();
> ~constellation_bpsk_impl();
>
> unsigned int decision_maker(const gr_complex *sample);
> *float decision_maker_soft(const gr_complex *sample);*
> };
>
> and then defined it in constellation_impl.cc as
>
> float
> constellation_bpsk_impl::decision_maker_soft(const gr_complex *sample) {
> return (-4*real(*sample));
> }
>
> But when I call my function like this
>
> mod->decision_maker_soft from ls.cc (least square equalizer cc file), it
> says mod object has no member decision_maker_soft
>
> Why does *mod* object not look my decision_maker_soft as it is a method
> of constellation_bpsk_impl ??
>
> What am I missing here ?
>
> I thought that mod object is looking your decision_maker inside
> constellations_impl, it shud see mine too...
>
>
>


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

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

2018-01-19 Thread sumit kumar

Actually I have to test it in a interference limited environment, I guess
the soft demodulate will be needed. I saw your blog post about how you
cleverly used your won constellations https://www.bastibl.net/constellation-
objects/

However when I try doing something like that, I get errors.

For example, I defined my own function decision_maker_soft inside
constellations_impl.h as follows

class constellation_bpsk_impl : public constellation_bpsk
{
public:
constellation_bpsk_impl();
~constellation_bpsk_impl();

unsigned int decision_maker(const gr_complex *sample);
*float decision_maker_soft(const gr_complex *sample);*
};

and then defined it in constellation_impl.cc as

float
constellation_bpsk_impl::decision_maker_soft(const gr_complex *sample) {
return (-4*real(*sample));
}

But when I call my function like this

mod->decision_maker_soft from ls.cc (least square equalizer cc file), it
says mod object has no member decision_maker_soft

Why does *mod* object not look my decision_maker_soft as it is a method of
constellation_bpsk_impl ??

What am I missing here ?

I thought that mod object is looking your decision_maker inside
constellations_impl, it shud see mine too...




On 18 January 2018 at 15:22, Bastian Bloessl  wrote:

> I'm not sure if I understand you correctly, but you have to differentiate
> what performance you mean. IT++ might have better decoding performance
> (since it's using soft-bits), but the SIMD implementation has better
> computational performance (i.e., needs less CPU).
>
> To be honest, I didn't do a lot of testing between IT++ and the current
> version. (I think I've seen a paper that compared soft-bits vs. hard-bits
> and there was a 2-3dB improvement, but you have to check). Since the
> decoder was a CPU bottleneck, I was more than happy to merge the SIMD
> implementation, which was developed by Gonzalo Arcos based on the gr-dtv
> decoder. See here
>
> http://www.ccs-labs.org/bib/arcos2016accelerating/
>
> Best,
> Bastian
>
> On 1/18/2018 13:41, sumit kumar wrote:
>
>> Thanks for confirming. I believe that IT++ version will work with
>> corresponding GNU Radio version.
>>
>> Also what do you think (since you have developed the code for long time
>> :) ) : IT++ version will be as efficient as the current one? I mean the
>> current version uses SIMD for Viterbi.
>> I have tested the current version for success rate. I can share the
>> results(attached). Success rate mentioned is nothing but ratio of received
>> to transmitted frame per second using a R&H VSG. The test was done over the
>> air.
>>
>>
>>
>> On 18 January 2018 at 13:06, Bastian Bloessl > m...@bastibl.net>> wrote:
>>
>> Hi,
>>
>> you are right. The current implementation does not use soft-bits but
>> feeds hard bits into the decoder.
>>
>> In 2013, I used the soft-input Viterbi decoder from the IT++ library.
>>
>> http://itpp.sourceforge.net/4.3.1/convcode.html
>> <http://itpp.sourceforge.net/4.3.1/convcode.html>
>>
>> Best,
>> Bastian
>>
>> On 01/17/2018 11:36 AM, sumit kumar wrote:
>>
>> Hi,
>>
>> I am doing some proof of concept using gr-ieee 802.11.
>> The paper by author [1] says that it uses softbits, however in
>> the method
>>
>> *constellation::decision_maker(const gr_complex *sample)*, I see
>> outputs as hardbits.
>> Am I missing something here i.e. any particular commit or branch
>>     where the softbits implementation is there.
>>
>>Its very important for my algorithm to use softbits :-/
>>
>> [1]
>> https://conferences.sigcomm.org/sigcomm/2013/papers/srif/p9.pdf
>> <https://conferences.sigcomm.org/sigcomm/2013/papers/srif/p9.pdf>
>>
>> Sumit
>>
>>
>>
>>
>> --
>> Sumit Kumar
>>
>>
>>


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

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

2018-01-18 Thread sumit kumar

Thanks for confirming. I believe that IT++ version will work with
corresponding GNU Radio version.

Also what do you think (since you have developed the code for long time :)
) : IT++ version will be as efficient as the current one? I mean the
current version uses SIMD for Viterbi.

I have tested the current version for success rate. I can share the
results(attached). Success rate mentioned is nothing but ratio of received
to transmitted frame per second using a R&H VSG. The test was done over the
air.

On 18 January 2018 at 13:06, Bastian Bloessl  wrote:

> Hi,
>
> you are right. The current implementation does not use soft-bits but feeds
> hard bits into the decoder.
>
> In 2013, I used the soft-input Viterbi decoder from the IT++ library.
>
> http://itpp.sourceforge.net/4.3.1/convcode.html
>
> Best,
> Bastian
>
> On 01/17/2018 11:36 AM, sumit kumar wrote:
>
>> Hi,
>>
>> I am doing some proof of concept using gr-ieee 802.11.
>> The paper by author [1] says that it uses softbits, however in the method
>>
>> *constellation::decision_maker(const gr_complex *sample)*, I see outputs
>> as hardbits.
>> Am I missing something here i.e. any particular commit or branch where
>> the softbits implementation is there.
>>
>>   Its very important for my algorithm to use softbits :-/
>>
>> [1] https://conferences.sigcomm.org/sigcomm/2013/papers/srif/p9.pdf
>>
>> Sumit
>>
>

-- 
Sumit Kumar

GR IEEE 80211 OTA TESTS.xlsx
Description: MS-Excel 2007 spreadsheet
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help with gr::io_signature::makev

2018-01-17 Thread sumit kumar

Yes indeed, it was a C++11 issue! Thanks

On 13 January 2018 at 11:16, Sakthivel Velumani  wrote:

> I think you are using an older standard of C compiler. The C11 does not
> allow to initialise a vector using {}. But this doesn't matter as it
> compiled successfully. Try initialising the vector with its constructor and
> then assign the values. It doesn't make sense but still no harm in trying.
>
> Regards,
> Sakthivel
>
>
> On 13-Jan-2018 5:48 AM, "sumit kumar"  wrote:
>
> The input signature is not a problem here. For gr::io_signature::*make*(2,
> 2, sizeof(gr_complex)), i.e. when using make, size of all input items is
> same. Its is different when using make2, make3 and makev.
>
>
>
>
> On 13 January 2018 at 01:23, Sakthivel Velumani 
> wrote:
>
>> Hi Sumit,
>>
>> You have given no of input streams as 2 but mentioned size of item for
>> only one. This may be the source of the error. Try correcting it and let us
>> know.
>>
>> Regards,
>> Sakthivel
>>
>> On Fri, Jan 12, 2018 at 10:37 PM, sumit kumar 
>> wrote:
>>
>>> Hi,
>>>
>>> I am trying to use *gr::io_signature::makev* for my output signature in
>>> my bar_impl.cc
>>>
>>> bar_impl::bar_impl(int offset, int freq)
>>>   : gr::block("bar",
>>>   gr::io_signature::make(2, 2, sizeof(gr_complex)),
>>>  * gr::io_signature::makev(4, 4, out_vect))*
>>>
>>> For that in the header I did following in the header bar_impl.h
>>>
>>> *const std::vector out_vect = {sizeof(gr_complex),
>>> sizeof(gr_complex), sizeof(float), sizeof(float)};*
>>>
>>> It compiles but when I do gr_modtool makexml, it throws this error
>>>
>>> john@john-Precision-5510:~/nuradio/src/gr-fist$ gr_modtool makexml bar
>>> GNU Radio module name identified: fist
>>> Warning: This is an experimental feature. Don't expect any magic.
>>> Searching for matching files in lib/:
>>> Making GRC bindings for lib/bar_impl.cc...
>>> tbi
>>> Error: Can't parse output signature.
>>> Traceback (most recent call last):
>>>   File "/home/john/nuradio/bin/gr_modtool", line 46, in 
>>> main()
>>>   File "/home/john/nuradio/bin/gr_modtool", line 38, in main
>>> modtool.run()
>>>   File 
>>> "/home/john/nuradio/lib/python2.7/dist-packages/gnuradio/modtool/modtool_makexml.py",
>>> line 76, in run
>>> self._make_grc_xml_from_block_data(params, iosig, blockname)
>>>   File 
>>> "/home/john/nuradio/lib/python2.7/dist-packages/gnuradio/modtool/modtool_makexml.py",
>>> line 100, in _make_grc_xml_from_block_data
>>> if iosig[inout]['max_ports'] == '-1':
>>> KeyError: 'out'
>>>
>>> Need some help :)
>>>
>>> --
>>> Sumit Kumar
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
>
> --
> Sumit Kumar
>
>
>
>


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

[Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

2018-01-17 Thread sumit kumar

Hi,

I am doing some proof of concept using gr-ieee 802.11.
The paper by author [1] says that it uses softbits, however in the method

*constellation::decision_maker(const gr_complex *sample)*, I see outputs as
hardbits.
Am I missing something here i.e. any particular commit or branch where the
softbits implementation is there.

 Its very important for my algorithm to use softbits :-/

[1] https://conferences.sigcomm.org/sigcomm/2013/papers/srif/p9.pdf

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

Re: [Discuss-gnuradio] Help with gr::io_signature::makev

2018-01-12 Thread sumit kumar

The input signature is not a problem here. For gr::io_signature::*make*(2,
2, sizeof(gr_complex)), i.e. when using make, size of all input items is
same. Its is different when using make2, make3 and makev.




On 13 January 2018 at 01:23, Sakthivel Velumani  wrote:

> Hi Sumit,
>
> You have given no of input streams as 2 but mentioned size of item for
> only one. This may be the source of the error. Try correcting it and let us
> know.
>
> Regards,
> Sakthivel
>
> On Fri, Jan 12, 2018 at 10:37 PM, sumit kumar  wrote:
>
>> Hi,
>>
>> I am trying to use *gr::io_signature::makev* for my output signature in
>> my bar_impl.cc
>>
>> bar_impl::bar_impl(int offset, int freq)
>>   : gr::block("bar",
>>   gr::io_signature::make(2, 2, sizeof(gr_complex)),
>>  * gr::io_signature::makev(4, 4, out_vect))*
>>
>> For that in the header I did following in the header bar_impl.h
>>
>> *const std::vector out_vect = {sizeof(gr_complex),
>> sizeof(gr_complex), sizeof(float), sizeof(float)};*
>>
>> It compiles but when I do gr_modtool makexml, it throws this error
>>
>> john@john-Precision-5510:~/nuradio/src/gr-fist$ gr_modtool makexml bar
>> GNU Radio module name identified: fist
>> Warning: This is an experimental feature. Don't expect any magic.
>> Searching for matching files in lib/:
>> Making GRC bindings for lib/bar_impl.cc...
>> tbi
>> Error: Can't parse output signature.
>> Traceback (most recent call last):
>>   File "/home/john/nuradio/bin/gr_modtool", line 46, in 
>> main()
>>   File "/home/john/nuradio/bin/gr_modtool", line 38, in main
>> modtool.run()
>>   File 
>> "/home/john/nuradio/lib/python2.7/dist-packages/gnuradio/modtool/modtool_makexml.py",
>> line 76, in run
>> self._make_grc_xml_from_block_data(params, iosig, blockname)
>>   File 
>> "/home/john/nuradio/lib/python2.7/dist-packages/gnuradio/modtool/modtool_makexml.py",
>> line 100, in _make_grc_xml_from_block_data
>> if iosig[inout]['max_ports'] == '-1':
>> KeyError: 'out'
>>
>> Need some help :)
>>
>> --
>> Sumit Kumar
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


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

[Discuss-gnuradio] Help with gr::io_signature::makev

2018-01-12 Thread sumit kumar

Hi,

I am trying to use *gr::io_signature::makev* for my output signature in my
bar_impl.cc

bar_impl::bar_impl(int offset, int freq)
  : gr::block("bar",
  gr::io_signature::make(2, 2, sizeof(gr_complex)),
 * gr::io_signature::makev(4, 4, out_vect))*

For that in the header I did following in the header bar_impl.h

*const std::vector out_vect = {sizeof(gr_complex), sizeof(gr_complex),
sizeof(float), sizeof(float)};*

It compiles but when I do gr_modtool makexml, it throws this error

john@john-Precision-5510:~/nuradio/src/gr-fist$ gr_modtool makexml bar
GNU Radio module name identified: fist
Warning: This is an experimental feature. Don't expect any magic.
Searching for matching files in lib/:
Making GRC bindings for lib/bar_impl.cc...
tbi
Error: Can't parse output signature.
Traceback (most recent call last):
  File "/home/john/nuradio/bin/gr_modtool", line 46, in 
main()
  File "/home/john/nuradio/bin/gr_modtool", line 38, in main
modtool.run()
  File
"/home/john/nuradio/lib/python2.7/dist-packages/gnuradio/modtool/modtool_makexml.py",
line 76, in run
self._make_grc_xml_from_block_data(params, iosig, blockname)
  File
"/home/john/nuradio/lib/python2.7/dist-packages/gnuradio/modtool/modtool_makexml.py",
line 100, in _make_grc_xml_from_block_data
if iosig[inout]['max_ports'] == '-1':
KeyError: 'out'

Need some help :)

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

Re: [Discuss-gnuradio] Announcing USRP/GNU Radio and RFNoC Workshops in the Los Angeles Area

2017-11-29 Thread Sumit Kumar

Hello Neel,

Sounds great!

Do you have such workshop plans in Europe, probably in France/Germany.
Recently I attended the NI workshop on the same during ICC 2017 Paris, but
due to some reasons the agenda was not covered during the workshop. And it
was very short also.

I am very much interested in attending such detailed workshop. I request
you to plan :)

Regards
Sumit

On Wed, Nov 29, 2017 at 6:58 PM, Neel Pandeya 
wrote:

> ==
> Ettus Research will be running a series of free, hands-on,
> technical workshops in the Los Angeles area.
>
> USRP, UHD, GNU Radio Workshop
> Tuesday December 12, from 09:00 to 17:00
> El Segundo, California, USA
>
> RFNoC Workshop
> Wednesday December 13, from 09:00 to 16:00
> El Segundo, California, USA
>
> USRP, UHD, GNU Radio Workshop
> Thursday December 14, from 09:00 to 17:00
> Santa Ana, California, USA
>
> RFNoC Workshop
> Friday December 15, from 09:00 to 16:00
> Santa Ana, California, USA
>
> ==
> Descriptions of the Workshops:
>
> Title:
> Introduction to the USRP, UHD, and GNU Radio (Open-Source Toolchain)
>
> Abstract:
> This workshop will provide a thorough and practical introduction to
> the USRP hardware and the open-source software toolchain (UHD and
> GNU Radio). We will examine the hardware and architecture of the
> entire USRP family of software-defined radios. We will discuss topics
> such as how to get started using a new USRP device, how to install and
> configure the open-source software toolchain, programming the USRP
> using the UHD API from C++, using GNU Radio with the USRP and creating
> and running flowgraphs, using GNU Radio from both GRC and Python, and
> various debugging techniques. Several exercises will be performed,
> such as implementing an FM transmitter and receiver. Various
> demonstrations of wireless systems will be shown. A discussion of the
> embedded E310 radio and using embedded SDR will be included. Several
> other open-source tools will be discussed, such as GQRX, Fosphor,
> Inspectrum, and several Out-of-Tree (OOT) modules. A discussion of
> cellular applications, including OpenBTS and LTE stacks, as well as
> GPS/GNSS applications will be presented. Several other miscellaneous
> topics such as 10 Gigabit Ethernet networking, host system performance
> tuning, X300/X310 device recovery, and some best practices will be
> discussed. Attendees should come away with a solid foundation and
> practical understanding of how to configure, program, and use the USRP
> to implement a wide range range of wireless systems.
>
> Title:
> FPGA Programming on the USRP with the RFNoC Framework
>
> Abstract:
> Ettus Research's RFNoC (RF Network-on-Chip) software framework is
> designed to decrease the development time for experienced FPGA
> engineers seeking to integrate IP into the USRP FPGA signal
> processing chain. RFNoC is the framework for USRP devices that use
> Xilinx 7-series FPGAs (E310, E312, X300, X310). RFNoC is built around
> a packetized network infrastructure in the FPGA that handles the
> transport of control and sample data between the host CPU and the
> radio. Users target their custom algorithms to the FPGA in the form
> of Computation Engines (CE), which are processing blocks that attach
> to this network. CEs act as independent nodes on the network that can
> receive and transmit data to any other node (e.g., another CE, the
> radio block, or the host CPU).  Users can create modular,
> FPGA-accelerated SDR applications by chaining CEs into a flow graph.
> RFNoC is supported in UHD and GNU Radio. In this workshop, we will
> present an interactive hands-on tutorial on RFNoC, including a
> discussion on its design and capabilities, demonstrations of several
> existing examples, and a walk-through on implementing a user-defined
> CE and integrating the CE into GNU Radio.
>
> ==
> Addresses of the two workshop locations:
>
> AWR Corporation / National Instruments
> 1960 E Grand Avenue, Suite 430
> El Segundo, California, 90245
> http://www.awrcorp.com/company/contact-us/locations
>
> WinSoft
> 1932 E Deere Avenue, Suite 110
> Santa Ana, California, 92705
> http://www.winsoft.com/
> http://www.ni.com/training/locations/
>
> ==
> Details and Logistics:
>
> * The workshops are free, technical, and hands-on.
>
> * The content of the two sessions of the USRP, UHD, GNU Radio Workshop
> and the RFNoC Workshop will be the same between El Segundo
> and Santa Ana.
>
> * Each day, coffee and donuts/bagels will be provided at 08:30,
> as well as lunch around 12:00, and an afternoon snack.
>
> * In both workshops, laptop computers and USRP radios will be
> provided for use. Attendees do not need to bring or prepare anything.
>
> * Space is limited and will be allocated on a fir

Re: [Discuss-gnuradio] Blank display in control port performance monitor in gr-ieee 80211

2017-11-22 Thread Sumit Kumar

The same happens while running gr-ieee-802-15-4 too :-/

They were working smoothly a couple of months back :(

On Wed, Nov 22, 2017 at 10:26 AM, Sumit Kumar  wrote:

> Hi,
>
> I am running wifi_rx and I put
>
> CtrlPort Performance Monitor and CtrlPort Monitor block in the flow graph.
>
> I don't see any thing on the Ctrl Performace Monitor. Its blank.
>
> Image attached.
>
> I remember I did the same experiment a couple of months back and it
> worked.
>
> Also whenever I click any button on the blank display of Ctrl Performace
> Monitor, I see following warnings
>
> 
> ControlPort Monitor running.
> ControlPort Monitor running.
> gr::log :INFO: controlport - Apache Thrift: -h john-Precision-5510 -p 32979
> OOmonitor::endpoints() = -h john-Precision-5510 -p 32979
> running: ['gr-perf-monitorx', 'john-Precision-5510', '32979']
> monitor::endpoints() = -h john-Precision-5510 -p 32979
> running: ['gr-ctrlport-monitor', 'john-Precision-5510', '32979']
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/matplotlib/backends/backend_qt5.py",
> line 259, in mousePressEvent
> guiEvent=event)
>   File "/usr/lib/python2.7/dist-packages/matplotlib/backend_bases.py",
> line 1903, in button_press_event
> self.callbacks.process(s, mouseevent)
>   File "/usr/lib/python2.7/dist-packages/matplotlib/cbook.py", line 563,
> in process
> proxy(*args, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/matplotlib/cbook.py", line 430,
> in __call__
> return mtd(*args, **kwargs)
>   File "/home/john/prefix/default/bin/gr-perf-monitorx", line 837, in
> button_press
> i = nearby.index(min(nearby))
> ValueError: min() arg is an empty sequence
> Traceback (most recent call last):
>   File "/home/john/prefix/default/bin/gr-perf-monitorx", line 594, in rtt
> self.parent.newSubWindow(  DataTableRuntimes(self.radioclient,
> self.G_stream),  "Runtime Table" );
>   File "/home/john/prefix/default/bin/gr-perf-monitorx", line 433, in
> __init__
> super(DataTableRuntimes, self).__init__( radioclient, G)
>   File "/home/john/prefix/default/bin/gr-perf-monitorx", line 353, in
> __init__
> Qt.QTableWidgetItem(nodes[i][0]))
>   File 
> "/usr/local/lib/python2.7/dist-packages/networkx/classes/reportviews.py",
> line 277, in __getitem__
> ddict = self._nodes[n]
> KeyError: 0
> Traceback (most recent call last):
>   File "/home/john/prefix/default/bin/gr-perf-monitorx", line 597, in bpt
> self.parent.newSubWindow(  DataTableBuffers(self.radioclient,
> self.G_stream),  "Buffers Table" );
>   File "/home/john/prefix/default/bin/gr-perf-monitorx", line 375, in
> __init__
> super(DataTableBuffers, self).__init__(radioclient, G)
>   File "/home/john/prefix/default/bin/gr-perf-monitorx", line 353, in
> __init__
> Qt.QTableWidgetItem(nodes[i][0]))
>   File 
> "/usr/local/lib/python2.7/dist-packages/networkx/classes/reportviews.py",
> line 277, in __getitem__
> ddict = self._nodes[n]
> 
>
>
>
>
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Blank display in control port performance monitor in gr-ieee 80211

2017-11-22 Thread Sumit Kumar

Hi,

I am running wifi_rx and I put

CtrlPort Performance Monitor and CtrlPort Monitor block in the flow graph.

I don't see any thing on the Ctrl Performace Monitor. Its blank.

Image attached.

I remember I did the same experiment a couple of months back and it worked.

Also whenever I click any button on the blank display of Ctrl Performace
Monitor, I see following warnings


ControlPort Monitor running.
ControlPort Monitor running.
gr::log :INFO: controlport - Apache Thrift: -h john-Precision-5510 -p 32979
OOmonitor::endpoints() = -h john-Precision-5510 -p 32979
running: ['gr-perf-monitorx', 'john-Precision-5510', '32979']
monitor::endpoints() = -h john-Precision-5510 -p 32979
running: ['gr-ctrlport-monitor', 'john-Precision-5510', '32979']
Traceback (most recent call last):
  File
"/usr/lib/python2.7/dist-packages/matplotlib/backends/backend_qt5.py", line
259, in mousePressEvent
guiEvent=event)
  File "/usr/lib/python2.7/dist-packages/matplotlib/backend_bases.py", line
1903, in button_press_event
self.callbacks.process(s, mouseevent)
  File "/usr/lib/python2.7/dist-packages/matplotlib/cbook.py", line 563, in
process
proxy(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/matplotlib/cbook.py", line 430, in
__call__
return mtd(*args, **kwargs)
  File "/home/john/prefix/default/bin/gr-perf-monitorx", line 837, in
button_press
i = nearby.index(min(nearby))
ValueError: min() arg is an empty sequence
Traceback (most recent call last):
  File "/home/john/prefix/default/bin/gr-perf-monitorx", line 594, in rtt
self.parent.newSubWindow(  DataTableRuntimes(self.radioclient,
self.G_stream),  "Runtime Table" );
  File "/home/john/prefix/default/bin/gr-perf-monitorx", line 433, in
__init__
super(DataTableRuntimes, self).__init__( radioclient, G)
  File "/home/john/prefix/default/bin/gr-perf-monitorx", line 353, in
__init__
Qt.QTableWidgetItem(nodes[i][0]))
  File
"/usr/local/lib/python2.7/dist-packages/networkx/classes/reportviews.py",
line 277, in __getitem__
ddict = self._nodes[n]
KeyError: 0
Traceback (most recent call last):
  File "/home/john/prefix/default/bin/gr-perf-monitorx", line 597, in bpt
self.parent.newSubWindow(  DataTableBuffers(self.radioclient,
self.G_stream),  "Buffers Table" );
  File "/home/john/prefix/default/bin/gr-perf-monitorx", line 375, in
__init__
super(DataTableBuffers, self).__init__(radioclient, G)
  File "/home/john/prefix/default/bin/gr-perf-monitorx", line 353, in
__init__
Qt.QTableWidgetItem(nodes[i][0]))
  File
"/usr/local/lib/python2.7/dist-packages/networkx/classes/reportviews.py",
line 277, in __getitem__
ddict = self._nodes[n]

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

[Discuss-gnuradio] Understanding GNU Radio Debugging

2017-11-16 Thread Sumit Kumar

(My comments are unbold, system commands and prints are bold)

Hi,

I followed tutorials below:

https://wiki.gnuradio.org/index.php/TutorialsGDB
https://wiki.gnuradio.org/index.php/TutorialsDebugging

I made a dummy block. I am learning to debug GR apps. I put the following
inside my work function

*std::cout << "Hello" << std::endl; *
*GR_LOG_DEBUG(d_logger, "\n");*
*GR_LOG_DEBUG(d_logger, boost::format("Hello Debugger") );*

And I expect them to be printed while the program runs. However I never see
them printed at all :-/ Then I thought to use gdb and see whats happening.

Here is what I did:
First I did cmake using the following :

*cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_GR_LOG=On
-DCMAKE_INSTALL_PREFIX=../ ../*

Its says me following. I wanted logging actually but looks like it ignored
me.

*CMake Warning:*
*  Manually-specified variables were not used by the project:*

*ENABLE_GR_LOG*

Is this OK ?

Well I went ahead and compiled. Make test was also successful.

Now I created a grc file using my own block and in the top_block.py, I did
the following at the bottom:

*if __name__ == '__main__':*
*print 'Blocked waiting for GDB attach (pid = %d)' % (os.getpid(),)*
*raw_input ('Press Enter to continue: ')*
*main()*

Upon running it, I got pid and attached my gdb to that. Hit enter and I got
following

*john@john-Precision-5510:~/radio/default/src/gr-ieee-80211/build$ sudo gdb
-p 6160*
*GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1*
*Copyright (C) 2016 Free Software Foundation, Inc.*
*License GPLv3+: GNU GPL version 3 or later
>*
*This is free software: you are free to change and redistribute it.*
*There is NO WARRANTY, to the extent permitted by law.  Type "show copying"*
*and "show warranty" for details.*
*This GDB was configured as "x86_64-linux-gnu".*
*Type "show configuration" for configuration details.*
*For bug reporting instructions, please see:*
*>.*
*Find the GDB manual and other documentation resources online at:*
*>.*
*For help, type "help".*
*Type "apropos word" to search for commands related to "word".*
*Attaching to process 6160*
*[New LWP 6161]*
*[New LWP 6162]*
*[New LWP 6163]*
*[New LWP 6164]*
*[New LWP 6165]*
*[New LWP 6166]*
*[New LWP 6167]*
*[Thread debugging using libthread_db enabled]*
*Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".*
*0x7f654851624d in read () at ../sysdeps/unix/syscall-template.S:84*
*84 ../sysdeps/unix/syscall-template.S: No such file or directory.*

Is this normal ? I searched on google but couldn't understand properly.

Well I kept going ahead and made a break point on my work function.


*b gr::ieee802_11::test_cf_impl::work(int, std::vector >&, std::vector
>&) *

Then I continued in gdb, program started running correctly but never saw my
outputs printed. Even I made break point where the print statements are
there, dint work :(

*Breakpoint 1 at 0x7f65146cc2f0: file
/home/john/radio/default/src/gr-ieee-80211/lib/test_cf_impl.cc, line 63.*
*(gdb) c*
*Continuing.*
*[New Thread 0x7f650de3b700 (LWP 6300)]*
*[New Thread 0x7f650d63a700 (LWP 6301)]*
*[New Thread 0x7f650ce39700 (LWP 6302)]*
*[New Thread 0x7f64fc83b700 (LWP 6303)]*
*[New Thread 0x7f64fc03a700 (LWP 6304)]*
*[New Thread 0x7f64fb308700 (LWP 6306)]*
*[New Thread 0x7f64fab07700 (LWP 6307)]*
*[New Thread 0x7f64fa306700 (LWP 6308)]*
*[New Thread 0x7f64f9b05700 (LWP 6309)]*
*[New Thread 0x7f64f9304700 (LWP 6310)]*
*[Switching to Thread 0x7f64fab07700 (LWP 6307)]*

*Thread 15 "test_cf3" hit Breakpoint 1, gr::ieee802_11::test_cf_impl::work
(this=0x2023650, noutput_items=8184, *
*input_items=std::vector of length 1, capacity 1 = {...}, *
*output_items=std::vector of length 1, capacity 1 = {...})*
*at /home/john/radio/default/src/gr-ieee-80211/lib/test_cf_impl.cc:63*
*warning: Source file is more recent than executable.*
*63 {*
*(gdb) n*
*[Thread 0x7f64fc03a700 (LWP 6304) exited]*
*68   volk_32fc_magnitude_squared_32f(out, in, noi);*
*(gdb) n*
*63 {*

What obvious mistake I am doing ? Isn't this the right way to use
GR_LOG_DEBUGGER

I was also not able to see the print outputs during my make test.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help in adding new block to existing OOT module

2017-11-14 Thread Sumit Kumar

Yes just 1 minute after posting this mail I realized that hyphen in include
guard is the root.
I always created my own OOT, never added block in existing OOT, good
learning for me !

I understood, the "make install" should place the public header in
/include.

Yes the CMakelist.txt was updated by the gr_modtool.

Thanks :)



On Tue, Nov 14, 2017 at 5:51 PM, Marcus Müller  wrote:

> Hi Sumit,
>
> On Tue, 2017-11-14 at 17:13 +0100, Sumit Kumar wrote:
>
> > Added a new block test_block_cf to existing module gr-ieee-80211
> >
> > >> gr_modtool add test_block_cf
>
> Correct way to do it!
>
> > It added test_block_cf_impl.cc and test_block_cf_impl.h in /lib and
> > test_block_cf.h in /include/ieee802_11
>
> it should have also added the appropriate targets in the individual
> CMakeLists.txt,
>
> >
> > Now I did the usual stuff in my work function, also copied
> >
> > test_block_cf.h from /include/ieee802_11 to /prefix/include/ieee802-11/
> gnuradio/ieee802_11
> > to make it a public header file. Seems gr_modtool does not want to do
> this for me.
>
> Not its job; it sets up the CMake Files, and then the includes should
> be copied over with a "make install".
> >
> > I also noticed that by default my namespace was ieee802-11 which is
> different from ieee802_11 used by the author. Hence I changed ieee802-11 to
> ieee802_11 in all my files which were generated by gr_modtool.
>
> That's interesting! So, yeah, the author might have hit a slight
> inconsistency here:
> The project name (just like the folder name) is with -, the namespace
> is with _, so yes, your manual changes are necessary here.
>
> > Following to this I did following inside build directory of gr-ieee-80211
> >
> > >> cmake -DENABLE_DOXYGEN=ON -DCMAKE_INSTALL_PREFIX=../ ../
> > >> make
>
> > Make throws errors as below which is related to inheritance I guess.
> >
> >  #define INCLUDED_IEEE802-11_TEST_BLOCK_CF_IMPL_H
>
> as you can see, "-" becomes a problem, as it's interpreted as operator,
> so it needs to be replaced with "_" here, too.
>
> Best regards,
> Marcus
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Help in adding new block to existing OOT module

2017-11-14 Thread Sumit Kumar

Hi,

*I went inside the folder *

>> cd gr-ieee-80211

*Added a new block test_block_cf to existing module gr-ieee-80211*

>> gr_modtool add test_block_cf

It added test_block_cf_impl.cc and test_block_cf_impl.h in /lib and
test_block_cf.h in /include/ieee802_11

Now I did the usual stuff in my work function, also copied

test_block_cf.h from /include/ieee802_11 to
/prefix/include/ieee802-11/gnuradio/ieee802_11
to make it a public header file. *Seems gr_modtool does not want to do this
for me. *

I also noticed that by default my namespace was *ieee802-11* which is
different from *ieee802_11* used by the author. Hence I changed *ieee802-11
*to* ieee802_11 *in all my files which were generated by gr_modtool.

Following to this I did following inside build directory of gr-ieee-80211

>> cmake -DENABLE_DOXYGEN=ON -DCMAKE_INSTALL_PREFIX=../ ../
>> make

Make throws errors as below which is related to inheritance I guess.

~
john@john-Precision-5510:~/radio/default/src/gr-ieee-80211/build$ make
[  2%] Built target ieee802_11_generated_includes
[  4%] Built target ieee802_11_generated_sources
[  6%] Building CXX object
lib/CMakeFiles/gnuradio-ieee802_11.dir/test_block_cf_impl.cc.o
In file included from
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.cc:26:0:
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.h:21:25:
warning: extra tokens at end of #ifndef directive
 #ifndef INCLUDED_IEEE802-11_TEST_BLOCK_CF_IMPL_H
 ^
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.h:22:25:
warning: ISO C++11 requires whitespace after the macro name
 #define INCLUDED_IEEE802-11_TEST_BLOCK_CF_IMPL_H
 ^
In file included from
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.h:24:0,
 from
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.cc:26:
/home/john/radio/default/src/gr-ieee-80211/include/ieee802-11/test_block_cf.h:22:25:
warning: extra tokens at end of #ifndef directive
 #ifndef INCLUDED_IEEE802-11_TEST_BLOCK_CF_H
 ^
In file included from
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.cc:26:0:
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.h:30:5:
error: expected class-name before ‘{’ token
 {
 ^
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.cc:31:5:
error: ‘test_block_cf’ does not name a type
 test_block_cf::sptr
 ^
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.cc: In
constructor
‘gr::ieee802_11::test_block_cf_impl::test_block_cf_impl(size_t)’:
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.cc:42:23:
error: expected class-name before ‘(’ token
   : gr::sync_block("test_block_cf",
   ^
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.cc:42:23:
error: expected ‘{’ before ‘(’ token
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.cc: At
global scope:
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.cc:42:24:
error: expected unqualified-id before string constant
   : gr::sync_block("test_block_cf",
^
/home/john/radio/default/src/gr-ieee-80211/lib/test_block_cf_impl.cc:42:24:
error: expected ‘)’ before string constant
lib/CMakeFiles/gnuradio-ieee802_11.dir/build.make:560: recipe for target
'lib/CMakeFiles/gnuradio-ieee802_11.dir/test_block_cf_impl.cc.o' failed
make[2]: ***
[lib/CMakeFiles/gnuradio-ieee802_11.dir/test_block_cf_impl.cc.o] Error 1
CMakeFiles/Makefile2:200: recipe for target
'lib/CMakeFiles/gnuradio-ieee802_11.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-ieee802_11.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
john@john-Precision-5510:~/radio/default/src/gr-ieee-80211/build$
/* -*- c++ -*- */
/* 
 * Copyright 2017 <+YOU OR YOUR COMPANY+>.
 * 
 * This is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3, or (at your option)
 * any later version.
 * 
 * This software is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this software; see the file COPYING.  If not, write to
 * the Free Software Foundation, Inc., 51 Franklin Street,
 * Boston, MA 02110-1301, USA.
 */

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include 
#include "test_block_cf_impl.h"
#include 

namespace gr {
  namespace ieee802_11 {

test_block_cf::sptr
test_block_cf::make(size_t vlen)
{
  return gnuradio::get_initial_sptr
(new test_block_cf_

[Discuss-gnuradio] Sampling rate of gr-ieee 802.15.4

2017-11-09 Thread Sumit Kumar

Hi,

The 802.15.4 spec says that the channels should be 2 MHz wide with 5 MHz
inter channel spacing.

Why does gr-ieee 802.15.4 uses a sampling rate of 4MHz instead of 2 MHz ?

Off course it works with commercial devices, but I am curious why 4 MHz and
not 2 MHz.

Regards

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

Re: [Discuss-gnuradio] Successive Interference Cancellation using GR

2017-11-07 Thread Sumit Kumar

I was wondering whats the limit for set_history() of gr::block.

For SIC, my intuitive feeling is that I have to buffer the samples, a lot
of samples. If I take the simple case where PDU lengths are very less. 1
byte for 802.11 and 1 byte for 802.15.4,
I will end in 560 samples for 802.11 and 898 X 5 ~ 4000 samples for
802.15.4 (multiplied by 5 for upsampling the 4MHz signal of 802.15.4 to 20
MHz)

So the set_history should save at least 4000 previous samples.

I am not sure how it will affect the case where both 802.11 and 802.15.4
being decoded.


On Thu, Nov 2, 2017 at 9:42 PM, Sumit Kumar 
wrote:

> I want to implement a system where I will receive overlapped wifi and
> zigbee on the same channel using same RF front end. Then in the base band I
> wish to do interference cancellation.
>
> I understand that most of the time wifi is stronger than zigbee.
>
> So if the preamble of wifi is not damaged, I will be able to get the
> channel estimates of wifi.
>
> Hopefully if the wifi frame has not suffered much due to interference of
> zigbee(which is very much possible), I can decode and regenerate the wifi
> signal using my channel estimates.
>
> Then I will subtract this regenerated wifi signal from the mixed signal
> (wifi + zigbee).
>
> The residue should give me a relative clean signal from which decoding of
> zigbee might be possible.
>
> Here is graphic for reference:
>
> http://bit.ly/2gZ4Nkk
>
> y1 is a received signal which is x1 + x2. + noise.
>
> First we demodulate x2 (probably because it is stronger), then re modulate
> it. Then subtract it from y1 and then decode x1.
>
> Regards
>
> Sumit
>
>
>
> On Thu, Nov 2, 2017 at 9:02 PM, Marcus Müller 
> wrote:
>
>> Hi Sumit,
>>
>> I wrote that but can't remember the context (it seems there was some).
>>
>> So, maybe, let's start from scratch. What is it that you want to
>> implement as a whole that includes Successive Interference Cancellation?
>> What is the application you're building?
>>
>> Best regards,
>> Marcus
>>
>> On 02.11.2017 20:56, Sumit Kumar wrote:
>>
>> Hi,
>>
>> I was looking for some previous work and I found this link
>>
>> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00304.html
>>
>> where Marcus replied about the difficulty to realize such module in GR.
>>
>> I am sorry but I could't understand it properly.
>>
>> Can someone elaborate it :)
>>
>> I plan to perform SIC on a 802.15.4 waveform which is corrupted by 802.11
>> and vice versa.
>>
>> Regards
>>
>> Sumit
>>
>>
>> ___
>> 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

Re: [Discuss-gnuradio] Using OFDM Frame Equalizer

2017-11-06 Thread sumit kumar

The header will give you some hints  :)
https://gnuradio.org/doc/doxygen/ofdm__equalizer__base_8h_source.html

On 7 Nov 2017 05:51, "Shane Petcavich"  wrote:

> I'm trying to use OFDM Frame Equalizer block in a setup similar to the
> setup described in:
>
> https://gnuradio.org/doc/doxygen/page_ofdm.html
>
> However, from the documentation it is not quite clear what the equalizer
> argument needs to be set to. The documentation in gnuradio companion says
> "The equalizer object that will do the actual work". Unclear what this
> needs to be set to or how to implement the equalizer object. Any help would
> be appreciated.
>
> Thanks
>
>
>
> ___
> 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] Successive Interference Cancellation using GR

2017-11-02 Thread Sumit Kumar

I want to implement a system where I will receive overlapped wifi and
zigbee on the same channel using same RF front end. Then in the base band I
wish to do interference cancellation.

I understand that most of the time wifi is stronger than zigbee.

So if the preamble of wifi is not damaged, I will be able to get the
channel estimates of wifi.

Hopefully if the wifi frame has not suffered much due to interference of
zigbee(which is very much possible), I can decode and regenerate the wifi
signal using my channel estimates.

Then I will subtract this regenerated wifi signal from the mixed signal
(wifi + zigbee).

The residue should give me a relative clean signal from which decoding of
zigbee might be possible.

Here is graphic for reference:

http://bit.ly/2gZ4Nkk

y1 is a received signal which is x1 + x2. + noise.

First we demodulate x2 (probably because it is stronger), then re modulate
it. Then subtract it from y1 and then decode x1.

Regards

Sumit

On Thu, Nov 2, 2017 at 9:02 PM, Marcus Müller 
wrote:

> Hi Sumit,
>
> I wrote that but can't remember the context (it seems there was some).
>
> So, maybe, let's start from scratch. What is it that you want to implement
> as a whole that includes Successive Interference Cancellation? What is the
> application you're building?
>
> Best regards,
> Marcus
>
> On 02.11.2017 20:56, Sumit Kumar wrote:
>
> Hi,
>
> I was looking for some previous work and I found this link
>
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00304.html
>
> where Marcus replied about the difficulty to realize such module in GR.
>
> I am sorry but I could't understand it properly.
>
> Can someone elaborate it :)
>
> I plan to perform SIC on a 802.15.4 waveform which is corrupted by 802.11
> and vice versa.
>
> Regards
>
> Sumit
>
>
> ___
> 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] Successive Interference Cancellation using GR

2017-11-02 Thread Sumit Kumar

Hi,

I was looking for some previous work and I found this link

https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00304.html

where Marcus replied about the difficulty to realize such module in GR.

I am sorry but I could't understand it properly.

Can someone elaborate it :)

I plan to perform SIC on a 802.15.4 waveform which is corrupted by 802.11
and vice versa.

Regards

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

Re: [Discuss-gnuradio] Transition width

2017-11-02 Thread Sumit Kumar

Check this picture. Hope it helps

http://www.labbookpages.co.uk/audio/files/firWindowing/kaiser.png

If I am not wrong, a very small transition width will require more number
of filter taps.

On Thu, Nov 2, 2017 at 8:54 AM, Thom L  wrote:

> Hello,
> I can't understand what the "transition width" parameter represents when
> filtering in gnuradio .. And how to adjust it effectively?
> Thanks
> Thomas
>
> ___
> 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] Warning while running gr-ieee-80211

2017-10-25 Thread Sumit Kumar

Well indeed. I accidentally plugged USB 2.0 cable instead of 3. Thanks.

I realized that "A USB 3.0 cable is required for USB 3.0 speeds"


On Wed, Oct 25, 2017 at 9:08 AM, Bastian Bloessl  wrote:

> Hi,
>
> On 10/25/2017 06:13 AM, sumit kumar wrote:
>
>> *Ubuntu 16.04*
>> *GNURadio and gr-ieee-80211 installed yesterday using pybombs *
>>
>> I get this warning when I run the wifi_rx.grc
>>
>> "The total sum of rates (20.00 MSps on 1 channels) exceeds the
>> maximum capacity of the connection"
>>
>
> Looks like warning from your SDR driver. What are you using? If the same
> hardware already worked, the only thing I could imagine is that you plugged
> a USB 3.0-capable device in a USB 2.0 port.
>
> Best,
> Bastian
>
> ___
> 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] Warning while running gr-ieee-80211

2017-10-24 Thread sumit kumar

*Ubuntu 16.04*
*GNURadio and gr-ieee-80211 installed yesterday using pybombs *

I get this warning when I run the wifi_rx.grc

"The total sum of rates (20.00 MSps on 1 channels) exceeds the maximum
capacity of the connection"

And then a lot of overflows.

I was generating 802.11g using a VSG. My gr-ieee-80211 receiver is not
detecting anything.

I remember I performed the same test in June this year and results were 99%
(over the air).

Whats happening wrong ?

Regards

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

[Discuss-gnuradio] 802.15.4 Frame sync confusion

2017-10-18 Thread sumit kumar

Hi,


If my understanding is correct, most of the 802.15.4 receiver
implementations perform frame synchronization i.e. find the start of the
frame using the preambles which are nothing but 8 zeros(each of which is
further converted to 32 bit chip).

This is done after the OQPSK symbols (complex samples) are already decoded
to bits. Same does the gr-ieee 802.15.4

I was wondering why 802.15.4 does not do frame sync using the complex
samples itself like WiFi do using STS ?

I mean, it already has a pattern of 8 repeated zeros and hence a repeated
sequence of complex samples in the beginning of every frame.

What I am missing here ?

Regards

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

Re: [Discuss-gnuradio] SSH using gr-ieee 802.11 transceiver : (the youtube demo)

2017-07-11 Thread sumit kumar

On 12 July 2017 at 07:51, Bastian Bloessl  wrote:

> Hi,
>
> On 07/12/2017 01:37 AM, sumit kumar wrote:
>
>> Hello,
>>
>> I was trying to understand gr-ieee 802.11 wifi_transceiver.grc
>> I see the youtube video
>> https://www.youtube.com/watch?v=tAVgsJLM-sc
>>
>> I believe a single gr-ieee 802.11 wifi_transceiver.grc is running on a
>> laptop with usrp and communicating with a WiFi card (ath5k driver) of
>> another laptop
>> <*I hope my understanding is correct*>
>>
>
> Yes, that's right.
>
>
>> I visited the git page and it looks to me like "*Ad Hoc Network with WiFi
>> card*" as the author has mentioned >
>> How do I replicate this experiment. If someone has replicated the stuff
>> shown in video, pl let me know :)
>>
>
> The configuration that I used for the GNU Radio transceiver can be found
> in the apps/nic.sh script.
>
> It's not totally trivial to setup, you should have a rough idea about
> networking, MAC addresses, and ARP. Because on the other laptop you have to
> open an ad hoc network, add corresponding static ARP entries for the MAC
> configured for the GNU Radio transceiver, and set an IP in the same subnet
> as the GNU Radio transceivers TUN/TAP interface.
>
Hi,

Actually I am trying the same set-up :) However I face some issues. Such as
, when I configure my TP Link dongle (ath9k) in ad-hoc mode, it switches to
802.11b, instead of 802.11g. Could you suggest any such dongle where I can
force change the modulation method.
Regarding, ARP entries, I had the idea (couldn't  go ahead becz dongle
switch to 802.11b) : First establish adhoc connection between two
dongles(so that ARP tables are updated). Then copy mac address of one
dongle(say dongle A) to the transmitter of my openairinterface wifi
transceiver, then power off the dongle A and turn on my own cloned
transceiver.

However I was trying to send ACK for the pings generated from dongle B (the
other dongle) before the layer 2 trails are exhausted. I am trying all this
inside a RF cage.

How do you manage to work without sending ACK. Also I believe , you did
that video demo over the air. How did you manage without CSMA :)

>
> Best,
> Bastian
>
>
>
>> Regards
>>
>> Sumit
>>
>>
>> * It reminds me of tunnel application which I ran on GNU Radio long back
>> (2012 I guess). There was an application tunnel.py
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> --
> Dipl.-Inform. Bastian Bloessl
> CONNECT Center
> Trinity College Dublin
>
> GitHub/Twitter: @bastibl
> https://www.bastibl.net/
>

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

[Discuss-gnuradio] SSH using gr-ieee 802.11 transceiver : (the youtube demo)

2017-07-11 Thread sumit kumar

Hello,

I was trying to understand gr-ieee 802.11 wifi_transceiver.grc
I see the youtube video
https://www.youtube.com/watch?v=tAVgsJLM-sc

I believe a single gr-ieee 802.11 wifi_transceiver.grc is running on a
laptop with usrp and communicating with a WiFi card (ath5k driver) of
another laptop
<*I hope my understanding is correct*>

I visited the git page and it looks to me like "*Ad Hoc Network with WiFi
card*" as the author has mentioned.

How do I replicate this experiment. If someone has replicated the stuff
shown in video, pl let me know :)

Regards

Sumit


* It reminds me of tunnel application which I ran on GNU Radio long back
(2012 I guess). There was an application tunnel.py
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake warning with -DENABLE_PERFORMANCE_COUNTERS-On (gr-ieee80211)

2017-07-11 Thread sumit kumar

Ok, I fixed the apache issue and control port seems to be running on the
example provided in share/gnuradio/examples/ctrlport
polyphase example

However when I drag and dropped ctrlport in wifi_transceiver.grc , I see
the following

ControlPort Monitor running.
gr::log :INFO: controlport - Apache Thrift: -h john-Precision-5510 -p 39251
Omonitor::endpoints() = -h john-Precision-5510 -p 39251
running: ['gr-perf-monitorx', 'john-Precision-5510', '39251']
OConfiguration has not turned on all of the appropriate ControlPort
features:
[ControlPort] on = False
[ControlPort] edges_list = False
[PerfCounters] on = False
[PerfCounters] export = False

Then I manually set all of them to True, as I did last time, but no luck.

Do I have to rebuild everything again ? The documentation says I can change
the behavior at runtime :(


On 11 July 2017 at 16:08, Marcus Müller  wrote:

> So, the performance counters need to be enabled in your GNU Radio
> preferences; I don't think editing the configuration input template helps,
> unless you build & reinstall (don't do that). Instead, run
> `gnuradio-config-info --prefs` first and check whether PerfCounters are
> enabled.
>
> To query these counters, you can
>
>- use the gr::block::pc_bla_foo() methods of every block, or
>- use ControlPort at run time, for example using the
>gr-ctrlport-monitor, which you can add to a flowgraph elegantly from GRC.
>This, however, requires both an enabled controlport in CMake as well as a
>working and found Thrift installation at CMake time – check whether the
>CMake output contain
>
> -- Configuring gr-ctrlport support...
> --   Dependency Boost_FOUND = 1
> --   Dependency SWIG_FOUND = TRUE
> --   Dependency SWIG_VERSION_CHECK = TRUE
> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> *--   Enabling gr-ctrlport support.*
> --   Override with -DENABLE_GR_CTRLPORT=ON/OFF
>
> AND, directly below
>
> -- Checking for module 'thrift'
> --  Found thrift, version XX.XX.XX
>
> AND, below
>
> -- Python checking for Thrift - found
>
> AND, below
>
> -- Found THRIFT: /usr/lib64/libthrift.so
> -- Found and enabling Thrift backend to ControlPort
>
>
> On 07/11/2017 03:11 PM, sumit kumar wrote:
>
> Ok I understood. Now I have a following question.
>
> I did a grep in the build directory
>
> grep -r 'work_time_total' .
>
> And I found that indeed its there as said on https://gnuradio.org/doc/
> doxygen/page_perf_counters.html
> It  seems a lot of task is already been done ! :)
>
> Then I opened gnuradio-runtime.conf.in and did the following (as
> mentioned in the documentation)
>
> [PerfCounters]
> on = True
> export = True
> #clock = thread
> clock = monotonic
>
> Now I run my application , for example wifi_rx.py
>
> Where do I see the timings ?
>
> I opened the ieee802_11_swig.py, and I see def
> pc_work_time_total(self) is there for all the blocks, but how to use them
> :-/
>
> Can you give a use case, for example :
>
> In line 1953 of ieee802_11_swig.py, we have
>
> class frame_equalizer_sptr(object):
>
> and inside this calss we have the function :
>
> def pc_work_time_total(self):
> """pc_work_time_total(frame_equalizer_sptr self) -> float"""
> return _ieee802_11_swig.frame_equalizer_sptr_pc_work_time_
> total(self)
>
> Now what should I do to see total time consumed by frame_equalizer and
> where do I expect the output.
> 
> 
> ~~~
>
> ./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char 
> *)"mac_sptr_pc_work_time_total",
> _wrap_mac_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"mac_sptr_pc_work_time_total(mac_sptr self) -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
> *)"mapper_sptr_pc_work_time_total", _wrap_mapper_sptr_pc_work_time_total,
> METH_VARARGS, (char *)"mapper_sptr_pc_work_time_total(mapper_sptr self)
> -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
> *)"moving_average_cc_sptr_pc_work_time_total",
> _wrap_moving_average_cc_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"moving_average_cc_sptr_pc_work_time_total(moving_average_cc_sptr self)
> -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
> *)"moving_average_ff_sptr_pc_work_time_total",
> _wrap_moving_average_ff_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"moving_average_ff_sptr_pc_work_time_total(moving_average_ff_sptr self)
> -> float"},

Re: [Discuss-gnuradio] cmake warning with -DENABLE_PERFORMANCE_COUNTERS-On (gr-ieee80211)

2017-07-11 Thread sumit kumar

Ok I understood. Now I have a following question.

I did a grep in the build directory

grep -r 'work_time_total' .

And I found that indeed its there as said on https://gnuradio.org/doc/doxyg
en/page_perf_counters.html
It  seems a lot of task is already been done ! :)

Then I opened gnuradio-runtime.conf.in and did the following (as mentioned
in the documentation)

[PerfCounters]
on = True
export = True
#clock = thread
clock = monotonic

Now I run my application , for example wifi_rx.py

Where do I see the timings ?

I opened the ieee802_11_swig.py, and I see def pc_work_time_total(self)
is there for all the blocks, but how to use them :-/

Can you give a use case, for example :

In line 1953 of ieee802_11_swig.py, we have

class frame_equalizer_sptr(object):

and inside this calss we have the function :

def pc_work_time_total(self):
"""pc_work_time_total(frame_equalizer_sptr self) -> float"""
return
_ieee802_11_swig.frame_equalizer_sptr_pc_work_time_total(self)

Now what should I do to see total time consumed by frame_equalizer and
where do I expect the output.
~~~

./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"mac_sptr_pc_work_time_total", _wrap_mac_sptr_pc_work_time_total,
METH_VARARGS, (char *)"mac_sptr_pc_work_time_total(mac_sptr self) ->
float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"mapper_sptr_pc_work_time_total", _wrap_mapper_sptr_pc_work_time_total,
METH_VARARGS, (char *)"mapper_sptr_pc_work_time_total(mapper_sptr self) ->
float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"moving_average_cc_sptr_pc_work_time_total",
_wrap_moving_average_cc_sptr_pc_work_time_total, METH_VARARGS, (char
*)"moving_average_cc_sptr_pc_work_time_total(moving_average_cc_sptr self)
-> float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"moving_average_ff_sptr_pc_work_time_total",
_wrap_moving_average_ff_sptr_pc_work_time_total, METH_VARARGS, (char
*)"moving_average_ff_sptr_pc_work_time_total(moving_average_ff_sptr self)
-> float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"parse_mac_sptr_pc_work_time_total",
_wrap_parse_mac_sptr_pc_work_time_total, METH_VARARGS, (char
*)"parse_mac_sptr_pc_work_time_total(parse_mac_sptr self) -> float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"sync_long_sptr_pc_work_time_total",
_wrap_sync_long_sptr_pc_work_time_total, METH_VARARGS, (char
*)"sync_long_sptr_pc_work_time_total(sync_long_sptr self) -> float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"sync_short_sptr_pc_work_time_total",
_wrap_sync_short_sptr_pc_work_time_total, METH_VARARGS, (char
*)"sync_short_sptr_pc_work_time_total(sync_short_sptr self) -> float"},




On 11 July 2017 at 13:17, Marcus Müller  wrote:

> Hi Sumit,
>
> Does only GNU Radio need to be built with the  flag
> -DENABLE_PERFORMANCE_COUNTERS or the OOT projects too ?
>
> exactly, only GNU Radio needs to be built with that flag – functionally,
> it's something that is done in the scheduler, not in the blocks the
> scheduler runs.
>
> Best regards,
>
> Marcus
>
> On 07/11/2017 12:59 PM, sumit kumar wrote:
>
> Hi,
>
> I have to do timing analysis of individual blocks of gr-ieee80211
> I have built my gnuradio with the following
>
> ~/rfnoc/src/gnuradio/build$ cmake -DCMAKE_INSTALL_PREFIX=/home/john/rfnoc
> -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_PERFORMANCE_COUNTERS=On
> -Werror ../
>
> build was successful.
>
> And again I built gr-ieee80211 with following
>
> ~/rfnoc/src/gr-ieee-80211/build$ cmake -DCMAKE_INSTALL_PREFIX=/home/john/rfnoc
> -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_PERFORMANCE_COUNTERS=On
> -Werror ../
>
> However I get a warning that
> *CMake Warning:*
> *  Manually-specified variables were not used by the project:*
>
> *ENABLE_PERFORMANCE_COUNTERS*
>
> In order to do timing analysis of individual blocks of gr-ieee80211, I am
> following the documentation at
> https://gnuradio.org/doc/doxygen/page_perf_counters.html
>
> Does only GNU Radio need to be built with the  flag
> -DENABLE_PERFORMANCE_COUNTERS or the OOT projects too ?
>
> 
> 
> ~~
> john@john-Precision-5510:~/rfnoc/src/gr-ieee-80211/build$ cmake
> -DCMAKE_INSTALL_PREFIX=/home/john/rfnoc -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DENABLE_PERFORMANCE_COUNTERS=On -Werror ../
> -- Boost version: 1.58.0
> -- Found the following Boost librar

[Discuss-gnuradio] cmake warning with -DENABLE_PERFORMANCE_COUNTERS-On (gr-ieee80211)

2017-07-11 Thread sumit kumar

Hi,

I have to do timing analysis of individual blocks of gr-ieee80211
I have built my gnuradio with the following

~/rfnoc/src/gnuradio/build$ cmake -DCMAKE_INSTALL_PREFIX=/home/john/rfnoc
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_PERFORMANCE_COUNTERS=On -Werror
../

build was successful.

And again I built gr-ieee80211 with following

~/rfnoc/src/gr-ieee-80211/build$ cmake
-DCMAKE_INSTALL_PREFIX=/home/john/rfnoc -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DENABLE_PERFORMANCE_COUNTERS=On -Werror ../

However I get a warning that
*CMake Warning:*
*  Manually-specified variables were not used by the project:*

*ENABLE_PERFORMANCE_COUNTERS*

In order to do timing analysis of individual blocks of gr-ieee80211, I am
following the documentation at
https://gnuradio.org/doc/doxygen/page_perf_counters.html

Does only GNU Radio need to be built with the  flag
-DENABLE_PERFORMANCE_COUNTERS or the OOT projects too ?

~~
john@john-Precision-5510:~/rfnoc/src/gr-ieee-80211/build$ cmake
-DCMAKE_INSTALL_PREFIX=/home/john/rfnoc -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DENABLE_PERFORMANCE_COUNTERS=On -Werror ../
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   filesystem
--   system
Checking for GNU Radio Module: RUNTIME
 * INCLUDES=/home/john/rfnoc/include
 * LIBS=/home/john/rfnoc/lib/libgnuradio-runtime.so;/home/
john/rfnoc/lib/libgnuradio-pmt.so
GNURADIO_RUNTIME_FOUND = TRUE
Checking for GNU Radio Module: DIGITAL
 * INCLUDES=/home/john/rfnoc/include
 * LIBS=/home/john/rfnoc/lib/libgnuradio-digital.so;/home/
john/rfnoc/lib/libgnuradio-runtime.so;/home/john/rfnoc/
lib/libgnuradio-pmt.so
GNURADIO_DIGITAL_FOUND = TRUE
Checking for GNU Radio Module: FFT
 * INCLUDES=/home/john/rfnoc/include
 * LIBS=/home/john/rfnoc/lib/libgnuradio-fft.so;/home/john/
rfnoc/lib/libgnuradio-runtime.so;/home/john/rfnoc/lib/libgnuradio-pmt.so
GNURADIO_FFT_FOUND = TRUE
Checking for GNU Radio Module: FILTER
 * INCLUDES=/home/john/rfnoc/include
 * LIBS=/home/john/rfnoc/lib/libgnuradio-filter.so;/home/
john/rfnoc/lib/libgnuradio-fft.so;/home/john/rfnoc/lib/
libgnuradio-runtime.so;/home/john/rfnoc/lib/libgnuradio-pmt.so
GNURADIO_FILTER_FOUND = TRUE
Checking for GNU Radio Module: PMT
 * INCLUDES=/home/john/rfnoc/include
 * LIBS=/home/john/rfnoc/lib/libgnuradio-runtime.so;/home/
john/rfnoc/lib/libgnuradio-pmt.so
GNURADIO_PMT_FOUND = TRUE
-- Found LOG4CPP: /usr/lib/liblog4cpp.so
-- 
-- Checking for module SWIG
-- Found SWIG version 3.0.8.
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

ENABLE_PERFORMANCE_COUNTERS


-- Build files have been written to: /home/john/rfnoc/src/gr-ieee-
80211/build
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Reg: gr-ieee 802.11 and wireshark settings for commercial NIC

2016-12-06 Thread Sumit Kumar

On Tue, Dec 6, 2016 at 4:58 AM, Bastian Bloessl 
wrote:

> Hi,
>
> On 5 Dec 2016, at 23:08, sumit kumar  wrote:
> I  mean the wireshark dint detect transmission from gr-ieee 802.11
> transmitter also apart from my custom build transmitter(openairinterface).
>
>>
>>
>
> So AFAIS, this are two problems.
>
> - Your custom transmitter is received by gr-ieee802-11, but not by you
> WiFi card. I guess that’s a configuration issue (see my previous reply).
>
I am working on this.

>
> - gr-ieee802-11 is not received by gr-ieee802-11.
>
No, this works perfectly :) This was never an issue !

> Please make sure to
> - reset the flow graphs to their initial state (no parameters changed).
> Clone the repository again, for example.
> - try to change the gain
> - double-check which TX port is used and if an antenna is connected to
> that port.
>
>
> Best,
> Bastian
>
>
>
>
>>
>>
>>>
>>> I think you should make sure to
>>> - tune to the correct frequency/channel
>>>
>>> Currently I have put this filter in wireshark wlan_radio.frequency ==
>>> 2432 and using gr-ieee 802.11 tx tuned to the same.
>>>
>>
>> You will have to configure the card using something like
>>
>> iw phy  set channel 
>>
>> The filter doesn't tune the card to the correct frequency.
>
> This is also not helping though ! :-/
>
>>
>>
>>
>> - make sure that the network manager doesn't interfere
>>>
>>> How to do this ?
>>>
>>
>> sudo service network-manager stop
>>
>> or edit /etc/NetworkManager/NetworkManager.conf
>>
> I did this, but it stopped my wifi signals. I mean the wifi icon was gone.
>
>
>>
>>
>> Best,
>> Bastian
>>
>>
> Regards
>
> --
> Sumit Kumar
>
>
>
> --
> Dipl.-Inform. Bastian Bloessl
> Distributed Embedded Systems Group
> University of Paderborn, Germany
> http://www.ccs-labs.org/~bloessl/
>
>


-- 
-- 
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Re g tunnel.py

2012-04-05 Thread sumit kumar

4 machines !! so was any extra setting were done or just the same commands
on every machine i.e.

tunnel.py --freq  --bitrate 500k
 and then in other terminal
sudo ifconfig gr0 192.168.200.x



On Thu, Apr 5, 2012 at 7:03 PM, Tom Rondeau  wrote:

> On Thu, Apr 5, 2012 at 7:45 AM, sumitstop
>  wrote:
> >
> > Hi all,
> >
> > Can I use tunnel.py for more than 2 systems. Right now I am able to ping
> > between two systems ( 192.168.200.1  & 192.168.200.2). But when I run the
> > same program in the third system (192.168.200.3) it says destination host
> > unreachable after pinging.
> >
> > ** USRP-1
> >Ubuntu 10.04
> >gnuradio 3.5.2
> >
> > -
> > Sumit Kr.
> > Research Assistant
> > Communication Research center
> > IIIT Hyderabad
> > India
>
>
> Sumit,
> Yes, it is possible, but things get increasingly difficult with
> co-channel interference and no error correction in tunnel.py. At one
> point, I have 4 machines communicating over tunnel.py with each other.
>
> Tom
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

85 matches

Mail list logo