Re: [Discuss-gnuradio] packet sending part

[Martin Braun]

Sure you can change the tx rate, but I'm not sure what you're asking.

Maybe you can start a new thread, and explain what you're trying to do.

M

On 03/24/2016 07:02 PM, SangHyuk Kim wrote:
> HI,
> 
> I checked those files, but I'm using recent version
> 
> I think this is related with usrp Tx rate.
> 
> In usrp_sink_impl.cc, I found function work(noutput_items, input_items,
> output_items). It sends packet to air.
> 
> And I check how many items are passed at this part.
> Most of all is 4096 or 8188 (I think 4096 is maximum packet size but, I
> don't know about 8188), however, these numbers are unstable
> 
> My question is
> 
> Can I change usrp Tx rate ? or this is fixed ?
> 
> Thanks
> 
> 
> 
> 2016-03-25 9:57 GMT+09:00 Martin Braun  >:
> 
> SangHyuk,
> 
> you're not using the more recent OFDM blocks, so you won't get a lot of
> support here -- I recommend moving to the tx_ofdm and rx_ofdm stuff
> instead.
> 
> Cheers,
> Martin
> 
> On 03/24/2016 04:04 AM, SangHyuk Kim wrote:
> > Hi,
> >
> > I'm trying to understand how OFDM packet Tx working
> >
> > I checked Tx rate and I got a poor rate
> > (qam16, freq 1.18GHz, BW 25 MHz, pkt_size 400 --> 4.0 Mbps)
> >
> > I found it's because msg_queue block when packet be inserted to tail
> >
> > When Tx calls 'send_pkt(payload, ..)', it make packet and insert
> to tail
> > of msg_queue.
> >
> > And delete_head is called by ofdm_mapper_bcv_impl::work.
> >
> > I tried to change queue limit from 4 to 0 (non-blocking) and it caused
> > down my computer (maybe memory problem)
> >
> > In this point, I'm wondering which part calls ofdm_mapper_bcv_impl ?
> > In other words, where is actual packet transmitting part ?
> >
> > 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
> 
> 


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

Re: [Discuss-gnuradio] OOT Module Template Expansion Issues

[Martin Braun]

Jacob,

the best way is probably to submit a pull request and then continue the
discussion there, where we can do code reviews.

Thanks!

Martin

On 03/24/2016 08:12 PM, Jacob Gilbert wrote:
> Just as a little more information, it looks like the top-level
> gr_modtool CMake template does attempt to set it's own module directory
> as the top priority
> (https://github.com/gnuradio/gnuradio/blob/master/gr-utils/python/modtool/gr-newmod/CMakeLists.txt#L35),
> however the find_package command
> (https://github.com/gnuradio/gnuradio/blob/master/gr-utils/python/modtool/gr-newmod/CMakeLists.txt#L114)
> makes the system module path a higher preference.
> 
> Re-adding the OOT module directory to the top of CMAKE_MODULE_PATH fixes
> this (though it now appears twice in CMAKE_MODULE_PATH) and allows the
> fix mentioned above to succeed. Is this an acceptable way of handling
> things?
> 
> Jacob
> 
> On Thu, Mar 24, 2016 at 7:00 PM, Jacob Gilbert
> mailto:mrjacobagilb...@gmail.com>> wrote:
> 
> I agree my current approach of clobbering the generate_helper.py
> file that GrMiscUtils sticks into build/lib and build/include is not
> a good one. I am only using it because right now the
> `include(GrMiscUtils)` points to the module in
> /lib/cmake/gnuradio/GrMiscUtils.cmake. I'd rather it
> be pointed to the module inside the OOT at
> /cmake/Modules/GrMiscUtils.cmake, where almost everything
> I put above already lives.
> 
> If that can work we just have to add the appropriate:
> 
> sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python') 
> or
> sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../../python') 
> 
> lines in the GR_EXPAND_X... macros inside the gr_modtool template
> here: 
> https://github.com/gnuradio/gnuradio/blob/master/gr-utils/python/modtool/gr-newmod/cmake/Modules/GrMiscUtils.cmake.
>  I
> just don't understand cmake enough to understand how to get it to
> use the GrMiscUtils inside the OOT module.
> 
> Jacob
> 
> On Thu, Mar 24, 2016 at 6:48 PM, Martin Braun
> mailto:martin.br...@ettus.com>> wrote:
> 
> You can't point to the module inside GNU Radio, because that
> might not
> be installed when you're developing a module.
> 
> If your way works, that's great, but maybe this can be factored
> out into
> a single CMake module as not to bloat the individual
> CMakeLists.txt files.
> 
> Cheers,
> Martin
> 
> 
> On 03/24/2016 05:24 PM, Jacob Gilbert wrote:
> > Thanks Martin,
> >
> > I added something like this to the CMakeLists.txt files in lib and
> > include/testmod:
> >
> > file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/generate_helper.py
> > "#!${PYTHON_EXECUTABLE}
> > import sys, os, re
> > sys.path.append('${GR_RUNTIME_PYTHONPATH}')
> > sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
> > os.environ['srcdir'] = '${CMAKE_CURRENT_SOURCE_DIR}'
> > os.chdir('${CMAKE_CURRENT_BINARY_DIR}')
> > if __name__ == '__main__':
> >   import build_utils
> >   root, inp = sys.argv[1:3]
> >   for sig in sys.argv[3:]:
> >   name = re.sub ('X+', sig, root)
> >   d = build_utils.standard_impl_dict2(name, sig,
> '${component}')
> >   build_utils.expand_template(d, inp)
> > ")
> >
> > Is that what you mean? Or can I tell CMake to use the module in
> > tesmod/cmake/Modules/GrPlatform.cmake?
> >
> > I'd like to know the recommended way, and we can get this
> added into the
> > modtool templates.
> >
> > Jacob
> >
> > On Thu, Mar 24, 2016 at 6:05 PM, Martin Braun
> mailto:martin.br...@ettus.com>
> >  >> wrote:
> >
> > The short answer is, the templated in-tree stuff has
> access to some
> > modules we don't actually export to OOTs. You'll need to
> copy the
> > template infrastructure into your OOT.
> >
> > Cheers,
> > Martin
> >
> > On 03/24/2016 11:25 AM, Jacob Gilbert wrote:
> > > I am attempting to add several templatized blocks to an
> OOT module and
> > > am having trouble with getting things to build correctly.
> > >
> > > After using modtool to add the new block, adding the .t
> extensions to
> > > the impl.cc/imp.h/.h 
> 
> >  files, and adding test
> > > code, I added the following to ../lib/CMakeLists.txt:
> > >
> > >
> > > include(GrMiscUtils)
> > > GR_EXPAND_X_C

Re: [Discuss-gnuradio] [USRP-users] Segmentation Fault from uhd::transport when stopping/starting flowgraph

[Martin Braun]

Oh, I see -- you're calling stop() on the top_block, or the usrp block?
I know we fixed a segfault issue in
4ae7a6015ba719a4720f61cc6f3857de2ebda89f (the praise goes to Marcus
Müller for the fix), but this is not on maint, only on master. What are
you running?

Cheers,
Martin

On 03/24/2016 05:25 PM, Jacob Gilbert wrote:
> Sorry for not being explicit, I am doing this using GR (stock gr-uhd).
> 
> Jacob
> 
> On Thu, Mar 24, 2016 at 5:22 PM, Martin Braun via USRP-users
> mailto:usrp-us...@lists.ettus.com>> wrote:
> 
> Jacob,
> 
> are you using GNU Radio or straight UHD? Your email seems to imply the
> former, but I want to confirm.
> 
> Your backtrace looks familiar; in benchmark_rate we used to sometimes
> run into cases where we'd segfault and then they might look like this.
> The reason was we were shutting down stuff out of order.
> 
> If you have your custom app, make sure the streamer is stopped, then
> flushed, then destroyed before the multi_usrp object is destroyed.
> If you don't do that, the recv thread might be trying to access samples
> for which there are no more valid buffers. The converter would be the
> first to see this => matches your bt.
> 
> Cheers,
> Martin
> 
> 
> On 03/24/2016 06:54 AM, Jacob Gilbert via USRP-users wrote:
> > I have a flowgraph that requires stopping and starting to reconfigure
> > its output, and have run into two different segfaults originating from
> > within UHD.
> >
> > Starting and stopping is done based on user input and by either
> issuing
> > the stop() wait() sequence, or by having a block return "WORK_DONE"
> > (-1). Both have been shown to produce both types of segfault, however
> > the WORK_DONE method anecdotally appears to be less frequent. The
> errors
> > always occur while waiting for the wait() function to return and
> > occasionally hang for an extremely long time before actually throwing
> > sigsev.
> >
> > BT's of the segfaults are here:
> >
> > 
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7f8704fe9700 (LWP 103995)]
> > 0x7f87b25589d0 in
> >
> uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
> > long) () from /usr/local/lib/libuhd.so.003
> > (gdb) i trace
> > No tracepoints.
> > (gdb) bt
> > #0  0x7f87b25589d0 in
> >
> uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
> > long) () from /usr/local/lib/libuhd.so.003
> > #1  0x7f87b26e8433 in
> task_impl::task_loop(boost::function
> > const&) ()
> >from /usr/local/lib/libuhd.so.003
> > #2  0x7f87be684e7a in ?? () from
> > /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
> > #3  0x7f87d2831182 in start_thread (arg=0x7f8704fe9700) at
> > pthread_create.c:312
> > #4  0x7f87d255e47d in clone () at
> > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> >
> > 
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7fce1cff9700 (LWP 112591)]
> > 0x7fcebb8e0b83 in
> >
> 
> __convert_sc16_item32_be_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector > const*> const&, uhd::ref_vector const&, unsigned long) () from
> > /usr/local/lib/libuhd.so.003
> > (gdb) bt
> > #0  0x7fcebb8e0b83 in
> >
> 
> __convert_sc16_item32_be_1_fc32_1_PRIORITY_SIMD::operator()(uhd::ref_vector > const*> const&, uhd::ref_vector const&, unsigned long) () from
> > /usr/local/lib/libuhd.so.003
> > #1  0x7fcebbb33ad9 in
> >
> uhd::transport::sph::recv_packet_handler::converter_thread_task(unsigned
> > long) () from /usr/local/lib/libuhd.so.003
> > #2  0x7fcebbcc3433 in
> task_impl::task_loop(boost::function
> > const&)
> > () from /usr/local/lib/libuhd.so.003
> > #3  0x7fcec7c5fe7a in ?? ()
> >from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
> > #4  0x7fcedbe0c182 in start_thread (arg=0x7fce1cff9700)
> > at pthread_create.c:312
> > #5  0x7fcedbb3947d in clone ()
> > at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> > (gdb)
> >
> > 
> >
> > System Details:
> > OS: Ubuntu 14.04-3
> > UHD 3.9.2
> > GNU Radio: 3.7.9.1
> >
> > Thanks,
> > Jacob
> >
> >
> >
> > ___
> > USRP-users mailing list
> > usrp-us...@lists.ettus.com 
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> 
> 
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.co

Re: [Discuss-gnuradio] OOT Module Template Expansion Issues

[Jacob Gilbert]

Just as a little more information, it looks like the top-level gr_modtool
CMake template does attempt to set it's own module directory as the top
priority (
https://github.com/gnuradio/gnuradio/blob/master/gr-utils/python/modtool/gr-newmod/CMakeLists.txt#L35),
however the find_package command (
https://github.com/gnuradio/gnuradio/blob/master/gr-utils/python/modtool/gr-newmod/CMakeLists.txt#L114)
makes the system module path a higher preference.

Re-adding the OOT module directory to the top of CMAKE_MODULE_PATH fixes
this (though it now appears twice in CMAKE_MODULE_PATH) and allows the fix
mentioned above to succeed. Is this an acceptable way of handling things?

Jacob

On Thu, Mar 24, 2016 at 7:00 PM, Jacob Gilbert 
wrote:

> I agree my current approach of clobbering the generate_helper.py file
> that GrMiscUtils sticks into build/lib and build/include is not a good
> one. I am only using it because right now the `include(GrMiscUtils)` points
> to the module in /lib/cmake/gnuradio/GrMiscUtils.cmake.
> I'd rather it be pointed to the module inside the OOT at
> /cmake/Modules/GrMiscUtils.cmake, where almost everything I
> put above already lives.
>
> If that can work we just have to add the appropriate:
>
> sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
> or
> sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../../python')
>
> lines in the GR_EXPAND_X... macros inside the gr_modtool template here:
> https://github.com/gnuradio/gnuradio/blob/master/gr-utils/python/modtool/gr-newmod/cmake/Modules/GrMiscUtils.cmake
> . I just don't understand cmake enough to understand how to get it to use
> the GrMiscUtils inside the OOT module.
>
> Jacob
>
> On Thu, Mar 24, 2016 at 6:48 PM, Martin Braun 
> wrote:
>
>> You can't point to the module inside GNU Radio, because that might not
>> be installed when you're developing a module.
>>
>> If your way works, that's great, but maybe this can be factored out into
>> a single CMake module as not to bloat the individual CMakeLists.txt files.
>>
>> Cheers,
>> Martin
>>
>>
>> On 03/24/2016 05:24 PM, Jacob Gilbert wrote:
>> > Thanks Martin,
>> >
>> > I added something like this to the CMakeLists.txt files in lib and
>> > include/testmod:
>> >
>> > file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/generate_helper.py
>> > "#!${PYTHON_EXECUTABLE}
>> > import sys, os, re
>> > sys.path.append('${GR_RUNTIME_PYTHONPATH}')
>> > sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
>> > os.environ['srcdir'] = '${CMAKE_CURRENT_SOURCE_DIR}'
>> > os.chdir('${CMAKE_CURRENT_BINARY_DIR}')
>> > if __name__ == '__main__':
>> >   import build_utils
>> >   root, inp = sys.argv[1:3]
>> >   for sig in sys.argv[3:]:
>> >   name = re.sub ('X+', sig, root)
>> >   d = build_utils.standard_impl_dict2(name, sig, '${component}')
>> >   build_utils.expand_template(d, inp)
>> > ")
>> >
>> > Is that what you mean? Or can I tell CMake to use the module in
>> > tesmod/cmake/Modules/GrPlatform.cmake?
>> >
>> > I'd like to know the recommended way, and we can get this added into the
>> > modtool templates.
>> >
>> > Jacob
>> >
>> > On Thu, Mar 24, 2016 at 6:05 PM, Martin Braun > > > wrote:
>> >
>> > The short answer is, the templated in-tree stuff has access to some
>> > modules we don't actually export to OOTs. You'll need to copy the
>> > template infrastructure into your OOT.
>> >
>> > Cheers,
>> > Martin
>> >
>> > On 03/24/2016 11:25 AM, Jacob Gilbert wrote:
>> > > I am attempting to add several templatized blocks to an OOT
>> module and
>> > > am having trouble with getting things to build correctly.
>> > >
>> > > After using modtool to add the new block, adding the .t
>> extensions to
>> > > the impl.cc/imp.h/.h 
>> >  files, and adding test
>> > > code, I added the following to ../lib/CMakeLists.txt:
>> > >
>> > >
>> > > include(GrMiscUtils)
>> > > GR_EXPAND_X_CC_H(testmod testblock_X_impl  c f i
>> s b)
>> > >
>> > > ...
>> > >
>> > > list(APPEND testmod_sources
>> > > ${generated_sources}
>> > > 
>> > >
>> > >
>> > > and the following to ../include/testmod/CMakeLists.txt:
>> > >
>> > >
>> > > include(GrMiscUtils)
>> > > GR_EXPAND_X_H(testmod testblock_X  c f i s b)
>> > >
>> > > add_custom_target(testmod_generated_includes DEPENDS
>> > > ${generated_includes}
>> > > )
>> > >
>> > > ...
>> > >
>> > > install(FILES
>> > > ${generated_includes}
>> > >
>> > > 
>> > >
>> > >
>> > >
>> > > These were borrowed from in-tree templates like fir_filter_XXX; I
>> was
>> > > unable to find an OOT module using templates. I also added
>> appropriate
>> > > #include, %include, and GR_SWIG_BLOCK_MAGIC2 to
>> > swig/testmod_swig.i fo

Re: [Discuss-gnuradio] packet sending part

[SangHyuk Kim]

HI,

I checked those files, but I'm using recent version

I think this is related with usrp Tx rate.

In usrp_sink_impl.cc, I found function work(noutput_items, input_items,
output_items). It sends packet to air.

And I check how many items are passed at this part.
Most of all is 4096 or 8188 (I think 4096 is maximum packet size but, I
don't know about 8188), however, these numbers are unstable

My question is

Can I change usrp Tx rate ? or this is fixed ?

Thanks



2016-03-25 9:57 GMT+09:00 Martin Braun :

> SangHyuk,
>
> you're not using the more recent OFDM blocks, so you won't get a lot of
> support here -- I recommend moving to the tx_ofdm and rx_ofdm stuff
> instead.
>
> Cheers,
> Martin
>
> On 03/24/2016 04:04 AM, SangHyuk Kim wrote:
> > Hi,
> >
> > I'm trying to understand how OFDM packet Tx working
> >
> > I checked Tx rate and I got a poor rate
> > (qam16, freq 1.18GHz, BW 25 MHz, pkt_size 400 --> 4.0 Mbps)
> >
> > I found it's because msg_queue block when packet be inserted to tail
> >
> > When Tx calls 'send_pkt(payload, ..)', it make packet and insert to tail
> > of msg_queue.
> >
> > And delete_head is called by ofdm_mapper_bcv_impl::work.
> >
> > I tried to change queue limit from 4 to 0 (non-blocking) and it caused
> > down my computer (maybe memory problem)
> >
> > In this point, I'm wondering which part calls ofdm_mapper_bcv_impl ?
> > In other words, where is actual packet transmitting part ?
> >
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Project proposal for review

[Martin Braun]

On 03/24/2016 05:19 PM, Martin Braun wrote:
> - If you give us comment-access, we could comment in-page

Discard this, I see you also have it on the GSoC page.

M

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

Re: [Discuss-gnuradio] OOT Module Template Expansion Issues

[Jacob Gilbert]

I agree my current approach of clobbering the generate_helper.py file that
GrMiscUtils sticks into build/lib and build/include is not a good one. I am
only using it because right now the `include(GrMiscUtils)` points to the
module in /lib/cmake/gnuradio/GrMiscUtils.cmake. I'd rather
it be pointed to the module inside the OOT at
/cmake/Modules/GrMiscUtils.cmake,
where almost everything I put above already lives.

If that can work we just have to add the appropriate:

sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
or
sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../../python')

lines in the GR_EXPAND_X... macros inside the gr_modtool template here:
https://github.com/gnuradio/gnuradio/blob/master/gr-utils/python/modtool/gr-newmod/cmake/Modules/GrMiscUtils.cmake
. I just don't understand cmake enough to understand how to get it to use
the GrMiscUtils inside the OOT module.

Jacob

On Thu, Mar 24, 2016 at 6:48 PM, Martin Braun 
wrote:

> You can't point to the module inside GNU Radio, because that might not
> be installed when you're developing a module.
>
> If your way works, that's great, but maybe this can be factored out into
> a single CMake module as not to bloat the individual CMakeLists.txt files.
>
> Cheers,
> Martin
>
>
> On 03/24/2016 05:24 PM, Jacob Gilbert wrote:
> > Thanks Martin,
> >
> > I added something like this to the CMakeLists.txt files in lib and
> > include/testmod:
> >
> > file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/generate_helper.py
> > "#!${PYTHON_EXECUTABLE}
> > import sys, os, re
> > sys.path.append('${GR_RUNTIME_PYTHONPATH}')
> > sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
> > os.environ['srcdir'] = '${CMAKE_CURRENT_SOURCE_DIR}'
> > os.chdir('${CMAKE_CURRENT_BINARY_DIR}')
> > if __name__ == '__main__':
> >   import build_utils
> >   root, inp = sys.argv[1:3]
> >   for sig in sys.argv[3:]:
> >   name = re.sub ('X+', sig, root)
> >   d = build_utils.standard_impl_dict2(name, sig, '${component}')
> >   build_utils.expand_template(d, inp)
> > ")
> >
> > Is that what you mean? Or can I tell CMake to use the module in
> > tesmod/cmake/Modules/GrPlatform.cmake?
> >
> > I'd like to know the recommended way, and we can get this added into the
> > modtool templates.
> >
> > Jacob
> >
> > On Thu, Mar 24, 2016 at 6:05 PM, Martin Braun  > > wrote:
> >
> > The short answer is, the templated in-tree stuff has access to some
> > modules we don't actually export to OOTs. You'll need to copy the
> > template infrastructure into your OOT.
> >
> > Cheers,
> > Martin
> >
> > On 03/24/2016 11:25 AM, Jacob Gilbert wrote:
> > > I am attempting to add several templatized blocks to an OOT module
> and
> > > am having trouble with getting things to build correctly.
> > >
> > > After using modtool to add the new block, adding the .t extensions
> to
> > > the impl.cc/imp.h/.h 
> >  files, and adding test
> > > code, I added the following to ../lib/CMakeLists.txt:
> > >
> > >
> > > include(GrMiscUtils)
> > > GR_EXPAND_X_CC_H(testmod testblock_X_impl  c f i s
> b)
> > >
> > > ...
> > >
> > > list(APPEND testmod_sources
> > > ${generated_sources}
> > > 
> > >
> > >
> > > and the following to ../include/testmod/CMakeLists.txt:
> > >
> > >
> > > include(GrMiscUtils)
> > > GR_EXPAND_X_H(testmod testblock_X  c f i s b)
> > >
> > > add_custom_target(testmod_generated_includes DEPENDS
> > > ${generated_includes}
> > > )
> > >
> > > ...
> > >
> > > install(FILES
> > > ${generated_includes}
> > >
> > > 
> > >
> > >
> > >
> > > These were borrowed from in-tree templates like fir_filter_XXX; I
> was
> > > unable to find an OOT module using templates. I also added
> appropriate
> > > #include, %include, and GR_SWIG_BLOCK_MAGIC2 to
> > swig/testmod_swig.i for
> > > each of the generated blocks. However, when I attempt to build I
> > get the
> > > following error:
> > >
> > >   File
> > >
>  "/home/jacob/gr-testmod/build/include/testmod/generate_helper.py",
> > > line 9, in 
> > > import build_utils
> > > ImportError: No module named build_utils
> > >
> > >
> > >
> > > This obviously does not happen to in-tree modules. I attempted to
> > modify
> > > the gr-testmod/cmake/Modules/GrMiscUtils.cmake file where the
> > > GR_EXPAND_.X..() macros are defined to explicitly include the
> > > appropriate path, however it appears that by default the include
> > > statement I am using actually uses the GrMiscUtils.cmake installed
> > with
> > > gnuradio (into /usr/local/lib/cmake/gnuradio/ in my case). If I
> modify
> > > the u

Re: [Discuss-gnuradio] packet sending part

[Martin Braun]

SangHyuk,

you're not using the more recent OFDM blocks, so you won't get a lot of
support here -- I recommend moving to the tx_ofdm and rx_ofdm stuff instead.

Cheers,
Martin

On 03/24/2016 04:04 AM, SangHyuk Kim wrote:
> Hi,
> 
> I'm trying to understand how OFDM packet Tx working
> 
> I checked Tx rate and I got a poor rate
> (qam16, freq 1.18GHz, BW 25 MHz, pkt_size 400 --> 4.0 Mbps)
> 
> I found it's because msg_queue block when packet be inserted to tail
> 
> When Tx calls 'send_pkt(payload, ..)', it make packet and insert to tail
> of msg_queue.
> 
> And delete_head is called by ofdm_mapper_bcv_impl::work.
> 
> I tried to change queue limit from 4 to 0 (non-blocking) and it caused
> down my computer (maybe memory problem)
> 
> In this point, I'm wondering which part calls ofdm_mapper_bcv_impl ?
> In other words, where is actual packet transmitting part ?
> 
> 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] Building custom RFNoC block

[Martin Braun]

On 03/24/2016 06:34 AM, William Healey wrote:
> -- == Full list of RFNoC blocks: 
> -- * 0/Radio_0
> -- * 0/Radio_1
> -- * 0/AddSub_0
> -- * 0/FIR_0
> -- * 0/FFT_0
> -- * 0/Window_0
> -- * 0/NullSrcSink_0
> -- * 0/LogPwr_0
> -- * 0/MovingAverage_0
> -- * 0/VectorIIR_0
> -- * 0/KeepOneInN_0
> -- * 0/Test_0
> -- * 0/FIFO_0

This is good -- UHD is picking up your new block and all. The GNU Radio
part should be easy in comparison.

> To try to get the block to appear in GRC I  made copies of the cpp
> (uhd/host/lib/rfnoc/test_ctrl_impl.cpp), hpp
> (uhd/host/include/uhd/rfnoc/test_ctrl.hpp) and xml
> (uhd/host/include/uhd/rfnoc/blocks/test.xml) files used by the default
> FIR filter and again slightly customized them for my test block. After
> editing the files I also had to make changes to
> uhd/host/include/uhd/rfnoc/CMakeLists.txt and
> uhd/host/lib/rfnoc/CMakeLists.txt so that the new cpp and hpp files
> would be included when I rebuilt UHD. After rebuilding UHD the blocks
> still did not appear in GRC though.

Yes, they're unrelated. Note you don't need the .cpp and .hpp files for
simple blocks.

> To get the test block to appear in GRC I had to add files to my gr-ettus
> directory (gr-ettus/include/ettus/rfnoc_test_cci.h  
> gr-ettus/lib/rfnoc_test_cci_impl.cc  
> gr-ettus/lib/rfnoc_test_cci_impl.h   gr-ettus/grc/uhd_rfnoc_test.xml)
> and update some makefiles (gr-ettus/include/ettus/CMakeLists.txt  
> gr-ettus/lib/CMakeLists.txt   gedit
> gr-ettus/build/grc/cmake_install.cmake). With the updated files, I
> rebuilt gr-ettus and the test block now appeared in GNU Radio Companion.

This is also good; looks on you're on the right path.
> Now, even though I could add the test block to a flow graph when I tried
> to run the design I received an error about there being no module
> ettus.test. To fix this problem I had to edit gr-ettus/swig/ettus_swig.i
> and add lines for the test block. After rebuilding gr-ettus again the
> error went away, but was replaced with a new one: RuntimeError: Block
> control is not of requested type. I believe this error is caused by a
> lack of certain xml files. Looking in the directory

I don't think so; given your uhd_usrp_probe output. I suspect some
reference to the fir block in your test code.

Your list of files is correct. I think you're nearly there. Check for
any FIR references in your test block.

Cheers,
Martin


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

Re: [Discuss-gnuradio] OOT Module Template Expansion Issues

[Martin Braun]

You can't point to the module inside GNU Radio, because that might not
be installed when you're developing a module.

If your way works, that's great, but maybe this can be factored out into
a single CMake module as not to bloat the individual CMakeLists.txt files.

Cheers,
Martin


On 03/24/2016 05:24 PM, Jacob Gilbert wrote:
> Thanks Martin,
> 
> I added something like this to the CMakeLists.txt files in lib and
> include/testmod:
> 
> file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/generate_helper.py
> "#!${PYTHON_EXECUTABLE}
> import sys, os, re
> sys.path.append('${GR_RUNTIME_PYTHONPATH}')
> sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
> os.environ['srcdir'] = '${CMAKE_CURRENT_SOURCE_DIR}'
> os.chdir('${CMAKE_CURRENT_BINARY_DIR}')
> if __name__ == '__main__':
>   import build_utils
>   root, inp = sys.argv[1:3]
>   for sig in sys.argv[3:]:
>   name = re.sub ('X+', sig, root)
>   d = build_utils.standard_impl_dict2(name, sig, '${component}')
>   build_utils.expand_template(d, inp)
> ")
> 
> Is that what you mean? Or can I tell CMake to use the module in
> tesmod/cmake/Modules/GrPlatform.cmake?
> 
> I'd like to know the recommended way, and we can get this added into the
> modtool templates.
> 
> Jacob
> 
> On Thu, Mar 24, 2016 at 6:05 PM, Martin Braun  > wrote:
> 
> The short answer is, the templated in-tree stuff has access to some
> modules we don't actually export to OOTs. You'll need to copy the
> template infrastructure into your OOT.
> 
> Cheers,
> Martin
> 
> On 03/24/2016 11:25 AM, Jacob Gilbert wrote:
> > I am attempting to add several templatized blocks to an OOT module and
> > am having trouble with getting things to build correctly.
> >
> > After using modtool to add the new block, adding the .t extensions to
> > the impl.cc/imp.h/.h 
>  files, and adding test
> > code, I added the following to ../lib/CMakeLists.txt:
> >
> >
> > include(GrMiscUtils)
> > GR_EXPAND_X_CC_H(testmod testblock_X_impl  c f i s b)
> >
> > ...
> >
> > list(APPEND testmod_sources
> > ${generated_sources}
> > 
> >
> >
> > and the following to ../include/testmod/CMakeLists.txt:
> >
> >
> > include(GrMiscUtils)
> > GR_EXPAND_X_H(testmod testblock_X  c f i s b)
> >
> > add_custom_target(testmod_generated_includes DEPENDS
> > ${generated_includes}
> > )
> >
> > ...
> >
> > install(FILES
> > ${generated_includes}
> >
> > 
> >
> >
> >
> > These were borrowed from in-tree templates like fir_filter_XXX; I was
> > unable to find an OOT module using templates. I also added appropriate
> > #include, %include, and GR_SWIG_BLOCK_MAGIC2 to
> swig/testmod_swig.i for
> > each of the generated blocks. However, when I attempt to build I
> get the
> > following error:
> >
> >   File
> > "/home/jacob/gr-testmod/build/include/testmod/generate_helper.py",
> > line 9, in 
> > import build_utils
> > ImportError: No module named build_utils
> >
> >
> >
> > This obviously does not happen to in-tree modules. I attempted to
> modify
> > the gr-testmod/cmake/Modules/GrMiscUtils.cmake file where the
> > GR_EXPAND_.X..() macros are defined to explicitly include the
> > appropriate path, however it appears that by default the include
> > statement I am using actually uses the GrMiscUtils.cmake installed
> with
> > gnuradio (into /usr/local/lib/cmake/gnuradio/ in my case). If I modify
> > the used GR_EXPAND_X... macros and manually add the correct path
> > (sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python') or
> > '../../python' in the case of the include macro), expansion works
> > correctly, however this makes the code very un-portable.
> >
> > Given my elementary understand of CMake, I have no idea what I am
> doing
> > incorrectly, or what changes if any should be made to modtool, but
> I was
> > unable to find any other documents on how to go about doing this.
> >
> > Thanks,
> > Jacob
> >
> >
> > ___
> > 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/discus

Re: [Discuss-gnuradio] Draft Proposal GSoC: Offline Analysis and Visualization Tools

[Martin Braun]

Reading your proposal, I don't understand what tools exactly I'll have
after you're finished, and how they would look like. Can you provide
some examples and/or mockups?

M

On 03/24/2016 01:11 PM, Usman Haider wrote:
> Hi Nathan,
> 
> I appreciate the time you spent reading the draft and providing such
> detailed feedback. I have uploaded some related MATLAB code on my github
> account [1]. I have added some snapshots in the directory as well so
> that one can see the output without running code. Also uploaded java
> code written for android application that plots spectrum (magnitude and
> phase) of data received on Bluetooth [2]. I have added these in my
> proposal. I am mentioning here for quick reference. I have updated my
> proposal according to your feedback. You can find updated proposal  here:
> 
> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
> 
> 
> Thanks again for your feedback.
> 
> 
> Regards,
> Usman
> 
> 
> [1] https://github.com/UHaider/PastCode/tree/master/MATLAB
> [2] https://github.com/UHaider/PastCode/tree/master/Android
> 
> On Wed, Mar 23, 2016 at 10:01 PM, West, Nathan
> mailto:n...@ostatemail.okstate.edu>> wrote:
> 
> Looking through the proposal I mostly see your translation of the
> idea from the GSoC ideas list to a proposal format. All of that is
> fine, but we've already decided this is a reasonable idea and the
> proposal should convince us that you're the right person to work on it.
> 
> You've provided the right evidence that you've read some of the GSoC
> pages, but my current criticism boils down to missing information
> that we ask for
> here: http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCStudentInfo
> 
> I'll point out *some* specifics but please don't just list responses
> to these things in the proposal. Rather reshape it to giving us an
> idea of what you want to do (which you have) and why you're the
> right person. The list I'm providing is not meant to be exhaustive,
> and I'm not suggesting that you're not the right person to do this,
> just that you haven't addressed that (or your eligibility for GSoC
> in your proposal. It's also possible I am being dense and missed
> some of this information.
> 
> From the page I linked you're missing:
> * Proof of your coding capabilities (this is the big one)
> * University and student status (more of a formality)
> * why do you want to do *this* project? (this is not critical, but
> if you've done any classes or work in areas related to your proposal
> idea than that looks very good)
> 
> Ideally this is all more than a single sentence that says "I did a
> matlab simulation once in a class and it was cool", but much less
> than a college admissions essay on why DSP will save the world.
> 
> Looking forward to the next draft (and hopefully faster turnaround),
> -Nathan
> 
> PS - most of this email can be copy and pasted as feedback for
> several other proposals I've read so far.
> 
> 
> On Wed, Mar 23, 2016 at 6:19 AM, Usman Haider
> mailto:usmanhaide...@gmail.com>> wrote:
> 
> I have not get any feedback on this yet. I hope I have not
> missed anything important? Please, provide feedback on this.
> 
> 
> Regards,
> Usman
> 
> 
> On Mon, Mar 21, 2016 at 11:45 PM, Usman Haider
> mailto:usmanhaide...@gmail.com>> wrote:
> 
> I have added lambda expression in deliverables based on
> Tim's comments. This will allow user to enter lambda
> expression in GUI. That expression will be then evaluated on
> samples and result will be displayed. Rather than providing
> fixed mathematical function (scale/normalize), user  can
> apply anonymous functions, they want, on samples using
> Lambda construct. This will give user more flexibility. I
> have updated my proposal. You can see it on following link
> 
> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
> 
> Awaiting feedback.
> 
> Regards,
> Usman
> 
> On Thu, Mar 17, 2016 at 1:07 PM, Usman Haider
> mailto:usmanhaide...@gmail.com>>
> wrote:
> 
> Hi Community,
> 
> I have made my proposal for the subject GSoC idea.
> Please have a look and give feedback. Thanks for your time.
> 
> 
> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
> 
> Regards,
> Usman
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Dis

Re: [Discuss-gnuradio] OOT Module Template Expansion Issues

[Jacob Gilbert]

Thanks Martin,

I added something like this to the CMakeLists.txt files in lib and
include/testmod:

file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/generate_helper.py
"#!${PYTHON_EXECUTABLE}
import sys, os, re
sys.path.append('${GR_RUNTIME_PYTHONPATH}')
sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python')
os.environ['srcdir'] = '${CMAKE_CURRENT_SOURCE_DIR}'
os.chdir('${CMAKE_CURRENT_BINARY_DIR}')
if __name__ == '__main__':
  import build_utils
  root, inp = sys.argv[1:3]
  for sig in sys.argv[3:]:
  name = re.sub ('X+', sig, root)
  d = build_utils.standard_impl_dict2(name, sig, '${component}')
  build_utils.expand_template(d, inp)
")

Is that what you mean? Or can I tell CMake to use the module in
tesmod/cmake/Modules/GrPlatform.cmake?

I'd like to know the recommended way, and we can get this added into the
modtool templates.

Jacob

On Thu, Mar 24, 2016 at 6:05 PM, Martin Braun 
wrote:

> The short answer is, the templated in-tree stuff has access to some
> modules we don't actually export to OOTs. You'll need to copy the
> template infrastructure into your OOT.
>
> Cheers,
> Martin
>
> On 03/24/2016 11:25 AM, Jacob Gilbert wrote:
> > I am attempting to add several templatized blocks to an OOT module and
> > am having trouble with getting things to build correctly.
> >
> > After using modtool to add the new block, adding the .t extensions to
> > the impl.cc/imp.h/.h  files, and adding test
> > code, I added the following to ../lib/CMakeLists.txt:
> >
> >
> > include(GrMiscUtils)
> > GR_EXPAND_X_CC_H(testmod testblock_X_impl  c f i s b)
> >
> > ...
> >
> > list(APPEND testmod_sources
> > ${generated_sources}
> > 
> >
> >
> > and the following to ../include/testmod/CMakeLists.txt:
> >
> >
> > include(GrMiscUtils)
> > GR_EXPAND_X_H(testmod testblock_X  c f i s b)
> >
> > add_custom_target(testmod_generated_includes DEPENDS
> > ${generated_includes}
> > )
> >
> > ...
> >
> > install(FILES
> > ${generated_includes}
> >
> > 
> >
> >
> >
> > These were borrowed from in-tree templates like fir_filter_XXX; I was
> > unable to find an OOT module using templates. I also added appropriate
> > #include, %include, and GR_SWIG_BLOCK_MAGIC2 to swig/testmod_swig.i for
> > each of the generated blocks. However, when I attempt to build I get the
> > following error:
> >
> >   File
> > "/home/jacob/gr-testmod/build/include/testmod/generate_helper.py",
> > line 9, in 
> > import build_utils
> > ImportError: No module named build_utils
> >
> >
> >
> > This obviously does not happen to in-tree modules. I attempted to modify
> > the gr-testmod/cmake/Modules/GrMiscUtils.cmake file where the
> > GR_EXPAND_.X..() macros are defined to explicitly include the
> > appropriate path, however it appears that by default the include
> > statement I am using actually uses the GrMiscUtils.cmake installed with
> > gnuradio (into /usr/local/lib/cmake/gnuradio/ in my case). If I modify
> > the used GR_EXPAND_X... macros and manually add the correct path
> > (sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python') or
> > '../../python' in the case of the include macro), expansion works
> > correctly, however this makes the code very un-portable.
> >
> > Given my elementary understand of CMake, I have no idea what I am doing
> > incorrectly, or what changes if any should be made to modtool, but I was
> > unable to find any other documents on how to go about doing this.
> >
> > Thanks,
> > Jacob
> >
> >
> > ___
> > 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] Project proposal for review

[Martin Braun]

- If you give us comment-access, we could comment in-page
- Polish the looks. Check punctuation, grammar and spelling.
- I can see you like machine learning, and you're not alone here, but
I'm not sure what it should do w.r.t. filter design
- I don't understand what the results toolbox is, or what exactly the
deliverables are, except for the porting to newer QT
- Please provide more detail for what you actually want to do.

Cheers,
Martin

On 03/24/2016 03:56 PM, Prateek Singhi wrote:
> Greetings,
> 
> I am probably a bit too late in my draft submission. Sincere apologies.
> However it would be a huge help if I could obtain some valuable
> suggestions on improving my proposal for Filter Design Enhancements for
> GSoc 2016.
> 
> Here is the link:
> 
> https://docs.google.com/document/d/18ByVAKqKqJXuIGd_P85QbHI-b59DQlIS982XUqu4b2E/edit?usp=sharing
> 
> Many Thanks.
> Prateek Singhi
> 
> 
> ___
> 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] OOT Module Template Expansion Issues

[Martin Braun]

The short answer is, the templated in-tree stuff has access to some
modules we don't actually export to OOTs. You'll need to copy the
template infrastructure into your OOT.

Cheers,
Martin

On 03/24/2016 11:25 AM, Jacob Gilbert wrote:
> I am attempting to add several templatized blocks to an OOT module and
> am having trouble with getting things to build correctly.
> 
> After using modtool to add the new block, adding the .t extensions to
> the impl.cc/imp.h/.h  files, and adding test
> code, I added the following to ../lib/CMakeLists.txt:
> 
> 
> include(GrMiscUtils)
> GR_EXPAND_X_CC_H(testmod testblock_X_impl  c f i s b)
> 
> ...
> 
> list(APPEND testmod_sources
> ${generated_sources}
> 
> 
> 
> and the following to ../include/testmod/CMakeLists.txt:
> 
> 
> include(GrMiscUtils)
> GR_EXPAND_X_H(testmod testblock_X  c f i s b)
> 
> add_custom_target(testmod_generated_includes DEPENDS
> ${generated_includes}
> )
> 
> ...
> 
> install(FILES
> ${generated_includes}
> 
> 
> 
> 
> 
> These were borrowed from in-tree templates like fir_filter_XXX; I was
> unable to find an OOT module using templates. I also added appropriate
> #include, %include, and GR_SWIG_BLOCK_MAGIC2 to swig/testmod_swig.i for
> each of the generated blocks. However, when I attempt to build I get the
> following error:
> 
>   File
> "/home/jacob/gr-testmod/build/include/testmod/generate_helper.py",
> line 9, in 
> import build_utils
> ImportError: No module named build_utils
> 
> 
> 
> This obviously does not happen to in-tree modules. I attempted to modify
> the gr-testmod/cmake/Modules/GrMiscUtils.cmake file where the
> GR_EXPAND_.X..() macros are defined to explicitly include the
> appropriate path, however it appears that by default the include
> statement I am using actually uses the GrMiscUtils.cmake installed with
> gnuradio (into /usr/local/lib/cmake/gnuradio/ in my case). If I modify
> the used GR_EXPAND_X... macros and manually add the correct path
> (sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python') or
> '../../python' in the case of the include macro), expansion works
> correctly, however this makes the code very un-portable. 
> 
> Given my elementary understand of CMake, I have no idea what I am doing
> incorrectly, or what changes if any should be made to modtool, but I was
> unable to find any other documents on how to go about doing this.
> 
> Thanks,
> Jacob
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


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

Re: [Discuss-gnuradio] How to "close" osmosdr source?

[Kevin Reid]

On Mar 24, 2016, at 15:13, M. Ranganathan  wrote:
> This works fine using USRP so I am wondering if there is a way to close the 
> osmosdr  "source" explicitly before restart.

You must ensure that the old block is destroyed.

In order to do this, you must of course drop all references to it within your 
program, but you must also remove it from the GR flow graph and, if the graph 
is running, _unlock() the graph_ before creating the new block.

But:

> I am building a sensor using osmosdr which continuously sends data to a 
> server. I want the sensor to be resilient to server restarts, so when a 
> server disconnection is detected, my sensor tries to restart itself.

Instead of recreating the source, why not recreate the connection to the server 
and keep the source?

-- 
Kevin Reid  


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

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

  From: 
Tom Golden


Date: 
Thu, 24 Mar 2016 13:07:57 -0600


>Sorry - I was attempting to be courteous to other users.

No worries.  It's just that others can't learn and contribute, if the
conversation goes off list.  Also, I charge for private consulting. ;)

If other users don't like on-topic posts, then I suppose they'll be
unsubscribing shortly anyway.


>I added a Correlation Estimator before the MSK Timing Recover looking
>for 0x7E (the start frame byte for AX.25).  I think it found it (based
>on the image below) - unfortunately when it hits, execution stops with
>the error:


>thread[thread-per-block[9]: ]:
>mmse_fir_interpolator_cc: imu out of bounds.

Ah crud, that bug.

OK, in the MSK timing recovery block, "mu" is an inter-sample distance
in the range [0.0, 1.0), which gets passed to the mmse_fir_interpolator
to interpolate between samples.

The MSK timing recovery block doesn't do enough sanity checking on the
"time_est" tag payload value produced by the corr_est block, so it
screws up its internal value of "mu" and then bombs.

Does your version of gnuradio have this fix in place:
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/msk_timing_recovery_cc_impl.cc#L150
?

If you run the flowgraph again, can you put a tag_debug block on the
output of the corr_est block to dump out the values of the "time_est"
tag.  I'm curious as to what value of "time_est" coming out of the
corr_est block may be tripping up the msk_timing_recovery_block.


-Andy





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

[Discuss-gnuradio] Project proposal for review

[Prateek Singhi]

Greetings,

I am probably a bit too late in my draft submission. Sincere apologies.
However it would be a huge help if I could obtain some valuable suggestions
on improving my proposal for Filter Design Enhancements for GSoc 2016.

Here is the link:

https://docs.google.com/document/d/18ByVAKqKqJXuIGd_P85QbHI-b59DQlIS982XUqu4b2E/edit?usp=sharing

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

[Discuss-gnuradio] How to "close" osmosdr source?

[M. Ranganathan]

Hello,

I am building a sensor using osmosdr which continuously sends data to a
server. I want the sensor to be resilient to server restarts, so when a
server disconnection is detected, my sensor tries to restart itself.

However, I am finding I get the following error:

FATAL: [bladeRF source] Failed to open bladeRF device *:instance=0

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.

This works fine using USRP so I am wondering if there is a way to close the
osmosdr  "source" explicitly before restart.

Thank you in advance for your help.


Ranga.

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

Re: [Discuss-gnuradio] GNU Radio Organizational Changes to Address Growth

[Robert McGwier]

Great stuff  Jonathan.  I look forward to working with you.  Do you think I
will still be here when I am 70?

;-)
Bob


On Mon, Mar 14, 2016 at 10:15 AM, Johnathan Corgan 
wrote:

> Most of you already know me, as I’ve been in the GNU Radio community for
> eleven years in various roles, including release manager, integration
> manager, Live SDR developer, infrastructure manager, engineering
> consultant, and technical trainer.  Today I’m happy to move on to the role
> of Chief Architect.
>
> It is an exciting time of transition for GNU Radio.  Recently there has
> been large growth in several areas--growth in our user base, our number of
> contributors, the types of radio applications and computing environments
> that GNU Radio is running in, and hardware vendor support for interfacing
> with GNU Radio applications.
>
> Much of this success comes from the efforts of unpaid volunteer
> contributors whose code they have made freely available to others in the
> community.  This is the nature of open source development, and to a large
> extent this has been accomplished without much formal direction from the
> project.  As the GNU Radio codebase has grown more complex, we’ve seen the
> need for more structured guidance and coordination across development
> efforts.
>
> As Ben has outlined, we’re filling out the new organizational roles of
> Tech Leads, whom we are looking to champion their respective areas of
> development.  This includes:
>
>
>-
>
>Developing a roadmap for feature development and communicating that
>roadmap to the user community and code contributors across the project
>-
>
>Identifying and recruiting individual code contributors
>-
>
>Shepherding feature proposals in their area through the process of
>getting community feedback and clarification
>-
>
>Coordinating code integration in their area of the code tree prior to
>final review and merging
>-
>
>Ensuring support issues and questions in their area of responsibility
>are properly resolved
>
>
> In the next few weeks, Ben and I will be sharing more details about how we
> will fill out the organization and how we will be operating the project and
> the new Foundation.  Key among these are:
>
>
>-
>
>A new process for proposing, getting community feedback on, and
>documenting new (significant) feature development, patterned after the
>Python Improvement Proposal process many of you are already familiar with
>-
>
>A more structured code review, unit testing, integration, and release
>management process
>-
>
>Roadmap-based development tracks that allow better coordination among
>different developers, especially for feature sets that cross organizational
>lines
>-
>
>Improved communication among our globally distributed community and
>developer base
>
>
> As Chief Architect, I’ll be working closely with Ben, our user community,
> and each of our Tech Leads to accomplish these goals.
>
> -Johnathan
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Bob McGwier
Founder, Federated Wireless, Inc
Founder and Technical Advisor, HawkEye 360, Inc
Research Professor Virginia Tech
Dir. Research:  The Ted and Karyn Hume Center for National Security and
Technology
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
Director of AMSAT
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Organizational Changes to Address Growth

[Robert McGwier]

Ben:

Don't forget you are a Hokie too! Good luck!

Bob


On Fri, Mar 18, 2016 at 6:51 PM, Ben Hilburn  wrote:

> Hi all -
>
> As I mentioned in the thread regarding the website updates, we recently
> discovered that changes to the gnuradio.org DNS caused some MX record
> issues, and many of you didn't actually receive the introduction e-mails
> that Johnathan and I sent out. If you didn't receive them and are
> interested in reading them, you can find them here:
>
>- News Item: http://gnuradio.org/redmine/news/63
>- My Statement:
>http://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00349.html
>- Johnathan's Statement:
>http://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00350.html
>
> Also, as Martin shared yesterday, we had to postpone the developers' call
> due to travel. The next dev call will be *Thurs 31 March*.
>
> As always, if you have any questions, please feel free to send me a note.
> Thanks!
>
> Cheers,
> Ben
>
> On Mon, Mar 14, 2016 at 10:11 AM, Tom Rondeau  wrote:
>
>> I've been running the GNU Radio project for over five years. In this
>> time, we've dramatically expanded its capabilities, prominence, and
>> performance. We have attracted great developers and a fantastic user base.
>> And we have built the highly successful and growing annual GNU Radio
>> conference.
>>
>> I feel that I have accomplished a great deal of what I was hoping to when
>> I took over this role. Part of my job (and much of the fun) was being
>> hands-on with the code almost daily. But there's a lot more to do in GNU
>> Radio, and it is time for a new vision to move it forward to where we see
>> it going next.
>>
>> While I was thinking about this role change, the opportunity arose for me
>> to become a DARPA program manager, which is one of the most exciting
>> opportunities I can imagine. I will still be working on radio,
>> communications, and, of course, software radio, and I still hope to support
>> the project and continue working with the community we have in whatever
>> ways that I can. But this new position gives me an opportunity to pursue
>> engineering, science, technology, and research in areas and ways that I
>> haven't been able to do in my current role.
>>
>> I am pleased to announce our new leadership team, who are already very
>> familiar to many of you. Ben Hilburn will be taking over as Project Lead
>> while Johnathan Corgan will become the Chief Architect in charge of the
>> codebase. They have already been doing a great job of building up their
>> team structure and their vision for the next stages of this project, which
>> is exactly what we need to grow and move the project forward.
>>
>> The transition is already happening, and we can all consider Ben and
>> Johnathan to have taken up their roles today. I will still be actively
>> involved in GNU Radio over the next couple of months until I start my new
>> position at the end of May.
>>
>> You'll be hearing more details from them soon. But I hope that everyone
>> knows how proud I am of this project and what we're doing here as well as
>> my confidence in Ben, Johnathan, and what is coming next.
>>
>> Thank you all!
>>
>> Tom
>>
>>
>> ___
>> 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
>
>


-- 
Bob McGwier
Founder, Federated Wireless, Inc
Founder and Technical Advisor, HawkEye 360, Inc
Research Professor Virginia Tech
Dir. Research:  The Ted and Karyn Hume Center for National Security and
Technology
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
Director of AMSAT
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Organizational Changes to Address Growth

[Robert McGwier]

Best of luck to you Tom.  Come visit the Hokies!

Bob
Virginia Tech

On Mon, Mar 14, 2016 at 10:11 AM, Tom Rondeau  wrote:

> I've been running the GNU Radio project for over five years. In this time,
> we've dramatically expanded its capabilities, prominence, and performance.
> We have attracted great developers and a fantastic user base. And we have
> built the highly successful and growing annual GNU Radio conference.
>
> I feel that I have accomplished a great deal of what I was hoping to when
> I took over this role. Part of my job (and much of the fun) was being
> hands-on with the code almost daily. But there's a lot more to do in GNU
> Radio, and it is time for a new vision to move it forward to where we see
> it going next.
>
> While I was thinking about this role change, the opportunity arose for me
> to become a DARPA program manager, which is one of the most exciting
> opportunities I can imagine. I will still be working on radio,
> communications, and, of course, software radio, and I still hope to support
> the project and continue working with the community we have in whatever
> ways that I can. But this new position gives me an opportunity to pursue
> engineering, science, technology, and research in areas and ways that I
> haven't been able to do in my current role.
>
> I am pleased to announce our new leadership team, who are already very
> familiar to many of you. Ben Hilburn will be taking over as Project Lead
> while Johnathan Corgan will become the Chief Architect in charge of the
> codebase. They have already been doing a great job of building up their
> team structure and their vision for the next stages of this project, which
> is exactly what we need to grow and move the project forward.
>
> The transition is already happening, and we can all consider Ben and
> Johnathan to have taken up their roles today. I will still be actively
> involved in GNU Radio over the next couple of months until I start my new
> position at the end of May.
>
> You'll be hearing more details from them soon. But I hope that everyone
> knows how proud I am of this project and what we're doing here as well as
> my confidence in Ben, Johnathan, and what is coming next.
>
> Thank you all!
>
> Tom
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Bob McGwier
Founder, Federated Wireless, Inc
Founder and Technical Advisor, HawkEye 360, Inc
Research Professor Virginia Tech
Dir. Research:  The Ted and Karyn Hume Center for National Security and
Technology
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
Director of AMSAT
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Draft Proposal GSoC: Offline Analysis and Visualization Tools

[Usman Haider]

Hi Nathan,

I appreciate the time you spent reading the draft and providing such
detailed feedback. I have uploaded some related MATLAB code on my github
account [1]. I have added some snapshots in the directory as well so that
one can see the output without running code. Also uploaded java code
written for android application that plots spectrum (magnitude and phase)
of data received on Bluetooth [2]. I have added these in my proposal. I am
mentioning here for quick reference. I have updated my proposal according
to your feedback. You can find updated proposal  here:

https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf


Thanks again for your feedback.


Regards,
Usman


[1] https://github.com/UHaider/PastCode/tree/master/MATLAB
[2] https://github.com/UHaider/PastCode/tree/master/Android

On Wed, Mar 23, 2016 at 10:01 PM, West, Nathan 
wrote:

> Looking through the proposal I mostly see your translation of the idea
> from the GSoC ideas list to a proposal format. All of that is fine, but
> we've already decided this is a reasonable idea and the proposal should
> convince us that you're the right person to work on it.
>
> You've provided the right evidence that you've read some of the GSoC
> pages, but my current criticism boils down to missing information that we
> ask for here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCStudentInfo
>
> I'll point out *some* specifics but please don't just list responses to
> these things in the proposal. Rather reshape it to giving us an idea of
> what you want to do (which you have) and why you're the right person. The
> list I'm providing is not meant to be exhaustive, and I'm not suggesting
> that you're not the right person to do this, just that you haven't
> addressed that (or your eligibility for GSoC in your proposal. It's also
> possible I am being dense and missed some of this information.
>
> From the page I linked you're missing:
> * Proof of your coding capabilities (this is the big one)
> * University and student status (more of a formality)
> * why do you want to do *this* project? (this is not critical, but if
> you've done any classes or work in areas related to your proposal idea than
> that looks very good)
>
> Ideally this is all more than a single sentence that says "I did a matlab
> simulation once in a class and it was cool", but much less than a college
> admissions essay on why DSP will save the world.
>
> Looking forward to the next draft (and hopefully faster turnaround),
> -Nathan
>
> PS - most of this email can be copy and pasted as feedback for several
> other proposals I've read so far.
>
>
> On Wed, Mar 23, 2016 at 6:19 AM, Usman Haider 
> wrote:
>
>> I have not get any feedback on this yet. I hope I have not missed
>> anything important? Please, provide feedback on this.
>>
>>
>> Regards,
>> Usman
>>
>>
>> On Mon, Mar 21, 2016 at 11:45 PM, Usman Haider 
>> wrote:
>>
>>> I have added lambda expression in deliverables based on Tim's comments.
>>> This will allow user to enter lambda expression in GUI. That expression
>>> will be then evaluated on samples and result will be displayed. Rather than
>>> providing fixed mathematical function (scale/normalize), user  can apply
>>> anonymous functions, they want, on samples using Lambda construct. This
>>> will give user more flexibility. I have updated my proposal. You can see it
>>> on following link
>>>
>>> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>>>
>>> Awaiting feedback.
>>>
>>> Regards,
>>> Usman
>>>
>>> On Thu, Mar 17, 2016 at 1:07 PM, Usman Haider 
>>> wrote:
>>>
 Hi Community,

 I have made my proposal for the subject GSoC idea. Please have a look
 and give feedback. Thanks for your time.

 https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf

 Regards,
 Usman

>>>
>>>
>>
>> ___
>> 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] Draft Proposal GSoC: Offline Analysis and Visualization Tools

[Usman Haider]

Hi Marcus,

Thanks for your feedback, it was helpful. I have made changes according to
your feedback. By the term "tabbed manner", I meant that each plot will
have its own tab. User can select a particular plot type by clicking on its
tab. I replaced the term in the draft. You can see the the updated draft
here:


https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf

Regards,
Usman


> Hi Usman,
>
> make sure your punctuation is right; only use "?" after a sentence that
> /really/ is a question. Make sure there is always a space after
> punctuation, and don't make generalizing (and hence, wrong) statements
> like "And yes,Polar Codes are the coolest codes", which are a bit /too/
> colloquial for an application. Also, after make sure that the words
> after abbreviations ("e.g." etc) have the right capitalization. There's
> also still some typos; get a friend to cross-read the document
> critically; four eyes see more than two.
>
> We're usually not very picky about that, but considering this is an
> application, I might add that on the website, and in the documentation,
> we generally use the capitalization "GNU Radio", not "Gnu Radio"; we
> didn't invent the GNU project, it was already there when Eric Blossom
> started with GNU Radio.
>
> Content-wise, you've got a very fine, week-wise breakdown of your plans;
> however, the items you'd do in those weeks seem of very different size
> and defined at vastly different precisions. Comparing
>
> > Week 8 (11th July - 17th July):
> > a. Add functionality for saving selected plot as a picture.
> > b. Extract user selected samples and save it to another file.
>
> and
>
> > Week 6 (27th June - 03rd July):
> > a. Coding for signal visualization in time, frequency and scatter plots
> in
> > tabbed manner.
> > b. Updating of plots based on tags. e.g sample rate change can
> > translate to
> > change in time-axis of time domain plot.
>
> I'd say that Week 6 contains the a significant of the core deliverable
> of your GSoC proposal, whilst week 8 really has only two features to
> complete.  Maybe you can balance that timeline a little more; not all
> things take the same time!
>
> Also, after literature, I'm still not sure what you mean with displaying
> something in a "tabbed manner"; you should explain that.
>
> Best regards,
> Marcus
> On 23.03.2016 11:19, Usman Haider wrote:
> > I have not get any feedback on this yet. I hope I have not missed
> > anything important? Please, provide feedback on this.
> >
> >
> > Regards,
> > Usman
> >
> > On Mon, Mar 21, 2016 at 11:45 PM, Usman Haider
> > mailto:usmanhaide...@gmail.com>> wrote:
> >
> > I have added lambda expression in deliverables based on Tim's
> > comments. This will allow user to enter lambda expression in GUI.
> > That expression will be then evaluated on samples and result will
> > be displayed. Rather than providing fixed mathematical function
> > (scale/normalize), user  can apply anonymous functions, they want,
> > on samples using Lambda construct. This will give user more
> > flexibility. I have updated my proposal. You can see it on
> > following link
> >
> > https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
> >
> > Awaiting feedback.
> >
> > Regards,
> > Usman
> >
> > On Thu, Mar 17, 2016 at 1:07 PM, Usman Haider
> > mailto:usmanhaide...@gmail.com>> wrote:
> >
> > Hi Community,
> >
> > I have made my proposal for the subject GSoC idea. Please have
> > a look and give feedback. Thanks for your time.
> >
> > https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
> >
> > Regards,
> > Usman
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OOT Module Template Expansion Issues

[Jacob Gilbert]

I am attempting to add several templatized blocks to an OOT module and am
having trouble with getting things to build correctly.

After using modtool to add the new block, adding the .t extensions to the
impl.cc/imp.h/.h files, and adding test code, I added the following to
../lib/CMakeLists.txt:


include(GrMiscUtils)
GR_EXPAND_X_CC_H(testmod testblock_X_impl  c f i s b)

...

list(APPEND testmod_sources
${generated_sources}



and the following to ../include/testmod/CMakeLists.txt:


include(GrMiscUtils)
GR_EXPAND_X_H(testmod testblock_X  c f i s b)

add_custom_target(testmod_generated_includes DEPENDS
${generated_includes}
)

...

install(FILES
${generated_includes}





These were borrowed from in-tree templates like fir_filter_XXX; I was
unable to find an OOT module using templates. I also added appropriate
#include, %include, and GR_SWIG_BLOCK_MAGIC2 to swig/testmod_swig.i for
each of the generated blocks. However, when I attempt to build I get the
following error:

  File "/home/jacob/gr-testmod/build/include/testmod/generate_helper.py",
line 9, in 
import build_utils
ImportError: No module named build_utils



This obviously does not happen to in-tree modules. I attempted to modify
the gr-testmod/cmake/Modules/GrMiscUtils.cmake file where the
GR_EXPAND_.X..() macros are defined to explicitly include the appropriate
path, however it appears that by default the include statement I am using
actually uses the GrMiscUtils.cmake installed with gnuradio (into
/usr/local/lib/cmake/gnuradio/ in my case). If I modify the used
GR_EXPAND_X... macros and manually add the correct path
(sys.path.append('${CMAKE_CURRENT_SOURCE_DIR}/../python') or '../../python'
in the case of the include macro), expansion works correctly, however this
makes the code very un-portable.

Given my elementary understand of CMake, I have no idea what I am doing
incorrectly, or what changes if any should be made to modtool, but I was
unable to find any other documents on how to go about doing this.

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

Re: [Discuss-gnuradio] diminishing returns with increasing frequency offset

[Bastian Bloessl]

Hi,

> On 22 Mar 2016, at 21:58, tom x  wrote:
> 
> >What you could try is to adapt alpha of the single pole IIR, to get the same 
> >averaging with the increased sample rate.
> 
> I tried a variety of values without success but was not really sure what I 
> was doing. Can you expand on what you meant by
> "get the same averaging with the increased sample rate", and how to check 
> this?  I thought about the equation for the 
> single pole filter being subtracted from the original signal  (that is, 
> x[n]-y[n], where y[n] = a*x[n] + (1-a)*y[n-1]), but I didn't
> see the relationship between this and the sample rate. 

Following your notation you would have to decrease ‘a'. Think of a moving 
average, implemented with a FIR filter, which averages over a certain time 
window. If you double the sample rate, you have to double the length of the 
filter to average over the same time window.

Another thing you could try is multiplying the output of the subtract block by 
2, when switching to 8MHz. This way, the input of the MM block would have the 
same amplitude (and amplitude matters).

Apart from that I don’t see any obvious problems. Unfortunately, I’m not in the 
office to test your 8MHz flow graph :-/


> 
> Here is a picture of the RX chain (which works for 4M but not 8, even with 
> the omega adjustment)
> 
> http://i.imgur.com/Kezk9Fq.jpg?1 
> 
> I can put a scope after the USRP source and see some nice bursts; but I'm 
> having trouble inspecting the signal after this 
> block in the chain..what is a good way to visualize what's happening after 
> the quadrature demodulation?

After the subtract block you should have a signal that is centered around 0 and 
the chip sequences should be clearly visible. (The problem is that the trigger 
doesn’t work for the phase.)


> 
> >When this transceiver was implemented, the polyphase clock sync block was 
> >not available yet. You are right, it should improve performance. 
> > If you switch to that block and see performance improvements, it would be 
> > great if you made a pull request.
> 
> I made a pull request to parameterize the sample rate in the PHY block, so it 
> wouldn't be hard coded in. If we can figure out these issues
> I'd be happy to do some tests to compare the two and then make another pull 
> request.

Thanks for the pull request. I just replied on github. In brief, I would prefer 
to keep the transceiver as simple as possible to provide an easy to use base 
that can be easily adapted to ones needs.
I think there are many aspects/paramters that can be studied, but I’m afraid it 
would make the code much more complicated if we introduce options for all of 
them.

(Replacing the MM Clock Recovery with something more robust would, of course, 
still be a good idea in my opinion.)

Best,
Bastian


> 
> >I think there is no reason why that shouldn’t work. It would be helpful if 
> >you could upload your flow graph, maybe there is
> > a mistake somewhere (the picture you posted did not show the USRP and 
> > xlating filters 
> 
>  here is my 2 channel receiver, showing the USRP and filters 
> 
> http://i.imgur.com/dZpIqUw.png?1 
> 
> (the variable chan_width is 2M).
> Can you see some other issue? Maybe getting this working depends on 
> increasing the samp_rate, which goes back to the first problem.
> 
> Thanksagain,
> Tom
> 
> On Mon, Mar 21, 2016 at 3:42 AM, Bastian Bloessl  > wrote:
> Hi,
> 
>> On 19 Mar 2016, at 12:08, tom x > > wrote:
>> 
>> I tried doubling both, the sample rate to 8MHz and Omega to 4, but still no 
>> progress. The setup is simply the 802.15.4 PHY block connected to a USRP 
>> source, listening for an over the air transmission. Can you give some 
>> insight on how you picked the other MM Clock Recovery params? Is there any 
>> other dependence in the PHY block? The papers and guides I looked at explain 
>> what the MM params are but don't give much intuition for choosing them. 
> 
> I didn’t set them and am not an expert, but I think there is no justification 
> for this particular parameter set, i.e., there is no easy formula for 
> calculating ideal parameters. I guess someone started with an educated guess 
> and made simulations to find parameters that worked reasonably well.
> 
> Anyhow, I don’t think that the parameters of the MM block are the problem 
> (once you adapted omega of course). As far as I see
> - the gain parameters are independent from the sample rate as the 
> error/feedback is calculated once per symbol
> - mu is the initial phase and doesn’t matter
> - omega relative limit could be cut in half (when using 8MHz). IIRC, it’s the 
> maximum frequency deviation normalised with the sample rate.
> 
> 
> What you could try is to adapt alpha of the single pole IIR, to get the same 
> averaging with the increased sample rate.
> 
>> 
>> Additionally, based on posts in this thread: 
>> https:

Re: [Discuss-gnuradio] uhd_fft seg fault

[Alexander Levedahl]

Can you run gdb --args python [your flowgraph with its arguments]?

At some point I had an issue that I traced to an FFT block and it turned
out to be one of the volk instructions had a bug in it that was later fixed.

Alex

On Thu, Mar 24, 2016 at 8:29 AM, Marcus D. Leech  wrote:

> On 03/24/2016 07:34 AM, Daniel R. Marlow wrote:
>
>>
>>
>> Thanks Marcus.
>>
>> I did a "sudo ldconfig" but to no avail.
>>
>> I am wondering if the problem is destructive interference between the
>> apt-get install of the binaries
>> and my attempt to install using PyBOMBS?   If so, is there anything I
>> should do to get rid of the PyBOMBS
>> other than an "rm" of the installation directories?
>>
>> --Dan
>>
> That is almost certainly the case.
>
> What installation prefix did you have PyBombs use?I think it will have
> instructed you to use an env.sh, or setupenv.sh, which will
>   contain settings of LD_LIBRARY_PATH, PYTHONPATH, etc.  If you simply log
> out, and log back in, and don't run that setup script,
>   you may be OK, without having to uninstall the PyBombs-installed stuff.
>
> But I'll point out that GR+friends installed from packages are going to be
> out-of-date, sometimes, spectacularly.
>
>
>
>
 marlow@sdr3:~/21cm$ uhd_fft -1420M
 Segmentation fault (core dumped)
 marlow@sdr3:~/21cm$ gnuradio-companion
 Segmentation fault (core dumped)
 marlow@sdr3:~/21cm$ python top_block_ex.py
 Segmentation fault (core dumped)
 marlow@sdr3:~/21cm$




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

>>> ___
>>> 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] Ettus N210 GMSK 9600

[Andy Walls]

Hi Tom:

On Thu, 2016-03-24 at 08:56 -0600, Tom Golden wrote:
> Feel free to ignore this request - as you've helped me quite a lot.

This is the last one I'll respond to that isn't on list.


> I'm sending packets of N bytes containing repeating  in the
> data.  Using you're model, I tapped off of the binary slicer to save
> the bits to a file.  I think I'm in a good position SNR wise now - but
> I'm not seeing any repeated patterns in the data.  Any additional sage
> wisdom?

Well, unless you pack the bits into bytes, things will be hard to see in
the file.  

Even then, if you don't use blocks to find your preamble and line things
up, then you might see your pattern shifted in the resulting bytes.

>From looking at the data, it looks like you have a preamble that is
something like 

0x00 0x00 .. 0x00 0x55 0x01 0x04 ...

The long stream of 0's could fool the square and sync coarse frequency
sync, so be mindful of that.  You might have to do a smarter, data-aided
coarse frequency sync using your received preamble compared to a
reference preamble instead.

The MSK Timing recovery block isn't converging rapidly enough on the
0x55 to get you the right bits for that part of the preamble.
You should consider using the corr_est block to detect and tag your
preamble, so the MSK timing recovery block gets reset when it sees the
tag and converges rapidly on your preamble.

The frequency deviation is higher than I would expect for GMSK at 9600
baud with a BT of 0.4, which is +/- 2400 Hz max.  Check your modulation
index is 0.5, otherwise you're GFSK instead of GMSK; in case you care
about that.

Regards,
Andy

> 
> 
> Thanks,
> -Tom
> 
> 
> 
> On Wed, Mar 23, 2016 at 6:41 PM, Tom Golden 
> wrote:
> Hi Andy,
> 
> 

> 

> Thanks so much for the link!  I'm digging into the gr-ais code
> - but there's certainly a learning curve there. :)
> 
> 
> Thanks!!
> -Tom
> 
> 
> 
> On Wed, Mar 23, 2016 at 5:28 PM, Andy Walls
>  wrote:
> 
> >  From:
> > Tom Golden
> >   Subject:
> > Re: [Discuss-gnuradio] Ettus N210
> > GMSK 9600
> >  Date:
> > Wed, 23 Mar 2016 13:14:18 -0600
> >
> >
> 
> __
> > Here's my flow-graph along with a snapshot of the
> constellation and
> > FFT.
> >
> >
> > Thanks!!
> > -Tom
> 
> Hi Tom,
> 
> A couple of things:
> 
> a) The polyphase resampler isn't going to work well
> without a filter
> definition in the taps field.
> 
> b) The constellation sink will not display anything
> meaningful without
> sample timing synchronization; it is not useful at its
> current position
> in the flowgraph.  The constellation sink also doesn't
> display anything
> useful for an FSK modulation normally; (G)MSK being an
> exception, if
> treating it like a PSK modulation vs. FSK.
> 
> c) You don't have any coarse or fine frequency
> synchronization.  That
> will cause you major problems, if trying to treat GMSK
> as a PSK
> modulation.  It will cause you minor problems, if
> treating GMSK as an
> FSK modulation.
> 
> d) Timing recovery blocks usually want a signal that
> has peaks (which
> you get by putting the signal through a matched
> filter), and those peaks
> should nominally be scaled to +/- 1.0.  You don't have
> a matched filter
> or an AGC before the Clock Recovery block.
> 
> e) The USRP's 0 dB gain setting is actually the USRP
> inserting the
> maximum attenuation it can (e.g. 37 dB of
> attenuation).  That can kill
> your signal to noise ratio.  You may want to consider
> adding "gain" as
> long as the time domain signal doesn't look clipped
> (sometimes hard to
> tell with FSK).
> 
> f) You may wish to look at what Nick Foster's gr-ais
> does to demodulate
> a 9600 baud GMSK AIS signal.  It will probably give
> 

[Discuss-gnuradio] uhd_rx_cfile does not stop running

[Alexander Levedahl]

Hello,

I am using an X310.  Recently, I upgraded both gnuradio and uhd versions.

For gnuradio, running gnuradio-config-info -v returns 33110293.

The most recent change number listed in the UHD changelog is 3.9.2

I recently upgraded the firmware version from 9 to 20 using:
uhd_image_loader --args="[type,address]"
--fpga-path="[path]/usrp_x310_fpga_HGS.bit"

After burning the image I decided to run uhd_rx_cfile to make sure
everything still worked:
uhd_rx_cfile --samp-rate=200e6 -f 2.45e9 -g 0 -N 200e6 -s ./test2.16iqle

This captures 200 million samples at a rate of 200MSps and stores them as
complex short.

The file size was correct at 800MB, but the process would not terminate.
Prior to doing these upgrades, the process would terminate when it reached
the end of the file.

When I ran the process, the first line printed is:
linux; GNU C++ version 4.4.7 20120313 (Red Hat 4.4.7-4); Boost_105600;
UHD_003.010.git-0-unknown.

I am fairly certain the version of UHD I used is 3.9.2, not 3.10.  I saw an
email recently that 3.9.3 was just released, so I am mildly confused as to
why 3.10 is being printed.

In addition, when I ran uhd_rx_cfile with th -v option it failed on print
the Receiving on {} channels line, because of "ValueError: zero length
field name in format".  Commenting that line out fixed the issue.  None of
the rest of the information looked incorrect.

Finally, the ettus man page on usrp_x3x0, says to burn the XGS image when
using 10 Gigabit and HGS when using 1 Gigabit.  However, I can only find an
HG and an HGS image.

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

[Discuss-gnuradio] Building custom RFNoC block

[William Healey]

Hello,

I am trying to create a custom RFNoC block for a USRP X310
(UHD_003.010.rfnoc-316-gb7546712). I have looked at the instructions
on-line for Getting Started
 and RFNoC
Specifications
 and they
seem to say that all I should need to get the RFNoC block setup is a
verilog, cpp, hpp, and xml file but this hasn't been the case.

I want my RFNoC block to be a copy of the default  FIR block, so I copied
the FIR verilog code, changed some of the variable names from 'FIR' to
'test' and gave it a unique NOC ID. I also edited the
uhd/fpga-src/usrp3/top/x300/rfnoc_ce_auto_inst_x310.v file, replacing the
fosphor block with the new test block.

Next I edited uhd/fpga-src/usrp3/lib/rfnoc/Makefile.srcs, adding a line for
my noc_block_test.v.

I used then ran  make X310_RFNOC_HGS (using Vivado 2015.2) to create my
FPGA image which worked successfully and installed it onto the X310. Even
though I was able to see the test block when running uhd_usrp_probe, the
block did not appear in GNU Radio Companion.

-- == Full list of RFNoC blocks: 
-- * 0/Radio_0
-- * 0/Radio_1
-- * 0/AddSub_0
-- * 0/FIR_0
-- * 0/FFT_0
-- * 0/Window_0
-- * 0/NullSrcSink_0
-- * 0/LogPwr_0
-- * 0/MovingAverage_0
-- * 0/VectorIIR_0
-- * 0/KeepOneInN_0
-- * 0/Test_0
-- * 0/FIFO_0

To try to get the block to appear in GRC I  made copies of the cpp
(uhd/host/lib/rfnoc/test_ctrl_impl.cpp), hpp
(uhd/host/include/uhd/rfnoc/test_ctrl.hpp) and xml
(uhd/host/include/uhd/rfnoc/blocks/test.xml) files used by the default FIR
filter and again slightly customized them for my test block. After editing
the files I also had to make changes to
uhd/host/include/uhd/rfnoc/CMakeLists.txt and
uhd/host/lib/rfnoc/CMakeLists.txt so that the new cpp and hpp files would
be included when I rebuilt UHD. After rebuilding UHD the blocks still did
not appear in GRC though.

To get the test block to appear in GRC I had to add files to my gr-ettus
directory (gr-ettus/include/ettus/rfnoc_test_cci.h
gr-ettus/lib/rfnoc_test_cci_impl.cc   gr-ettus/lib/rfnoc_test_cci_impl.h
gr-ettus/grc/uhd_rfnoc_test.xml) and update some makefiles
(gr-ettus/include/ettus/CMakeLists.txt   gr-ettus/lib/CMakeLists.txt
gedit gr-ettus/build/grc/cmake_install.cmake). With the updated files, I
rebuilt gr-ettus and the test block now appeared in GNU Radio Companion.

Now, even though I could add the test block to a flow graph when I tried to
run the design I received an error about there being no module ettus.test.
To fix this problem I had to edit gr-ettus/swig/ettus_swig.i and add lines
for the test block. After rebuilding gr-ettus again the error went away,
but was replaced with a new one: RuntimeError: Block control is not of
requested type. I believe this error is caused by a lack of certain xml
files. Looking in the directory gr-ettus/build/docs/doxygen/xml it contains
files such as classgr_1_1ettus_1_1rfnoc__fir__cci.xml and
classgr_1_1ettus_1_1rfnoc__fir__cci__impl.xml.

I have not found a way to generate similar xml files for my rfnoc test
block. I am wondering how to generate these files, or if there is another
method for creating a custom RFNoC block. I have looked at the instructions
for creating out of tree modules using gr-modtool (
https://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules/5) and
it did create the xml files I am looking for for the square_ff block but it
seems to me that gr-modtool can only be used to create host layer blocks
and not RFNoC blocks.

For summary these are all the files I edited or created:
uhd/fpga-src/usrp3/lib/rfnoc/noc_block_test.v
uhd/fpga-src/usrp3/top/x300/rfnoc_ce_auto_inst_x310.v
uhd/fpga-src/usrp3/lib/rfnoc/Makefile.srcs

uhd/host/include/uhd/rfnoc/test_ctrl.hpp
uhd/host/include/uhd/rfnoc/CMakeLists.txt
uhd/host/include/uhd/rfnoc/blocks/test.xml
uhd/host/lib/rfnoc/test_ctrl_impl.cpp
uhd/host/lib/rfnoc/CMakeLists.txt

gr-ettus/build/grc/cmake_install.cmake
gr-ettus/grc/uhd_rfnoc_test.xml
gr-ettus/include/ettus/CMakeLists.txt
gr-ettus/include/ettus/rfnoc_test_cci.h
gr-ettus/lib/rfnoc_test_cci_impl.cc
gr-ettus/lib/CMakeLists.txt
gr-ettus/swig/ettus_swig.i


Thank you,

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

Re: [Discuss-gnuradio] Upgrade UHD

[Marcus D. Leech]

On 03/24/2016 08:44 AM, Mhe wrote:

I use live_USB.

Regards,
Diyar Muhammed
M: 009647504690060

I'd recommend making yourself a much-newer LiveUSB:

https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD



On Mar 24, 2016, at 12:32 PM, Marcus D. Leech  wrote:


On 03/24/2016 06:38 AM, Diyar Muhammed wrote:
Dear ALL,
I would like to upgrade UHD.
is there any way to do it?
In advance many thanks

What OS are you using?

Did you install UHD from pre-packaged binaries provided by your distribution?



___
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] Upgrade UHD

[Mhe]

I use live_USB.

Regards,
Diyar Muhammed
M: 009647504690060

> On Mar 24, 2016, at 12:32 PM, Marcus D. Leech  wrote:
> 
>> On 03/24/2016 06:38 AM, Diyar Muhammed wrote:
>> Dear ALL,
>> I would like to upgrade UHD.
>> is there any way to do it?
>> In advance many thanks
> What OS are you using?
> 
> Did you install UHD from pre-packaged binaries provided by your distribution?
> 
> 
> 
> ___
> 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] Upgrade UHD

[Marcus D. Leech]

On 03/24/2016 06:38 AM, Diyar Muhammed wrote:

Dear ALL,
I would like to upgrade UHD.
is there any way to do it?
In advance many thanks


What OS are you using?

Did you install UHD from pre-packaged binaries provided by your 
distribution?




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

Re: [Discuss-gnuradio] uhd_fft seg fault

[Marcus D. Leech]

On 03/24/2016 07:34 AM, Daniel R. Marlow wrote:



Thanks Marcus.

I did a "sudo ldconfig" but to no avail.

I am wondering if the problem is destructive interference between the apt-get 
install of the binaries
and my attempt to install using PyBOMBS?   If so, is there anything I should do 
to get rid of the PyBOMBS
other than an "rm" of the installation directories?

--Dan

That is almost certainly the case.

What installation prefix did you have PyBombs use?I think it will 
have instructed you to use an env.sh, or setupenv.sh, which will
  contain settings of LD_LIBRARY_PATH, PYTHONPATH, etc.  If you simply 
log out, and log back in, and don't run that setup script,

  you may be OK, without having to uninstall the PyBombs-installed stuff.

But I'll point out that GR+friends installed from packages are going to 
be out-of-date, sometimes, spectacularly.





marlow@sdr3:~/21cm$ uhd_fft -1420M
Segmentation fault (core dumped)
marlow@sdr3:~/21cm$ gnuradio-companion
Segmentation fault (core dumped)
marlow@sdr3:~/21cm$ python top_block_ex.py
Segmentation fault (core dumped)
marlow@sdr3:~/21cm$




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

___
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] uhd_fft seg fault

[Daniel R. Marlow]

On Mar 23, 2016, at 8:53 PM, Marcus D. Leech wrote:

> On 03/23/2016 07:46 PM, Daniel R. Marlow wrote:
>> Hello,
>> 
>>   H/W:  Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz
>>USRP:  Ettus B210
>> OS:  Ubuntu 15.04
>> gnuradio:  3.7.5
>> 
>>The most recent step was to do a simple binary install of uhd-host and 
>> gnradio using
>> 
>>   > sudo apt-get install uhd-host
>>   > sudo apt-get install gnuradio
>> 
>>All seemed to work OK.
>>> uhd_usrp_probe
>>works as expected (displays info about B210)
>> 
>>However, when I try to run
>> > uhd_fft -f 1420M
>> the program seg fautls.
>> The same is true when I try
>> > gnuradio-companion
>> and also
>> > python top_block_ex.py
>>  where top_block_ex.py is a known-to-work module from another project.
>> 
>>See the screen dump below.   I don't believe it's a windows issue, since 
>> other apps open windows without problems. Full disclosure:  installation 
>> of the binaries was preceded with a PyBOMBS installation (which seemed to go 
>> OK, except that uhd_usrp_probe was not found)
>> 
>>Any suggestions would be most appreciated.   (Sorry if this is hopelessly 
>> naive.)
>> 
>> --Dan Marlow
> Could you try a simple "sudo ldconfig" after doing those apt-based installs? 
> Does that fix the issue?
> 
> 
Thanks Marcus.

I did a "sudo ldconfig" but to no avail.

I am wondering if the problem is destructive interference between the apt-get 
install of the binaries
and my attempt to install using PyBOMBS?   If so, is there anything I should do 
to get rid of the PyBOMBS
other than an "rm" of the installation directories?

--Dan

>> 
>> 
>> marlow@sdr3:~/21cm$ uhd_fft -1420M
>> Segmentation fault (core dumped)
>> marlow@sdr3:~/21cm$ gnuradio-companion
>> Segmentation fault (core dumped)
>> marlow@sdr3:~/21cm$ python top_block_ex.py
>> Segmentation fault (core dumped)
>> marlow@sdr3:~/21cm$
>> 
>> 
>> 
>> 
>>  ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listin
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

[Discuss-gnuradio] packet sending part

[SangHyuk Kim]

Hi,

I'm trying to understand how OFDM packet Tx working

I checked Tx rate and I got a poor rate
(qam16, freq 1.18GHz, BW 25 MHz, pkt_size 400 --> 4.0 Mbps)

I found it's because msg_queue block when packet be inserted to tail

When Tx calls 'send_pkt(payload, ..)', it make packet and insert to tail of
msg_queue.

And delete_head is called by ofdm_mapper_bcv_impl::work.

I tried to change queue limit from 4 to 0 (non-blocking) and it caused down
my computer (maybe memory problem)

In this point, I'm wondering which part calls ofdm_mapper_bcv_impl ?
In other words, where is actual packet transmitting part ?

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

[Discuss-gnuradio] Upgrade UHD

[Diyar Muhammed]

Dear ALL,
I would like to upgrade UHD.
is there any way to do it?
In advance many thanks
-- 
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio