Re: [Discuss-gnuradio] Testing 'noblock' Class

2016-06-02 Thread Dave NotTelling
Martin,

 I have no idea how or why, but it magically works now.  Must have
heard you were on the case :D  Thank you!

-Dave

On Thu, Jun 2, 2016 at 11:19 AM, Martin Braun 
wrote:

> Dave,
>
> what I did was
>
> 1. gr_modtool add -t noblock fo. Answer 'yes' when asked for a QA file.
> 2. Add a silly function to the new class
> 3. Populate the QA files
> 4. 'make test'
>
> That's it. Worked fine.
>
> M
>
> On 06/01/2016 02:58 PM, Dave NotTelling wrote:
> > Also, when I use CPPUNIT_ASSERT_MESSAGE("foobar\n", 1 == 2) I only see
> > the 'F' get printed in the output of ./test-moo.  I do not see the
> > requested message.
> >
> > Perhaps a better question would be are there any good examples of doing
> > this?
> >
> > Thanks!
> >
> > On Wed, Jun 1, 2016 at 1:52 PM, Dave NotTelling  > > wrote:
> >
> > That worked!  One more question: How do I make the test run with
> > 'make test'?  It seems that 'make test' only runs the actual GNU
> > Radio modules and not the 'noblock' classes.
> >
> > On Wed, Jun 1, 2016 at 12:32 PM, Dave NotTelling
> > > wrote:
> >
> > I was not using CPPUINT_ASSER_EQUAL.  I will give that a go
> > later today.  Thank you!
> >
> > On Wed, Jun 1, 2016 at 12:08 PM, Martin Braun
> > > wrote:
> >
> > Are you using assert() or CPPUNIT_ASSERT_*?
> >
> > I just hacked something together, and it worked/failed just
> > fine.
> >
> > This is my class:
> > {{{
> >  34 class TESTOR_API fo
> >  35 {
> >  36 public:
> >  37   fo();
> >  38   ~fo();
> >  39
> >  40   int return_five() { return 5; }
> >  41 private:
> >  42 };
> > }}}
> >
> > And my test:
> > {{{
> >  30 void
> >  31 qa_fo::t1()
> >  32 {
> >  33 fo F;
> >  34 CPPUNIT_ASSERT_EQUAL(F.return_five(), 5);
> >  35 CPPUNIT_ASSERT_EQUAL(F.return_five(), 6);
> >  36 }
> > }}}
> >
> > Line 35 causes to fail when I run make test.
> >
> > M
> >
> > On 05/31/2016 12:36 PM, Dave NotTelling wrote:
> > > I created a noblock C++ class and asked for QA tests to be
> > created.  I
> > > see that the _qa files exist for both .h and .cc files.
> > But, when I run
> > > 'make test' I only see the tests for the actual blocks
> > (sync in this
> > > case).  If I run ./lib/test-MyOTT then I see the output of
> > my noblock
> > > test, but the assert() calls don't cause a failure.  Am I
> > doing
> > > something wrong?
> > >
> > > Thank you!
> > >
> > > -Dave
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org 
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] GNURadio autmatic gain adjustment

2016-06-02 Thread Simon Olvhammar

Hi Ben,
I have implemented a function to dynamically change my system gain based 
on sample distribution (to utilize full range of A/D converter). However 
I'm wondering why the sample values have a dependance on sample rate.

Simon

Den 2016-06-01 kl. 17:19, skrev Ben Hilburn:

Hi Simon -

Just to make sure I'm understanding your question correctly: are you 
asking how to dynamically change your system gain or scale your 
samples so that you are using the full range [-1, +1]?


Cheers,
Ben

On Tue, May 31, 2016 at 5:07 PM, olvhammar > wrote:


Hi,

In my GNURadio program I need to determine the correct gain in
order to fully utilize the dynamic range of the A/D converter of
the Ettus USRP x310.
I currently have implemented a automatic function for this using
the probe samples block and make sure that values stays just
within -1 > +1. I.e I check the distribution and make sure a
certain percentage of the values doesnt go above a threshold value.
However the values seems to have a dependence on sample rates, how
should I think here? Anyone else that have implemented this using
the probe block, what was your method?

Best regards
Simon

___
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] Testing 'noblock' Class

2016-06-02 Thread Martin Braun
Dave,

what I did was

1. gr_modtool add -t noblock fo. Answer 'yes' when asked for a QA file.
2. Add a silly function to the new class
3. Populate the QA files
4. 'make test'

That's it. Worked fine.

M

On 06/01/2016 02:58 PM, Dave NotTelling wrote:
> Also, when I use CPPUNIT_ASSERT_MESSAGE("foobar\n", 1 == 2) I only see
> the 'F' get printed in the output of ./test-moo.  I do not see the
> requested message.  
> 
> Perhaps a better question would be are there any good examples of doing
> this?
> 
> Thanks!
> 
> On Wed, Jun 1, 2016 at 1:52 PM, Dave NotTelling  > wrote:
> 
> That worked!  One more question: How do I make the test run with
> 'make test'?  It seems that 'make test' only runs the actual GNU
> Radio modules and not the 'noblock' classes.
> 
> On Wed, Jun 1, 2016 at 12:32 PM, Dave NotTelling
> > wrote:
> 
> I was not using CPPUINT_ASSER_EQUAL.  I will give that a go
> later today.  Thank you!
> 
> On Wed, Jun 1, 2016 at 12:08 PM, Martin Braun
> > wrote:
> 
> Are you using assert() or CPPUNIT_ASSERT_*?
> 
> I just hacked something together, and it worked/failed just
> fine.
> 
> This is my class:
> {{{
>  34 class TESTOR_API fo
>  35 {
>  36 public:
>  37   fo();
>  38   ~fo();
>  39
>  40   int return_five() { return 5; }
>  41 private:
>  42 };
> }}}
> 
> And my test:
> {{{
>  30 void
>  31 qa_fo::t1()
>  32 {
>  33 fo F;
>  34 CPPUNIT_ASSERT_EQUAL(F.return_five(), 5);
>  35 CPPUNIT_ASSERT_EQUAL(F.return_five(), 6);
>  36 }
> }}}
> 
> Line 35 causes to fail when I run make test.
> 
> M
> 
> On 05/31/2016 12:36 PM, Dave NotTelling wrote:
> > I created a noblock C++ class and asked for QA tests to be
> created.  I
> > see that the _qa files exist for both .h and .cc files. 
> But, when I run
> > 'make test' I only see the tests for the actual blocks
> (sync in this
> > case).  If I run ./lib/test-MyOTT then I see the output of
> my noblock
> > test, but the assert() calls don't cause a failure.  Am I
> doing
> > something wrong?
> >
> > Thank you!
> >
> > -Dave
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 


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


Re: [Discuss-gnuradio] Extending a GNU Radio block with use of inheritance

2016-06-02 Thread Piotr Krysik
W dniu 02.06.2016 o 12:12, Sylvain Munaut pisze:
> Hi,
>
>> but I still don't know how to use inheritance to extend
>> existing blocks (something that in a lot of cases would make perfect sense).
> You can't.
>
> The whole _impl coding pattern is specifically designed to hide the
> internals to outsiders and as such, you just can't extend it from an
> outside project.
>
>
> Cheers,
>
> Sylvain
>
Thanks Sylvain,

You saved me from going into this dead end and loosing time in the process.

Best Regards,
Piotr Krysik

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


Re: [Discuss-gnuradio] Gnu Radio Profiling Questions

2016-06-02 Thread Ben Hilburn
Hi Yile -

Please keep your responses on-list so that others can benefit.

Did you try running other programs from your GNU Radio install, like GRC?

Cheers,
Ben

On Wed, Jun 1, 2016 at 4:44 PM, Yile Ku  wrote:

> Notes on building performance profiling GNU radio
> 1. install thrift-0.9.2
> 2. set  'export
> PYTHONPATH=/usr/lib/python2.7/site-packages:/usr/lib/python2.7/dist-packages'
> 3. cmake -DENABLE_PERFORMANCE_COUNTERS=True ..
> 4. verify output for found thrift is true
>
> On Wed, Jun 1, 2016 at 9:14 AM, Ben Hilburn  wrote:
>
>> Hi Yile -
>>
>> Can you use anything from your install, like `gnuradio-companion`? Based
>> on the error, your issue doesn't appear to be related to profiling, but
>> rather setting up your $PYTHONPATH for using GNU Radio, generally.
>>
>> Have you configured your $PYTHONPATH post install?
>>
>>
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/FedoraInstall/67#Post-installation-instructions
>>
>> Cheers,
>> Ben
>>
>> On Tue, May 31, 2016 at 11:25 AM, Yile Ku  wrote:
>>
>>> Hello.
>>>
>>> I built gnu radio using the cmake -DENABLE_PERFORMANCE_COUNTERS=True on
>>> Ubuntu 14.04.4 32-bit.  I then did a 'sudo make install'.
>>>
>>> When I run gr-ctrlport-monitor I get the following error:
>>>
>>> e@ubuntu:~$ gr-ctrlport-monitor
>>> Traceback (most recent call last):
>>>   File "/usr/local/bin/gr-ctrlport-monitor", line 28, in 
>>> from gnuradio.ctrlport.GrDataPlotter import *
>>>   File
>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GrDataPlotter.py",
>>> line 26, in 
>>> from gnuradio.ctrlport.GNURadio import ControlPort
>>> ImportError: No module named GNURadio
>>>
>>> Is there a good Wiki page on setting up profiling?
>>> Y-
>>>
>>>
>>> ___
>>> 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] Make fails

2016-06-02 Thread Ben Hilburn
Hi Tom -

Just to be sure, after pulling the latest from `master`, did you also
update your Volk submodule pointer?

$ git submodule update

Cheers,
Ben

On Wed, Jun 1, 2016 at 10:44 PM, Ron Economos  wrote:

> Master builds okay here.
>
> The VOLK commit for this is:
>
>
> https://github.com/gnuradio/volk/commit/11fadd3af8ebd3c9ddda6160e115a686a3aec5d8
>
> The corresponding GNU Radio commit is:
>
>
> https://github.com/gnuradio/gnuradio/commit/cee8f5041c70c01e8ee128be7d817d4594f8cffb
>
> Ron
>
>
> On 06/01/2016 07:32 PM, Ron Economos wrote:
>
> Your VOLK version doesn't look correct. It should be b930d7f. I suggest
> you do a git clone instead of git pull.
>
> I'm building master right now just to be sure.
>
> Ron W6RZ
>
> On 06/01/2016 06:57 PM, Tom McDermott wrote:
>
> For the first time in a couple of years of successful monthly or so
> updates from git on master,
> I've had make fail.  Ubuntu 14.04, 64-bit architecture, using all 8 cores
> for make. Volk did an update
> on the pull from git tonight.
> gnuradio master version a7285ea
> volk master version 56c0235
>
> Seems to be in
> gr::dtv::dvbt_ofdm_sym_acquisition_impl::peak_detect_process   argument
> conversion  calling into volk.
>
> Here is the build output from make where the errors start...
>
> [ 90%] Built target test_atsci
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/glfsr_source_f_impl.cc.o
> [ 91%] Building CXX object
> gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_demod_reference_signals_impl.cc.o
> [ 91%] Building CXX object
> gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_demap_impl.cc.o
> [ 91%] Building CXX object
> gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_bit_inner_deinterleaver_impl.cc.o
> [ 91%] Building CXX object
> gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_viterbi_decoder_impl.cc.o
> [ 91%]
> /home/tom/gnuradio/gr-dtv/lib/dvbt/dvbt_ofdm_sym_acquisition_impl.cc: In
> member function ‘int
> gr::dtv::dvbt_ofdm_sym_acquisition_impl::peak_detect_process(const float*,
> int, int*, int*)’:
> /home/tom/gnuradio/gr-dtv/lib/dvbt/dvbt_ofdm_sym_acquisition_impl.cc:53:68:
> error: cannot convert ‘uint16_t* {aka short unsigned int*}’ to ‘unsigned
> int*’ in argument passing
>volk_32f_index_max_16u(_index, [0], datain_length);
> ^
> Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/hdlc_deframer_bp_impl.cc.o
> [ 91%] Building CXX object
> gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_convolutional_deinterleaver_impl.cc.o
> make[2]: ***
> [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt/dvbt_ofdm_sym_acquisition_impl.cc.o]
> Error 1
> make[2]: *** Waiting for unfinished jobs
> [ 91%] [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/hdlc_framer_pb_impl.cc.o
> Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/header_payload_demux_impl.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/kurtotic_equalizer_cc_impl.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/lms_dd_equalizer_cc_impl.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/map_bb_impl.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/modulate_vector.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/mpsk_receiver_cc_impl.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/mpsk_snr_est.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/mpsk_snr_est_cc_impl.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/msk_timing_recovery_cc_impl.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_carrier_allocator_cvc_impl.cc.o
> [ 91%] [ 91%] [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_chanest_vcvc_impl.cc.o
> Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_cyclic_prefixer_impl.cc.o
> Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_base.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_simpledfe.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_static.cc.o
> [ 91%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_frame_acquisition_impl.cc.o
> make[1]: *** [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> [ 92%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_frame_equalizer_vcvc_impl.cc.o
> [ 92%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_frame_sink_impl.cc.o
> [ 92%] Building CXX object
> gr-digital/lib/CMakeFiles/gnuradio-digital.dir/ofdm_insert_preamble_impl.cc.o
> [ 

Re: [Discuss-gnuradio] Extending a GNU Radio block with use of inheritance

2016-06-02 Thread Sylvain Munaut
Hi,

> but I still don't know how to use inheritance to extend
> existing blocks (something that in a lot of cases would make perfect sense).

You can't.

The whole _impl coding pattern is specifically designed to hide the
internals to outsiders and as such, you just can't extend it from an
outside project.


Cheers,

Sylvain

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


Re: [Discuss-gnuradio] Extending a GNU Radio block with use of inheritance

2016-06-02 Thread Piotr Krysik
W dniu 02.06.2016 o 11:28, Andrej Rode pisze:
> Hello Piotr,
>
>> If I can inherit from *_impl classes - are you able to present how to do
>> it? *_impl.h headers are not installed together with GNU Radio so I'm
>> not able include them.
> If you want to modify basic blocks shipped with GNU Radio you should
> install GNU radio sources. Depending on your distribution you could use
> PyBOMBS to get reproducible GNU Radio builds with your modifications.
>
>  And this is just a start - then I don't know how
>> prepare CMake files so derived class is linked correctly, and how to
>> prepare SWIG input file. If you are able to spare some time to describe
>> it I would greatly appreciate that.
> I don't know of your current experience with GNU Radio but it sounds
> like you did not play around a lot with GNU Radio already.
> For projects not relevant for the main GNU Radio tree there exists the
> concept of Out-Of-Tree modules (OOT-Modules). With the tool gr_modtool
> it is quite easy to get started with your own module/blocks.
>
> I myself did not modify/create inherited blocks from already existing
> blocks in GNU Radio. The $(class)_impl method was just a suggestion to
> get a hand on the general_work function of the class. Maybe someone else
> will also comment on this issue on the mailing lists. As GNU Radio is
> Free Software you can and should take a look at the sources yourself :).
>
> If you are new to GNU Radio best take a look at the Tutorials [0]. For
> creating own modules especially the OOT-Guide is very useful [1].
>
> Best Regards,
> Andrej
>
> [0] http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials
> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
>
>
>
Hi Andrej and all,

I have some experience with OOT modules - I've developed two OOT
projects (gr-gsm and Multi-RTL). And this is part of the problem - I've
played a bit with GNU Radio, I'm familiar with portions of GNU Radio's
source code, but I still don't know how to use inheritance to extend
existing blocks (something that in a lot of cases would make perfect sense).

I can modify GNU Radio source - but this way I will create a new version
of GNU Radio (specific for needs of my project) that users of my
projects will have to install. In comparison with that copying the
signal processing block's code to my project in order to add few lines
is a lot better option (in terms of amount of code that need to be
maintained, distributed and installed). And the point is to make things
easier not harder for everyone. If a GNU Radio's gurus tell me that
copying the source code is the best option in this situation and I that
shouldn't try to do that with use of inheritance, I'll be able to live
with that answer :).

P.S. please respond also to the mailing-list so others can benefit from
your responses.

Best Regards,
Piotr Krysik

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


Re: [Discuss-gnuradio] Extending a GNU Radio block with use of inheritance

2016-06-02 Thread Piotr Krysik










W dniu 02.06.2016 o 10:46, Andrej Rode pisze:
> Hello Piotr,
>
>
> > Is it possible to do what I want with use of inheritance? If yes -
> > how to do it so I wouldn't have to copy the code?
>
> If your extension of the block is a general enhancement someone else
> could make use of. It is best to directly modify the general_work
> function of the block and contribute back your results.
>
> If your extension is specialized for your use case take a look at
> $(class)_impl. It should be possible to inherit from
> fractional_resampler_impl and then reimplement or modify the functions
> you want to extend.
>
> Maybe there is some other, even better way of achieving your goal I
> don't know yet.
>
> Best Regards,
> Andrej
Hi Andrej,

There are cases when my modifications could benefit others (on a side
note: in my opinion what would benefit everyone would be ability to
access setters of all of the blocks with use of stream tags and
messages), but there are also cases when I want to add some
modifications specific to my project and it doesn't make sense to even
try to make these changes included in the GNU Radio.

If I can inherit from *_impl classes - are you able to present how to do
it? *_impl.h headers are not installed together with GNU Radio so I'm
not able include them. And this is just a start - then I don't know how
prepare CMake files so derived class is linked correctly, and how to
prepare SWIG input file. If you are able to spare some time to describe
it I would greatly appreciate that.

Best Regards,
Piotr




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