Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

> > Only reason, I am resistant to the idea of not using the Bokeh server is > that the existing features and scope of the project will be reduced. Since, > all the plots and widgets are necessary in order to make the module usable, > limiting the plots will not be good enough. Although I am open

Re: [Discuss-gnuradio] [GSoC] A DAB/DAB+ transceiver app: Draft of proposal

Hi Ben, thanks a lot for your helpful advice! Most typos should be fixed by now and I am going to add the paragraph breaks. The chapter "Deliverable Features" - you are right - does not clearly separate the deliverables from the existing stuff. I am going to improve that. Thanks again!

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

Hi Usman, so, is there anything wrong? By the way, it's usually not a good idea to build software *on* an embedded device itself; you'd typically try to get your software built on a "proper" PC, because compiling C++ is a very RAM and disk IO intense operation, and takes O(forever) time on a

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

Also, the jessie-backports Debian Repo contains GNU Radio 3.7.10.1 (thanks Maitland!) and that is pretty current, so I don't really see a reason to compile such a massive piece of software on the beaglebone. Best regards, Marcus On 21.03.2017 19:21, Marcus Müller wrote: > > Hi Usman, > > so,

[Discuss-gnuradio] GNU Radio on Beaglebone black

Hi I am currently building GNU Radio 3.7.10.0 on Beaglebone black. When I run cmake I am getting ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] installing a python package without elevated privileges

Personal two cents: On most modern linuxes, you shouldn't be installing mako via pip, and much less even numpy (because that's a huge compile including fortran interfaces). I just go and remove pip from the list of preferred packagers on my systems¹. Never ran into problems with that. Now, I've

Re: [Discuss-gnuradio] [GSoC] A DAB/DAB+ transceiver app: Draft of proposal

Hi Moritz - Nice work! I'm really happy to see this proposal. A few notes: * If you plan on integrating any other software into your work, please specifically call out its license. * As Martin said, it would be good to fix some of the typos. Also, please add a paragraph break (either an indent

Re: [Discuss-gnuradio] [USRP-users] B210 - file transmit using ofdm

Hi Julian, in the future, please try to keep your questions on the mailing lists, so that it's not like only one person can contribute experience. In your case, maybe the discuss-gnuradio mailing list would be interesting, sign up is under [1]. You'll find an archive there that also answers your

Re: [Discuss-gnuradio] installing a python package without elevated privileges

Thank you for your reply. However, I don't want to have anything done manually. Maybe I need rephrasing my initial post: It is not that I want PyBOMBS to to do a pip --user but I am more wondering why it is saying: > PyBOMBS.PackageManager - DEBUG - Using packager pip > PyBOMBS.Packager.pip -

Re: [Discuss-gnuradio] Python/SWIG problems

Awesome! Thanks, Dan! -- M On 03/21/2017 10:25 AM, Daniel P. Martin wrote: > I will volunteer to do that! I've got a deadline this week keeping me > very busy and then a week on vacation, so it may be two weeks before I > get to it. > > Regards, > > Dan > > > On 3/21/17 12:09 PM, Martin

Re: [Discuss-gnuradio] Python/SWIG problems

I will volunteer to do that! I've got a deadline this week keeping me very busy and then a week on vacation, so it may be two weeks before I get to it. Regards, Dan On 3/21/17 12:09 PM, Martin Braun wrote: Dan, would you like to add the info the wiki? Maybe onto the FAQ? -- M On

Re: [Discuss-gnuradio] [USRP-users] Audio Synchronization

Hi Marcus, Yes, we had long discussions and I had discussion with Fons separately as well. I tried to implement his paper http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf on an embedded platform to quickly check the behavior as well, were I can adjust the audio sample rate in hardware.

[Discuss-gnuradio] GNU Radio on Beaglebone black

Hi, I am currently building GNU Radio 3.7.10.1 on Beaglebone black running Debian 8.6. I have disable some components for testing and to speed up the process. After installing the dependencies when I run cmake I am getting following messages. Are these messages okay? Do I have to pass any flags

[Discuss-gnuradio] GPU accelerated Viterbi decoder?

Dera All, In almost all cases the Viterbi decoder block eats a lot of CPU time. The best alternative is a GPU solution. I have searched for an open source GPU implementation but could not find one. There is a MATLAB implementation but that one is far from open source. Any Ideas? Is it easy to

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

Dear Ben and Bastian, Thank you very much for the feedback. @Ben: Thank you for this error. I have not tried to dig deep in this error because it was just a prototype. @Bastian: You got the server architecture correct. I am planning to do exactly same. Coming to queries about using Bokeh:I agree

Re: [Discuss-gnuradio] GPU accelerated Viterbi decoder?

Hi Mehmeto, On 21.03.2017 10:24, Mehmeto wrote: > Dera All, > In almost all cases the Viterbi decoder block eats a lot of CPU time. True, but only for higher rates. But yeah, channel coding is a major CPU load, always. > The > best alternative is a GPU solution. That *is* a bold claim. Note

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

Hi Kartik, thanks for the feedback! so, I took the time and tried to read up a bit on what Bokeh does, how it's partitioned. I'd like to describe this here as shortly as possible, mostly for my own understanding and to foster more discussion with others that can't find the time, and would kindly

[Discuss-gnuradio] examples of use of command ports for usrp sink and source

Hello GR, Are there any grc flowgraphs showing use of looped USRP Source/Sink for examples if in the middle of some flowgraphs I needed to re-tune the Radio. I just saw in the corresponding grc blocks "command" port but I don't know what are they expecting. Regards, Naceur -- View this

Re: [Discuss-gnuradio] installing a python package without elevated privileges

Huh, that seems a bit *too* permissive – other users might thus have modified freely a script that you run as your user! On 21.03.2017 21:39, Naceur wrote: > Thanks. I just circumvented it by getting rid of pip requirement and asking > the recipe to get the deb/rpm requirements instead. > FYI,

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

Hello all, Thank you very much for the discussions and feedbacks. I will try to answer all of them one-by-one. Mail from Marcus: * said server has a REST API, i.e. ispolled from the client only? Or can there be pushing data from server -> client? What is the model you'd prefer? Your

Re: [Discuss-gnuradio] no payload length passed from header data

I have figured it out myself. The length tag key in the Head Payload Demux block must match the key value in the header. In my case, it is "payload symbols". -- View this message in context: http://gnuradio.4.n7.nabble.com/no-payload-length-passed-from-header-data-tp63160p63228.html Sent

Re: [Discuss-gnuradio] installing a python package without elevated privileges

Thanks. I just circumvented it by getting rid of pip requirement and asking the recipe to get the deb/rpm requirements instead. FYI, my /home/nae/.local/bin/pip was already allowed 777. Regards, Naceur -- View this message in context:

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

On Tue, 2017-03-21 at 22:59 +0500, Usman Haider wrote: > Hi, > > I am currently building GNU Radio 3.7.10.1 on Beaglebone black > running Debian 8.6.  I have disable some components for testing and > to speed up the process. After installing the dependencies when I run > cmake I am getting

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

Hello Sylvain, One thing that I find a bit weird in the proposal is to use a new "generate option" webui. For the qt/wx/... that makes more sense because : (1) they're exclusive, you can't be both WX and QT, trying to link multiple graphics framework in the same app is just not practical

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

Oh! Excellent. Never thought about this. So, basically we may want to develop a read-only version of webgui in future. Let me see how can I add the webGui block with QT. If it is not possible during GSoC, I think we can easily extend the current structure to make it read-only and by using a

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

Hi, One thing that I find a bit weird in the proposal is to use a new "generate option" webui. For the qt/wx/... that makes more sense because : (1) they're exclusive, you can't be both WX and QT, trying to link multiple graphics framework in the same app is just not practical (possible).

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

> If we see from the user perspective, why would someone need two displays ? You're assuming it would be the same people ... or at the same time. * I could use QT locally but still expose a web UI for people to remotely see what I'm describing. The local Qt UI could be more complete and just

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

On Wed, Mar 22, 2017 at 2:52 AM, Dennis Glatting wrote: > On Tue, 2017-03-21 at 22:59 +0500, Usman Haider wrote: > > Hi, > > > > I am currently building GNU Radio 3.7.10.1 on Beaglebone black > > running Debian 8.6. I have disable some components for testing and > > to speed

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

On Wed, 2017-03-22 at 09:34 +0500, Usman Haider wrote: > > > On Wed, Mar 22, 2017 at 2:52 AM, Dennis Glatting > wrote: > > On Tue, 2017-03-21 at 22:59 +0500, Usman Haider wrote: > > > Hi, > > > > > > I am currently building GNU Radio 3.7.10.1 on Beaglebone black > > > running

Re: [Discuss-gnuradio] GNU Radio on Beaglebone black

Hi Marcus, I tried to setup a cross-compile environment on a PC but was not able to do so for BBB although I am able to do so for E310, thanks to people@ettus for providing the SDK :). I am still learning how can I do it for BBB. But at the same time I am trying to build GNU Radio, with some

Re: [Discuss-gnuradio] fast parallel filtering

Bah, I messed up my filter designs in that last flowgraph. (Transition BW != Stopband Freq). Never drink beer while designing filters. :) See the attached, fixed flowgraph (v4). -Andy On Mon, Mar 20, 2017 at 9:30 PM, Andy Walls wrote: > Hi Dirk: > > On Mon, Mar 20,

Re: [Discuss-gnuradio] GPU accelerated Viterbi decoder?

What data rates are you working at? I haven't had so much trouble with Viterbi being a limiting factor up to about 1 Mbps QPSK with concatenated coding. Sadly, I have no experience moving this to GPU. On Tue, Mar 21, 2017 at 5:25 AM Mehmeto wrote: > Dera All, > In

Re: [Discuss-gnuradio] installing a python package without elevated privileges

The answer would be virtualenvs, but virtualenvs are not fully supported in PyBOMBS. You might be able to to this by hand, but I've never tried it: - Create a prefix using the --virtualenv switch - Manually pip install the package into the virtualenv - Maybe you need to manually set the package

Re: [Discuss-gnuradio] Python/SWIG problems

Dan, would you like to add the info the wiki? Maybe onto the FAQ? -- M On 03/20/2017 01:46 AM, Daniel P. Martin wrote: > I found the answer to this post in the discuss-gnuradio archive. The > answer was posted by Patrick Sathyanathan: > > [Discuss-gnuradio] OOT Module Attribute Error module

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

Hello, good to see so much feedback to this proposal. This feature is clearly something that we all want to see become reality! I have discussed this idea with Kartik beforehand offline and I am glad to see all of you have the same issues/objections. While bokeh (and plotly) were mentioned in

[Discuss-gnuradio] Want to hire someone to build BPSK/QPSK receiver

I posted this last year, but didn’t really have any takers, so I thought I’d try again and increase the pay. I have a project that requires a gnu radio receiver that can receive, demodulate, and decode BPSK and QPSK data coming from a satellite modem. The modem also has FEC that will need to be