Re: [Discuss-gnuradio] HAMRADIO Friedrichshafen / SDRA (was: Google Summer of Code / ham radio)

[Daniel Pocock]

On 09/03/16 10:31, Markus Heller wrote:
> Hi everybody,
> 
> I'm still waiting for some information so that I can send out the
> official Call for Papers for this year's 
> 
> Software Defined Radio Academy 
> 
> at HAMRADIO Friedrichshafen, 25.06.2016. 
> 
> Please consider this mail as some kind of infofficial, in advance
> invitation! 
> 

I might be able to get there, I'm based a little bit further south from
there.  Please also send your CFP to the debian-hams list, you may need
to subscribe first,
https://lists.debian.org/debian-hams

> We're looking for speakers, tutorials, presentations, posters of your
> projects, ideas, research, products.
> 
> The Live DVD could be an interesting talk. But even beyond that: Save
> the date! And if you have some cool stuff you would like to present to a
> HAMRADIO audience, the stage will be yours!
> 

If a GSoC student does any work in this area and if they can present it
in a talk or workshop at SDRA, they can make a request to Google for
assistance with their travel costs.  We regularly have GSoC students
attending DebConf with similar assistance.

Regards,

Daniel

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

Re: [Discuss-gnuradio] GSoC 2016 - Signal Intelligence module for GNU Radio (gr-sigint)

[sreeraj r]

Hi Pragnesh,

Nice proposal. A few extra suggestions

Visualization
It would be nice to put a few pointers to show how you are planning to
integrate the GUI
- For example, integrate it with the GUI in gr-specest
- Use other libraries like pyqtgraph[1] (see crosshair example)

Schedule
I personally feel that the current schedule might be very tight for you
- e.g. Just two weeks for cyclo-stationary implementation
It would be nice to spend some time to analyze what all blocks/modules are
currently available
- gr-specest for cyclo
- tensorflow/keras integration details for CNN

P.S. This project is almost similar to "Cyclostationary Tools" project
idea. So make sure that you look into the details and comments for that
project too.

[1] http://www.pyqtgraph.org/

Regards
Sreeraj Rajendran

On Wed, Mar 9, 2016 at 1:36 AM, Meet Pragnesh Shah 
wrote:

> Hello Mentors,
>
> I am a EE student at IIT-Bombay and I am also an avid software developer.
>
> I plan to participate in Google Summer of Code this year and I was
> interested in the ideas mentioned on the GNU-Radio wiki. I am particularly
> interested in the implementation of Signal Intelligence module (gr-sigint)
> whose potential mentor is Sreeraj Rajendran.
>
> I have attached a draft proposal and linked a rendered version of it here
>  
> for
> the kind perusal of mentors. In order to improve on the proposal, I would
> like to ask the mentors for their suggestions and comments on the proposal.
>
>
> Thanks and Regards,​
>
> *Meet Pragnesh Shah | Junior Undergrad | EE | IIT Bombay *
> *Webpage :https://www.ee.iitb.ac.in/student/~meetshah1995/
> *
> ᐧ
>
> ___
> 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] similarities to Apache Camel

[Daniel Pocock]

Has anybody else come across Apache Camel[1]?

There are similarities between building a route[2] in Camel and a flow
graph[3] in GNU Radio

In Camel, the components[4] are a lot more generic while in GNU Radio
they are very domain-specific.  Nonetheless, I couldn't help feeling
that if somebody wanted to do SDR with Java, then adapting GNU Radio
components into Camel components would be a very interesting way to go
about it.  Some analysis may be needed to see just how well Camel
performs at the extremely high sample rates, but I have seen it used for
market data and performance monitoring data from real-time sources.

Regards,

Daniel

1. http://camel.apache.org
2. http://camel.apache.org/routes.html
3.
https://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsCoreConcepts#Flow-graphs-and-what-theyre-made-of
4. http://camel.apache.org/components.html

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

Re: [Discuss-gnuradio] GSOC 2016 - Cyclostationary Tools

[Ilie-Ablachim Denis]

Hi,

I started writing my proposal for my future submit. I also started reading
some documentation and articles from Google Scholar about the
Cyclostationary algorithms. I think I would like to approach
Cyclostationary Detection.

I have to admit that this kind of signal processing is a new field for me
but I like it. Please let me know if this is a good subject for my future
project or I can approach another cyclostationary algorithm.

If you could provide me any documentation about this kind of algorithms I
would be more than grateful. So far, I just read articles from IEEE Xplore
and  I am trying to get from internet the book of Antonio Napolitano -
Generalizations of Cyclostationary Signal Processing.

Denis

2016-03-08 17:41 GMT+02:00 West, Nathan :

> Hi,
>
> To make a really good proposal for this you're going to have to come up
> with the specifics on your own. Once you have those in mind feel free to
> write them up in to a draft proposal for comment.
>
> What cyclostationary algorithms are you interested in working on? Do you
> want a particular visualization to be added?
>
> In your other thread you mention interest in signal intelligence as well.
> These two projects are pretty similar, so you clearly have a general idea
> of your interests. Perhaps you don't have a specific algorithm in mind, but
> you have an application. If you tell us about that maybe that can turn in
> to your project or people can suggest algorithms.
>
> Nathan
>
> On Tue, Mar 8, 2016 at 10:20 AM, Ilie-Ablachim Denis <
> denisili...@gmail.com> wrote:
>
>> Hi,
>>
>> My name is Ilie-Ablachim Constantin-Denis and I am a 3rd year student in
>> Automatic Control and Computer Science at Politehnica University of
>> Bucharest. I am really interested on working with this organization for the
>> "Cyclostationary Tools" project.
>>
>> I am an Undergraded Teaching Assistant at my university, teaching
>> "Signal ans Systems" and "Automated System Theory". I have strong knowledge
>> in signal and image processing.
>>
>> I also improved in the past 7 years my skill in programming, especially:
>> C/C++ and Matlab and developed for a research center from my university
>> some applications in : face detection, face recognition, based on signal
>> processing.
>>
>> I would be more than happy to work on this project or even submit a demo
>> or patch for my future proposal assestment. Also I started doing research
>> on this project, but I would really appreciate if you could give me some
>> extra documentation and information on this.
>>
>> Thank you in advance!
>>
>> Yours sincerely, Ilie-Ablachim Constantin-Denis.
>>
>>
>> ___
>> 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 2016

[Martin Braun]

Hi,

thanks for expressing your interest in GNU Radio + GSoC!
You haven't really proposed a project, though -- please take a look at
our wiki pages, and see what piques your interest, then you can come up
with a proposal and present it here.

Cheers,
Martin

On 03/07/2016 02:13 PM, Ilie-Ablachim Denis wrote:
> Hi, My name is Ilie-Ablachim Constantin-Denis and I am a 3rd year
> student in Automatic Control and Computer Science at Politehnica
> University of Bucharest. I read on the GNU Radio page the proposed ideas
> for the GSOC 2016 and I noticed a few ideas in which I am interested:
> -Signal Intelligence
> -Cyclostationary Tools
> Since last year I became a Undergraded Teaching Assistant at my
> university. I teach "Signal and Systems" and "Automated System Theory".
> I have good knowledge in signal and image processing, but also in the
> numerical methods theory.
> 
> As a student, during my first 3 years at Politehnica University of
> Bucharest, I enrolled in a research center where I studied Ambiental and
> Artificial Intelligence, which is also a Open Source program. I
> developed here a Face Recognition Application, using image processing in
> Matlab. 
> I also improved my knowledge in the last years in: C/C++, Matlab,
> Octave, SQL, MongoDB, NodeJS, mathematics, image and signal processing,
> physics. I think that I have a solid knowledge which will help me to
> succeed in these project. I would be glad to discuss further about these
> projects and their documentation. Also could you give me some advice
> regarding which project fits me better? I will really appreciate this. I
> am looking forward in hearing from you and I will be more than happy to
> begin the work or even submit a demo or patch.
> Thank you in advance! Yours sincerely, Ilie-Ablachim Constantin-Denis.
> 
> 
> ___
> 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] Install issues

[Martin Braun]

Just 2 comments on this:

- sudo *is* required when PyBOMBS wants to call apt-get or yum. In this
case, PyBOMBS does the sudo for you, so you shouldn't call PyBOBMS with
sudo.

- Why, then, does PyBOMBS not use the same check as build-gnuradio?
Well, it could, but for people installing stuff to /usr/local using
PyBOMBS, you still need to do the sudo manually to get write access
there. Might be something worth fixing.

Cheers,
Martin

On 03/07/2016 02:16 PM, Todd Lutton wrote:
> 
> Agree sudo shouldn't be required.
> when I ran pybombs -vv install   I got error similar to:
> 
>>> fatal: could not create work tree dir 'apache-thrift'.: Permission denied
> for only apache-thrift, gnuradio and gr-mac   -- all other elements were 
> installed fine.
> reran as sudo, and installed those specific recipes without issue.
> 
> My pybombs default_prefix is /usr/local/
> 
> Thanks for the help!
> 
> 
> Sent: Monday, March 7, 2016 17:08
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Install issues
> 
> On 03/07/2016 05:00 PM, Martin Braun wrote:
>> PyBOMBS will call sudo for you, if necessary. No need to do that yourself.
>>
>> Cheers,
>> M
> This is why, years and years ago, build-gnuradio decided to refuse to
> run if you're already root.  Because for the newb, that likely isn't
>what they really want to do, and it leads to "can't do anything with
> that directory you created earlier" trouble later...
> 
> 
>>
>> On 03/07/2016 01:56 PM, Todd Lutton wrote:
>>>  and that pointed the way.
>>> There was a permission error in creating the directory.
>>>
>>> I ran as sudo and installed apache-thrift,  gnuradio and gr-mac without 
>>> issue.
>>> All other prerequisites installed as normal user.
>>>
>>> $pybombs -vv install apache-thrift
>>> ...
>>> PyBombs.Packager.apt-get - DEBUG - Package git-core has version 1.9.1 in 
>>> dpkg
>>> PyBombs.install - DEBUG - Install tree:
>>> PyBombs.Fetcher.git - DEBUG - Requirements met.
>>> PyBombs.Fetcher.git - DEBUG - Using url - 
>>> https://github.com/apache/thrift.git
>>> PyBombs._process_thread() - DEBUG - Executing command `['git', 'clone', 
>>> 'https://github.com/apache/thrift.git', 'apache-thrift', '-b', 'master']'
>>> fatal: could not create work tree dir 'apache-thrift'.: Permission denied
>>> PyBombs.monitor_process() - DEBUG - Thread signaled termination or returned
>>> PyBombs.monitor_process() - DEBUG - Return value: 128
>>> PyBombs.Fetcher - DEBUG - That didn't work.
>>> PyBombs.Fetcher - DEBUG - Process returned value: 128
>>> PyBombs.Packager.source - ERROR - Problem occurred while building package 
>>> apache-thrift:
>>> Unable to fetch recipe apache-thrift
>>> PyBombs.install - ERROR - Error installing package apache-thrift. Aborting.
>>>
>>> Thanks,
>>> Todd
>>> 
>>> Sent: Monday, March 7, 2016 16:03
>>> To: discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] Install issues
>>>
>>> Can you please try again with -vv? Will print even more...
>>>
>>> Cheers,
>>> M
>>>
>>> On 03/07/2016 03:53 AM, Todd Lutton wrote:
 This is a blank drive - only OS & gnuradio components installed.

 $ df -h
 Filesystem   Size  Used Avail Use% Mounted on
 /dev/mapper/ubuntu--vg-root  286G  4.1G  267G   2% /
 none 4.0K 0  4.0K   0% /sys/fs/cgroup
 udev 4.0G  4.0K  4.0G   1% /dev
 tmpfs806M  1.2M  804M   1% /run
 none 5.0M 0  5.0M   0% /run/lock
 none 4.0G  156K  4.0G   1% /run/shm
 none 100M   68K  100M   1% /run/user
 /dev/sda1236M   46M  178M  21% /boot



 

 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Install issues

 Hi Todd,

 hm, not too sure, but this looks like the getting of source code failed,
 though Cloning reached the 100% mark, so my first suspicion is: not
 enough space on your drive to unpack thrift?
 What does "df -h" say?

 Cheers,
 Marcus


 On 07.03.2016 12:15, Todd Lutton wrote:
> Running pybombs -v install gnuradio
>
> PyBombs.PackageManager - DEBUG - Checking if package git is installed.
> PyBombs.ReqScanner - DEBUG - Parsing 'git-core || git'
> PyBombs.Packager.apt-get - DEBUG - Package git-core has version 1.9.1 in 
> dpkg
> PyBombs.PackageManager - DEBUG - Checking if package git is installed.
> PyBombs.ReqScanner - DEBUG - Parsing 'git-core || git'
> PyBombs.Packager.apt-get - DEBUG - Package git-core has version 1.9.1 in 
> dpkg
> PyBombs.install - DEBUG - Install tree:
> PyBombs.Fetcher.git - DEBUG - Requirements met.
> PyBombs.Fetcher.git - DEBUG - Using url - 
> https://github.com/apache/thrift.git
> PyBombs._process_th

Re: [Discuss-gnuradio] GSoC 2016 - Signal Intelligence module for GNU Radio (gr-sigint)

[Martin Braun]

Hi,

this is a really good first draft at a proposal! A couple of points:

- Publish this on a place like github, so you can easily iterate and
don't have to send PDFs to the mailing list.
- There's a couple of typos in the draft. Just sayin'
- In the text, you mention you will use the last 2 weeks for review and
cleanup, can you put that into the timeline as well, just for an easier
overview
- Can you expand how the individual modules will work together? For
example, you show a list of classifiers, but I don't understand what
happens when you select one. Are they individual blocks, or kernels, or
something else?

Cheers,
Martin

On 03/08/2016 04:36 PM, Meet Pragnesh Shah wrote:
> Hello Mentors, 
> 
> I am a EE student at IIT-Bombay and I am also an avid software developer. 
> 
> I plan to participate in Google Summer of Code this year and I was
> interested in the ideas mentioned on the GNU-Radio wiki. I am
> particularly interested in the implementation of Signal Intelligence
> module (gr-sigint) whose potential mentor is Sreeraj Rajendran. 
> 
> I have attached a draft proposal and linked a rendered version of
> it here
>  
> for
> the kind perusal of mentors. In order to improve on the proposal, I
> would like to ask the mentors for their suggestions and comments on the
> proposal.   
>  
> Thanks and Regards,​
> 
> *Meet Pragnesh Shah | Junior Undergrad | EE | IIT Bombay *
> *Webpage :https://www.ee.iitb.ac.in/student/~meetshah1995/*
> ᐧ
> 
> 
> ___
> 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] BladeRF + osmosdr + gnuradio

[Brian Padalino]

On Wed, Mar 9, 2016 at 1:56 PM, M. Ranganathan  wrote:
> Hello,
>
> I am trying to get bladeRF to work as a receiver in order to decode LTE
> signals from within a gnuradio block. Here is my configuration :
>
>
> self.u =  osmosdr.source( args="numchan=" + str(1) + " " +
> "bladerf=0" )
> self.u.set_sample_rate(int(self.samp_rate))
> self.u.set_freq_corr(0, 0)
> self.u.set_dc_offset_mode(1, 0)
> self.u.set_iq_balance_mode(2, 0)
> self.u.set_gain_mode(True, 0)
> self.u.set_gain(3, 0)
> self.u.set_if_gain(15, 0)
> self.u.set_bb_gain(15, 0)
>
> It connects to the bladerf and reads values from it but there's something
> wrong with my gain settings I believe because the values I read don't make
> sense. Does somebody have experience with this configuration? Please share
> your settings.

Don't use the numchan argument.  That might be confusing things, but I
am not 100% sure.

Have you tried using the osmocom_fft GUI for getting an understanding
of the gain levels you need?

Brian

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

[Discuss-gnuradio] QT GUI Bercurve Sink - confusion about number of block ports

[Tracie Perez]

Hi all,

If I open a new flow graph in GRC and select a QT GUI Bercurve Sink 
block, the default parameters create 16 ports (connections) on the 
block. The default in the "Num Curves" field is 1 and the default in the 
"esno" field is numpy.arange(0.0, 4.0, .5), which is 8 values. I'm not 
sure why there are 16 ports.


If you then change "Num Curves" to 2, the number of ports on the block 
changes to 32. Also, if you change the value of "esno" to a different 
range of values, it changes the number of ports. Is that on purpose? 
Should the specified number of esno values be related to the number of 
ports?


I would expect that the number of ports on this block is simply equal to 
the number of curves specified. i.e., 2 in the "num curves" field 
generates 2 ports on the block.


In fact, that is the behavior of the ber_curve_gen.grc example. However 
if you start from a new flowgraph, there's a different behavior.


Any clarification on this would be appreciated. I'm working with GNU 
Radio v. 3.7.9.1.


Thanks,
tracie

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

Re: [Discuss-gnuradio] Packet drop from Ethernet (A BIG PROBLEM)

[Nikos Balkanas]

Hi Mostafa,

You seem to be confused about sample resolution. There is sample resolution
taking place at the FPGA, and sample resolution that can take place at uhd
driver in the host. Important to know is that usrp ADCs will sample at 16
bits I/Q (32 bits) /sample. That's a hardware limit you cannot improve
upon. If you reduce that at the FPGA to 8bits you save bandwidth from your
ethernet. If you change it at the driver, you only make it compatible with
your userspace app. Both are controlled at the same place, the streamer.
FPGA resolution is configured at stream_args.otw_format, while uhd output
resolution is configured at stream_args.cpu_format. For more info check the
uhd_usrp_get_rx_streamer at
http://files.ettus.com/manual/globals_func_u.html

You also are using a PCI NIC for transfer. These are cheap but notoriously
bad. I've tried both a DG-Link and a TP-Link and couldn't get over 300
Mbps, using Realtek's r8169 driver, without even having anything else in my
PCI bus.

HTH,
Nikos

On Wed, Mar 9, 2016 at 11:33 AM, Mostafa Alizadeh 
wrote:

> Hi Nikos,
>
> This is exaclty the issue related to the GNURadio application rather than
> USRP because the problem is from the host. That is not possible to transfer
> 30 Msps, however, what about 20 Msps? I expect to be able to transfer 20
> Msps at least.
>
> Another point that you mentioned is "changing the resolution of the
> samples". In contrast, as far as I know, if you change the sample
> resolution it does not reduce the bit rate of the Ethernet interface,
> however, it changes the interpretation of the samples! It is easy to run a
> program for different sample resolution and observe that there is no change
> in the bit rate of the Eth. Interface.
>
> How to change the ethernet parameters or anything else ( if any idea ) to
> reduce packet dropping??
>
> Thanks in advance,
> Mostafa
> On Mar 9, 2016 11:25 AM, "Nikos Balkanas"  wrote:
>
>> Hi,
>>
>> This issue is better addressed to usrp-us...@ettus.com. Briefly I can
>> tell you that you can never reach 30M samples/sec over a 1 GbE interface.
>> 30 x 32/bits/sample = 960. Need a bit for metadata, packet overheads,
>> etc. you will drop packages. Especially if your NIC is PCI based :(
>> Try reducing your sample resolution to 8 bits. You may have better luck.
>>
>> HTH,
>> Nikos
>>
>> On Wed, Mar 9, 2016 at 9:42 AM, Mostafa Alizadeh 
>> wrote:
>>
>>> Hello all,
>>> I stuck on an incridible challenge in sending/receiving a large
>>> bandwidth. I have an USRP N210 and an WBX daughterboard, while I must be
>>> able to capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with
>>> the sample rate of 25Msps or even 20Msps I have some dropped packets. Based
>>> on my knowledge, this is due to CPU which does not have enough time to
>>> capture from Ethernet, however, I have the powerful one, 12 core CPU. When
>>> I have a large GNURadio program to run, there are some dropped packets. I
>>> searched everywhere but I did not find a complete description of the
>>> solution. What is (are ) the solution(s )? Please help me with any
>>> information! :(
>>>
>>> Best regards
>>> Mostafa
>>>
>>> ___
>>> 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] Google Summer of Code / ham radio

[Daniel Pocock]

On 09/03/16 00:16, Tom Rondeau wrote:
> On Tue, Mar 8, 2016 at 3:09 PM, Daniel Pocock  > wrote:
> 
> On 08/03/16 20:52, Johnathan Corgan wrote:
>> On Tue, Mar 8, 2016 at 10:06 AM, Daniel Pocock > > wrote:
>>  
>>
>> Debian and GNU Radio are both confirmed in GSoC this year, is
>> there
>> interest in advertising this idea[1] for converting the GNU
>> Radio live
>> DVD into a Debian Live project, merging with the Debian Ham CD?
>>
>>
>> ​The GNU Radio Live SDR environment builder is completely
>> scripted, and designed to allow easy customization:
>>
>> https://github.com/gnuradio/gnuradio-livesdr
>>
>> For simple binary package installations, you can add a file with a
>> list of packages here:
>>
>> 
>> https://github.com/gnuradio/gnuradio-livesdr/tree/livesdr/config/install-pkgs.d
>>
>> To add additional PyBOMBS (1.0) based GNU Radio OOT modules, you
>> can modify:
>>
>> 
>> https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr/config/pybombs.d/install.conf
>>
>> The conversion to using PyBOMBS 2.0​ is in progress.
>>
>> So it would be straightforward to create a long-lived branch that
>> focuses on ham radio specific content.
>>
> 
> The Debian Ham Blend produces both a live CD/DVD and also a
> collection of packages that people can conveniently install as part
> of a normal Debian system on their HDD:
> 
>https://www.debian.org/blends/hamradio/
> 
> Many of the things in the Blend are not specific to ham radio
> though.  e.g you can use the gpredict utility to track any type of
> satellite.  Browse the list of metapackages to see what I mean:
> https://www.debian.org/blends/hamradio/get/metapackages
> 
> The benefit of adapting things from the GNU Radio live SDR
> environment into the Debian Ham Blend is that it would involve more
> people in the long term, as you get the experience of the Debian Ham
> team, the Debian Live maintainers and a lot of other Debian
> resources too.
> 
> Parts of this task, such as making a ready-to-run transceiver, would
> not only be for use in the live environment, they would be for users
> on any platform.
> 
> I'm not suggesting that the current Live SDR solution is broken,
> rather, a combined solution may be stronger in the long term.
> 
> Regards,
> 
> Daniel
> 
> 
> 
> Hi Daniel,
> 
> I think this is an interesting project, and I like the idea of getting
> students excited about radio through some of these harder challenges in
> the amateur space. Yet looking through your ideas here, I think this
> project mostly belongs in the Debian space. We're going to be keeping
> our model and development method behind the GNU Radio LiveDVD because it
> very nicely serves exactly our purpose. It's designed to get people up
> and developing on GNU Radio quickly. This is a much different mission
> than providing an OS with a known set of end user applications. That's
> what you're going for and that's a fantastic, but separate, service.
> 


Thanks for the feedback

I've written up a project proposal on both the GNU Radio and Debian
wikis, it doesn't favor either of the Live DVD solutions and it simply
asks the student to work on ham-related tasks that could be distributed
in either or both of them.

If anybody else has ideas for this project please feel free to add them
into the wiki.

Regards,

Daniel

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

[Discuss-gnuradio] BladeRF + osmosdr + gnuradio

[M. Ranganathan]

Hello,

I am trying to get bladeRF to work as a receiver in order to decode LTE
signals from within a gnuradio block. Here is my configuration :


self.u =  osmosdr.source( args="numchan=" + str(1) + " " +
"bladerf=0" )
self.u.set_sample_rate(int(self.samp_rate))
self.u.set_freq_corr(0, 0)
self.u.set_dc_offset_mode(1, 0)
self.u.set_iq_balance_mode(2, 0)
self.u.set_gain_mode(True, 0)
self.u.set_gain(3, 0)
self.u.set_if_gain(15, 0)
self.u.set_bb_gain(15, 0)

It connects to the bladerf and reads values from it but there's something
wrong with my gain settings I believe because the values I read don't make
sense. Does somebody have experience with this configuration? Please share
your settings.

Thanks,

Ranga.

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

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

[Eugene Grayver]

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

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[West, Nathan]

Good news!

That branch now belongs in GNU Radio.

Cheers,
Nathan

On Wed, Mar 9, 2016 at 8:45 AM, devin kelly  wrote:

> Thanks for the help, I don't think I could have figured this out on my own.
>
> This is because I'm on RHEL7 (argh!).  My libfftw.so doesn't contain any
> references to AVX. For me there are a couple of options for fixing this:
>
> 1) Use Nathan's branch.
> 2) Rebuild fftw with AVX support
> 3) Rebuild GR and Volk without AVX.
>
> I tried 2) first and noticed this in the spec file that was in the source
> RPM I was trying to rebuild:
>
> %ifarch %{ix86} x86_64
> # Enable SSE2 support for x86 and x86_64
> # (no avx as it is claimed to drastically slower)
> for((i=0;i<2;i++)); do
>  prec_flags[i]+=" --enable-sse2"
> done
> %endif
>
> Is the spec file author right?  Now I'm a little confused about the
> approach I should take.  I'll probably just go with 1) in the mean time.
>
> Thanks again Nathan,
> Devin
>
> On Wed, Mar 9, 2016 at 1:06 AM, West, Nathan 
> wrote:
>
>> The a and c vectors come from gr:fft objects' internal buffers. These are
>> internally created with fftwf_malloc (lines 152/156 of gr-fft/lib/fft.cc).
>> fftwf_malloc is obviously not generating buffers with proper alignment so
>> you're seeing a 50% (per buffer) that this segfaults. I'll note that this
>> is also only an issue with fftwf buffers when fftwf isn't built with AVX
>> support (and therefore nothing in fftwf requires  a 32-byte aligned buffer).
>>
>> Andy Walls (thanks!) pointed out on IRC that we had a similar issue years
>> ago with a QT sink.
>>
>> I have a branch that should fix this (
>> https://github.com/n-west/gnuradio/tree/fft-avx-alignment). I also
>> suggest you look in to getting a version of fftwf built with AVX. I don't
>> know if there's a good way to tell, but if I run readelf -a on my
>> libfftw3.so I see some functions with avx in the name.
>>
>> Cheers,
>> nw
>>
>>
>> On Tue, Mar 8, 2016 at 1:31 PM, devin kelly  wrote:
>>
>>> OK, here's my C program:
>>>
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> int main() {
>>>
>>> size_t alignment = volk_get_alignment();
>>>
>>> uint8_t* ptr;
>>>
>>> ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
>>> printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr,
>>> *ptr);
>>> volk_free((void*)ptr);
>>> ptr = NULL;
>>>
>>>
>>> return 0;
>>> }
>>>
>>>
>>> Compile:
>>>
>>> $ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib
>>>
>>> It's output:
>>>
>>> $ ./volk_test
>>> Using Volk machine: avx2_64_mmx_orc
>>> alignment = 32, ptr = 151b040, *ptr = 00
>>>
>>> Also, I've attached the output from the preprocessor, this command:
>>>
>>> $ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
>>> -DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
>>> -g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
>>> -I/local_disk/gr_3.7.9_src/volk/include
>>> -I/local_disk/gr_3.7.9_src/volk/kernels
>>> -I/local_disk/gr_3.7.9_src/volk/build_debug/lib
>>> -I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
>>> volk_malloc_preprocessed   -c
>>> /local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c
>>>
>>> I just found the compiler step from from doing 'VERBOSE=1 make' then
>>> changed the output and added -E.  I attached volk_malloc_preprocessed as
>>> well.
>>>
>>> It looks like this is my volk_malloc():
>>>
>>>
>>> void *volk_malloc(size_t size, size_t alignment)
>>> {
>>>   void *ptr;
>>>
>>>
>>>
>>>
>>>   if (alignment == 1)
>>> return malloc(size);
>>>
>>>   int err = posix_memalign(&ptr, alignment, size);
>>>   if(err == 0) {
>>> return ptr;
>>>   }
>>>   else {
>>> fprintf(stderr,
>>> "VOLK: Error allocating memory "
>>> "(posix_memalign: error %d: %s)\n", err, strerror(err));
>>> return ((void *)0);
>>>   }
>>> }
>>>
>>>
>>>
>>> Devin
>>>
>>>
>>>
>>> On Tue, Mar 8, 2016 at 11:37 AM, West, Nathan <
>>> n...@ostatemail.okstate.edu> wrote:
>>>

 On Tue, Mar 8, 2016 at 10:58 AM, devin kelly 
 wrote:

> Calling 'info variables' (or args or locals) the last few frames
> didn't give me any real info so I built a copy of GR/Volk with debug
> symbols.  I ran the FG again, this time from GDB, here's my back trace.  
> In
> this backtrace you can see the arguments passed in each call.  I have an
> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>

 Excellent. Thanks for going through that extra step. It really helps.


>
> Here's are the links for the relevant code:
>
>
> https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fft_filter.cc#L323
>
> https://github.com/gnuradio/gnuradio/blob/222e0003f9797a1b92d64855bd2b93f0d9099f93/gr-digital/lib/corr_est_

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[Anon Lister]

To answer your question however, he's misguided. Fftw and volk both have
methods (volk_profile, fftw-wisdom) to profile and determine the best
instructions to use for cases where they have multiple options, it's not
going to get noticeably slower by compiling the extra stuff in.
On Mar 9, 2016 8:47 AM, "devin kelly"  wrote:

> Thanks for the help, I don't think I could have figured this out on my own.
>
> This is because I'm on RHEL7 (argh!).  My libfftw.so doesn't contain any
> references to AVX. For me there are a couple of options for fixing this:
>
> 1) Use Nathan's branch.
> 2) Rebuild fftw with AVX support
> 3) Rebuild GR and Volk without AVX.
>
> I tried 2) first and noticed this in the spec file that was in the source
> RPM I was trying to rebuild:
>
> %ifarch %{ix86} x86_64
> # Enable SSE2 support for x86 and x86_64
> # (no avx as it is claimed to drastically slower)
> for((i=0;i<2;i++)); do
>  prec_flags[i]+=" --enable-sse2"
> done
> %endif
>
> Is the spec file author right?  Now I'm a little confused about the
> approach I should take.  I'll probably just go with 1) in the mean time.
>
> Thanks again Nathan,
> Devin
>
> On Wed, Mar 9, 2016 at 1:06 AM, West, Nathan 
> wrote:
>
>> The a and c vectors come from gr:fft objects' internal buffers. These are
>> internally created with fftwf_malloc (lines 152/156 of gr-fft/lib/fft.cc).
>> fftwf_malloc is obviously not generating buffers with proper alignment so
>> you're seeing a 50% (per buffer) that this segfaults. I'll note that this
>> is also only an issue with fftwf buffers when fftwf isn't built with AVX
>> support (and therefore nothing in fftwf requires  a 32-byte aligned buffer).
>>
>> Andy Walls (thanks!) pointed out on IRC that we had a similar issue years
>> ago with a QT sink.
>>
>> I have a branch that should fix this (
>> https://github.com/n-west/gnuradio/tree/fft-avx-alignment). I also
>> suggest you look in to getting a version of fftwf built with AVX. I don't
>> know if there's a good way to tell, but if I run readelf -a on my
>> libfftw3.so I see some functions with avx in the name.
>>
>> Cheers,
>> nw
>>
>>
>> On Tue, Mar 8, 2016 at 1:31 PM, devin kelly  wrote:
>>
>>> OK, here's my C program:
>>>
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> int main() {
>>>
>>> size_t alignment = volk_get_alignment();
>>>
>>> uint8_t* ptr;
>>>
>>> ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
>>> printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr,
>>> *ptr);
>>> volk_free((void*)ptr);
>>> ptr = NULL;
>>>
>>>
>>> return 0;
>>> }
>>>
>>>
>>> Compile:
>>>
>>> $ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib
>>>
>>> It's output:
>>>
>>> $ ./volk_test
>>> Using Volk machine: avx2_64_mmx_orc
>>> alignment = 32, ptr = 151b040, *ptr = 00
>>>
>>> Also, I've attached the output from the preprocessor, this command:
>>>
>>> $ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
>>> -DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
>>> -g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
>>> -I/local_disk/gr_3.7.9_src/volk/include
>>> -I/local_disk/gr_3.7.9_src/volk/kernels
>>> -I/local_disk/gr_3.7.9_src/volk/build_debug/lib
>>> -I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
>>> volk_malloc_preprocessed   -c
>>> /local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c
>>>
>>> I just found the compiler step from from doing 'VERBOSE=1 make' then
>>> changed the output and added -E.  I attached volk_malloc_preprocessed as
>>> well.
>>>
>>> It looks like this is my volk_malloc():
>>>
>>>
>>> void *volk_malloc(size_t size, size_t alignment)
>>> {
>>>   void *ptr;
>>>
>>>
>>>
>>>
>>>   if (alignment == 1)
>>> return malloc(size);
>>>
>>>   int err = posix_memalign(&ptr, alignment, size);
>>>   if(err == 0) {
>>> return ptr;
>>>   }
>>>   else {
>>> fprintf(stderr,
>>> "VOLK: Error allocating memory "
>>> "(posix_memalign: error %d: %s)\n", err, strerror(err));
>>> return ((void *)0);
>>>   }
>>> }
>>>
>>>
>>>
>>> Devin
>>>
>>>
>>>
>>> On Tue, Mar 8, 2016 at 11:37 AM, West, Nathan <
>>> n...@ostatemail.okstate.edu> wrote:
>>>

 On Tue, Mar 8, 2016 at 10:58 AM, devin kelly 
 wrote:

> Calling 'info variables' (or args or locals) the last few frames
> didn't give me any real info so I built a copy of GR/Volk with debug
> symbols.  I ran the FG again, this time from GDB, here's my back trace.  
> In
> this backtrace you can see the arguments passed in each call.  I have an
> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>

 Excellent. Thanks for going through that extra step. It really helps.


>
> Here's are the links for the relevant code:
>
>
> https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232
>

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[Anon Lister]

I would use fftw source from their site not rhels source rpm, unless you
need to deploy it on a large number of machines. (Even then I would pull
latest source and update the srpm)

You can just build fftw from source. Add almost all the configure options.
We do this on rhel 6 because their version doesn't support wisdom or take
advantage of any recent CPU releases. It should install in /usr/local by
default. Just add the library path to /etc/ld.so.conf and run ldconfig and
you'll be set.
On Mar 9, 2016 8:47 AM, "devin kelly"  wrote:

> Thanks for the help, I don't think I could have figured this out on my own.
>
> This is because I'm on RHEL7 (argh!).  My libfftw.so doesn't contain any
> references to AVX. For me there are a couple of options for fixing this:
>
> 1) Use Nathan's branch.
> 2) Rebuild fftw with AVX support
> 3) Rebuild GR and Volk without AVX.
>
> I tried 2) first and noticed this in the spec file that was in the source
> RPM I was trying to rebuild:
>
> %ifarch %{ix86} x86_64
> # Enable SSE2 support for x86 and x86_64
> # (no avx as it is claimed to drastically slower)
> for((i=0;i<2;i++)); do
>  prec_flags[i]+=" --enable-sse2"
> done
> %endif
>
> Is the spec file author right?  Now I'm a little confused about the
> approach I should take.  I'll probably just go with 1) in the mean time.
>
> Thanks again Nathan,
> Devin
>
> On Wed, Mar 9, 2016 at 1:06 AM, West, Nathan 
> wrote:
>
>> The a and c vectors come from gr:fft objects' internal buffers. These are
>> internally created with fftwf_malloc (lines 152/156 of gr-fft/lib/fft.cc).
>> fftwf_malloc is obviously not generating buffers with proper alignment so
>> you're seeing a 50% (per buffer) that this segfaults. I'll note that this
>> is also only an issue with fftwf buffers when fftwf isn't built with AVX
>> support (and therefore nothing in fftwf requires  a 32-byte aligned buffer).
>>
>> Andy Walls (thanks!) pointed out on IRC that we had a similar issue years
>> ago with a QT sink.
>>
>> I have a branch that should fix this (
>> https://github.com/n-west/gnuradio/tree/fft-avx-alignment). I also
>> suggest you look in to getting a version of fftwf built with AVX. I don't
>> know if there's a good way to tell, but if I run readelf -a on my
>> libfftw3.so I see some functions with avx in the name.
>>
>> Cheers,
>> nw
>>
>>
>> On Tue, Mar 8, 2016 at 1:31 PM, devin kelly  wrote:
>>
>>> OK, here's my C program:
>>>
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> int main() {
>>>
>>> size_t alignment = volk_get_alignment();
>>>
>>> uint8_t* ptr;
>>>
>>> ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
>>> printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr,
>>> *ptr);
>>> volk_free((void*)ptr);
>>> ptr = NULL;
>>>
>>>
>>> return 0;
>>> }
>>>
>>>
>>> Compile:
>>>
>>> $ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib
>>>
>>> It's output:
>>>
>>> $ ./volk_test
>>> Using Volk machine: avx2_64_mmx_orc
>>> alignment = 32, ptr = 151b040, *ptr = 00
>>>
>>> Also, I've attached the output from the preprocessor, this command:
>>>
>>> $ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
>>> -DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
>>> -g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
>>> -I/local_disk/gr_3.7.9_src/volk/include
>>> -I/local_disk/gr_3.7.9_src/volk/kernels
>>> -I/local_disk/gr_3.7.9_src/volk/build_debug/lib
>>> -I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
>>> volk_malloc_preprocessed   -c
>>> /local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c
>>>
>>> I just found the compiler step from from doing 'VERBOSE=1 make' then
>>> changed the output and added -E.  I attached volk_malloc_preprocessed as
>>> well.
>>>
>>> It looks like this is my volk_malloc():
>>>
>>>
>>> void *volk_malloc(size_t size, size_t alignment)
>>> {
>>>   void *ptr;
>>>
>>>
>>>
>>>
>>>   if (alignment == 1)
>>> return malloc(size);
>>>
>>>   int err = posix_memalign(&ptr, alignment, size);
>>>   if(err == 0) {
>>> return ptr;
>>>   }
>>>   else {
>>> fprintf(stderr,
>>> "VOLK: Error allocating memory "
>>> "(posix_memalign: error %d: %s)\n", err, strerror(err));
>>> return ((void *)0);
>>>   }
>>> }
>>>
>>>
>>>
>>> Devin
>>>
>>>
>>>
>>> On Tue, Mar 8, 2016 at 11:37 AM, West, Nathan <
>>> n...@ostatemail.okstate.edu> wrote:
>>>

 On Tue, Mar 8, 2016 at 10:58 AM, devin kelly 
 wrote:

> Calling 'info variables' (or args or locals) the last few frames
> didn't give me any real info so I built a copy of GR/Volk with debug
> symbols.  I ran the FG again, this time from GDB, here's my back trace.  
> In
> this backtrace you can see the arguments passed in each call.  I have an
> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>

 Excellent. Thanks for going through that extra step. It really helps.
>>

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[devin kelly]

Thanks for the help, I don't think I could have figured this out on my own.

This is because I'm on RHEL7 (argh!).  My libfftw.so doesn't contain any
references to AVX. For me there are a couple of options for fixing this:

1) Use Nathan's branch.
2) Rebuild fftw with AVX support
3) Rebuild GR and Volk without AVX.

I tried 2) first and noticed this in the spec file that was in the source
RPM I was trying to rebuild:

%ifarch %{ix86} x86_64
# Enable SSE2 support for x86 and x86_64
# (no avx as it is claimed to drastically slower)
for((i=0;i<2;i++)); do
 prec_flags[i]+=" --enable-sse2"
done
%endif

Is the spec file author right?  Now I'm a little confused about the
approach I should take.  I'll probably just go with 1) in the mean time.

Thanks again Nathan,
Devin

On Wed, Mar 9, 2016 at 1:06 AM, West, Nathan 
wrote:

> The a and c vectors come from gr:fft objects' internal buffers. These are
> internally created with fftwf_malloc (lines 152/156 of gr-fft/lib/fft.cc).
> fftwf_malloc is obviously not generating buffers with proper alignment so
> you're seeing a 50% (per buffer) that this segfaults. I'll note that this
> is also only an issue with fftwf buffers when fftwf isn't built with AVX
> support (and therefore nothing in fftwf requires  a 32-byte aligned buffer).
>
> Andy Walls (thanks!) pointed out on IRC that we had a similar issue years
> ago with a QT sink.
>
> I have a branch that should fix this (
> https://github.com/n-west/gnuradio/tree/fft-avx-alignment). I also
> suggest you look in to getting a version of fftwf built with AVX. I don't
> know if there's a good way to tell, but if I run readelf -a on my
> libfftw3.so I see some functions with avx in the name.
>
> Cheers,
> nw
>
>
> On Tue, Mar 8, 2016 at 1:31 PM, devin kelly  wrote:
>
>> OK, here's my C program:
>>
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> int main() {
>>
>> size_t alignment = volk_get_alignment();
>>
>> uint8_t* ptr;
>>
>> ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
>> printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr,
>> *ptr);
>> volk_free((void*)ptr);
>> ptr = NULL;
>>
>>
>> return 0;
>> }
>>
>>
>> Compile:
>>
>> $ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib
>>
>> It's output:
>>
>> $ ./volk_test
>> Using Volk machine: avx2_64_mmx_orc
>> alignment = 32, ptr = 151b040, *ptr = 00
>>
>> Also, I've attached the output from the preprocessor, this command:
>>
>> $ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
>> -DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
>> -g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
>> -I/local_disk/gr_3.7.9_src/volk/include
>> -I/local_disk/gr_3.7.9_src/volk/kernels
>> -I/local_disk/gr_3.7.9_src/volk/build_debug/lib
>> -I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
>> volk_malloc_preprocessed   -c
>> /local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c
>>
>> I just found the compiler step from from doing 'VERBOSE=1 make' then
>> changed the output and added -E.  I attached volk_malloc_preprocessed as
>> well.
>>
>> It looks like this is my volk_malloc():
>>
>>
>> void *volk_malloc(size_t size, size_t alignment)
>> {
>>   void *ptr;
>>
>>
>>
>>
>>   if (alignment == 1)
>> return malloc(size);
>>
>>   int err = posix_memalign(&ptr, alignment, size);
>>   if(err == 0) {
>> return ptr;
>>   }
>>   else {
>> fprintf(stderr,
>> "VOLK: Error allocating memory "
>> "(posix_memalign: error %d: %s)\n", err, strerror(err));
>> return ((void *)0);
>>   }
>> }
>>
>>
>>
>> Devin
>>
>>
>>
>> On Tue, Mar 8, 2016 at 11:37 AM, West, Nathan <
>> n...@ostatemail.okstate.edu> wrote:
>>
>>>
>>> On Tue, Mar 8, 2016 at 10:58 AM, devin kelly  wrote:
>>>
 Calling 'info variables' (or args or locals) the last few frames didn't
 give me any real info so I built a copy of GR/Volk with debug symbols.  I
 ran the FG again, this time from GDB, here's my back trace.  In this
 backtrace you can see the arguments passed in each call.  I have an
 i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.

>>>
>>> Excellent. Thanks for going through that extra step. It really helps.
>>>
>>>

 Here's are the links for the relevant code:


 https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232

 https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fft_filter.cc#L323

 https://github.com/gnuradio/gnuradio/blob/222e0003f9797a1b92d64855bd2b93f0d9099f93/gr-digital/lib/corr_est_cc_impl.cc#L214

 Could the problem be that nitems is 257 and num_points is 512?  Or
 should nitems really be 256 and not 257?

>>>
>>> I don't think so. I'm not familiar with the details of the fft_filter
>>> implementations, but usually these things will take in some history if they
>>> don'

Re: [Discuss-gnuradio] Packet drop from Ethernet (A BIG PROBLEM)

[Marcus Müller]

Hi Nikos,
you're absolutely right with respect to it just being a bus bandwidth
limitation: Gigabit ethernet can only carry 1Gbit/s, and with 16 bit per
I and Q part, 31.25 Megasamples would be the maximum rate you could get
through; adding a bit of overhead (it's not that much, roughly 40B
overhead per 1450B payload, so roughly 2.7%), this gets reduced to
roughly 30 MS/s, and including the fact that an average NIC isn't always
using the cable to its fullest extent, that might be even less.
So another reason why this isn't a GNU Radio issue is that 30MS/s is not
a rate supported by the USRP: sampling rates need to be
master_clock_rate/N, N being a natural number. That master clock rate is
fixed to 100MHz on N210, so the only possible rates are

100MS/s (impossible over Gigabit Ethernet),
50MS/s (only possible with 8bit samples),
33.333MS/s (only possible with 8bit samples, but bad, because 3 is an
odd decimation, and anti-aliasing filter performance is much worse for
these),
25MS/s,
20MS/s,
and so on.

UHD will print a warning that the rate is impossible and that a "close
by" rate was used.

Best regards,
Marcus


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

[Discuss-gnuradio] Fwd: Packet drop from Ethernet (A BIG PROBLEM)

[Mostafa Alizadeh]

***
Tehran
IRAN
Tel: +98 (919) 158-7730
Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir
Homepage: Linkedin 

***

-- Forwarded message --
From: Mostafa Alizadeh 
Date: Wed, Mar 9, 2016 at 1:52 PM
Subject: Re: [Discuss-gnuradio] Packet drop from Ethernet (A BIG PROBLEM)
To: Nikos Balkanas 



I said changing the resolution of the samples does not any effect on the
network transferring rate! In the figure below, I tested two cases by USRP
source, the first one with "complex int 16" (the left bit stream shown in
the figure below) and the second one with "complex float 32" (the second
bit stream show in the figure below). The bit rate is the same. I do not
know about ADC/DAC, however I see the bit rate coming the Ethernet.


[image: Inline image 1]



My operating system is Ubuntu 14.04 and I have a PCI-based Ethernet! :(


***
Tehran
IRAN
Tel: +98 (919) 158-7730
Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir
Homepage: Linkedin 

***

On Wed, Mar 9, 2016 at 1:26 PM, Nikos Balkanas  wrote:

> Hi Mostafa,
>
> This is a usrp issue, and depends exactly on the hardware. Before you look
> into the host for optimizing its networking parameters, you should make
> sure that your hardware can handle it.
> For example reducing the sample resolution in your N200. ADCs in USRPs use
> quad sampling, which means they generate I/Q (imaginary/real) data for each
> sample. At full resolution, this is 16 bits each or 32 bits/Sample. At
> reduced sample resolution, which takes place in the FPGA, you get 8 + 8 =
> 16 bits/sample, therefore half the bandwidth of full resolution going
> through the wire.
>
> Now, you should be able to handle 20 MS/s at full resolution, 20x32 = 640
> Mbps. But a lot of NICS have problems, especially the PCI ones. What is
> your NIC? What is your OS?
>
> BR,
> Nikos
>
>
> On Wed, Mar 9, 2016 at 11:33 AM, Mostafa Alizadeh 
> wrote:
>
>> Hi Nikos,
>>
>> This is exaclty the issue related to the GNURadio application rather than
>> USRP because the problem is from the host. That is not possible to transfer
>> 30 Msps, however, what about 20 Msps? I expect to be able to transfer 20
>> Msps at least.
>>
>> Another point that you mentioned is "changing the resolution of the
>> samples". In contrast, as far as I know, if you change the sample
>> resolution it does not reduce the bit rate of the Ethernet interface,
>> however, it changes the interpretation of the samples! It is easy to run a
>> program for different sample resolution and observe that there is no change
>> in the bit rate of the Eth. Interface.
>>
>> How to change the ethernet parameters or anything else ( if any idea ) to
>> reduce packet dropping??
>>
>> Thanks in advance,
>> Mostafa
>> On Mar 9, 2016 11:25 AM, "Nikos Balkanas"  wrote:
>>
>>> Hi,
>>>
>>> This issue is better addressed to usrp-us...@ettus.com. Briefly I can
>>> tell you that you can never reach 30M samples/sec over a 1 GbE interface.
>>> 30 x 32/bits/sample = 960. Need a bit for metadata, packet overheads,
>>> etc. you will drop packages. Especially if your NIC is PCI based :(
>>> Try reducing your sample resolution to 8 bits. You may have better luck.
>>>
>>> HTH,
>>> Nikos
>>>
>>> On Wed, Mar 9, 2016 at 9:42 AM, Mostafa Alizadeh >> > wrote:
>>>
 Hello all,
 I stuck on an incridible challenge in sending/receiving a large
 bandwidth. I have an USRP N210 and an WBX daughterboard, while I must be
 able to capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with
 the sample rate of 25Msps or even 20Msps I have some dropped packets. Based
 on my knowledge, this is due to CPU which does not have enough time to
 capture from Ethernet, however, I have the powerful one, 12 core CPU. When
 I have a large GNURadio program to run, there are some dropped packets. I
 searched everywhere but I did not find a complete description of the
 solution. What is (are ) the solution(s )? Please help me with any
 information! :(

 Best regards
 Mostafa

 ___
 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] Packet drop from Ethernet (A BIG PROBLEM)

[Nikos Balkanas]

Hi Mostafa,

This is a usrp issue, and depends exactly on the hardware. Before you look
into the host for optimizing its networking parameters, you should make
sure that your hardware can handle it.
For example reducing the sample resolution in your N200. ADCs in USRPs use
quad sampling, which means they generate I/Q (imaginary/real) data for each
sample. At full resolution, this is 16 bits each or 32 bits/Sample. At
reduced sample resolution, which takes place in the FPGA, you get 8 + 8 =
16 bits/sample, therefore half the bandwidth of full resolution going
through the wire.

Now, you should be able to handle 20 MS/s at full resolution, 20x32 = 640
Mbps. But a lot of NICS have problems, especially the PCI ones. What is
your NIC? What is your OS?

BR,
Nikos


On Wed, Mar 9, 2016 at 11:33 AM, Mostafa Alizadeh 
wrote:

> Hi Nikos,
>
> This is exaclty the issue related to the GNURadio application rather than
> USRP because the problem is from the host. That is not possible to transfer
> 30 Msps, however, what about 20 Msps? I expect to be able to transfer 20
> Msps at least.
>
> Another point that you mentioned is "changing the resolution of the
> samples". In contrast, as far as I know, if you change the sample
> resolution it does not reduce the bit rate of the Ethernet interface,
> however, it changes the interpretation of the samples! It is easy to run a
> program for different sample resolution and observe that there is no change
> in the bit rate of the Eth. Interface.
>
> How to change the ethernet parameters or anything else ( if any idea ) to
> reduce packet dropping??
>
> Thanks in advance,
> Mostafa
> On Mar 9, 2016 11:25 AM, "Nikos Balkanas"  wrote:
>
>> Hi,
>>
>> This issue is better addressed to usrp-us...@ettus.com. Briefly I can
>> tell you that you can never reach 30M samples/sec over a 1 GbE interface.
>> 30 x 32/bits/sample = 960. Need a bit for metadata, packet overheads,
>> etc. you will drop packages. Especially if your NIC is PCI based :(
>> Try reducing your sample resolution to 8 bits. You may have better luck.
>>
>> HTH,
>> Nikos
>>
>> On Wed, Mar 9, 2016 at 9:42 AM, Mostafa Alizadeh 
>> wrote:
>>
>>> Hello all,
>>> I stuck on an incridible challenge in sending/receiving a large
>>> bandwidth. I have an USRP N210 and an WBX daughterboard, while I must be
>>> able to capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with
>>> the sample rate of 25Msps or even 20Msps I have some dropped packets. Based
>>> on my knowledge, this is due to CPU which does not have enough time to
>>> capture from Ethernet, however, I have the powerful one, 12 core CPU. When
>>> I have a large GNURadio program to run, there are some dropped packets. I
>>> searched everywhere but I did not find a complete description of the
>>> solution. What is (are ) the solution(s )? Please help me with any
>>> information! :(
>>>
>>> Best regards
>>> Mostafa
>>>
>>> ___
>>> 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] Packet drop from Ethernet (A BIG PROBLEM)

[Mostafa Alizadeh]

Hi Nikos,

This is exaclty the issue related to the GNURadio application rather than
USRP because the problem is from the host. That is not possible to transfer
30 Msps, however, what about 20 Msps? I expect to be able to transfer 20
Msps at least.

Another point that you mentioned is "changing the resolution of the
samples". In contrast, as far as I know, if you change the sample
resolution it does not reduce the bit rate of the Ethernet interface,
however, it changes the interpretation of the samples! It is easy to run a
program for different sample resolution and observe that there is no change
in the bit rate of the Eth. Interface.

How to change the ethernet parameters or anything else ( if any idea ) to
reduce packet dropping??

Thanks in advance,
Mostafa
On Mar 9, 2016 11:25 AM, "Nikos Balkanas"  wrote:

> Hi,
>
> This issue is better addressed to usrp-us...@ettus.com. Briefly I can
> tell you that you can never reach 30M samples/sec over a 1 GbE interface.
> 30 x 32/bits/sample = 960. Need a bit for metadata, packet overheads, etc.
> you will drop packages. Especially if your NIC is PCI based :(
> Try reducing your sample resolution to 8 bits. You may have better luck.
>
> HTH,
> Nikos
>
> On Wed, Mar 9, 2016 at 9:42 AM, Mostafa Alizadeh 
> wrote:
>
>> Hello all,
>> I stuck on an incridible challenge in sending/receiving a large
>> bandwidth. I have an USRP N210 and an WBX daughterboard, while I must be
>> able to capture/transfer up to 30Msample/sec(1Gig ethernet limit ), with
>> the sample rate of 25Msps or even 20Msps I have some dropped packets. Based
>> on my knowledge, this is due to CPU which does not have enough time to
>> capture from Ethernet, however, I have the powerful one, 12 core CPU. When
>> I have a large GNURadio program to run, there are some dropped packets. I
>> searched everywhere but I did not find a complete description of the
>> solution. What is (are ) the solution(s )? Please help me with any
>> information! :(
>>
>> Best regards
>> Mostafa
>>
>> ___
>> 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] Google Summer of Code / ham radio

[Markus Heller]

Hi everybody,

I'm still waiting for some information so that I can send out the
official Call for Papers for this year's 

Software Defined Radio Academy 

at HAMRADIO Friedrichshafen, 25.06.2016. 

Please consider this mail as some kind of infofficial, in advance
invitation! 

We're looking for speakers, tutorials, presentations, posters of your
projects, ideas, research, products.

The Live DVD could be an interesting talk. But even beyond that: Save
the date! And if you have some cool stuff you would like to present to a
HAMRADIO audience, the stage will be yours!

SDRA is part of the great HAMRADIO fair with 18.000 visitors, so it's
worth a visit anyway, even from far away. Last year we had visitors
(even a speaker) from Australia... 

Please check the SDRA website:

http://www.sdra-2016.de

vy73
markus 
dl8rds

Am Dienstag, den 08.03.2016, 20:40 +0100 schrieb Marcus Müller:
> Regarding the Ham things: That's something that I can only emphasize:
> Students, whatever qualification, experiences and projects you have
> done
> with radio, it's probably not the worst idea to mention that! Also,
> especially Ham Radio has a very active crowd, so if you can find a
> project that suits you and you'd like to see it do something related
> with amateur radio operation, it's very likely that you can get active
> help here.
> 
> In general: Get in contact, do that early, talk about what you want to
> do and what skills you bring and think you'll need to acquire. Every
> positive interaction with the community definitely makes you more
> valuable to the project :)



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

[Discuss-gnuradio] Looking for N200 and N210 cases and/or used or broken USRPs N200, N210 or other USRP

[Martin]

Hi,

For a few N210 and N200, with lost or damaged cases, I am looking for 
replacement cases.
Ettus/NI does not sell seperate cases, so I am looking for anybody else 
that has one or more of these cases.

Or do you have broken N210 and/or N200 units so I can re-use the case.

I am also interested in working used USRPs (any model).

Please contact me if you have one or more of these.

Thanks in advance.

Martin Dudok van Heel
Olifantasia.com signal processing solutions
USRP and OpenBTS kit sales Europe

Contact:Martin Dudok van Heel
Tel:+31 33-4799840
Fax:+31 84-2253821
Email:  pa1...@olifantasia.com
Website:http://www.olifantasia.com/cms/en

Company:Olifantasia
Address:Zandkamp 95
Postal Code:3828 GE
City:   Hoogland
Country:NETHERLANDS
Chamber of Commerce:32115647
VAT registration nr.:   NL1721.44.681.B01
DUNS number:41-456-6294

Private customers in the EU can request a refund if they are not 
satisfied with ordered standard items and have returned them in pristine 
condition within 14 days of purchase.


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

Re: [Discuss-gnuradio] Upgrade shared library issue

[Nikos Balkanas]

Plz disregard. I had to remake and reinstall gr-baz.
Probably will need to do for several other gr-packages.

BR
Nikos

On Wed, Mar 9, 2016 at 10:25 AM, Nikos Balkanas  wrote:

> Hi,
>
> I just upgraded gnuradio from 3.7.6.1 to 3.7.9.1. Uninstalled old version
> and installed new. When, however, I try to run a flow in companion, I get:
>
> Generating: '/home/nikos/Desktop/top_block.py'
>
> Executing: /usr/bin/python2 -u /home/nikos/Desktop/top_block.py
>
> Traceback (most recent call last):
> File "/home/nikos/Desktop/top_block.py", line 20, in 
> from baz import baudline
>   File "/usr/local/lib/python2.7/dist-packages/baz/__init__.py, line 40,
> in 
> from baz_swig import *
> File "/usr/local/lib/python2.7/dist-packages/baz/baz_swig.py", line 28, in
> 
> _baz_swig = swig_import_helper()
> File "/usr/local/lib/python2.7/dist-packages/baz/baz_swig.py", line 24, in
> swig_import_helper
> _mod = imp.load_module('_baz_swig', fp, pathname, description)
> ImportError: libgnuradio-runtime-3.7.6.1.so.0.0.0: cannot open shared
> object file: No such file or directory
>
> >>> Done (return code 1)
>
> _baz_swig seems to still be depended on the old library,
> libgnuradio-runtime-3.7.6.1.so.0.0.0. That old library doesn't exist on my
> system, nor in ld.so.cache. I have uninstalled and reinstalled gnuradio
> 3.7.9.1 again, to no avail.
> Any advise would be appreciated
>
> TIA
> Nikos
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Upgrade shared library issue

[Nikos Balkanas]

Hi,

I just upgraded gnuradio from 3.7.6.1 to 3.7.9.1. Uninstalled old version
and installed new. When, however, I try to run a flow in companion, I get:

Generating: '/home/nikos/Desktop/top_block.py'

Executing: /usr/bin/python2 -u /home/nikos/Desktop/top_block.py

Traceback (most recent call last):
File "/home/nikos/Desktop/top_block.py", line 20, in 
from baz import baudline
  File "/usr/local/lib/python2.7/dist-packages/baz/__init__.py, line 40, in

from baz_swig import *
File "/usr/local/lib/python2.7/dist-packages/baz/baz_swig.py", line 28, in

_baz_swig = swig_import_helper()
File "/usr/local/lib/python2.7/dist-packages/baz/baz_swig.py", line 24, in
swig_import_helper
_mod = imp.load_module('_baz_swig', fp, pathname, description)
ImportError: libgnuradio-runtime-3.7.6.1.so.0.0.0: cannot open shared
object file: No such file or directory

>>> Done (return code 1)

_baz_swig seems to still be depended on the old library,
libgnuradio-runtime-3.7.6.1.so.0.0.0. That old library doesn't exist on my
system, nor in ld.so.cache. I have uninstalled and reinstalled gnuradio
3.7.9.1 again, to no avail.
Any advise would be appreciated

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