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

[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

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

[Sakthivel Velumani]

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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[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] OFDM channel tap questions

[Jeff Long]

Ah, normalization was the secret. The phase offset is there because the 
subcarriers frequencies each look like a phasor that keeps moving (at a 
rate relative to its offset). You want to predict what the phase will be 
at the next symbol.


On 01/12/2018 01:59 PM, edwin wrote:

Hi Jeff,

I just found out that if I normalize these taps by the FFT number(64 in 
this case), they have magnitude of 1! Now my questions are:


Why are there phase offset? The phase offset for each subchannel seems 
different. Is it because of imperfect synchronization?



Regards,

Edwin




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

Re: [Discuss-gnuradio] OFDM channel tap questions

[edwin]

Hi Jeff,

I just found out that if I normalize these taps by the FFT number(64 in 
this case), they have magnitude of 1! Now my questions are:


Why are there phase offset? The phase offset for each subchannel seems 
different. Is it because of imperfect synchronization?



Regards,

Edwin


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

Re: [Discuss-gnuradio] OOT Module Not Working Properly

[CEL]

Hi Tellrell,

>def forecast(self, noutput_items, ninput_items_required):
>#setup size of input_items[i] for work call
>for i in range(len(ninput_items_required)):
>ninput_items_required[i] = noutput_items

what your forecast does: it tells the GNU Radio runtime that your block
behaves like a sync block. So, you should've probably saved yourself
the hassle of implementing a forecast – and that source of bugs – by
simply using a sync_block instead!

>def general_work(self, input_items, output_items):
>in0 = input_items[0]
>self.seen+=in0.shape[0]

Your logic misses one interesting case:
So, let's say self.num_samples = 1024. Then, let your block have
consumed 1000 items in the last work(), so that now self.seen == 1000.

Now, you're greeted with 1000 new items, self.seen == 2000. However,
let the first threshold-exceeding item be the first one of these 1000
new items (or, the absolute 1001. item). So, that is not an item that
came after the 1024, but before. Still, it counts!

There's a high chance that already your first call gets for example
2048 items. So, your program logic breaks down instantly! Even if all
but the first sample of these 2048 are smaller than your threshold,
your block will trigger :(. 

So, what you want is some kind of very simple state machine:

Let your block have a self.status variable, which can hold different
values. Often, these values are just integers or so from a constants
table, but it could be strings, whatever is unique. What your work()
does depends on which state your block currently has:

Start your block in the STATUS_IDLE state; in that state, you use a
variable that counts the number of items already consumed in that state
(your self.seen).
After consuming **exactly** self.num_samples items (not the whole
noutput_items, just how much is need to make
self.seen==self.num_samples!!), you switch to the STATUS_ARMED state.
Now, you look for samples that exceed your threshold, consume all
samples up to (and including) that one, and then switch back to
STATUS_IDLE (don't forget to reset self.seen).

Best regards,
Marcus

On Fri, 2018-01-12 at 02:47 -0500, Tellrell White wrote:
> Hello Guys
> 
> I'm creating a customized block in the GNU Radio framework using python that 
> takes in a number of input items and once that number of input items 
> surpasses a certain number, 1024 of the input items are taken and stored into 
> an array, and then those items are converted to dB and lastly compared to a 
> threshold value, 5 in this case. If any of the values are greater than the 
> threshold value, a message is printed indicating a signal is present, and if 
> none of the values are greater than 5, this is indicated with a message 
> stating "No signal is present".
> 
> In the flow graph attached, I'm using a cosine source and a gaussian noise 
> source to test my block in two different scenarios. 
> 
> In scenario 1, I run the flow graph with both signal sources and I expect to 
> receive a message stating "A signal is present" because the power of the 
> signal will be greater than the threshold. 
> 
> In scenario 2, the cosine source is disabled and only the noise source is 
> runing. In this scenario I expect to get a message indicating no signal is 
> present because the calculated power will be lower than the threshold.
> 
> Scenario 1 works, however, scenario 2 doesn't work no matter how high I raise 
> the threshold value and, at this point, I'm not quite sure as to why. 
> 
> Any help would be appreciated. Both the .py script for the oot block and the 
> .grc file are included.
> 
> Tellrell 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT Module Not Working Properly

[Jeff Long]

Noise amplitude is 1.0, so you are generating a lot of noise.

The following two lines in your block are not right. 'c' is computed but 
not used. 'i' is the original value, not the log. Not sure about the 
scaling factor (1024).


#converts 1024 values stored in in1 to dB and stores them in c
c = math.log10(i/1024)

#checks if any of the values stored in c are greater than a threshold value
if i > 70:

On 01/12/2018 02:47 AM, Tellrell White wrote:

Hello Guys

I'm creating a customized block in the GNU Radio framework using python 
that takes in a number of input items and once that number of input 
items surpasses a certain number, 1024 of the input items are taken and 
stored into an array, and then those items are converted to dB and 
lastly compared to a threshold value, 5 in this case. If any of the 
values are greater than the threshold value, a message is printed 
indicating a signal is present, and if none of the values are greater 
than 5, this is indicated with a message stating "No signal is present".


In the flow graph attached, I'm using a cosine source and a gaussian 
noise source to test my block in two different scenarios.


In scenario 1, I run the flow graph with both signal sources and I 
expect to receive a message stating "A signal is present" because the 
power of the signal will be greater than the threshold.


In scenario 2, the cosine source is disabled and only the noise source 
is runing. In this scenario I expect to get a message indicating no 
signal is present because the calculated power will be lower than the 
threshold.


Scenario 1 works, however, scenario 2 doesn't work no matter how high I 
raise the threshold value and, at this point, I'm not quite sure as to why.


Any help would be appreciated. Both the .py script for the oot block and 
the .grc file are included.


Tellrell


___
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] package 'gnuradio-fft' not found

[Koyel Das]

Hi,

Thanks so much. I could resolve the issue by installing the dependencies.

Regards,
Koyel

On Wed, Jan 10, 2018 at 9:35 PM, Dave NotTelling 
wrote:

> You are missing quite a few libs.  The one that's causing your specific
> issue:
>
> -- Configuring gr-fec support...
> --   Dependency ENABLE_VOLK = ON
> --   Dependency Boost_FOUND = 1
> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> --   Dependency ENABLE_GR_BLOCKS = ON
> --   Enabling gr-fec support.
> --   Override with -DENABLE_GR_FEC=ON/OFF
> -- checking for module 'fftw3f >= 3.0'
> --   package 'fftw3f >= 3.0' not found
> -- Could NOT find FFTW3F (missing:  FFTW3F_LIBRARIES FFTW3F_INCLUDE_DIRS)
> --
> -- Configuring gr-fft support...
> --   Dependency ENABLE_VOLK = ON
> --   Dependency Boost_FOUND = 1
> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> --   Dependency ENABLE_GR_BLOCKS = ON
> --   Dependency FFTW3F_FOUND = FALSE
> --   Disabling gr-fft support.
> --   Override with -DENABLE_GR_FFT=ON/OFF
>
> Notice that fftwf3 is missing which means you don't have libfftw which
> means no FFT support.  Since you're running Ubuntu you should look at
> https://wiki.gnuradio.org/index.php/UbuntuInstall and run the canned
> apt-get commands for your version.
>
> On Tue, Jan 9, 2018 at 11:48 PM, Koyel Das  wrote:
>
>> Hi,
>>
>> yes cmake of gnuradio has gr-fft and many other components disables.
>> Following is the outcome of cmake
>>
>> -- Build type not specified: defaulting to release.
>> -- Build type set to Release.
>> -- Extracting version information from git describe...
>> -- Compiler Version: cc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
>> Copyright (C) 2013 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:::-O3 -DNDEBUG  -std=gnu99
>> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized
>> /usr/bin/c++:::-O3 -DNDEBUG  -std=c++98 -fvisibility=hidden
>> -Wsign-compare -Wall -Wno-uninitialized
>> -- ADDING PERF COUNTERS
>> -- Building Static Libraries: OFF
>> -- Boost version: 1.54.0
>> -- Found the following Boost libraries:
>> --   date_time
>> --   program_options
>> --   filesystem
>> --   system
>> --   regex
>> --   thread
>> -- Enabling use of known bad versions of Boost.
>> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
>> suitable version "2.7.6", minimum required is "2.7")
>> --
>> -- Checking for module SWIG
>> -- Found SWIG version 2.0.11.
>> -- Requested SWIG version is at least .
>> -- Disabling SWIG because version check failed.
>> --
>> -- 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 = FALSE
>> --   Dependency SWIG_VERSION_CHECK = FALSE
>> --   Disabling python-support support.
>> --   Override with -DENABLE_PYTHON=ON/OFF
>> --
>> -- Configuring testing-support support...
>> --   Dependency CPPUNIT_FOUND = TRUE
>> --   Enabling testing-support support.
>> --   Override with -DENABLE_TESTING=ON/OFF
>> --
>> -- Configuring VOLK support...
>> -- Build type set to Release.
>> -- Extracting version information from git describe...
>> --
>> -- Python checking for python >= 2.5
>> -- Python checking for python >= 2.5 - found
>> --
>> -- Python checking for Cheetah >= 2.0.0
>> -- Python checking for Cheetah >= 2.0.0 - found
>> -- Boost version: 1.54.0
>> -- Found the following Boost libraries:
>> --   filesystem
>> --   system
>> --   unit_test_framework
>> --   program_options
>> -- Enabling use of known bad versions of Boost.
>> -- checking for module 'orc-0.4 > 0.4.11'
>> --   package 'orc-0.4 > 0.4.11' not 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
>> -- 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
>> -- Available machines: generic;sse2_64_mmx;sse3_64_mm
>> x;ssse3_64_mmx;sse4_a_64_mmx;sse4_1_64_mmx;sse4_2_64_mmx;
>> avx_64_mmx;avx2_64_mmx
>> -- BUILD TYPE = RELEASE
>> -- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden
>> -Wsign-compare -Wall -Wno-uninitialized -Wall
>> -- BUILD INFO ::: generic ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
>> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall
>> -- BUILD INFO ::: sse2_64_mmx ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
>> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
>> -mmmx -msse -msse2
>> -- BUILD INFO