Re: [Discuss-gnuradio] log4cpp library not found

On 03/31/2017 09:13 PM, li...@lazygranch.com wrote: opensuse 42.2 This is the only "missing" thing I can find in the cmake ..: -- Configuring volk support... -- Enabling volk support. -- Override with -DENABLE_VOLK=ON/OFF -- Override with -DENABLE_INTERNAL_VOLK=ON/OFF -- ENABLE_GR_LOG

Re: [Discuss-gnuradio] ASK Modulation

You mean, mapping 1s and 0s to 1s and 0s? :) You can very simply implement an ASK modem with pulse shaping filters and some other blocks. I'm not sure about clock synchronization, though. -- M On 03/31/2017 01:17 PM, Qurat-Ul-Ann Akbar wrote: > Hello, > > Is ASK modulation implemented in

[Discuss-gnuradio] log4cpp library not found

opensuse 42.2 This is the only "missing" thing I can find in the cmake ..: -- Configuring volk support... -- Enabling volk support. -- Override with -DENABLE_VOLK=ON/OFF -- Override with -DENABLE_INTERNAL_VOLK=ON/OFF -- ENABLE_GR_LOG set to ON. -- HAVE_LOG4CPP set to False. --

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

Being all things to everyone is tough. I recently contributed some code to support the openSUSE package manager, zypper, in pybombs. So universal support is kind of an evolving feature. Perhaps it would be a start to simply limit the initial virtualenv support to python2. I would suggest that

[Discuss-gnuradio] ASK Modulation

Hello, Is ASK modulation implemented in gnuradio? I know that BPSK, QPSK and QAM are. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM/GR-IEEE802-11

Understood. Thanks! On Fri, Mar 31, 2017 at 2:32 PM, Marcus Müller wrote: > Depends on where you are. But usually, no. > > On 31.03.2017 19:54, Thomas Wilkinson wrote: > > Legally, I can perform tests within ISM bands. Correct? > > On Fri, Mar 31, 2017 at 1:14 PM,

Re: [Discuss-gnuradio] OFDM/GR-IEEE802-11

Depends on where you are. But usually, no. On 31.03.2017 19:54, Thomas Wilkinson wrote: > Legally, I can perform tests within ISM bands. Correct? > > On Fri, Mar 31, 2017 at 1:14 PM, Martin Braun > wrote: > > You can change the frequency

Re: [Discuss-gnuradio] OFDM/GR-IEEE802-11

Legally, I can perform tests within ISM bands. Correct? On Fri, Mar 31, 2017 at 1:14 PM, Martin Braun wrote: > You can change the frequency technically. Legally, we can't give you > advice here other than to follow the rules. > > Cheers, > Martin > > On 03/30/2017 09:52 AM,

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

On 03/24/2017 12:21 PM, Ben Hilburn wrote: > While this does prove the feasibility of independent front-end and > back-ends, it is still "all-in" on Bokeh in the sense that the server > and integration with GR is built with Bokeh. Again, I'm not saying > that's the wrong decision, but I want to be

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

Please note that there's an open issue on how PyBOMBS and venvs are effectively broken (https://github.com/gnuradio/pybombs/issues/363). There are also related issues regarding the fact that we don't know if we're running Python 2 or 3. So yeah, I know about this, and would love to see it fixed,

[Discuss-gnuradio] [GSoC] Submission deadline is nearly up!

Everyone, the student submission deadline for projects is nearly up. Please make sure to wrap up your conversations on this list, and post a PDF to the GSoC website. Of course, there's still time to discuss proposals until March 3rd, when the submission ends, and I believe you can also update

Re: [Discuss-gnuradio] FG probe generation of thread.start() race conditions (python tutorials)

James, thanks for pointing that out! Can you submit a pull request against the gr-tutorial repository? Thanks, Martin On 03/29/2017 10:22 AM, James Shimer wrote: > Sorry if this is a duplicate/newbie question (didn't find anything > searching). When going thru the python examples. I came

Re: [Discuss-gnuradio] OFDM/GR-IEEE802-11

You can change the frequency technically. Legally, we can't give you advice here other than to follow the rules. Cheers, Martin On 03/30/2017 09:52 AM, Thomas Wilkinson wrote: > > Please forgive me as I am new to SDRs and DSP. > > I am interested in development of a radio link using two B210s

Re: [Discuss-gnuradio] Undocumented custom blocks in GNU Radio

Both these problems probably stem from the same root cause. Try and load the underlying library file in Python (something like "cd build/swig; python -c 'import _channelsounder_swig.py'") and it'll most likely crash. That should clue you into what's going wrong. -- M On 03/30/2017 10:36 PM,

Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code

On 03/31/2017 07:32 AM, Koslowski, Sebastian (CEL) wrote: > Dear Håkon, > > I am very excited to see interest in this topic! A few additional comments: > > - Any new templating should be done using Mako. The new YAML format > Martin mentioned roughly looks like this: The more I think about it,

Re: [Discuss-gnuradio] How to know that the last sample has arrived

Hi Ruben, technically, I like the idea of having the scheduler do things like tagging final packets. That could be a low-overhead operation (happens only once in an application's livetime), and you could hack it into the scheduler relatively easy, but, to be honest, the last thing our scheduler

[Discuss-gnuradio] Dealing with GRC variables and GRC callbacks (was: GNU Radio Companion Extensions: Output C++ Code)

Hi Sebastian, (Håkon, this is half-related to your proposal; there's questions arising from this, but I think I'd like to raise them later, if at all, after Sebastian has enlightened me :) ) you're touching a very delicate subject here: I personally think that GRC variables should have been for

Re: [Discuss-gnuradio] How to know that the last sample has arrived

Thank you both for answering. > I would totally agree with Marcus. Especially you first approach can't > work reliably. It appeared quite stable for file_source, but I got some problems today with one of my custom blocks which suddenly caused the following block to be called with ninput_items[0]

Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code

Dear Håkon, I am very excited to see interest in this topic! A few additional comments: - Any new templating should be done using Mako. The new YAML format Martin mentioned roughly looks like this: """ id: blocks_add_const_vxx label: Add Const parameters: - id: type label: IO Type

Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code

Hi Martin, okay, I see. This is useful information, thanks a lot! Best regards, Håkon Vågsether There's another thing: On 3.8, we'll be going to a different model of > writing GRC bindings (YAML-based). It's difficult to summarize the > changes, but basically, don't assume that we'll be using

Re: [Discuss-gnuradio] [GSoC] GNU Radio Companion Extensions: Output C++ Code

Hi Marcus, thank you for your feedback. > Also, would kind of had preferred to read "I've not used GNU Radio much > before, but I've played around with the LiveDVD (or whatever you'd have > done)" instead of reading "I've not used GNU Radio before(at all)" and > seeing you use pretty dated

Re: [Discuss-gnuradio] File sink question

Hi Ellie, On 31.03.2017 02:52, Ellie White wrote: > Thank you for the quick response. I guess I had been confused and had > set the sampling rate far too high! I think the right sampling rate > should be 2 MHz for the RTL-SDR dongle, based on what I’ve seen online > – does that sound more

Re: [Discuss-gnuradio] How to know that the last sample has arrived

Hey, > I honestly think that way is at least more reliable than the one you > sketched above, but probably still not all that reliable. I would totally agree with Marcus. Especially you first approach can't work reliably. What about using tagged streams or just a tag on the last sample? Is that

Re: [Discuss-gnuradio] How to know that the last sample has arrived

Hi Ruben, > If I consume (ninput_items[0] - 1) samples every time general_work is > called, I will eventually get general_work called with ninput_items[0] > == 1. Would this be a reliable way to do it? Or is there a more > straightforward way which I cannot see? Oh, I *think* that might work, but

[Discuss-gnuradio] How to know that the last sample has arrived

Hi, Is there a good way to find out from inside general_work that the last sample has arrived? (such as from vector_source_X or file_source) If I consume (ninput_items[0] - 1) samples every time general_work is called, I will eventually get general_work called with ninput_items[0] == 1. Would

Re: [Discuss-gnuradio] File sink question

Hello Marcus - Thank you for the quick response. I guess I had been confused and had set the sampling rate far too high! I think the right sampling rate should be 2 MHz for the RTL-SDR dongle, based on what I've seen online - does that sound more appropriate to you? Regarding the rest of my