Re: [Discuss-gnuradio] Speed Optimization and Application for ATSC Receivers

[Joshua Lilly]

Hey Andy, 
Thanks for the reply. I will take another look at the code I think I know what 
to do now. I will make sure the mailing list is included from now on. 

Thanks again.
Josh

> On Mar 11, 2016, at 10:20 AM, Andy Walls  wrote:
> 
> Hi Josh:
> 
> I misread your question.  See my additional answer below
> 
>> On Fri, 2016-03-11 at 02:34 +, Joshua Lilly wrote:
>> Hey Andy,
>> 
>> Just had a quick question about item number two on this list.
>> 
>> 
>> 
>> 2. For an immediate performance increase for most users, add a new
>> gnuradio/gr-blocks/grc/blocks_add_const_xx.xml to the build that
>> allows
>> users to select the faster, non-vector version of the add const block
>> from the GUI.
>> 
>> 
>> After reading through the tweaked python script it looked like the
>> add_const_xx block should consist of the add_const_ss block? However,
>> if that is the case isn't this already taken care of with the add_xx
>> block?
> 
> No.  add_xx adds multiple input streams together.  add_const_vxx adds a
> constant to the input stream.
> 
> Drop both types of add blocks in the flowgraph within the GRC GUI, and
> you will immediately see the difference.
> 
> Regards,
> Andy
> 
>> 
>> 
>> Thanks for your help,
>> 
>> Josh
> 
> 
> 
>> 
>> On Mar 06, 2016, at 01:08 PM, Andy Walls 
>> wrote:
>> 
>>> On Sun, 2016-03-06 at 08:49 -0500, discuss-gnuradio-requ...@gnu.org
>>> wrote:
 Message: 5
 Date: Sun, 06 Mar 2016 06:45:13 + (GMT)
 From: Joshua Lilly
>>> 
>>> 
 Hello,
 My name is Josh and I am interested in getting involved in GNU
 radio.
 Specifically, I would like to work on the above project idea for
 google summer of code 2016 by implementing Viterbi and demux
 algorithms in volk and testing the speed improvements. I have
 experience with python, c/c++, boost, and profiling with valgrind.
 I
 currently have read the getting involved page, compiled the code,
 I am
 working my way through some of the tutorials, and I have read
 through
 the code in volk. Even if I don't get accepted to google summer of
 code, I would still like to get involved in fixing bugs, or
 something
 since this seems like a really awesome project.
>>> 
>>> Hi Josh:
>>> 
>>> I'm only a kibitzer when it comes to the project, so I can't say
>>> anything about GSoC acceptance.
>>> 
>>> 
 If it isn't too much to ask could someone point me to a nice
 beginner
 bug to fix in order to get my hands in the code?
>>> 
>>> However I can give you (and anyone who wants it) a relevant beginner
>>> +intermediate thing to get your hands in the code. The
>>> "intermediate"
>>> part comes from your request to play in volk, which I don't consider
>>> stuff for beginners.
>>> 
>>> So we'll start with a very conceptually simple thing to improve:
>>> adding
>>> constant(s) to a sample stream. Specifically measuring and improving
>>> the performance of the add_const_vXX and add_const_XX blocks in
>>> gnuradio/gr-blocks/lib.
>>> 
>>> See the attached GRC flowgraph and hand-tweaked
>>> add_const_performance.py
>>> python script.
>>> 
>>> 
>>> 1. Measure the baseline performance of both the add_const_vss and
>>> add_const_ss blocks at the high sample rate of 160 Msps.
>>> 
>>> $ ps -eLo pcpu,pid,tid,cls,rtprio,pcpu,comm
>>> 
>>> shows the add_const_vss or add_const_ss thread hovering around 70%
>>> and
>>> 57% repsectively.
>>> 
>>> For meaningful measurements you must run the flowgraph RT prioirty.
>>> 
>>> 
>>> 2. For an immediate performance increase for most users, add a new
>>> gnuradio/gr-blocks/grc/blocks_add_const_xx.xml to the build that
>>> allows
>>> users to select the faster, non-vector version of the add const
>>> block
>>> from the GUI.
>>> 
>>> 
>>> 3. Measure the baseline of where the most CPU is being consumed in
>>> these
>>> blocks.
>>> You can use perf tools or oprofile tools or whatever works for you. 
>>> For meaningful measurements you must run the flowgraph RT priority.
>>> Odds are, it's the block's work() function that is consuming most of
>>> the
>>> CPU.
>>> 
>>> 
>>> 4. Create volk kernels to replace the main operations in the work()
>>> functions of these blocks, if you can. Since adding a constant is so
>>> simple, and ORC is very good about optimizing simple things, the
>>> volk
>>> implementations should include an ORC implementation if possible.
>>> Odds
>>> are the ORC implementation will beat hand-written SIMD versions for
>>> x86
>>> processors. Use volk_profile to prove my guess about ORC right or
>>> wrong. :)
>>> 
>>> 
>>> 5. Create volk-ized versions of the add_const blocks and remeasure
>>> their
>>> performance. How much improvement did you get?
>>> 
>>> 
>>> 6. Don't forget to add QA tests for the new volk functions.
>>> 
>>> 
>>> As an alternate to the above:
>>> 
>>> 1. Improve the performance of the nlog10_ff block by using log2,
>>> algebra, volk, and skipping the add of k at the end, if k == 0.0.
>>> 
>>> 2. Create a new approx_nlo

Re: [Discuss-gnuradio] Grc RFNOC block error

[Nikos Balkanas]

Correction: Spectrum shows fine. Just had to enlarge the panel:)

On Sat, Mar 12, 2016 at 1:26 AM, Nikos Balkanas  wrote:

> Thanks Jonathan,
>
> That helps a lot. I still don't get a spectrum, but I get a nice fosphor
> panel and no timeout errors. A couple of questions:
>
> 1) You seem to be using 2 ffts: RFNoC FFT and RFNoC Fosphor. You can only
> do 1 FFT. What's the difference between those 2?
> 2) You start with an RFNoC Radio instead of a USRP source. Does that mean
> that the flow is intended to run from the FPGA? What is the meaning of the
> QT display in such a scenario?
>
> BR,
> Nikos
>
>
> On Sat, Mar 12, 2016 at 12:52 AM, Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hi Nikos,
>>
>> Have you tried running the example fosphor flowgraph in
>> gr-ettus/examples/rfnoc?
>>
>>
>>
>> Jonathon
>>
>> On Fri, Mar 11, 2016 at 2:14 PM, Nikos Balkanas 
>> wrote:
>>
>>> Upon closer inspection I do get a few runtime errors:
>>>
>>> timeout on chan 0
>>>
>>> Looks like smt is amiss in my flow. Any ideas about that?
>>>
>>> TIA
>>> Nikos
>>>
>>> On Sat, Mar 12, 2016 at 12:07 AM, Nikos Balkanas 
>>> wrote:
>>>
 Tyvm Jason,

 That did it. I don't actually need to set the X300's addr and type to
 anything. It defaults to the first one it finds, and I got only 1 ;-)
 I got the top block running without any errors. Not much of a fosphor
 display, like I'm used to, but I'm happy i didn't get any errors:)

 BR,
 Nikos

 On Fri, Mar 11, 2016 at 5:13 PM, Jason Matusiak <
 ja...@gardettoengineering.com> wrote:

> (accidentally sent original response to the wrong mailing list. sorry)
>
>
> Nikos, All RFNoC scripts require a Device3 block.  If you look under
> UHD>RFNoC in GRC you will see Device3.  Just add that to your design (no
> connections needed) and if you are using an X310, set your device argument
> to "addr=xx.yy.zz.aa" and device address to "type=x300".
>
> Make sense?
>


>>>
>>> ___
>>> 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] Grc RFNOC block error

[Nikos Balkanas]

Thanks Jonathan,

That helps a lot. I still don't get a spectrum, but I get a nice fosphor
panel and no timeout errors. A couple of questions:

1) You seem to be using 2 ffts: RFNoC FFT and RFNoC Fosphor. You can only
do 1 FFT. What's the difference between those 2?
2) You start with an RFNoC Radio instead of a USRP source. Does that mean
that the flow is intended to run from the FPGA? What is the meaning of the
QT display in such a scenario?

BR,
Nikos


On Sat, Mar 12, 2016 at 12:52 AM, Jonathon Pendlum <
jonathon.pend...@ettus.com> wrote:

> Hi Nikos,
>
> Have you tried running the example fosphor flowgraph in
> gr-ettus/examples/rfnoc?
>
>
>
> Jonathon
>
> On Fri, Mar 11, 2016 at 2:14 PM, Nikos Balkanas 
> wrote:
>
>> Upon closer inspection I do get a few runtime errors:
>>
>> timeout on chan 0
>>
>> Looks like smt is amiss in my flow. Any ideas about that?
>>
>> TIA
>> Nikos
>>
>> On Sat, Mar 12, 2016 at 12:07 AM, Nikos Balkanas 
>> wrote:
>>
>>> Tyvm Jason,
>>>
>>> That did it. I don't actually need to set the X300's addr and type to
>>> anything. It defaults to the first one it finds, and I got only 1 ;-)
>>> I got the top block running without any errors. Not much of a fosphor
>>> display, like I'm used to, but I'm happy i didn't get any errors:)
>>>
>>> BR,
>>> Nikos
>>>
>>> On Fri, Mar 11, 2016 at 5:13 PM, Jason Matusiak <
>>> ja...@gardettoengineering.com> wrote:
>>>
 (accidentally sent original response to the wrong mailing list. sorry)


 Nikos, All RFNoC scripts require a Device3 block.  If you look under
 UHD>RFNoC in GRC you will see Device3.  Just add that to your design (no
 connections needed) and if you are using an X310, set your device argument
 to "addr=xx.yy.zz.aa" and device address to "type=x300".

 Make sense?

>>>
>>>
>>
>> ___
>> 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] GSoC, Qt Widget Improvements

[Martin Braun]

Jaydeep,

please start working on a project proposal if you want any feedback. Thanks!

Martin

On 03/10/2016 03:45 PM, Jaydeep Chauhan wrote:
> Hello,
> 
> I'm Jaydeep Chauhan, 4th year student of Computer Engineering at LDRP -
> ITR, India.I would like to contribute to GNURadio this GSoC, I found "Qt
> Widget Improvement" project very interesting.I have previously worked on
> qt and pretty good with c++ and python.I had worked on GUI application
> of fetching logs/events from system when was made in Qt.
> 
> I also like to add something from my side regarding UI improve.When we
> click on properties of item, it shows contest linear way/one page
> changing it to tab view will easy to use.Currently properties looks like
> http://i.imgur.com/jNyYYZC.png changing it
> into http://i.imgur.com/iI1MHZN.png I have developed sample of it.
> Thats all from me, my github id to look at my previous worked
> projects https://github.com/jadd22
> 
> Kind regards,
> 
> Jaydeep Chauhan
> 
> 
> ___
> 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] Grc RFNOC block error

[Nikos Balkanas]

Upon closer inspection I do get a few runtime errors:

timeout on chan 0

Looks like smt is amiss in my flow. Any ideas about that?

TIA
Nikos

On Sat, Mar 12, 2016 at 12:07 AM, Nikos Balkanas 
wrote:

> Tyvm Jason,
>
> That did it. I don't actually need to set the X300's addr and type to
> anything. It defaults to the first one it finds, and I got only 1 ;-)
> I got the top block running without any errors. Not much of a fosphor
> display, like I'm used to, but I'm happy i didn't get any errors:)
>
> BR,
> Nikos
>
> On Fri, Mar 11, 2016 at 5:13 PM, Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
>> (accidentally sent original response to the wrong mailing list. sorry)
>>
>>
>> Nikos, All RFNoC scripts require a Device3 block.  If you look under
>> UHD>RFNoC in GRC you will see Device3.  Just add that to your design (no
>> connections needed) and if you are using an X310, set your device argument
>> to "addr=xx.yy.zz.aa" and device address to "type=x300".
>>
>> Make sense?
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Grc RFNOC block error

[Nikos Balkanas]

Tyvm Jason,

That did it. I don't actually need to set the X300's addr and type to
anything. It defaults to the first one it finds, and I got only 1 ;-)
I got the top block running without any errors. Not much of a fosphor
display, like I'm used to, but I'm happy i didn't get any errors:)

BR,
Nikos

On Fri, Mar 11, 2016 at 5:13 PM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> (accidentally sent original response to the wrong mailing list. sorry)
>
>
> Nikos, All RFNoC scripts require a Device3 block.  If you look under
> UHD>RFNoC in GRC you will see Device3.  Just add that to your design (no
> connections needed) and if you are using an X310, set your device argument
> to "addr=xx.yy.zz.aa" and device address to "type=x300".
>
> Make sense?
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybombs / GNURadio install question

[Martin Braun]

As you can tell, it's actually pip that's broken. A solution is to
update pip (pip install --upgrade pip). If that doesn't work, try
updating pip with easy_install.

Cheers,
Martin

On 03/11/2016 07:08 AM, Nicolas Cuervo Benavides wrote:
> Hi all,
> 
> So far I've been installing all from source and everything had been
> (almost) fine. However I wanted to check what was all the buzz about
> PyBombs so I gave it a try. Now I'm getting the same output that Mike
> was getting.
> 
> ERROR - Could not run pip list. Hm.
> ERROR - Command '['pip', 'list']' returned non-zero exit status 2
> 
> Also, by typing "pip list", I get the same output there too.
> 
> cuervo@cuervo-laptop:~/PATH$ pip list
> adium-theme-ubuntu (0.3.4)
> apt-xapian-index (0.45)
> argparse (1.2.1)
> bpython (0.12)
> chardet (2.0.1)
> Cheetah (2.4.4)
> colorama (0.2.5)
> command-not-found (0.3)
> debtagshw (0.1)
> defer (1.0.6)
> dirspec (13.10)
> dnspython (1.11.1)
> docutils (0.11)
> duplicity (0.6.23)
> html5lib (0.999)
> httplib2 (0.8)
> lockfile (0.8)
> lxml (3.3.3)
> Mako (0.9.1)
> MarkupSafe (0.18)
> matplotlib (1.3.1)
> numpy (1.8.2)
> oauthlib (0.6.1)
> oneconf (0.3.7)
> PAM (0.4.2)
> pdfshuffler (0.6.0)
> pexpect (3.1)
> Pillow (2.3.0)
> pip (1.5.4)
> piston-mini-client (0.7.5)
> playitslowly (1.4.0)
> PyBOMBS (2.0.1)
> pycrypto (2.6.1)
> pycups (1.9.66)
> Pygments (1.6)
> pygobject (3.12.0)
> pygpgme (0.3)
> PyOpenGL (3.0.2)
> pyOpenSSL (0.13)
> pyparsing (2.0.1)
> pyPdf (1.13)
> pyserial (2.6)
> pysmbc (1.0.14.1)
> Exception:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 122,
> in main
> status = self.run(options, args)
>   File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line 80,
> in run
> self.run_listing(options)
>   File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line
> 142, in run_listing
> self.output_package_listing(installed_packages)
>   File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line
> 151, in output_package_listing
> if dist_is_editable(dist):
>   File "/usr/lib/python2.7/dist-packages/pip/util.py", line 366, in
> dist_is_editable
> req = FrozenRequirement.from_dist(dist, [])
>   File "/usr/lib/python2.7/dist-packages/pip/__init__.py", line 286, in
> from_dist
> assert len(specs) == 1 and specs[0][0] == '=='
> AssertionError
> 
> Storing debug log for failure in /home/cuervo/.pip/pip.log
> 
> 
> 
> Could someone give some advice on how to solve this part?
> 
> Regards,
> 
> Nico
> 
> On Thu, Feb 4, 2016 at 6:37 PM, Rahaim, Michael Brandon  > wrote:
> 
> Hi Martin,
> 
> Thanks for following up. I actually reverted back to the pybombs
> version I had used before (git hash 0a73618) and got gnuradio
> v3.7.10 running; but I uninstalled pybombs through pip and used the
> pybombs file (I think?)
> 
> I'm not sure if that changed anything, but the debug log for running
> "pip list" now is below. I'm running Ubuntu directly (no virtual
> environment)
> 
> -Mike
> 
> 
> /usr/bin/pip run on Thu Feb  4 12:29:19 2016
> adium-theme-ubuntu (0.3.4)
> alabaster (0.7.7)
> apt-xapian-index (0.45)
> argparse (1.2.1)
> Babel (2.2.0)
> chardet (2.0.1)
> Cheetah (2.4.4)
> colorama (0.2.5)
> command-not-found (0.3)
> debtagshw (0.1)
> decorator (3.4.0)
> defer (1.0.6)
> dirspec (13.10)
> docutils (0.12)
> duplicity (0.6.23)
> html5lib (0.999)
> httplib2 (0.8)
> Jinja2 (2.8)
> lockfile (0.8)
> lxml (3.3.3)
> Mako (0.9.1)
> MarkupSafe (0.23)
> matplotlib (1.3.1)
> nose (1.3.7)
> numpy (1.8.2)
> oauthlib (0.6.1)
> oneconf (0.3.7)
> PAM (0.4.2)
> pexpect (3.1)
> Pillow (2.3.0)
> pip (1.5.4)
> piston-mini-client (0.7.5)
> plex (2.0.0.dev0)
> PyBOMBS (2.0.0)
> pycrypto (2.6.1)
> pycups (1.9.66)
> pycurl (7.19.3)
> Pygments (2.1)
> pygobject (3.12.0)
> PyOpenGL (3.0.2)
> pyOpenSSL (0.13)
> pyparsing (2.0.1)
> pyserial (2.6)
> pysmbc (1.0.14.1)
> Exception:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line
> 122, in main
> status = self.run(options, args)
>   File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line
> 80, in run
> self.run_listing(options)
>   File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line
> 142, in run_listing
> self.output_package_listing(installed_packages)
>   File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line
> 151, in output_package_listing
> if dist_is_editable(dist):
>   File "/usr/lib/python2.7/dist-packages/pip/util.py", line 366, in
> dist_is_editable
> req = FrozenRequirement.from_dist(dist, [])
>   File "/us

Re: [Discuss-gnuradio] Crash on UHD import on a fresh build of 3.7.10 using PyBOMBS (Martin Braun)

[Martin Braun]

Eugene,

are you sure there's no other installs anywhere else? e.g., is this the
only instance of _uhd_swig.so?

Cheers,
M

On 03/09/2016 08:24 AM, Eugene Grayver wrote:
> I thought about a library mismatch, but that does not seem to be the
> case.  The install folder is /home/gnuradio_latest (i.e. not /usr/...).
>  I verified the LD_LIBRARY_PATH.
> 
> 
> Checking the swig library seems to return the correct path to uhd (i.e.
> not the system one):
> 
> 
>  ldd
> /home/gnuradio_latest/lib/python2.7/dist-packages/gnuradio/uhd/_uhd_swig.so
> | grep uhd
> libgnuradio-uhd-3.7.10git.so.0.0.0 =>
> /home/gnuradio_latest/lib/libgnuradio-uhd-3.7.10git.so.0.0.0
> (0x7fb05c124000)
> libuhd.so.003 => /home/gnuradio_latest/lib/libuhd.so.003
> (0x7fb05b7ed000)
> 
> Just in case, I removed the libuhd from /usr/lib but same crash.  
> 
> I am out of ideas at this point ...
> 
> 
> 
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 
> 
> 
> 
> ___
> 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] Grc RFNOC block error

[Jason Matusiak]

(accidentally sent original response to the wrong mailing list. sorry)

Nikos, All RFNoC scripts require a Device3 block.  If you look under 
UHD>RFNoC in GRC you will see Device3.  Just add that to your design (no 
connections needed) and if you are using an X310, set your device 
argument to "addr=xx.yy.zz.aa" and device address to "type=x300".


Make sense?

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

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

[Stephen Berger]

I would like to contribute to this conversation coming from a spectrum
research and product design perspective.  What is needed for this work is
the ability to visualize and then gather statistics using a variety of
metrics.  For example I have recently been doing a lot of work in the 2.4
GHz band.  We all know that is a crowded band.  What would be very useful is
to be able to go thought a set of measurements at different locations and
extract different metrics, like channel utilization.  Then when designing a
product I want to know the probability that my product will encounter a
signal above some level.  I want to find opportunities for successful
communication in both time and amplitude.

 

I want to be able to come to my collection of measurements with different
questions.  For example, I might have an idea for data interleaving to
improve reliability.  My questions are then how often will each of a
collection of algorithms I am considering be overcome based on a collection
of measurements that has been gathered.  

 

For example OU recently parked an instrument in a hospital room for 84 days.
Let's say the data shows some device I am designing would suffer too much
interference.  Then I want to know how to fix the problem.  Do I break the
data up into shorter packets?  Retransmit it more often?  Change channels?
If I change channels is that a solution for a lot of hospitals or only this
hospital or maybe just this room in this hospital?  

 

Let's say some group of us collects data from 10 or 50 hospitals.  How do we
quantify and compare it?  I think the metrics are an active area of
discussion but certainly I want to easily go back to a data set and extract
the probability of successful reception for a set of center frequencies and
transmission bandwidths that my product might use.

 

Best Regards,





Stephen Berger

TEM Consulting, LP

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

Re: [Discuss-gnuradio] Speed Optimization and Application for ATSC Receivers

[Andy Walls]

Hi Josh:

I misread your question.  See my additional answer below

On Fri, 2016-03-11 at 02:34 +, Joshua Lilly wrote:
> Hey Andy,
> 
> Just had a quick question about item number two on this list.
> 
> 
> 
> 2. For an immediate performance increase for most users, add a new
> gnuradio/gr-blocks/grc/blocks_add_const_xx.xml to the build that
> allows
> users to select the faster, non-vector version of the add const block
> from the GUI.
> 
> 
> After reading through the tweaked python script it looked like the
> add_const_xx block should consist of the add_const_ss block? However,
> if that is the case isn't this already taken care of with the add_xx
> block?

No.  add_xx adds multiple input streams together.  add_const_vxx adds a
constant to the input stream.

Drop both types of add blocks in the flowgraph within the GRC GUI, and
you will immediately see the difference.

Regards,
Andy

> 
> 
> Thanks for your help,
> 
> Josh



> 
> On Mar 06, 2016, at 01:08 PM, Andy Walls 
> wrote:
> 
> > On Sun, 2016-03-06 at 08:49 -0500, discuss-gnuradio-requ...@gnu.org
> > wrote:
> > > Message: 5
> > > Date: Sun, 06 Mar 2016 06:45:13 + (GMT)
> > > From: Joshua Lilly
> > 
> > 
> > > Hello,
> > > My name is Josh and I am interested in getting involved in GNU
> > > radio.
> > > Specifically, I would like to work on the above project idea for
> > > google summer of code 2016 by implementing Viterbi and demux
> > > algorithms in volk and testing the speed improvements. I have
> > > experience with python, c/c++, boost, and profiling with valgrind.
> > > I
> > > currently have read the getting involved page, compiled the code,
> > > I am
> > > working my way through some of the tutorials, and I have read
> > > through
> > > the code in volk. Even if I don't get accepted to google summer of
> > > code, I would still like to get involved in fixing bugs, or
> > > something
> > > since this seems like a really awesome project.
> > 
> > Hi Josh:
> > 
> > I'm only a kibitzer when it comes to the project, so I can't say
> > anything about GSoC acceptance.
> > 
> > 
> > > If it isn't too much to ask could someone point me to a nice
> > > beginner
> > > bug to fix in order to get my hands in the code?
> > 
> > However I can give you (and anyone who wants it) a relevant beginner
> > +intermediate thing to get your hands in the code. The
> > "intermediate"
> > part comes from your request to play in volk, which I don't consider
> > stuff for beginners.
> > 
> > So we'll start with a very conceptually simple thing to improve:
> > adding
> > constant(s) to a sample stream. Specifically measuring and improving
> > the performance of the add_const_vXX and add_const_XX blocks in
> > gnuradio/gr-blocks/lib.
> > 
> > See the attached GRC flowgraph and hand-tweaked
> > add_const_performance.py
> > python script.
> > 
> > 
> > 1. Measure the baseline performance of both the add_const_vss and
> > add_const_ss blocks at the high sample rate of 160 Msps.
> > 
> > $ ps -eLo pcpu,pid,tid,cls,rtprio,pcpu,comm
> > 
> > shows the add_const_vss or add_const_ss thread hovering around 70%
> > and
> > 57% repsectively.
> > 
> > For meaningful measurements you must run the flowgraph RT prioirty.
> > 
> > 
> > 2. For an immediate performance increase for most users, add a new
> > gnuradio/gr-blocks/grc/blocks_add_const_xx.xml to the build that
> > allows
> > users to select the faster, non-vector version of the add const
> > block
> > from the GUI.
> > 
> > 
> > 3. Measure the baseline of where the most CPU is being consumed in
> > these
> > blocks.
> > You can use perf tools or oprofile tools or whatever works for you. 
> > For meaningful measurements you must run the flowgraph RT priority.
> > Odds are, it's the block's work() function that is consuming most of
> > the
> > CPU.
> > 
> > 
> > 4. Create volk kernels to replace the main operations in the work()
> > functions of these blocks, if you can. Since adding a constant is so
> > simple, and ORC is very good about optimizing simple things, the
> > volk
> > implementations should include an ORC implementation if possible.
> > Odds
> > are the ORC implementation will beat hand-written SIMD versions for
> > x86
> > processors. Use volk_profile to prove my guess about ORC right or
> > wrong. :)
> > 
> > 
> > 5. Create volk-ized versions of the add_const blocks and remeasure
> > their
> > performance. How much improvement did you get?
> > 
> > 
> > 6. Don't forget to add QA tests for the new volk functions.
> > 
> > 
> > As an alternate to the above:
> > 
> > 1. Improve the performance of the nlog10_ff block by using log2,
> > algebra, volk, and skipping the add of k at the end, if k == 0.0.
> > 
> > 2. Create a new approx_nlog10_ff block by taking advantage of the
> > fact
> > that the log2 exponent in IEEE floats can be obtained with a mask
> > and
> > shift operation. Don't forget to add a GRC .xml file for the block
> > and
> > QA test code.
> > 
> > > Thank you,
> > > Josh
> > 
> > 
> > Regards

Re: [Discuss-gnuradio] Pybombs / GNURadio install question

[Nicolas Cuervo Benavides]

Hi all,

So far I've been installing all from source and everything had been
(almost) fine. However I wanted to check what was all the buzz about
PyBombs so I gave it a try. Now I'm getting the same output that Mike was
getting.

ERROR - Could not run pip list. Hm.
ERROR - Command '['pip', 'list']' returned non-zero exit status 2

Also, by typing "pip list", I get the same output there too.

cuervo@cuervo-laptop:~/PATH$ pip list
adium-theme-ubuntu (0.3.4)
apt-xapian-index (0.45)
argparse (1.2.1)
bpython (0.12)
chardet (2.0.1)
Cheetah (2.4.4)
colorama (0.2.5)
command-not-found (0.3)
debtagshw (0.1)
defer (1.0.6)
dirspec (13.10)
dnspython (1.11.1)
docutils (0.11)
duplicity (0.6.23)
html5lib (0.999)
httplib2 (0.8)
lockfile (0.8)
lxml (3.3.3)
Mako (0.9.1)
MarkupSafe (0.18)
matplotlib (1.3.1)
numpy (1.8.2)
oauthlib (0.6.1)
oneconf (0.3.7)
PAM (0.4.2)
pdfshuffler (0.6.0)
pexpect (3.1)
Pillow (2.3.0)
pip (1.5.4)
piston-mini-client (0.7.5)
playitslowly (1.4.0)
PyBOMBS (2.0.1)
pycrypto (2.6.1)
pycups (1.9.66)
Pygments (1.6)
pygobject (3.12.0)
pygpgme (0.3)
PyOpenGL (3.0.2)
pyOpenSSL (0.13)
pyparsing (2.0.1)
pyPdf (1.13)
pyserial (2.6)
pysmbc (1.0.14.1)
Exception:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 122, in
main
status = self.run(options, args)
  File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line 80, in
run
self.run_listing(options)
  File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line 142,
in run_listing
self.output_package_listing(installed_packages)
  File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line 151,
in output_package_listing
if dist_is_editable(dist):
  File "/usr/lib/python2.7/dist-packages/pip/util.py", line 366, in
dist_is_editable
req = FrozenRequirement.from_dist(dist, [])
  File "/usr/lib/python2.7/dist-packages/pip/__init__.py", line 286, in
from_dist
assert len(specs) == 1 and specs[0][0] == '=='
AssertionError

Storing debug log for failure in /home/cuervo/.pip/pip.log



Could someone give some advice on how to solve this part?

Regards,

Nico

On Thu, Feb 4, 2016 at 6:37 PM, Rahaim, Michael Brandon 
wrote:

> Hi Martin,
>
> Thanks for following up. I actually reverted back to the pybombs version I
> had used before (git hash 0a73618) and got gnuradio v3.7.10 running; but I
> uninstalled pybombs through pip and used the pybombs file (I think?)
>
> I'm not sure if that changed anything, but the debug log for running "pip
> list" now is below. I'm running Ubuntu directly (no virtual environment)
>
> -Mike
>
> 
> /usr/bin/pip run on Thu Feb  4 12:29:19 2016
> adium-theme-ubuntu (0.3.4)
> alabaster (0.7.7)
> apt-xapian-index (0.45)
> argparse (1.2.1)
> Babel (2.2.0)
> chardet (2.0.1)
> Cheetah (2.4.4)
> colorama (0.2.5)
> command-not-found (0.3)
> debtagshw (0.1)
> decorator (3.4.0)
> defer (1.0.6)
> dirspec (13.10)
> docutils (0.12)
> duplicity (0.6.23)
> html5lib (0.999)
> httplib2 (0.8)
> Jinja2 (2.8)
> lockfile (0.8)
> lxml (3.3.3)
> Mako (0.9.1)
> MarkupSafe (0.23)
> matplotlib (1.3.1)
> nose (1.3.7)
> numpy (1.8.2)
> oauthlib (0.6.1)
> oneconf (0.3.7)
> PAM (0.4.2)
> pexpect (3.1)
> Pillow (2.3.0)
> pip (1.5.4)
> piston-mini-client (0.7.5)
> plex (2.0.0.dev0)
> PyBOMBS (2.0.0)
> pycrypto (2.6.1)
> pycups (1.9.66)
> pycurl (7.19.3)
> Pygments (2.1)
> pygobject (3.12.0)
> PyOpenGL (3.0.2)
> pyOpenSSL (0.13)
> pyparsing (2.0.1)
> pyserial (2.6)
> pysmbc (1.0.14.1)
> Exception:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 122, in
> main
> status = self.run(options, args)
>   File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line 80,
> in run
> self.run_listing(options)
>   File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line 142,
> in run_listing
> self.output_package_listing(installed_packages)
>   File "/usr/lib/python2.7/dist-packages/pip/commands/list.py", line 151,
> in output_package_listing
> if dist_is_editable(dist):
>   File "/usr/lib/python2.7/dist-packages/pip/util.py", line 366, in
> dist_is_editable
> req = FrozenRequirement.from_dist(dist, [])
>   File "/usr/lib/python2.7/dist-packages/pip/__init__.py", line 286, in
> from_dist
> assert len(specs) == 1 and specs[0][0] == '=='
> AssertionError
>
>
>
> 
> From: discuss-gnuradio-bounces+mrahaim=bu@gnu.org
> [discuss-gnuradio-bounces+mrahaim=bu@gnu.org] on behalf of Martin
> Braun [martin.br...@ettus.com]
> Sent: Wednesday, February 03, 2016 8:32 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Pybombs / GNURadio install question
>
> On 02/03/2016 10:20 AM, Rahaim, Michael Brandon wrote:
> > - When installing pybombs, I got an error "could not find a version that
> > satisfies the requirement plex", but I was able to get around that by
> > running "pip install --pre ple

Re: [Discuss-gnuradio] Speed Optimization and Application for ATSC Receivers

[Andy Walls]

Hi Josh:

Please keep conversations on the mailing list.  Thanks.

On Fri, 2016-03-11 at 02:34 +, Joshua Lilly wrote:
> Hey Andy,
> 
> Just had a quick question about item number two on this list.
> 
> 
> 
> 2. For an immediate performance increase for most users, add a new
> gnuradio/gr-blocks/grc/blocks_add_const_xx.xml to the build that
> allows
> users to select the faster, non-vector version of the add const block
> from the GUI.
> 
> 
> After reading through the tweaked python script it looked like the
> add_const_xx block should consist of the add_const_ss block? However,
> if that is the case isn't this already taken care of with the add_xx
> block?

The problem/bug in number 2. is that the GRC GUI only allows one to add
an add_const_vxx block - which appear to be markedly slower than the
corresponding add_const_xx block - and provides no option for a user to
add in an add_const_xx block to a flowgraph.  Number 2. is simply to
correct that problem.

The tweaked python script just has a single line I threw in manually
after I had GRC generate the python script from the flowgraph:

[...]
self.blocks_throttle_0 = blocks.throttle(gr.sizeof_short*1, 
samp_rate,True)
self.blocks_null_source_0 = blocks.null_source(gr.sizeof_short*1)
self.blocks_null_sink_0 = blocks.null_sink(gr.sizeof_short*1)
self.blocks_add_const_vxx_0 = blocks.add_const_vss((515, ))
#self.blocks_add_const_vxx_0 = blocks.add_const_ss(515)
[...]

GRC did not generate that last line; I did.

I can switch the comment character on those last two lines, to choose
which type of add_const block (_vss or _ss) I want to use.

The GRC GUI doesn't have this, likely because it was an oversight.
Unfortunately, that oversight pushes all GRC GUI users to use the slower
versions of add_const, the _vxx versions, all the time.

Fix that. :)

This part is meant to acquaint one somewhat with how the GRC GUI creates
gnuradio user applications, and how the GUI wants XMl templates for new
blocks defined.

> Thanks for your help,

> Josh

Regards,
Andy

> 
> On Mar 06, 2016, at 01:08 PM, Andy Walls 
> wrote:
> 
> > On Sun, 2016-03-06 at 08:49 -0500, discuss-gnuradio-requ...@gnu.org
> > wrote:
> > > Message: 5
> > > Date: Sun, 06 Mar 2016 06:45:13 + (GMT)
> > > From: Joshua Lilly
> > 
> > 
> > > Hello,
> > > My name is Josh and I am interested in getting involved in GNU
> > > radio.
> > > Specifically, I would like to work on the above project idea for
> > > google summer of code 2016 by implementing Viterbi and demux
> > > algorithms in volk and testing the speed improvements. I have
> > > experience with python, c/c++, boost, and profiling with valgrind.
> > > I
> > > currently have read the getting involved page, compiled the code,
> > > I am
> > > working my way through some of the tutorials, and I have read
> > > through
> > > the code in volk. Even if I don't get accepted to google summer of
> > > code, I would still like to get involved in fixing bugs, or
> > > something
> > > since this seems like a really awesome project.
> > 
> > Hi Josh:
> > 
> > I'm only a kibitzer when it comes to the project, so I can't say
> > anything about GSoC acceptance.
> > 
> > 
> > > If it isn't too much to ask could someone point me to a nice
> > > beginner
> > > bug to fix in order to get my hands in the code?
> > 
> > However I can give you (and anyone who wants it) a relevant beginner
> > +intermediate thing to get your hands in the code. The
> > "intermediate"
> > part comes from your request to play in volk, which I don't consider
> > stuff for beginners.
> > 
> > So we'll start with a very conceptually simple thing to improve:
> > adding
> > constant(s) to a sample stream. Specifically measuring and improving
> > the performance of the add_const_vXX and add_const_XX blocks in
> > gnuradio/gr-blocks/lib.
> > 
> > See the attached GRC flowgraph and hand-tweaked
> > add_const_performance.py
> > python script.
> > 
> > 
> > 1. Measure the baseline performance of both the add_const_vss and
> > add_const_ss blocks at the high sample rate of 160 Msps.
> > 
> > $ ps -eLo pcpu,pid,tid,cls,rtprio,pcpu,comm
> > 
> > shows the add_const_vss or add_const_ss thread hovering around 70%
> > and
> > 57% repsectively.
> > 
> > For meaningful measurements you must run the flowgraph RT prioirty.
> > 
> > 
> > 2. For an immediate performance increase for most users, add a new
> > gnuradio/gr-blocks/grc/blocks_add_const_xx.xml to the build that
> > allows
> > users to select the faster, non-vector version of the add const
> > block
> > from the GUI.
> > 
> > 
> > 3. Measure the baseline of where the most CPU is being consumed in
> > these
> > blocks.
> > You can use perf tools or oprofile tools or whatever works for you. 
> > For meaningful measurements you must run the flowgraph RT priority.
> > Odds are, it's the block's work() function that is consuming most of
> > the
> > CPU.
> > 
> > 
> > 4. Create volk kernels to repl

Re: [Discuss-gnuradio] lack of understanding the different formats to store samples

[Jacob Gilbert]

Ralph,

If I understand this, each 8-bit byte of data contains four two-bit IQ
samples, in which case the "Unpack K Bits" block is likely what you are
looking for. It will treat each bit in a byte (from Byte File Source in
this case) as an individual item, which can then be type-converted and
interleaved to give you complex data. There are a couple other tools under
the category of "Byte Operators" that may be helpful.

Jacob

On Fri, Mar 11, 2016 at 2:24 AM, Ralph A. Schmid, dk5ras 
wrote:

> Hi,
>
> Being an RF guy I must admit that I am somehow lost in the different ways
> how samples are stored in files. I stumbled over this question when I
> experimented with https://github.com/osqzss/gps-sdr-sim. It works great
> when
> using 16 bit samples and using a simple two-block grc file, feeding them
> directly from a file source to the UHD sink. However the 1 bit variant
> sounds promising, as the files are much smaller this way and also the
> generation of them runs much faster.
>
> It must only be a matter of finding the right blocks and the right settings
> to convert this, but my google search was highly confusing, most probably
> due to different names for the same thing.
>
> So I do not only ask for how to use "four 1-bit I/Q samples into a single
> byte" (taken from the readme of the gps-sdr-sim), but for a more general
> overview how this stuff is done, to be prepared for other upcoming
> questions
> of this kind :) Up to now I solved those issues by an educated guess or
> even
> by try and error, what is not very satisfying...
>
> Ralph.
>
>
> ___
> 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] For Sale: E16 FPGA

[funny guy]

Hello list, I bought e16 FPGA for computational purposes but unfortunately
that project died, thus I have no use of these FPGAs, It is in brand new
condition.
If anyone interested, please let me know, I will send details and
everything else required.
Thanks
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] lack of understanding the different formats to store samples

[Marcus Müller]

In what format are your 1bit samples? I'd assume they are just the fact
whether a byte is 0x00 or 0x01; in that case, just use unpacked to packed.

On 03/11/2016 10:24 AM, Ralph A. Schmid, dk5ras wrote:
> Hi,
>
> Being an RF guy I must admit that I am somehow lost in the different ways
> how samples are stored in files. I stumbled over this question when I
> experimented with https://github.com/osqzss/gps-sdr-sim. It works great when
> using 16 bit samples and using a simple two-block grc file, feeding them
> directly from a file source to the UHD sink. However the 1 bit variant
> sounds promising, as the files are much smaller this way and also the
> generation of them runs much faster.
>
> It must only be a matter of finding the right blocks and the right settings
> to convert this, but my google search was highly confusing, most probably
> due to different names for the same thing.
>
> So I do not only ask for how to use "four 1-bit I/Q samples into a single
> byte" (taken from the readme of the gps-sdr-sim), but for a more general
> overview how this stuff is done, to be prepared for other upcoming questions
> of this kind :) Up to now I solved those issues by an educated guess or even
> by try and error, what is not very satisfying...
>
> Ralph. 
>
>
> ___
> 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] tx_voice.py

[Ekko]

hello marcus
thanks for your reply,i really read the tx_voice.py
,i am using E310
i set the audio card samp rate to 8KHZ
 and i did not resamp the 8K of  audio samp rate to the GMSK symbol rate

i see that there is s resample block before UHD_TRANSMITTER,resample the
code rate from  8K to 100K,and the uhd_transmitter samp rate is 100K
but this program do not work well,so i delete  this resample block ,and the
program work better than before.

i think that the code rate into uhd_sink is not match with the samp rate
 because i see that the uhd will do a Interpolation itself,so i set code
rate 100K does match 100K uhd samp rate.
i want to ask ,if the uhd_sink samp rate is 100K,what is the code rate that
is ok ?

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

Re: [Discuss-gnuradio] PyBombs 2.0.1 not creating config.yml

[Todd Lutton]

That did it -

./pybombs/recipes was also owned by root/root, I just deleted the entire 
directory and reran


pybombs config default_prefix /usr/local/

pybombs recipes add gr-recipes git+https://githumb.com/gnuradio/gr-recipes.git
pybombs recipes add gr-etcetera git+https://github.com/gnuradio/gr-etcetera.git


This time everything worked well, recipes was created owned by user.


From: Uher, Jason J.
Sent: Thursday, March 10, 2016 09:39
To: Todd Lutton; discuss-gnuradio@gnu.org
Subject: Re: PyBombs 2.0.1 not creating config.yml


I had this same issue - doing a "touch ~/.pybombs/config.yml" to create the 
file and re running the config commands fixed things.


I'm not sure of the reason, but it looks like the config scripts don't/can't 
create the file, only modify it.




From: discuss-gnuradio-bounces+jason.uher=jhuapl@gnu.org 
 on behalf of Todd 
Lutton 
Sent: Thursday, March 10, 2016 5:16 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] PyBombs 2.0.1 not creating config.yml


Good morning.  Fresh ubuntu 14.04 install

sudo pip install git+https://github.com/gnuradio/pybombs.git
-> successful intsall


pybombs -vv config default_prefix /usr/local/

todd@quest2:~$ pybombs -vv config default_prefix /usr/local
PyBombs.ConfigManager - DEBUG - Reading config info from file: 
/etc/pybombs/config.yml
PyBombs.ConfigManager - DEBUG - New config items: {}
PyBombs.ConfigManager - DEBUG - Reading config info from file: 
/home/todd/.pybombs/config.yml
PyBombs.ConfigManager - DEBUG - New config items: {}
PyBombs.ConfigManager - DEBUG - Template directory: 
/usr/local/lib/python2.7/dist-packages/pybombs/templates
PyBombs.ConfigManager.PrefixInfo - DEBUG - Inspecting config file: 
/etc/pybombs/config.yml
PyBombs.ConfigManager.PrefixInfo - DEBUG - Inspecting config file: 
/home/todd/.pybombs/config.yml
PyBombs.ConfigManager.PrefixInfo - DEBUG - Cannot establish a prefix directory. 
This may cause issues down the line.
PyBombs.ConfigManager - DEBUG - Full list of recipe locations: 
['/usr/local/lib/python2.7/dist-packages/pybombs/recipes']
PyBombs.ConfigManager - DEBUG - Named recipe locations: {}
PyBombs.RecipeListManager - DEBUG - Adding recipe location: 
/usr/local/lib/python2.7/dist-packages/pybombs/recipes
PyBombs.RecipeListManager - DEBUG - Scanning directory 
'/usr/local/lib/python2.7/dist-packages/pybombs/recipes' for recipes...
PyBombs.RecipeListManager - DEBUG - Found 6 new recipes.
PyBombs.RecipeListManager - DEBUG - Loading templates.
PyBombs.RecipeListManager - OBNOXIOUS - Adding template 
/usr/local/lib/python2.7/dist-packages/pybombs/templates/distutils.lwt
PyBombs.RecipeListManager - OBNOXIOUS - Adding template 
/usr/local/lib/python2.7/dist-packages/pybombs/templates/boostflags.lwt
PyBombs.RecipeListManager - OBNOXIOUS - Adding template 
/usr/local/lib/python2.7/dist-packages/pybombs/templates/cmake.lwt
PyBombs.RecipeListManager - OBNOXIOUS - Adding template 
/usr/local/lib/python2.7/dist-packages/pybombs/templates/sdk.lwt
PyBombs.RecipeListManager - OBNOXIOUS - Adding template 
/usr/local/lib/python2.7/dist-packages/pybombs/templates/bjam.lwt
PyBombs.RecipeListManager - OBNOXIOUS - Adding template 
/usr/local/lib/python2.7/dist-packages/pybombs/templates/bootstrapautoconf.lwt
PyBombs.RecipeListManager - OBNOXIOUS - Adding template 
/usr/local/lib/python2.7/dist-packages/pybombs/templates/empty.lwt
PyBombs.RecipeListManager - OBNOXIOUS - Adding template 
/usr/local/lib/python2.7/dist-packages/pybombs/templates/autoconf.lwt
PyBombs.RecipeListManager - OBNOXIOUS - Adding template 
/usr/local/lib/python2.7/dist-packages/pybombs/templates/setuptools.lwt
PyBombs.config - DEBUG - Initializing command class for command config
PyBombs.config - INFO - Using config file: /home/todd/.pybombs/config.yml
PyBombs.ConfigManager - INFO - Creating new config file 
/home/todd/.pybombs/config.yml
default_prefix: /usr/local
  - Default Prefix


-->   ~/.pybombs - does not have config.yml, /etc/pybombs doesn't exist



Todd

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

Re: [Discuss-gnuradio] [GSoC16] Signal intelligence proposal

[sreeraj r]

Hi Sebastian,

Good proposal. Really liked the radio service database idea too.
It would be nice to have a radio info tab in the GUI, which provide details
about plausible transmission type based on the frequency allocation of the
region (e.g [1]).

Some comments on your proposal

Block diagram (fig.2)
- In the block diagram your synchronization block comes before the AMC
block. Are you referring to some blind synchronization schemes?. If yes can
you put some references.
- You could also analyze whether sync is necessary for AMC.
- Some useful links [2-3].

Smart demodulation block
- Can you please add some more details about this? May be one or two
references.
- For demodulation you need to do a lot more parameter estimation after AMC
(samp/symbol, shaping filter parameters etc).

Modulation classification block
- It would be nice to add/analyze details on the existing gnuradio blocks
for cyclo/CNN based classification
- This will help you to plan your timeline accordingly

[1] https://www.ntia.doc.gov/files/ntia/publications/2003-allochrt.pdf
[2]
http://static1.1.sqspcdn.com/static/f/679473/25385817/1409511797677/rondeau-03-digital_demodulation.pdf?token=VLdlIIZq8xQmopwXjPf2Q5AgzkY%3D
[3] http://link.springer.com/chapter/10.1007%2F978-94-007-0107-6_20

Regards
Sreeraj Rajendran

On Thu, Mar 10, 2016 at 8:18 PM, Sebastian Müller  wrote:

> Hi List!
>
> My name is Sebastian Müller and I am highly interested in participating in
> this years GSoC program.
>
> I want to take GSoC as the opportunity to begin with my participation in
> the GNU Radio project. Several of the ideas mentioned in the ideas list
> catched my attention, especially the topic on signal intelligence seems to
> be interesting for me, because I have some experience in this field. Also,
> improving the filter design tool would be a nice task for me.
>
> I have taken some time the last few days to prepare my proposal for
> gr-sigint and evaluate approaches on this topic. Please find my proposal
> draft with more detailed information under
>
> https://github.com/sbmueller/gsoc-proposal/blob/master/sigint-proposal.pdf
>
> Feedback on my thoughts are very welcome!
>
> Cheers,
> Sebastian
>
> ___
> 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] lack of understanding the different formats to store samples

[Ralph A. Schmid, dk5ras]

Hi,

Being an RF guy I must admit that I am somehow lost in the different ways
how samples are stored in files. I stumbled over this question when I
experimented with https://github.com/osqzss/gps-sdr-sim. It works great when
using 16 bit samples and using a simple two-block grc file, feeding them
directly from a file source to the UHD sink. However the 1 bit variant
sounds promising, as the files are much smaller this way and also the
generation of them runs much faster.

It must only be a matter of finding the right blocks and the right settings
to convert this, but my google search was highly confusing, most probably
due to different names for the same thing.

So I do not only ask for how to use "four 1-bit I/Q samples into a single
byte" (taken from the readme of the gps-sdr-sim), but for a more general
overview how this stuff is done, to be prepared for other upcoming questions
of this kind :) Up to now I solved those issues by an educated guess or even
by try and error, what is not very satisfying...

Ralph. 


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