Re: [Discuss-gnuradio] \"make\" error while making detector (howto_detect_ff) block.

[Marcus Müller]

Hi Abhishek,

that guide refers to a somewhat outdated API, so it doesn't apply to
your case (that guide refers to an architecture where there was no
separate _impl class).

Have you read the guided tutorials and their chapter on C++ blocks? It's
explaining how you can add functions to blocks.
I'd personally recommend just starting anew, sticking to the guided
tutorials; wherever you got your guidance from, it mixes things that
apply to different versions of GNU Radio, and debugging this is really
not worth it when you could as well just start with a clean slate and
learn things *right*.

Best regards,
Marcus
On 04/01/2015 06:28 AM, abhishek wrote:
> hey marcus,
> here error given is, could not insert function, but we can according
> to
> "http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide#Public-Header-Files";.
> Even i am not able to get last and second last error of expected "("
> and "{", but in the code all brackets are up to the mark and used
> properly.
>
> abhishek@abhishek-Inspiron-N5110:~/gr-howto/build$ make
> Scanning dependencies of target gnuradio-howto
> [  5%] Building CXX object
> lib/CMakeFiles/gnuradio-howto.dir/howto_detect_ff_impl.cc.o
> In file included from
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:27:0:
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.h:40:7: error:
> ‘gr::howto::howto_detect_ff_impl::howto_detect_ff_impl(float, int,
> int)’ cannot be overloaded
>howto_detect_ff_impl(float pfa, int L, int samples);
>^
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.h:37:6: error: with
> ‘gr::howto::howto_detect_ff_impl::howto_detect_ff_impl(float, int, int)’
>   howto_detect_ff_impl (float pfa, int L, int samples);
>   ^
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:37:27: error:
> prototype for ‘gr::howto::howto_detect_ff::sptr
> gr::howto::howto_detect_ff::make(float, int, int)’ does not match any
> in class ‘gr::howto::howto_detect_ff’
>  howto_detect_ff::sptr howto_detect_ff::make(float pfa, int L, int
> samples)
>^
> In file included from
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.h:24:0,
>  from
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:27:
> /home/abhishek/gr-howto/include/howto/howto_detect_ff.h:49:19: error:
> candidate is: static gr::howto::howto_detect_ff::sptr
> gr::howto::howto_detect_ff::make()
>static sptr make();
>^
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc: In constructor
> ‘gr::howto::howto_detect_ff_impl::howto_detect_ff_impl(float, int, int)’:
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:57:71: warning:
> extended initializer lists only available with -std=c++11 or
> -std=gnu++11 [enabled by default]
>gr::io_signature::make (MIN_OUT, MAX_OUT, sizeof(float)),
> ^
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:66:5: error:
> expected ‘)’ before ‘(’ token
>  (howto_detect_ff_impl()::~howto_detect_ff_impl())
>  ^
> /home/abhishek/gr-howto/lib/howto_detect_ff_impl.cc:187:1: error:
> expected ‘{’ before ‘}’ token
>  }   /* namespace howto */
>  ^
> make[2]: ***
> [lib/CMakeFiles/gnuradio-howto.dir/howto_detect_ff_impl.cc.o] Error 1
> make[1]: *** [lib/CMakeFiles/gnuradio-howto.dir/all] Error 2
> make: *** [all] Error 2
>
> Could you please help me out with all individual errors. Attachment of
> al the 3 files are provided.
> Thanks in advance,
> Abhishek.


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

Re: [Discuss-gnuradio] Error in creating a block

[Marcus Müller]

Hi Vishwanatha,
we already talked about this:
http://lists.gnu.org/archive/html/discuss-gnuradio/2015-03/threads.html#00516
Did something change?
Did my instructions help you or are there still problems you encountered
and could not solve?

Best regards,
Marcus

On 04/01/2015 09:15 AM, Vishwanatha H G wrote:
> Hi..
>I created a block named 'costas'. But it showing the error as in
> screenshot attached. what is the problem with this? thanks for your
> advice.
>
>
> ___
> 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] costas loop for 16 PSK

[Vishwanatha H G]

Hi..
Any one has the control loop code for 16 PSK. Where should I get the code?
thanks
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] "Run to completion" not working with message passing blocks

[Marcus Müller]

Hi  Piotr,

nice to hear you got a step ahead!
so,
> I did that and what I obtained was:
> ---
>   16   Thread 0x7fffbdffb700 (LWP 13462) "python"
> pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
>   3Thread 0x7fffe9720700 (LWP 13449) "gsm_clock_offs1"
> pthread_cond_timedwait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
> * 1Thread 0x77fc7740 (LWP 13444) "python" 0x778e8da3 in
> select () at ../sysdeps/unix/syscall-template.S:81
> ---

I'd have a blind guess:
Thread 16 might be the "surviving" part of a python-spawned Timer()
thread, which caused a message _post at another thread, which might be
something that hangs if that block's thread no longer exists.

Can you switch to that thread:
thread 16
and then try to get a python backtrace [1]
py-bt
and maybe a simple C-style backtrace
bt

that might give you some information what is actually waiting on a
condition (which is what I guess from "pthread_cond_wait").

Greetings,
Marcus

[1] for this to work, you might need to follow these instructions from
http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB:

... make sure that the python development package is installed
(|python-devel| on Redhatoids, |python2.7-dev| on Debianoids); for some
systems, you should append the content of
|/usr/share/doc/{python-devel,python2.7-dev}/gdbinit[.gz]| to your
|~/.gdbinit|, and re-start |gdb|.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error in creating a block

[Marcus Müller]

Vishwanatha,

the error tells you about the problem. I'll have to rely on your ability
to interpret that error. You might find things that you don't
understand, and it's fine if you then write an email with a sufficient
description of the problem you're having. For now, you only give us a
screenshot and hope that we somehow gained telepathic abilities -- this
won't work; I'll have to ask you to read
http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors#Checklist-Asking-a-question-on-the-mailing-list
and follow the instructions there closely.

A very important line here is
"...Use your judgment of how much code to include; ", because that might
help us here (and more importantly, it might help you pin down the error
first yourself).

Best regards,
Marcus

On 04/01/2015 01:35 PM, Vishwanatha H G wrote:
> Yes it was and I succeeded in that.  But now I'm getting another
> threat as in screenshot attached. thanks
>
> On Wed, Apr 1, 2015 at 1:48 PM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> Hi Vishwanatha,
> we already talked about this:
> 
> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-03/threads.html#00516
> Did something change?
> Did my instructions help you or are there still problems you
> encountered and could not solve?
>
> Best regards,
> Marcus
>
> On 04/01/2015 09:15 AM, Vishwanatha H G wrote:
>> Hi..
>>I created a block named 'costas'. But it showing the error as
>> in screenshot attached. what is the problem with this? thanks for
>> your advice.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Discuss-gnuradio] Top-block does not find Probe Signal block

[Alejandro Pascual Laguna]

Hello GNUR's!

I am currently working with a SDR dongle which I want to lock at four different 
frequencies to see four consecutive parts of the spectrum. I have to do so 
because the sampling rate is not enough (2.4 MHz) to see at one glance the 
bandwidth I need (8 MHz). To achieve so I am multiplexing the values I want to 
lock my dongle to but I am getting some errors using the pair of blocks "Probe 
Signal" and "Function Probe" (see the flowgraph in [1] and errors trace [2]). 
By enabling/disabling some blocks I have guessed that the error about the 
overflow is caused by the WX GUI Number Sink, while the error of the 
non-existing attribute appears when I make use of the "variable" defined by the 
block Function Probe.

Of course I have followed the tutorial [3] and still couldn't make it to work.
Thank you very much in advance.

Greetings,
Alejandro

[1] http://imagizer.imageshack.us/a/img673/6338/mw0don.png
[2] http://pastebin.com/Kmxyw250
[3] 
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GRC/61#241-Examining-the-Probe-Signal-Block
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Simulating MIMO-OFDM systems

[Debarshi Sanyal]

Hi,

I am interested in simulating various algorithms for signal processing in
MIMO-OFDM based software-defined radios and cognitive radios.

In this context, I am curious to know if such simulations are possible with
GNU Radio?
For example, I would like to have a set of users with MIMO channels between
them. I want to find out the data rates at the receiver for various
settings of the MIMO-OFDM parameters.
If GNU Radio is not the right tool, can you please suggest if any other
such tool (not MATLAB type) is available?

Thank you for your time.


Regards,
Debarshi Kumar Sanyal
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simulating MIMO-OFDM systems

[Marcus Müller]

Hi Debarshi,

well, there's WiNeLo (Wireless Networks in the loop), which you can
attach multiple "virtual" SDR frontends to, and which uses GNU Radio to
model the channel and the SDRs.
https://github.com/no-net/gr-winelo
http://www.cel.kit.edu/download/OtterbachBraunJondral_ISWCS.pdf
Note: back when the paper was written, the channel simulation server was
based on a "simple" matrix; AFAIK I know it's using fully-fledged GNU
Radio by now.

Greetings,
Marcus

On 04/01/2015 03:21 PM, Debarshi Sanyal wrote:
> Hi,
>
> I am interested in simulating various algorithms for signal processing
> in MIMO-OFDM based software-defined radios and cognitive radios.
>
> In this context, I am curious to know if such simulations are possible
> with GNU Radio?
> For example, I would like to have a set of users with MIMO channels
> between them. I want to find out the data rates at the receiver for
> various settings of the MIMO-OFDM parameters.
> If GNU Radio is not the right tool, can you please suggest if any
> other such tool (not MATLAB type) is available?
>
> Thank you for your time.
>
>
> Regards,
> Debarshi Kumar Sanyal
>
>
> ___
> 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] Empty volk directory when I git gnuradio

[Chris "Gump" Graves]

Looks like some kind of link or something is broken when you try to GIT
gnuradio.  The build fails as volk will not build, and the volk sub-
directory is empty.  I did successfully GIT volk directly and clone it
to it's sub-directory in gnuradio, and the build then went fine.

Just throwing that out there so someone can try to fix it or get it fixed.

BT/AR
Chris "Gump" Graves


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

Re: [Discuss-gnuradio] Empty volk directory when I git gnuradio

[Sylvain Munaut]

git clone --recursive

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

[Discuss-gnuradio] How to increase the noutput_items

[Zhe Feng]

Dear all, 

I'm experiencing a problem with the noutput_items. 

I have written a sync block which did "return" several times. I found the
noutput_items dropped exactly by the amount that I returned. For example, if
I wrote "return 10", after that, I printed noutput_items and found it
decreased to noutput_items -10.

Due to this fashion, the noutput_items could decrease to a value that one of
my "if statement" isn't satisfied. In that case, several items wouldn't be
outputed so the actual size of output items is smaller than the size of
input items. Is it still a sync block?

I tried to wait for the noutput_items to increase but it didn't happen. I
tried to use "set_noutput_items( )" or "set_output_buffer()" to some values
I wanted, but they also failed. 

So I'm asking that how to tell the scheduler effectively that I want to
increase the noutput_items?

Thanks!
Best regards,
Zhe



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/How-to-increase-the-noutput-items-tp53075.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] How to increase the noutput_items

[Marcus Müller]

Hi,
noutput_items is what GNU Radio can maximally allow your block to
produce, which is the free size in the output buffer, which is the input
buffer of the next block.
So if your block is faster than the downstream block, you will see
exactly the behaviour you are observing. This is normal, and good.

There's nothing the scheduler can do about this -- something
"downstream" of your block just "backs up" the item flow, and your block
will have to wait until whatever is downstream of it is done consuming
input, so that there is space for output from your block again.

You could try using set_min_noutput_items [1] in your block's
constructor, so that GNU Radio won't even ask you to work() if there's
not enough space available.

Greetings,
Marcus


[1]
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a65cfc579150dc4d10c6180d3365aa9a8

On 04/01/2015 04:47 PM, Zhe Feng wrote:
> Dear all, 
>
> I'm experiencing a problem with the noutput_items. 
>
> I have written a sync block which did "return" several times. I found the
> noutput_items dropped exactly by the amount that I returned. For example, if
> I wrote "return 10", after that, I printed noutput_items and found it
> decreased to noutput_items -10.
>
> Due to this fashion, the noutput_items could decrease to a value that one of
> my "if statement" isn't satisfied. In that case, several items wouldn't be
> outputed so the actual size of output items is smaller than the size of
> input items. Is it still a sync block?
>
> I tried to wait for the noutput_items to increase but it didn't happen. I
> tried to use "set_noutput_items( )" or "set_output_buffer()" to some values
> I wanted, but they also failed. 
>
> So I'm asking that how to tell the scheduler effectively that I want to
> increase the noutput_items?
>
> Thanks!
> Best regards,
> Zhe
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/How-to-increase-the-noutput-items-tp53075.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> 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] Empty volk directory when I git gnuradio

[Marcus D. Leech]

On 04/01/2015 10:20 AM, Sylvain Munaut wrote:

git clone --recursive

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
When did the change actually occur?  I knew it was coming, but was 
waiting to update build-gnuradio to take this into account.



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

Re: [Discuss-gnuradio] Empty volk directory when I git gnuradio

[Johnathan Corgan]

This happened on Sunday.  The --recursive flag could have been added at any
point in anticipation of it.

On Wed, Apr 1, 2015 at 8:24 AM, Marcus D. Leech  wrote:

> On 04/01/2015 10:20 AM, Sylvain Munaut wrote:
>
>> git clone --recursive
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> When did the change actually occur?  I knew it was coming, but was waiting
> to update build-gnuradio to take this into account.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Empty volk directory when I git gnuradio

[Marcus D. Leech]

On 04/01/2015 11:26 AM, Johnathan Corgan wrote:
This happened on Sunday.  The --recursive flag could have been added 
at any point in anticipation of it.


Well, spank me.  I'd had it in my fuzzy little brain that I'd have to 
wait.  Ah well, just testing an update to build-gnuradio now.



On Wed, Apr 1, 2015 at 8:24 AM, Marcus D. Leech > wrote:


On 04/01/2015 10:20 AM, Sylvain Munaut wrote:

git clone --recursive

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

When did the change actually occur?  I knew it was coming, but was
waiting to update build-gnuradio to take this into account.


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




--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com


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

Re: [Discuss-gnuradio] How to increase the noutput_items

[Zhe Feng]

Dear Marcus,

Thanks for your comment!
I made a typo my previous post that I was going to say
"set_min_noutput_items" but I wrote "set_noutput_items". I actually used it
in the work function, but it didn't seem to function as I expected. After
reading your comment, I put it in the constructor and nothing changed.

Best regards,
Zhe

On Wed, Apr 1, 2015 at 11:18 AM, Marcus Müller 
wrote:

> Hi,
> noutput_items is what GNU Radio can maximally allow your block to
> produce, which is the free size in the output buffer, which is the input
> buffer of the next block.
> So if your block is faster than the downstream block, you will see
> exactly the behaviour you are observing. This is normal, and good.
>
> There's nothing the scheduler can do about this -- something
> "downstream" of your block just "backs up" the item flow, and your block
> will have to wait until whatever is downstream of it is done consuming
> input, so that there is space for output from your block again.
>
> You could try using set_min_noutput_items [1] in your block's
> constructor, so that GNU Radio won't even ask you to work() if there's
> not enough space available.
>
> Greetings,
> Marcus
>
>
> [1]
>
> http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a65cfc579150dc4d10c6180d3365aa9a8
>
> On 04/01/2015 04:47 PM, Zhe Feng wrote:
> > Dear all,
> >
> > I'm experiencing a problem with the noutput_items.
> >
> > I have written a sync block which did "return" several times. I found the
> > noutput_items dropped exactly by the amount that I returned. For
> example, if
> > I wrote "return 10", after that, I printed noutput_items and found it
> > decreased to noutput_items -10.
> >
> > Due to this fashion, the noutput_items could decrease to a value that
> one of
> > my "if statement" isn't satisfied. In that case, several items wouldn't
> be
> > outputed so the actual size of output items is smaller than the size of
> > input items. Is it still a sync block?
> >
> > I tried to wait for the noutput_items to increase but it didn't happen. I
> > tried to use "set_noutput_items( )" or "set_output_buffer()" to some
> values
> > I wanted, but they also failed.
> >
> > So I'm asking that how to tell the scheduler effectively that I want to
> > increase the noutput_items?
> >
> > Thanks!
> > Best regards,
> > Zhe
> >
> >
> >
> > --
> > View this message in context:
> http://gnuradio.4.n7.nabble.com/How-to-increase-the-noutput-items-tp53075.html
> > Sent from the GnuRadio mailing list archive at Nabble.com.
> >
> > ___
> > 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
>



-- 
Zhe Feng
Electrical Engineering: System
University of Michigan Ann Arbor
Tel: 734-834-3188
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simulating MIMO-OFDM systems

[Richard Bell]

Debarshi,

To be clear, since it sounds like you're new to GNU Radio, yes you can
implement MIMO-OFDM and it has been done by many people. There are papers
online that you can find detailing the journey, search for 'MIMO-OFDM with
GNU Radio' or something similar. The details of this will be up to you to
implement (for example the "users" you speak of and the logistics behind
that).

v/r,
Rich

On Wed, Apr 1, 2015 at 6:29 AM, Marcus Müller 
wrote:

>  Hi Debarshi,
>
> well, there's WiNeLo (Wireless Networks in the loop), which you can attach
> multiple "virtual" SDR frontends to, and which uses GNU Radio to model the
> channel and the SDRs.
> https://github.com/no-net/gr-winelo
> http://www.cel.kit.edu/download/OtterbachBraunJondral_ISWCS.pdf
> Note: back when the paper was written, the channel simulation server was
> based on a "simple" matrix; AFAIK I know it's using fully-fledged GNU Radio
> by now.
>
> Greetings,
> Marcus
>
>
> On 04/01/2015 03:21 PM, Debarshi Sanyal wrote:
>
>   Hi,
>
>  I am interested in simulating various algorithms for signal processing in
> MIMO-OFDM based software-defined radios and cognitive radios.
>
> In this context, I am curious to know if such simulations are possible
> with GNU Radio?
>  For example, I would like to have a set of users with MIMO channels
> between them. I want to find out the data rates at the receiver for various
> settings of the MIMO-OFDM parameters.
>  If GNU Radio is not the right tool, can you please suggest if any other
> such tool (not MATLAB type) is available?
>
>  Thank you for your time.
>
>
>  Regards,
> Debarshi Kumar Sanyal
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to increase the noutput_items

[Richard Bell]

Zhe,

Can you explain again why you require a min size for noutput_items? It
sounds like there might still be a misunderstanding as to what this
variable is used for. Why does your block care about the value of
noutput_items?

v/r,
Rich

On Wed, Apr 1, 2015 at 8:34 AM, Zhe Feng  wrote:

> Dear Marcus,
>
> Thanks for your comment!
> I made a typo my previous post that I was going to say
> "set_min_noutput_items" but I wrote "set_noutput_items". I actually used it
> in the work function, but it didn't seem to function as I expected. After
> reading your comment, I put it in the constructor and nothing changed.
>
> Best regards,
> Zhe
>
> On Wed, Apr 1, 2015 at 11:18 AM, Marcus Müller 
> wrote:
>
>> Hi,
>> noutput_items is what GNU Radio can maximally allow your block to
>> produce, which is the free size in the output buffer, which is the input
>> buffer of the next block.
>> So if your block is faster than the downstream block, you will see
>> exactly the behaviour you are observing. This is normal, and good.
>>
>> There's nothing the scheduler can do about this -- something
>> "downstream" of your block just "backs up" the item flow, and your block
>> will have to wait until whatever is downstream of it is done consuming
>> input, so that there is space for output from your block again.
>>
>> You could try using set_min_noutput_items [1] in your block's
>> constructor, so that GNU Radio won't even ask you to work() if there's
>> not enough space available.
>>
>> Greetings,
>> Marcus
>>
>>
>> [1]
>>
>> http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a65cfc579150dc4d10c6180d3365aa9a8
>>
>> On 04/01/2015 04:47 PM, Zhe Feng wrote:
>> > Dear all,
>> >
>> > I'm experiencing a problem with the noutput_items.
>> >
>> > I have written a sync block which did "return" several times. I found
>> the
>> > noutput_items dropped exactly by the amount that I returned. For
>> example, if
>> > I wrote "return 10", after that, I printed noutput_items and found it
>> > decreased to noutput_items -10.
>> >
>> > Due to this fashion, the noutput_items could decrease to a value that
>> one of
>> > my "if statement" isn't satisfied. In that case, several items wouldn't
>> be
>> > outputed so the actual size of output items is smaller than the size of
>> > input items. Is it still a sync block?
>> >
>> > I tried to wait for the noutput_items to increase but it didn't happen.
>> I
>> > tried to use "set_noutput_items( )" or "set_output_buffer()" to some
>> values
>> > I wanted, but they also failed.
>> >
>> > So I'm asking that how to tell the scheduler effectively that I want to
>> > increase the noutput_items?
>> >
>> > Thanks!
>> > Best regards,
>> > Zhe
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://gnuradio.4.n7.nabble.com/How-to-increase-the-noutput-items-tp53075.html
>> > Sent from the GnuRadio mailing list archive at Nabble.com.
>> >
>> > ___
>> > 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
>>
>
>
>
> --
> Zhe Feng
> Electrical Engineering: System
> University of Michigan Ann Arbor
> Tel: 734-834-3188
>
>
>
> ___
> 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] build failing in gr-dtv due to VOLK issues

[Marcus D. Leech]

I've attached the log from the make.

This is on Fedora 18, on a x64 platform.

The repo was cloned fresh just before the build, and I used  the "maint" 
branch.



[  5%] Built target volk
[  5%] Built target test_all
[  5%] Built target volk-config-info
[  5%] Built target volk_profile
[  5%] Built target pygen_python_volk_modtool_398fc
[  5%] Built target pygen_python_volk_modtool_a44b3
[  5%] Built target doxygen_target
[  5%] Built target pmt_generated
[  6%] Built target gnuradio-pmt
[ 10%] Built target gnuradio-runtime
[ 10%] Built target test-gnuradio-runtime
[ 10%] Built target gr_runtime_test
[ 11%] Built target test-gnuradio-pmt
[ 11%] Built target gr_pmt_test
[ 11%] Built target gnuradio-config-info
[ 11%] Built target _pmt_swig_doc_tag
[ 11%] Built target pmt_swig_swig_doc
[ 11%] Built target _pmt_swig_swig_tag
[ 11%] Built target pmt_swig_gnuradio_runtime_swig_7dd5e
[ 11%] Built target _pmt_swig
[ 11%] Built target pmt_swig
[ 11%] Built target _runtime_swig_doc_tag
[ 11%] Built target runtime_swig_swig_doc
[ 11%] Built target _runtime_swig_swig_tag
[ 11%] Built target runtime_swig_gnuradio_runtime_swig_7dd5e
[ 11%] Built target _runtime_swig
[ 11%] Built target pygen_gnuradio_runtime_swig_6f44f
[ 11%] Built target pygen_gnuradio_runtime_swig_e3688
[ 11%] Built target pygen_gnuradio_runtime_python_gnuradio_b4025
[ 12%] Built target pygen_gnuradio_runtime_python_gnuradio_gr_6c300
[ 12%] Built target pygen_gnuradio_runtime_python_gnuradio_gru_2625c
[ 12%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_0b393
[ 12%] Built target pygen_gnuradio_runtime_python_pmt_6c041
[ 13%] Built target pygen_gnuradio_runtime_examples_mp_sched_9085b
[ 13%] Built target pygen_gnuradio_runtime_examples_network_24811
[ 13%] Built target pygen_gnuradio_runtime_examples_volk_benchmark_8a7ea
[ 15%] Built target blocks_generated_includes
[ 33%] Built target gnuradio-blocks
[ 34%] Built target test-gr-blocks
[ 34%] Built target pygen_gr_blocks_python_blocks_62ff3
[ 34%] Built target _blocks_swig0_doc_tag
[ 34%] Built target blocks_swig0_swig_doc
[ 34%] Built target _blocks_swig0_swig_tag
[ 35%] Built target blocks_swig0_gr_blocks_swig_a6e57
[ 35%] Built target _blocks_swig0
[ 35%] Built target _blocks_swig1_doc_tag
[ 35%] Built target blocks_swig1_swig_doc
[ 35%] Built target _blocks_swig1_swig_tag
[ 35%] Built target blocks_swig1_gr_blocks_swig_a6e57
[ 35%] Built target _blocks_swig1
[ 36%] Built target _blocks_swig2_doc_tag
[ 36%] Built target blocks_swig2_swig_doc
[ 36%] Built target _blocks_swig2_swig_tag
[ 36%] Built target blocks_swig2_gr_blocks_swig_a6e57
[ 36%] Built target _blocks_swig2
[ 36%] Built target _blocks_swig3_doc_tag
[ 36%] Built target blocks_swig3_swig_doc
[ 36%] Built target _blocks_swig3_swig_tag
[ 36%] Built target blocks_swig3_gr_blocks_swig_a6e57
[ 36%] Built target _blocks_swig3
[ 36%] Built target _blocks_swig4_doc_tag
[ 37%] Built target blocks_swig4_swig_doc
[ 37%] Built target _blocks_swig4_swig_tag
[ 37%] Built target blocks_swig4_gr_blocks_swig_a6e57
[ 37%] Built target _blocks_swig4
[ 37%] Built target _blocks_swig5_doc_tag
[ 37%] Built target blocks_swig5_swig_doc
[ 37%] Built target _blocks_swig5_swig_tag
[ 37%] Built target blocks_swig5_gr_blocks_swig_a6e57
[ 37%] Built target _blocks_swig5
[ 37%] Built target pygen_gr_blocks_swig_2c55b
[ 37%] Built target pygen_gr_blocks_swig_56284
[ 37%] Built target pygen_gr_blocks_swig_5f125
[ 37%] Built target pygen_gr_blocks_swig_7852f
[ 38%] Built target pygen_gr_blocks_swig_789db
[ 38%] Built target pygen_gr_blocks_swig_d377d
[ 38%] Built target pygen_gr_blocks_swig_e9813
[ 38%] Built target pygen_gr_blocks_examples_tags_4a7fd
[ 38%] Built target pygen_gr_blocks_examples_ctrlport_bd225
[ 38%] Built target pygen_grc_e6370
[ 38%] Built target pygen_grc_base_ab781
[ 38%] Built target pygen_grc_grc_gnuradio_601e2
[ 38%] Built target pygen_grc_grc_gnuradio_e2630
[ 38%] Built target pygen_grc_gui_b7252
[ 39%] Built target pygen_grc_python_2a665
[ 39%] Built target pygen_grc_scripts_8f742
[ 41%] Built target gnuradio-fec
[ 41%] Built target gr_fec_rstest
[ 41%] Built target _fec_swig_doc_tag
[ 41%] Built target fec_swig_swig_doc
[ 41%] Built target _fec_swig_swig_tag
[ 41%] Built target fec_swig_gr_fec_swig_95135
[ 41%] Built target _fec_swig
[ 42%] Built target pygen_gr_fec_swig_367e3
[ 42%] Built target pygen_gr_fec_python_fec_5d022
[ 42%] Built target gnuradio-fft
[ 42%] Built target _fft_swig_doc_tag
[ 43%] Built target fft_swig_swig_doc
[ 43%] Built target _fft_swig_swig_tag
[ 43%] Built target fft_swig_gr_fft_swig_7c2a8
[ 43%] Built target _fft_swig
[ 43%] Built target pygen_gr_fft_swig_088ce
[ 43%] Built target pygen_gr_fft_python_fft_2d91f
[ 43%] Built target filter_generated_includes
[ 48%] Built target gnuradio-filter
[ 48%] Built target test-gr-filter
[ 48%] Built target _gr_filter_swig_doc_tag
[ 48%] Built target filter_swig_swig_doc
[ 48%] Built target _filter_swig_swig_tag
[ 48%] Built target filter_swig_gr_filter_swig_2

[Discuss-gnuradio] How to define a minimum number of input samples for a block.

[Daniel Mazzer]

Hi,

I'm developing a block that need a minimum number of input samples to
process, for example, the block must have at least 1000 samples.

In the work() function may I compare if the ninput_items[] is greater than
1000 and if not I return zero?
Should I need to create an internal buffer (history) to cumulate samples if
the number of samples provided was less that 1000, and the work() will
return 0?
There is any other way to configure the block to work with a minimum number
of samples?

Thank you.

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

Re: [Discuss-gnuradio] How to define a minimum number of input samples for a block.

[Martin Braun]

http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a65cfc579150dc4d10c6180d3365aa9a8

M

On 01.04.2015 10:04, Daniel Mazzer wrote:

Hi,

I'm developing a block that need a minimum number of input samples to
process, for example, the block must have at least 1000 samples.

In the work() function may I compare if the ninput_items[] is greater
than 1000 and if not I return zero?
Should I need to create an internal buffer (history) to cumulate samples
if the number of samples provided was less that 1000, and the work()
will return 0?
There is any other way to configure the block to work with a minimum
number of samples?

Thank you.

Daniel


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




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

Re: [Discuss-gnuradio] How to increase the noutput_items

[Martin Braun]

I don't know the details off the top of my head, but this might be one 
of those functions that you can't call during work(). Have you tried 
calling it in the ctor?


M

On 01.04.2015 08:34, Zhe Feng wrote:

Dear Marcus,

Thanks for your comment!
I made a typo my previous post that I was going to say
"set_min_noutput_items" but I wrote "set_noutput_items". I actually used
it in the work function, but it didn't seem to function as I expected.
After reading your comment, I put it in the constructor and nothing
changed.

Best regards,
Zhe

On Wed, Apr 1, 2015 at 11:18 AM, Marcus Müller mailto:marcus.muel...@ettus.com>> wrote:

Hi,
noutput_items is what GNU Radio can maximally allow your block to
produce, which is the free size in the output buffer, which is the input
buffer of the next block.
So if your block is faster than the downstream block, you will see
exactly the behaviour you are observing. This is normal, and good.

There's nothing the scheduler can do about this -- something
"downstream" of your block just "backs up" the item flow, and your block
will have to wait until whatever is downstream of it is done consuming
input, so that there is space for output from your block again.

You could try using set_min_noutput_items [1] in your block's
constructor, so that GNU Radio won't even ask you to work() if there's
not enough space available.

Greetings,
Marcus


[1]

http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a65cfc579150dc4d10c6180d3365aa9a8

On 04/01/2015 04:47 PM, Zhe Feng wrote:
 > Dear all,
 >
 > I'm experiencing a problem with the noutput_items.
 >
 > I have written a sync block which did "return" several times. I
found the
 > noutput_items dropped exactly by the amount that I returned. For
example, if
 > I wrote "return 10", after that, I printed noutput_items and found it
 > decreased to noutput_items -10.
 >
 > Due to this fashion, the noutput_items could decrease to a value
that one of
 > my "if statement" isn't satisfied. In that case, several items
wouldn't be
 > outputed so the actual size of output items is smaller than the
size of
 > input items. Is it still a sync block?
 >
 > I tried to wait for the noutput_items to increase but it didn't
happen. I
 > tried to use "set_noutput_items( )" or "set_output_buffer()" to
some values
 > I wanted, but they also failed.
 >
 > So I'm asking that how to tell the scheduler effectively that I
want to
 > increase the noutput_items?
 >
 > Thanks!
 > Best regards,
 > Zhe
 >
 >
 >
 > --
 > View this message in context:

http://gnuradio.4.n7.nabble.com/How-to-increase-the-noutput-items-tp53075.html
 > Sent from the GnuRadio mailing list archive at Nabble.com.
 >
 > ___
 > 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




--
Zhe Feng
Electrical Engineering: System
University of Michigan Ann Arbor
Tel: 734-834-3188




___
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] Simulating MIMO-OFDM systems

[Martin Braun]

The advantage will also be that you can use the exact same code for 
measurements. A lot of 'pure simuation' codes disregard too many 
real-world phenomena and only use AWGN as distortion, but lack the means 
to test over real channels.


As someone who spent a lot of time in academia, writing mixed 
simulation/measurement suites among other things, I'd like to encourage 
you to try this path of using GNU Radio.


Cheers,
M

On 01.04.2015 08:36, Richard Bell wrote:

Debarshi,

To be clear, since it sounds like you're new to GNU Radio, yes you can
implement MIMO-OFDM and it has been done by many people. There are
papers online that you can find detailing the journey, search for
'MIMO-OFDM with GNU Radio' or something similar. The details of this
will be up to you to implement (for example the "users" you speak of and
the logistics behind that).

v/r,
Rich

On Wed, Apr 1, 2015 at 6:29 AM, Marcus Müller mailto:marcus.muel...@ettus.com>> wrote:

Hi Debarshi,

well, there's WiNeLo (Wireless Networks in the loop), which you can
attach multiple "virtual" SDR frontends to, and which uses GNU Radio
to model the channel and the SDRs.
https://github.com/no-net/gr-winelo
http://www.cel.kit.edu/download/OtterbachBraunJondral_ISWCS.pdf
Note: back when the paper was written, the channel simulation server
was based on a "simple" matrix; AFAIK I know it's using
fully-fledged GNU Radio by now.

Greetings,
Marcus


On 04/01/2015 03:21 PM, Debarshi Sanyal wrote:

Hi,

I am interested in simulating various algorithms for signal
processing in MIMO-OFDM based software-defined radios and
cognitive radios.

In this context, I am curious to know if such simulations are
possible with GNU Radio?
For example, I would like to have a set of users with MIMO
channels between them. I want to find out the data rates at the
receiver for various settings of the MIMO-OFDM parameters.
If GNU Radio is not the right tool, can you please suggest if any
other such tool (not MATLAB type) is available?

Thank you for your time.


Regards,
Debarshi Kumar Sanyal


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



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




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




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

Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

[Martin Braun]

On 31.03.2015 14:25, Anderson, Douglas J. wrote:

Marcus,

That makes sense, I hadn't thought of the DSP tuning issue, though I
think it would be infinitely more useful to make the stream tagging
logic aware of LO/DSP tuning and tag the first usable block in either
case. Slightly more involved than I assumed though.


That is correct. It depends on pretty much everything, at the very least 
which exact device + d'board combo you're using.


Cheers,
M


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

Re: [Discuss-gnuradio] How to increase the noutput_items

[Zhe Feng]

Dear Martin,

I tried to call it in the constructor, and it's the same as call it in the
work function. It didn't work as I expected.

I was actually trying to update and adding more features to peak_detector2.
There is a conditional statement below in my work function.

if( noutput_items >= d_look_ahead)

I tried to use set_min_noutput_items (d_look_ahead) in the constructor and
in the work function. Neither of these two ways helped me satisfy the above
condition.


Best regards,
Zhe


On Wed, Apr 1, 2015 at 1:22 PM, Martin Braun  wrote:

> I don't know the details off the top of my head, but this might be one of
> those functions that you can't call during work(). Have you tried calling
> it in the ctor?
>
> M
>
> On 01.04.2015 08:34, Zhe Feng wrote:
>
>> Dear Marcus,
>>
>> Thanks for your comment!
>> I made a typo my previous post that I was going to say
>> "set_min_noutput_items" but I wrote "set_noutput_items". I actually used
>> it in the work function, but it didn't seem to function as I expected.
>> After reading your comment, I put it in the constructor and nothing
>> changed.
>>
>> Best regards,
>> Zhe
>>
>> On Wed, Apr 1, 2015 at 11:18 AM, Marcus Müller > > wrote:
>>
>> Hi,
>> noutput_items is what GNU Radio can maximally allow your block to
>> produce, which is the free size in the output buffer, which is the
>> input
>> buffer of the next block.
>> So if your block is faster than the downstream block, you will see
>> exactly the behaviour you are observing. This is normal, and good.
>>
>> There's nothing the scheduler can do about this -- something
>> "downstream" of your block just "backs up" the item flow, and your
>> block
>> will have to wait until whatever is downstream of it is done consuming
>> input, so that there is space for output from your block again.
>>
>> You could try using set_min_noutput_items [1] in your block's
>> constructor, so that GNU Radio won't even ask you to work() if there's
>> not enough space available.
>>
>> Greetings,
>> Marcus
>>
>>
>> [1]
>> http://gnuradio.org/doc/doxygen/classgr_1_1block.html#
>> a65cfc579150dc4d10c6180d3365aa9a8
>>
>> On 04/01/2015 04:47 PM, Zhe Feng wrote:
>>  > Dear all,
>>  >
>>  > I'm experiencing a problem with the noutput_items.
>>  >
>>  > I have written a sync block which did "return" several times. I
>> found the
>>  > noutput_items dropped exactly by the amount that I returned. For
>> example, if
>>  > I wrote "return 10", after that, I printed noutput_items and found
>> it
>>  > decreased to noutput_items -10.
>>  >
>>  > Due to this fashion, the noutput_items could decrease to a value
>> that one of
>>  > my "if statement" isn't satisfied. In that case, several items
>> wouldn't be
>>  > outputed so the actual size of output items is smaller than the
>> size of
>>  > input items. Is it still a sync block?
>>  >
>>  > I tried to wait for the noutput_items to increase but it didn't
>> happen. I
>>  > tried to use "set_noutput_items( )" or "set_output_buffer()" to
>> some values
>>  > I wanted, but they also failed.
>>  >
>>  > So I'm asking that how to tell the scheduler effectively that I
>> want to
>>  > increase the noutput_items?
>>  >
>>  > Thanks!
>>  > Best regards,
>>  > Zhe
>>  >
>>  >
>>  >
>>  > --
>>  > View this message in context:
>> http://gnuradio.4.n7.nabble.com/How-to-increase-the-
>> noutput-items-tp53075.html
>>  > Sent from the GnuRadio mailing list archive at Nabble.com.
>>  >
>>  > ___
>>  > 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
>>
>>
>>
>>
>> --
>> Zhe Feng
>> Electrical Engineering: System
>> University of Michigan Ann Arbor
>> Tel: 734-834-3188
>>
>>
>>
>>
>> ___
>> 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
>



-- 
Zhe Feng
Electrical Engineering: System
University of Michigan Ann Arbor
Tel: 734-834-3188
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

[Anderson, Douglas J.]

Martin,

I think we could have the same effect with a much simpler solution:

What about adding an lo_locked metadata tag to the stream of samples?

You could send lo_locked value=False on the last sample before LO unlocks, and 
lo_locked value=True for first sample after LO locks. That should be (?) simple 
to implement and would be equally as useful.

Otherwise, determining the first usable sample, as you said, "depends on pretty 
much everything", and that's a lot to push down on the end user.

-Doug


From: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org 
[discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of 
Martin Braun [martin.br...@ettus.com]
Sent: Wednesday, April 01, 2015 11:30 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

On 31.03.2015 14:25, Anderson, Douglas J. wrote:
> Marcus,
>
> That makes sense, I hadn't thought of the DSP tuning issue, though I
> think it would be infinitely more useful to make the stream tagging
> logic aware of LO/DSP tuning and tag the first usable block in either
> case. Slightly more involved than I assumed though.

That is correct. It depends on pretty much everything, at the very least
which exact device + d'board combo you're using.

Cheers,
M


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

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

Re: [Discuss-gnuradio] How to increase the noutput_items

[Zhe Feng]

Dear Richard,

I was trying to update and adding more features to the peak_detector2.
There is a sliding look_ahead parameter described in peak_detector, but
it's not actually implemented. There is a fixed look_ahead parameter coded
in peak_detector2, but there is a litte bug. So I was trying to combine
these two types of look_ahead windows in my new peak_detector2 block.

In my design, I have to guarantee the noutput_items is greater than the
d_look_ahead, otherwise, it might cause some unexpected problems. That's
why I used a conditional statement to make sure I only enable the peak
finding process when I have enough noutput_items.

Please check the pull request for further details.
https://github.com/gnuradio/gnuradio/pull/404


Best regards,
Zhe


On Wed, Apr 1, 2015 at 11:40 AM, Richard Bell 
wrote:

> Zhe,
>
> Can you explain again why you require a min size for noutput_items? It
> sounds like there might still be a misunderstanding as to what this
> variable is used for. Why does your block care about the value of
> noutput_items?
>
> v/r,
> Rich
>
> On Wed, Apr 1, 2015 at 8:34 AM, Zhe Feng  wrote:
>
>> Dear Marcus,
>>
>> Thanks for your comment!
>> I made a typo my previous post that I was going to say
>> "set_min_noutput_items" but I wrote "set_noutput_items". I actually used it
>> in the work function, but it didn't seem to function as I expected. After
>> reading your comment, I put it in the constructor and nothing changed.
>>
>> Best regards,
>> Zhe
>>
>> On Wed, Apr 1, 2015 at 11:18 AM, Marcus Müller 
>> wrote:
>>
>>> Hi,
>>> noutput_items is what GNU Radio can maximally allow your block to
>>> produce, which is the free size in the output buffer, which is the input
>>> buffer of the next block.
>>> So if your block is faster than the downstream block, you will see
>>> exactly the behaviour you are observing. This is normal, and good.
>>>
>>> There's nothing the scheduler can do about this -- something
>>> "downstream" of your block just "backs up" the item flow, and your block
>>> will have to wait until whatever is downstream of it is done consuming
>>> input, so that there is space for output from your block again.
>>>
>>> You could try using set_min_noutput_items [1] in your block's
>>> constructor, so that GNU Radio won't even ask you to work() if there's
>>> not enough space available.
>>>
>>> Greetings,
>>> Marcus
>>>
>>>
>>> [1]
>>>
>>> http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a65cfc579150dc4d10c6180d3365aa9a8
>>>
>>> On 04/01/2015 04:47 PM, Zhe Feng wrote:
>>> > Dear all,
>>> >
>>> > I'm experiencing a problem with the noutput_items.
>>> >
>>> > I have written a sync block which did "return" several times. I found
>>> the
>>> > noutput_items dropped exactly by the amount that I returned. For
>>> example, if
>>> > I wrote "return 10", after that, I printed noutput_items and found it
>>> > decreased to noutput_items -10.
>>> >
>>> > Due to this fashion, the noutput_items could decrease to a value that
>>> one of
>>> > my "if statement" isn't satisfied. In that case, several items
>>> wouldn't be
>>> > outputed so the actual size of output items is smaller than the size of
>>> > input items. Is it still a sync block?
>>> >
>>> > I tried to wait for the noutput_items to increase but it didn't
>>> happen. I
>>> > tried to use "set_noutput_items( )" or "set_output_buffer()" to some
>>> values
>>> > I wanted, but they also failed.
>>> >
>>> > So I'm asking that how to tell the scheduler effectively that I want to
>>> > increase the noutput_items?
>>> >
>>> > Thanks!
>>> > Best regards,
>>> > Zhe
>>> >
>>> >
>>> >
>>> > --
>>> > View this message in context:
>>> http://gnuradio.4.n7.nabble.com/How-to-increase-the-noutput-items-tp53075.html
>>> > Sent from the GnuRadio mailing list archive at Nabble.com.
>>> >
>>> > ___
>>> > 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
>>>
>>
>>
>>
>> --
>> Zhe Feng
>> Electrical Engineering: System
>> University of Michigan Ann Arbor
>> Tel: 734-834-3188
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


-- 
Zhe Feng
Electrical Engineering: System
University of Michigan Ann Arbor
Tel: 734-834-3188
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

[Marcus Müller]

Hi Doug,
> What about adding an lo_locked metadata tag to the stream of samples?
>
> You could send lo_locked value=False on the last sample before LO unlocks, 
> and lo_locked value=True for first sample after LO locks. That should be (?) 
> simple to implement and would be equally as useful.
The problem is that the architecture doesn't really allow this. You have
to imagine it like this:
There's two (ok, more than that, but basically) two things going through
the RX-side Motherboard/daughterboard connector:
1. Analog complex baseband, which gets converted to digital samples at
the physical sampling rate by the motherboard's ADC (typically 100+
MS/s), and
2. serial control lines.

Both the sample bit lines from the ADC as well as the serial control
lines end up in the FPGA. Now, UHD has a fast track on which it pushes
all the samples around, through the various DSP stages, and through your
Gigabit interface (on N2x0, for example). That's possible because
samples are just that - samples. No back and forth communication, just
FIFOs in one direction and an on-FPGA bus that configures the whole
thing and makes sure things such as timed commands are executed on time.

The daughterboards do all the analog magic -- using programmable gain
amplifiers, programmable LO synthesizers, attenuators etc.
To control these, the control lines are there. These basically are just
"extended" serial ports of your PC. UHD knows how, for example, to
configure a specific LO synthesizer to give you the desired frequency,
and it just instructs the USRP to do so ("Write this over your serial
control port #0", "Read the thing you get when asking for register 0x0F
on port #1", these kind of things). These transfers are a lot slower,
though they can be initiated at a given time (thanks to timed commands,
again), than the sample clock.

Now, when you ask UHD "what is the lo_locked sensor value?", UHD
translates that to an read instruction to the LO synthesizer, and
translates the answer it gets from the USRP back to something like
true/false. Typically, these requests take quite some time. Also, your
chip has no way of guessing early whether the LO is locked or not -- it
observes stability, and the speed it can detect whether the LO is locked
must be inverse to the quality of that observation.

Thus, getting the answer from the synthesizer chip would typically
longer than justifiable here -- you'd end up throwing away less samples
if you did not poll the chip for that info and just threw away a fixed
amount of samples after every rx_freq tag. Also, polling the sensor
might get in the way of "normal" operation, because it'd occupy the
serial line.

Greetings,
Marcus

On 04/01/2015 07:49 PM, Anderson, Douglas J. wrote:
> Martin,
>
> I think we could have the same effect with a much simpler solution:
>
> What about adding an lo_locked metadata tag to the stream of samples?
>
> You could send lo_locked value=False on the last sample before LO unlocks, 
> and lo_locked value=True for first sample after LO locks. That should be (?) 
> simple to implement and would be equally as useful.
>
> Otherwise, determining the first usable sample, as you said, "depends on 
> pretty much everything", and that's a lot to push down on the end user.
>
> -Doug
>
> 
> From: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org 
> [discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of 
> Martin Braun [martin.br...@ettus.com]
> Sent: Wednesday, April 01, 2015 11:30 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked
>
> On 31.03.2015 14:25, Anderson, Douglas J. wrote:
>> Marcus,
>>
>> That makes sense, I hadn't thought of the DSP tuning issue, though I
>> think it would be infinitely more useful to make the stream tagging
>> logic aware of LO/DSP tuning and tag the first usable block in either
>> case. Slightly more involved than I assumed though.
> That is correct. It depends on pretty much everything, at the very least
> which exact device + d'board combo you're using.
>
> Cheers,
> M
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

Re: [Discuss-gnuradio] How to increase the noutput_items

[Marcus Müller]

Have you tried set_output_multiple(x)? That would ensure that you'd
always get n*x output space, with n in 1,2,3...

Greetings,
Marcus

On 04/01/2015 07:49 PM, Zhe Feng wrote:
> Dear Martin, 
>
> I tried to call it in the constructor, and it's the same as call it in
> the work function. It didn't work as I expected. 
>
> I was actually trying to update and adding more features to
> peak_detector2. There is a conditional statement below in my work
> function. 
>
> if( noutput_items >= d_look_ahead) 
>
> I tried to use set_min_noutput_items (d_look_ahead) in the constructor
> and in the work function. Neither of these two ways helped me satisfy
> the above condition. 
>
>
> Best regards,
> Zhe
>
>
> On Wed, Apr 1, 2015 at 1:22 PM, Martin Braun  > wrote:
>
> I don't know the details off the top of my head, but this might be
> one of those functions that you can't call during work(). Have you
> tried calling it in the ctor?
>
> M
>
> On 01.04.2015 08:34, Zhe Feng wrote:
>
> Dear Marcus,
>
> Thanks for your comment!
> I made a typo my previous post that I was going to say
> "set_min_noutput_items" but I wrote "set_noutput_items". I
> actually used
> it in the work function, but it didn't seem to function as I
> expected.
> After reading your comment, I put it in the constructor and
> nothing
> changed.
>
> Best regards,
> Zhe
>
> On Wed, Apr 1, 2015 at 11:18 AM, Marcus Müller
> mailto:marcus.muel...@ettus.com>
>  >> wrote:
>
> Hi,
> noutput_items is what GNU Radio can maximally allow your
> block to
> produce, which is the free size in the output buffer,
> which is the input
> buffer of the next block.
> So if your block is faster than the downstream block, you
> will see
> exactly the behaviour you are observing. This is normal,
> and good.
>
> There's nothing the scheduler can do about this -- something
> "downstream" of your block just "backs up" the item flow,
> and your block
> will have to wait until whatever is downstream of it is
> done consuming
> input, so that there is space for output from your block
> again.
>
> You could try using set_min_noutput_items [1] in your block's
> constructor, so that GNU Radio won't even ask you to
> work() if there's
> not enough space available.
>
> Greetings,
> Marcus
>
>
> [1]
>
> 
> http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a65cfc579150dc4d10c6180d3365aa9a8
>
> On 04/01/2015 04:47 PM, Zhe Feng wrote:
>  > Dear all,
>  >
>  > I'm experiencing a problem with the noutput_items.
>  >
>  > I have written a sync block which did "return" several
> times. I
> found the
>  > noutput_items dropped exactly by the amount that I
> returned. For
> example, if
>  > I wrote "return 10", after that, I printed
> noutput_items and found it
>  > decreased to noutput_items -10.
>  >
>  > Due to this fashion, the noutput_items could decrease
> to a value
> that one of
>  > my "if statement" isn't satisfied. In that case,
> several items
> wouldn't be
>  > outputed so the actual size of output items is smaller
> than the
> size of
>  > input items. Is it still a sync block?
>  >
>  > I tried to wait for the noutput_items to increase but
> it didn't
> happen. I
>  > tried to use "set_noutput_items( )" or
> "set_output_buffer()" to
> some values
>  > I wanted, but they also failed.
>  >
>  > So I'm asking that how to tell the scheduler
> effectively that I
> want to
>  > increase the noutput_items?
>  >
>  > Thanks!
>  > Best regards,
>  > Zhe
>  >
>  >
>  >
>  > --
>  > View this message in context:
>
> 
> http://gnuradio.4.n7.nabble.com/How-to-increase-the-noutput-items-tp53075.html
>  > Sent from the GnuRadio mailing list archive at Nabble.com.
>  >
>  > ___
>  > Discuss-gnuradio mailing list
>  > Discuss-gnuradio@gnu.org
> 
>  

Re: [Discuss-gnuradio] How to define a minimum number of input samples for a block.

[Daniel Mazzer]

Hi Martin,

Thank you, I will try.
My block is asymmetric, for n input samples it will have always 4 output
samples.
So I thinking that if I configure the previous block as you suggested, it
will work, right?

Regards,
Daniel


On Wed, Apr 1, 2015 at 2:19 PM, Martin Braun  wrote:

> http://gnuradio.org/doc/doxygen/classgr_1_1block.html#
> a65cfc579150dc4d10c6180d3365aa9a8
>
> M
>
>
> On 01.04.2015 10:04, Daniel Mazzer wrote:
>
>> Hi,
>>
>> I'm developing a block that need a minimum number of input samples to
>> process, for example, the block must have at least 1000 samples.
>>
>> In the work() function may I compare if the ninput_items[] is greater
>> than 1000 and if not I return zero?
>> Should I need to create an internal buffer (history) to cumulate samples
>> if the number of samples provided was less that 1000, and the work()
>> will return 0?
>> There is any other way to configure the block to work with a minimum
>> number of samples?
>>
>> Thank you.
>>
>> Daniel
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

[Anderson, Douglas J.]

Excellent information, I will stick to dumping n samples after receiving 
rx_freq.

Thank you!
-Doug


From: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org 
[discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of 
Marcus Müller [marcus.muel...@ettus.com]
Sent: Wednesday, April 01, 2015 12:34 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked

Hi Doug,
> What about adding an lo_locked metadata tag to the stream of samples?
>
> You could send lo_locked value=False on the last sample before LO unlocks, 
> and lo_locked value=True for first sample after LO locks. That should be (?) 
> simple to implement and would be equally as useful.
The problem is that the architecture doesn't really allow this. You have
to imagine it like this:
There's two (ok, more than that, but basically) two things going through
the RX-side Motherboard/daughterboard connector:
1. Analog complex baseband, which gets converted to digital samples at
the physical sampling rate by the motherboard's ADC (typically 100+
MS/s), and
2. serial control lines.

Both the sample bit lines from the ADC as well as the serial control
lines end up in the FPGA. Now, UHD has a fast track on which it pushes
all the samples around, through the various DSP stages, and through your
Gigabit interface (on N2x0, for example). That's possible because
samples are just that - samples. No back and forth communication, just
FIFOs in one direction and an on-FPGA bus that configures the whole
thing and makes sure things such as timed commands are executed on time.

The daughterboards do all the analog magic -- using programmable gain
amplifiers, programmable LO synthesizers, attenuators etc.
To control these, the control lines are there. These basically are just
"extended" serial ports of your PC. UHD knows how, for example, to
configure a specific LO synthesizer to give you the desired frequency,
and it just instructs the USRP to do so ("Write this over your serial
control port #0", "Read the thing you get when asking for register 0x0F
on port #1", these kind of things). These transfers are a lot slower,
though they can be initiated at a given time (thanks to timed commands,
again), than the sample clock.

Now, when you ask UHD "what is the lo_locked sensor value?", UHD
translates that to an read instruction to the LO synthesizer, and
translates the answer it gets from the USRP back to something like
true/false. Typically, these requests take quite some time. Also, your
chip has no way of guessing early whether the LO is locked or not -- it
observes stability, and the speed it can detect whether the LO is locked
must be inverse to the quality of that observation.

Thus, getting the answer from the synthesizer chip would typically
longer than justifiable here -- you'd end up throwing away less samples
if you did not poll the chip for that info and just threw away a fixed
amount of samples after every rx_freq tag. Also, polling the sensor
might get in the way of "normal" operation, because it'd occupy the
serial line.

Greetings,
Marcus

On 04/01/2015 07:49 PM, Anderson, Douglas J. wrote:
> Martin,
>
> I think we could have the same effect with a much simpler solution:
>
> What about adding an lo_locked metadata tag to the stream of samples?
>
> You could send lo_locked value=False on the last sample before LO unlocks, 
> and lo_locked value=True for first sample after LO locks. That should be (?) 
> simple to implement and would be equally as useful.
>
> Otherwise, determining the first usable sample, as you said, "depends on 
> pretty much everything", and that's a lot to push down on the end user.
>
> -Doug
>
> 
> From: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org 
> [discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of 
> Martin Braun [martin.br...@ettus.com]
> Sent: Wednesday, April 01, 2015 11:30 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] gr-uhd: rx_freq tag and lo_locked
>
> On 31.03.2015 14:25, Anderson, Douglas J. wrote:
>> Marcus,
>>
>> That makes sense, I hadn't thought of the DSP tuning issue, though I
>> think it would be infinitely more useful to make the stream tagging
>> logic aware of LO/DSP tuning and tag the first usable block in either
>> case. Slightly more involved than I assumed though.
> That is correct. It depends on pretty much everything, at the very least
> which exact device + d'board combo you're using.
>
> Cheers,
> M
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing li

[Discuss-gnuradio] E310 Network Mode

[SOUTHCOTT, MARK A CIV USAF AFMC AFRL/RITC]

I am trying to enable the network emulation mode on my E310. It is my 
understanding that the UHD version must be 3.08 or higher to support this, but 
is that the UHD version on the laptop or E310? My Lubuntu 14.04 laptop has UHD 
3.08 while the E310 has 3.07.

Mark



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

[Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Martin Braun]

Hey everyone,

as you might have heard, a GNU Radio hackfest is going on in sunny 
California, and one thing we've gotten going is the 4.1 release for GNU 
Radio. As you can tell, this is a major version jump.


Here's a release summary:

*Move to .NET*: This is probably the biggest change for now. Because of 
our continuing troubles with SWIG, we decided to move to a different 
platform for interoperating between a high-performance language and an 
easy scripting language, and .NET serves this cause. So, anything 
previously written in C++ is now in C#, and for the simple stuff 
(previously Python blocks) we now use ASP.NET. This is also fantastic as 
it finally allows graphical development using Visual Basic.


This also allowed us to modify the block API. The downside is, all OOT 
modules will be incompatible with GR4 -- maybe gr_modtool will provide 
conversion utilities once it has been ported to Delphi.


Linux support is currently not available -- this is not ideal, but we 
figured the 3.x series had broken Windows support for a long time, so 
this simply moves the problem to a different operating system. 
Unfortunately, we can't provide liveSDR ISOs anymore, now, because of 
licensing issues. As soon as mono picks up the slack, we'll be able to 
port GNU Radio 4 to Mono and Linux support will be mostly back on track.


*Embedded Support*: As a result of the embedded Linux conference the 
week prior to the hackfest, we realized that this whole 'embedded' thing 
is just a fad and is eating up our development resources. We are thus 
dropping embedded platform support for now, although we might revisit 
this when embedded Windows becomes more popular.


*GNU Radio Companion:* To overcome the lack of volunteers developing 
GRC, we will be integrating our graphical development process into the 
.NET framework also. As mentioned before, Visual Basic is ideally suited 
for the development of graphical widgets and we're anticipating a surge 
in new graphical widgets from the community.


On the community side, there'll be a couple of changes, too: Some 
already guessed we'd be dropping the mailing list as a communications 
platform when we announced our endorsement of Stack Overflow. The 
mailing list will go down as soon as we have a new web-based forum 
available, where users can post images inline as well as use Emojis. To 
avoid excessive trolling, users will either need a Facebook or Paypal 
account to log in.


Thanks everyone for being part of this community and keeping it going!
Of course, all the new stuff can be found on the 4.1 release website:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Release4

Cheers,
Martin

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

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Anderson, Douglas J.]

I just threw up in my mouth a little...


From: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org 
[discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of 
Martin Braun [martin.br...@ettus.com]
Sent: Wednesday, April 01, 2015 1:30 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

Hey everyone,

as you might have heard, a GNU Radio hackfest is going on in sunny
California, and one thing we've gotten going is the 4.1 release for GNU
Radio. As you can tell, this is a major version jump.

Here's a release summary:

*Move to .NET*: This is probably the biggest change for now. Because of
our continuing troubles with SWIG, we decided to move to a different
platform for interoperating between a high-performance language and an
easy scripting language, and .NET serves this cause. So, anything
previously written in C++ is now in C#, and for the simple stuff
(previously Python blocks) we now use ASP.NET. This is also fantastic as
it finally allows graphical development using Visual Basic.

This also allowed us to modify the block API. The downside is, all OOT
modules will be incompatible with GR4 -- maybe gr_modtool will provide
conversion utilities once it has been ported to Delphi.

Linux support is currently not available -- this is not ideal, but we
figured the 3.x series had broken Windows support for a long time, so
this simply moves the problem to a different operating system.
Unfortunately, we can't provide liveSDR ISOs anymore, now, because of
licensing issues. As soon as mono picks up the slack, we'll be able to
port GNU Radio 4 to Mono and Linux support will be mostly back on track.

*Embedded Support*: As a result of the embedded Linux conference the
week prior to the hackfest, we realized that this whole 'embedded' thing
is just a fad and is eating up our development resources. We are thus
dropping embedded platform support for now, although we might revisit
this when embedded Windows becomes more popular.

*GNU Radio Companion:* To overcome the lack of volunteers developing
GRC, we will be integrating our graphical development process into the
.NET framework also. As mentioned before, Visual Basic is ideally suited
for the development of graphical widgets and we're anticipating a surge
in new graphical widgets from the community.

On the community side, there'll be a couple of changes, too: Some
already guessed we'd be dropping the mailing list as a communications
platform when we announced our endorsement of Stack Overflow. The
mailing list will go down as soon as we have a new web-based forum
available, where users can post images inline as well as use Emojis. To
avoid excessive trolling, users will either need a Facebook or Paypal
account to log in.

Thanks everyone for being part of this community and keeping it going!
Of course, all the new stuff can be found on the 4.1 release website:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Release4

Cheers,
Martin

___
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] E310 Network Mode

[Marcus D. Leech]

On 04/01/2015 03:13 PM, SOUTHCOTT, MARK A CIV USAF AFMC AFRL/RITC wrote:

I am trying to enable the network emulation mode on my E310. It is my 
understanding that the UHD version must be 3.08 or higher to support this, but 
is that the UHD version on the laptop or E310? My Lubuntu 14.04 laptop has UHD 
3.08 while the E310 has 3.07.

Mark



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
The UHD on the host side must have been build with E310 support, and it 
should be at least 3.8.0




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

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Marcel Stolz]

I totally agree

On 01/04/15 21:34, Anderson, Douglas J. wrote:

I just threw up in my mouth a little...


From: discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org 
[discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of 
Martin Braun [martin.br...@ettus.com]
Sent: Wednesday, April 01, 2015 1:30 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

Hey everyone,

as you might have heard, a GNU Radio hackfest is going on in sunny
California, and one thing we've gotten going is the 4.1 release for GNU
Radio. As you can tell, this is a major version jump.

Here's a release summary:

*Move to .NET*: This is probably the biggest change for now. Because of
our continuing troubles with SWIG, we decided to move to a different
platform for interoperating between a high-performance language and an
easy scripting language, and .NET serves this cause. So, anything
previously written in C++ is now in C#, and for the simple stuff
(previously Python blocks) we now use ASP.NET. This is also fantastic as
it finally allows graphical development using Visual Basic.

This also allowed us to modify the block API. The downside is, all OOT
modules will be incompatible with GR4 -- maybe gr_modtool will provide
conversion utilities once it has been ported to Delphi.

Linux support is currently not available -- this is not ideal, but we
figured the 3.x series had broken Windows support for a long time, so
this simply moves the problem to a different operating system.
Unfortunately, we can't provide liveSDR ISOs anymore, now, because of
licensing issues. As soon as mono picks up the slack, we'll be able to
port GNU Radio 4 to Mono and Linux support will be mostly back on track.

*Embedded Support*: As a result of the embedded Linux conference the
week prior to the hackfest, we realized that this whole 'embedded' thing
is just a fad and is eating up our development resources. We are thus
dropping embedded platform support for now, although we might revisit
this when embedded Windows becomes more popular.

*GNU Radio Companion:* To overcome the lack of volunteers developing
GRC, we will be integrating our graphical development process into the
.NET framework also. As mentioned before, Visual Basic is ideally suited
for the development of graphical widgets and we're anticipating a surge
in new graphical widgets from the community.

On the community side, there'll be a couple of changes, too: Some
already guessed we'd be dropping the mailing list as a communications
platform when we announced our endorsement of Stack Overflow. The
mailing list will go down as soon as we have a new web-based forum
available, where users can post images inline as well as use Emojis. To
avoid excessive trolling, users will either need a Facebook or Paypal
account to log in.

Thanks everyone for being part of this community and keeping it going!
Of course, all the new stuff can be found on the 4.1 release website:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Release4

Cheers,
Martin

___
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


--
_
Universität Bern
Institut für Informatik und angewandte Mathematik
Communication and Distributed Systems Research Group

Marcel Stolz, BSc
Master Student

Neubrückstrasse 10
CH-3012 Bern
mailto:marcel.st...@students.unibe.ch
http://www.cds.unibe.ch


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

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Marcus D. Leech]

On 04/01/2015 03:30 PM, Martin Braun wrote:

Hey everyone,

as you might have heard, a GNU Radio hackfest is going on in sunny 
California, and one thing we've gotten going is the 4.1 release for 
GNU Radio. As you can tell, this is a major version jump.


Here's a release summary:

*Move to .NET*: This is probably the biggest change for now. Because 
of our continuing troubles with SWIG, we decided to move to a 
different platform for interoperating between a high-performance 
language and an easy scripting language, and .NET serves this cause. 
So, anything previously written in C++ is now in C#, and for the 
simple stuff (previously Python blocks) we now use ASP.NET. This is 
also fantastic as it finally allows graphical development using Visual 
Basic.


This also allowed us to modify the block API. The downside is, all OOT 
modules will be incompatible with GR4 -- maybe gr_modtool will provide 
conversion utilities once it has been ported to Delphi.


Linux support is currently not available -- this is not ideal, but we 
figured the 3.x series had broken Windows support for a long time, so 
this simply moves the problem to a different operating system. 
Unfortunately, we can't provide liveSDR ISOs anymore, now, because of 
licensing issues. As soon as mono picks up the slack, we'll be able to 
port GNU Radio 4 to Mono and Linux support will be mostly back on track.


*Embedded Support*: As a result of the embedded Linux conference the 
week prior to the hackfest, we realized that this whole 'embedded' 
thing is just a fad and is eating up our development resources. We are 
thus dropping embedded platform support for now, although we might 
revisit this when embedded Windows becomes more popular.


*GNU Radio Companion:* To overcome the lack of volunteers developing 
GRC, we will be integrating our graphical development process into the 
.NET framework also. As mentioned before, Visual Basic is ideally 
suited for the development of graphical widgets and we're anticipating 
a surge in new graphical widgets from the community.


On the community side, there'll be a couple of changes, too: Some 
already guessed we'd be dropping the mailing list as a communications 
platform when we announced our endorsement of Stack Overflow. The 
mailing list will go down as soon as we have a new web-based forum 
available, where users can post images inline as well as use Emojis. 
To avoid excessive trolling, users will either need a Facebook or 
Paypal account to log in.


Thanks everyone for being part of this community and keeping it going!
Of course, all the new stuff can be found on the 4.1 release website:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Release4

Cheers,
Martin


You know, there's a tradition about April 1, that jokes played after 
13:00 local cause bad kharma to flow to the joker.   Just, you know, sayin'.





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

Re: [Discuss-gnuradio] E310 Network Mode

[Neel Pandeya]

You should use UHD 3.8.2 on your laptop.

You will need to build UHD from source, as most pre-built packages don't
enable E310 support (E310 support is not enabled by default).

When you build with CMake, be sure to add "-DENABLE_E300=ON" as a
command-line option.

--Neel



On 1 April 2015 at 12:13, SOUTHCOTT, MARK A CIV USAF AFMC AFRL/RITC <
mark.southcot...@us.af.mil> wrote:

> I am trying to enable the network emulation mode on my E310. It is my
> understanding that the UHD version must be 3.08 or higher to support this,
> but is that the UHD version on the laptop or E310? My Lubuntu 14.04 laptop
> has UHD 3.08 while the E310 has 3.07.
>
> Mark
>
>
>
> ___
> 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] Release Announcement: GNU Radio 4.1

[Martin Braun]

On 01.04.2015 12:40, Marcus D. Leech wrote:

You know, there's a tradition about April 1, that jokes played after
13:00 local cause bad kharma to flow to the joker.   Just, you know,
sayin'.


You underestimate my West-ness of timezone.

M

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

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Gerry Creager - NOAA Affiliate]

It's just not fair to keep reminding me that today's 1 APR. It's been too
busy to sort out the cruft from the rest of it all.

On Wed, Apr 1, 2015 at 2:40 PM, Marcus D. Leech  wrote:

> On 04/01/2015 03:30 PM, Martin Braun wrote:
>
>> Hey everyone,
>>
>> as you might have heard, a GNU Radio hackfest is going on in sunny
>> California, and one thing we've gotten going is the 4.1 release for GNU
>> Radio. As you can tell, this is a major version jump.
>>
>> Here's a release summary:
>>
>> *Move to .NET*: This is probably the biggest change for now. Because of
>> our continuing troubles with SWIG, we decided to move to a different
>> platform for interoperating between a high-performance language and an easy
>> scripting language, and .NET serves this cause. So, anything previously
>> written in C++ is now in C#, and for the simple stuff (previously Python
>> blocks) we now use ASP.NET. This is also fantastic as it finally allows
>> graphical development using Visual Basic.
>>
>> This also allowed us to modify the block API. The downside is, all OOT
>> modules will be incompatible with GR4 -- maybe gr_modtool will provide
>> conversion utilities once it has been ported to Delphi.
>>
>> Linux support is currently not available -- this is not ideal, but we
>> figured the 3.x series had broken Windows support for a long time, so this
>> simply moves the problem to a different operating system. Unfortunately, we
>> can't provide liveSDR ISOs anymore, now, because of licensing issues. As
>> soon as mono picks up the slack, we'll be able to port GNU Radio 4 to Mono
>> and Linux support will be mostly back on track.
>>
>> *Embedded Support*: As a result of the embedded Linux conference the week
>> prior to the hackfest, we realized that this whole 'embedded' thing is just
>> a fad and is eating up our development resources. We are thus dropping
>> embedded platform support for now, although we might revisit this when
>> embedded Windows becomes more popular.
>>
>> *GNU Radio Companion:* To overcome the lack of volunteers developing GRC,
>> we will be integrating our graphical development process into the .NET
>> framework also. As mentioned before, Visual Basic is ideally suited for the
>> development of graphical widgets and we're anticipating a surge in new
>> graphical widgets from the community.
>>
>> On the community side, there'll be a couple of changes, too: Some already
>> guessed we'd be dropping the mailing list as a communications platform when
>> we announced our endorsement of Stack Overflow. The mailing list will go
>> down as soon as we have a new web-based forum available, where users can
>> post images inline as well as use Emojis. To avoid excessive trolling,
>> users will either need a Facebook or Paypal account to log in.
>>
>> Thanks everyone for being part of this community and keeping it going!
>> Of course, all the new stuff can be found on the 4.1 release website:
>>
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Release4
>>
>> Cheers,
>> Martin
>>
>>
>>  You know, there's a tradition about April 1, that jokes played after
> 13:00 local cause bad kharma to flow to the joker.   Just, you know, sayin'.
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



-- 
Gerry Creager
NSSL/CIMMS
405.325.6371
++
“Big whorls have little whorls,
That feed on their velocity;
And little whorls have lesser whorls,
And so on to viscosity.”
Lewis Fry Richardson (1881-1953)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Johnathan Corgan]

On Wed, Apr 1, 2015 at 12:30 PM, Martin Braun 
wrote:

>
> Unfortunately, we can't provide liveSDR ISOs anymore, now, because of
> licensing issues.


Rest assured we are almost ready to announce our GNU Radio Live SDR Floppy
Disk Environment and parallel port license dongle.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Marcus Müller]

Hi Martin,

thanks for wrapping up the news!
Just to add a bit from the developers/infrastructural side of things:
>From the infrastructure side of things, we've agreed to migrate to our
own SharePoint server, and ditch git. It had terrible Perforce support,
and isn't really suited for VisualStudio projects. Also, it was really
more complex that it should have been. Obviously, that breaks pybombs
and build-gnuradio, but we should soon be seeing GR on the Windows 8/10
App Store.

I've spent the profits from last GRCON on the StackOverflow sponsoring
and Facebook adverising. You will be seeing the new GR4 logo next to
questions tagged with gnu-radio and software-defined-radio starting next
monday, and people with related interests (hams, .Net devs, or
GR-connected FB account) will see ads in their FB timeline soon, too;
the idea is that the revenue that we can generate by placing
successively more ads on gnuradio.org will quickly cover our FB
expenses, and will also give the project a touch of professionalism that
basically made all but academic lunatics stay away from GR.

Enjoy the ride,
Marcus

On 04/01/2015 09:30 PM, Martin Braun wrote:
> Hey everyone,
>
> as you might have heard, a GNU Radio hackfest is going on in sunny
> California, and one thing we've gotten going is the 4.1 release for
> GNU Radio. As you can tell, this is a major version jump.
>
> Here's a release summary:
>
> *Move to .NET*: This is probably the biggest change for now. Because
> of our continuing troubles with SWIG, we decided to move to a
> different platform for interoperating between a high-performance
> language and an easy scripting language, and .NET serves this cause.
> So, anything previously written in C++ is now in C#, and for the
> simple stuff (previously Python blocks) we now use ASP.NET. This is
> also fantastic as it finally allows graphical development using Visual
> Basic.
>
> This also allowed us to modify the block API. The downside is, all OOT
> modules will be incompatible with GR4 -- maybe gr_modtool will provide
> conversion utilities once it has been ported to Delphi.
>
> Linux support is currently not available -- this is not ideal, but we
> figured the 3.x series had broken Windows support for a long time, so
> this simply moves the problem to a different operating system.
> Unfortunately, we can't provide liveSDR ISOs anymore, now, because of
> licensing issues. As soon as mono picks up the slack, we'll be able to
> port GNU Radio 4 to Mono and Linux support will be mostly back on track.
>
> *Embedded Support*: As a result of the embedded Linux conference the
> week prior to the hackfest, we realized that this whole 'embedded'
> thing is just a fad and is eating up our development resources. We are
> thus dropping embedded platform support for now, although we might
> revisit this when embedded Windows becomes more popular.
>
> *GNU Radio Companion:* To overcome the lack of volunteers developing
> GRC, we will be integrating our graphical development process into the
> .NET framework also. As mentioned before, Visual Basic is ideally
> suited for the development of graphical widgets and we're anticipating
> a surge in new graphical widgets from the community.
>
> On the community side, there'll be a couple of changes, too: Some
> already guessed we'd be dropping the mailing list as a communications
> platform when we announced our endorsement of Stack Overflow. The
> mailing list will go down as soon as we have a new web-based forum
> available, where users can post images inline as well as use Emojis.
> To avoid excessive trolling, users will either need a Facebook or
> Paypal account to log in.
>
> Thanks everyone for being part of this community and keeping it going!
> Of course, all the new stuff can be found on the 4.1 release website:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Release4
>
> Cheers,
> Martin
>
> ___
> 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] Release Announcement: GNU Radio 4.1

[Marcus D. Leech]

On 04/01/2015 03:43 PM, Martin Braun wrote:

On 01.04.2015 12:40, Marcus D. Leech wrote:

You know, there's a tradition about April 1, that jokes played after
13:00 local cause bad kharma to flow to the joker.   Just, you know,
sayin'.


You underestimate my West-ness of timezone.

M


The Internet screwed up everything :)



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

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Michael Berman]

Please tell me the SharePoint server has no backups, and is running off a
56K modem running on GNURadio in somebody's grandmother's basement...

Michael

On Wed, Apr 1, 2015 at 12:48 PM, Marcus Müller 
wrote:

> Hi Martin,
>
> thanks for wrapping up the news!
> Just to add a bit from the developers/infrastructural side of things:
> From the infrastructure side of things, we've agreed to migrate to our
> own SharePoint server, and ditch git. It had terrible Perforce support,
> and isn't really suited for VisualStudio projects. Also, it was really
> more complex that it should have been. Obviously, that breaks pybombs
> and build-gnuradio, but we should soon be seeing GR on the Windows 8/10
> App Store.
>
> I've spent the profits from last GRCON on the StackOverflow sponsoring
> and Facebook adverising. You will be seeing the new GR4 logo next to
> questions tagged with gnu-radio and software-defined-radio starting next
> monday, and people with related interests (hams, .Net devs, or
> GR-connected FB account) will see ads in their FB timeline soon, too;
> the idea is that the revenue that we can generate by placing
> successively more ads on gnuradio.org will quickly cover our FB
> expenses, and will also give the project a touch of professionalism that
> basically made all but academic lunatics stay away from GR.
>
> Enjoy the ride,
> Marcus
>
> On 04/01/2015 09:30 PM, Martin Braun wrote:
> > Hey everyone,
> >
> > as you might have heard, a GNU Radio hackfest is going on in sunny
> > California, and one thing we've gotten going is the 4.1 release for
> > GNU Radio. As you can tell, this is a major version jump.
> >
> > Here's a release summary:
> >
> > *Move to .NET*: This is probably the biggest change for now. Because
> > of our continuing troubles with SWIG, we decided to move to a
> > different platform for interoperating between a high-performance
> > language and an easy scripting language, and .NET serves this cause.
> > So, anything previously written in C++ is now in C#, and for the
> > simple stuff (previously Python blocks) we now use ASP.NET. This is
> > also fantastic as it finally allows graphical development using Visual
> > Basic.
> >
> > This also allowed us to modify the block API. The downside is, all OOT
> > modules will be incompatible with GR4 -- maybe gr_modtool will provide
> > conversion utilities once it has been ported to Delphi.
> >
> > Linux support is currently not available -- this is not ideal, but we
> > figured the 3.x series had broken Windows support for a long time, so
> > this simply moves the problem to a different operating system.
> > Unfortunately, we can't provide liveSDR ISOs anymore, now, because of
> > licensing issues. As soon as mono picks up the slack, we'll be able to
> > port GNU Radio 4 to Mono and Linux support will be mostly back on track.
> >
> > *Embedded Support*: As a result of the embedded Linux conference the
> > week prior to the hackfest, we realized that this whole 'embedded'
> > thing is just a fad and is eating up our development resources. We are
> > thus dropping embedded platform support for now, although we might
> > revisit this when embedded Windows becomes more popular.
> >
> > *GNU Radio Companion:* To overcome the lack of volunteers developing
> > GRC, we will be integrating our graphical development process into the
> > .NET framework also. As mentioned before, Visual Basic is ideally
> > suited for the development of graphical widgets and we're anticipating
> > a surge in new graphical widgets from the community.
> >
> > On the community side, there'll be a couple of changes, too: Some
> > already guessed we'd be dropping the mailing list as a communications
> > platform when we announced our endorsement of Stack Overflow. The
> > mailing list will go down as soon as we have a new web-based forum
> > available, where users can post images inline as well as use Emojis.
> > To avoid excessive trolling, users will either need a Facebook or
> > Paypal account to log in.
> >
> > Thanks everyone for being part of this community and keeping it going!
> > Of course, all the new stuff can be found on the 4.1 release website:
> >
> > http://gnuradio.org/redmine/projects/gnuradio/wiki/Release4
> >
> > Cheers,
> > Martin
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Monahan-Mitchell, Tim]

In the interest of saving the GR support team costly web hosting fees, may I 
send a self-addressed package with my blank 3.5" floppies to get the release?
How many blank floppies should I send? I think I can get them in bulk on eBay.
I'm in no hurry, so return  by pre-paid surface mail is fine for me (it will 
take me time to convert my C++ GR blocks to C#).

- Tim

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

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Richard Bell]

This was a good April fools post, mainly because I forgot it was April 1st
and believed it. Thank you for getting the juices flowing!

Rich

On Wed, Apr 1, 2015 at 12:55 PM, Monahan-Mitchell, Tim <
tmona...@qti.qualcomm.com> wrote:

> In the interest of saving the GR support team costly web hosting fees, may
> I send a self-addressed package with my blank 3.5" floppies to get the
> release?
> How many blank floppies should I send? I think I can get them in bulk on
> eBay.
> I'm in no hurry, so return  by pre-paid surface mail is fine for me (it
> will take me time to convert my C++ GR blocks to C#).
>
> - Tim
>
> ___
> 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] Release Announcement: GNU Radio 4.1

[Marcus D. Leech]

On 04/01/2015 03:55 PM, Monahan-Mitchell, Tim wrote:

In the interest of saving the GR support team costly web hosting fees, may I send a 
self-addressed package with my blank 3.5" floppies to get the release?
How many blank floppies should I send? I think I can get them in bulk on eBay.
I'm in no hurry, so return  by pre-paid surface mail is fine for me (it will 
take me time to convert my C++ GR blocks to C#).

- Tim

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
This is probably an opportune time to announce my fork of Gnu Radio that 
uses Swift instead of C++.  I got my teenage son to do the re-writes, since

  he's learning Swift at school.  Creamy goodness.



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

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Bogdan Diaconescu]

I liked the one with porting to .Net especially that the previous day I got a 
presentation on a conference with how open source is .Net and how open MS is 
now :)

Bogdan
 


 On Wednesday, April 1, 2015 10:56 PM, "Monahan-Mitchell, Tim" 
 wrote:
   

 In the interest of saving the GR support team costly web hosting fees, may I 
send a self-addressed package with my blank 3.5" floppies to get the release?
How many blank floppies should I send? I think I can get them in bulk on eBay.
I'm in no hurry, so return  by pre-paid surface mail is fine for me (it will 
take me time to convert my C++ GR blocks to C#).

- Tim

___
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] Release Announcement: GNU Radio 4.1

[Ed Criscuolo]

My blood pressure spiked for the first sentence and a half! (then I
remembered the date)

@(^.^)@  Ed


On 4/1/15, 3:30 PM, Martin Braun wrote:

*Move to .NET*: This is probably the biggest change for now. Because of
our continuing troubles with SWIG, we decided to move to a different
platform for interoperating between a high-performance language and an
easy scripting language, and .NET serves this cause. So, anything
previously written in C++ is now in C#, and for the simple stuff
(previously Python blocks) we now use ASP.NET. This is also fantastic as
it finally allows graphical development using Visual Basic. ...



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

Re: [Discuss-gnuradio] build failing in gr-dtv due to VOLK issues

[Marcus D. Leech]

On 04/01/2015 01:02 PM, Marcus D. Leech wrote:

I've attached the log from the make.

This is on Fedora 18, on a x64 platform.

The repo was cloned fresh just before the build, and I used  the 
"maint" branch.





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

This is still failing after a "proper"  clone, using --recursive.

"maint" builds just fine, master fails.


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

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[Martin Braun]

On 01.04.2015 13:15, Ed Criscuolo wrote:

My blood pressure spiked for the first sentence and a half! (then I
remembered the date)


I was assuming the version number would be a clue, too :)

M


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

Re: [Discuss-gnuradio] Release Announcement: GNU Radio 4.1

[John Malsbury]

"This also allowed us to modify the block API. The downside is, all OOT
modules will be incompatible with GR4"

I have to ask for real - is this part of the April fools joke, or is it
true?

:)

On Wed, Apr 1, 2015 at 2:12 PM, Martin Braun  wrote:

> On 01.04.2015 13:15, Ed Criscuolo wrote:
>
>> My blood pressure spiked for the first sentence and a half! (then I
>> remembered the date)
>>
>
> I was assuming the version number would be a clue, too :)
>
>
> M
>
>
> ___
> 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] gr-uhd: rx_freq tag and lo_locked

[Martin Braun]

On 01.04.2015 10:49, Anderson, Douglas J. wrote:

Martin,

I think we could have the same effect with a much simpler solution:

What about adding an lo_locked metadata tag to the stream of
samples?


This would require the FPGA to automatically send some kind of 
notification that the LO has locked (our packet format doesn't have such 
a field), and the USRP sink to parse async messages or something like 
that for every sample (at least, every sample after an rx_freq tag). 
This would mean both architectural changes and added processing load.


My assertion 'depends on everything' also was a bit pessimistic. Tune 
time depends on certain parameters, such as devices used (mboard/dboard) 
and some DSP settings; possibly even temperature and other analogs. For 
a given setup, it won't change massively during operation.


So you're right that we're pushing this to the user, but without a 
really tight coupling between the app and the analog front-end (and I 
consider USB or Ethernet not fall into this category), there's not a 
simple solution -- unless you count measuring the delay between the 
first sample with the rx_freq tag and the end of the transition, and 
then statically adding another tag after X many samples, which I don't 
think you were asking for.


Cheers,
M

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

Re: [Discuss-gnuradio] How to define a minimum number of input samples for a block.

[Martin Braun]

On 01.04.2015 11:19, Daniel Mazzer wrote:

Hi Martin,

Thank you, I will try.
My block is asymmetric, for n input samples it will have always 4 output
samples.
So I thinking that if I configure the previous block as you suggested,
it will work, right?


In that case, you want something else:

Make your block an 'sync_interpolator' with an interpolation rate of 4. 
Then, in your work() function, you only get noutput_items, and the 
number of input items is implicitly noutput_items/4.


M


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

Re: [Discuss-gnuradio] GNU Radio on Zedboard

[Philip Balister]

On 03/31/2015 11:39 AM, Alireza Khodamoradi wrote:
> Philip,
> 
> I got it working. For some reason if I use *Ubuntu's Archive Manager* on my
> laptop to uncompress the .xz file, it doesn't work!
> 
> I had to uncompress it by this command: *unxz -d
> sdimage-8G-zedboard.direct.xz* in order to get it work.
> 
> Now I have a linux running on the zedboard with the gnu-radio. But I can't
> get the VGA to work - I have to use UART to connect to the linux - I saw it
> has *startx* , is there any way for me to get the VGA working?

I'd ask on the meta-xilinx list. We use hte BSP from Xilinx, which I do
not think has support for the video display. For that you need a special
driver (and I believe you need some stuff in the fpga). The build we
have doesn't depend on anything loaded in the fpga.

Philip

> 
> Thank you,
> Alireza
> 
> On Fri, Mar 20, 2015 at 6:54 AM, Philip Balister 
> wrote:
> 
>> On 03/19/2015 10:48 AM, Alireza Khodamoradi wrote:
>>> Here are the files I have in the FAT partition (boot):
>>>
>>> 1- boot.bin
>>> 2- u-boot.img
>>> 3- uEnv.txt
>>> 4- uImage
>>> 5- zc702-zynq7.dtb
>>>
>>> * I used this image: *sdimage-8G-zc702.direct*
>>
>> So this all looks correct. When you put the card in the PC both the FAT
>> and roofs partitions are mounted OK? You did use an 8G card?
>>
>> I'm not sure what to say at this point. Everything looks OK. I am
>> traveling and away from borads for a few weeks.
>>
>> Philip
>>
>>>
>>> On Thu, Mar 19, 2015 at 6:41 AM, Philip Balister 
>>> wrote:
>>>
 On 03/18/2015 10:44 PM, Alireza Khodamoradi wrote:
> Philip,
>
> Thank you for letting me using your images. I tried both of them with
 the *dd
> *command, it took me around 2000 seconds (30 mins) each and after using
> them on the board I get the following message via the UART:
>
> *U-Boot SPL 2014.01 (Jan 09 2015 - 20:24:45)*
> *mmc boot*
> *reading fpga.bin*
> *spl: error reding image fpga.bin, err - -1*
> *reading system.dtb*
> *spl: error reading image system.dtb, err - -1*
> *reading u-boot.img*
> *spl: error reading image u-boot.img, err - -1*
> *### ERROR ### Please RESET the board ###*

 So the first stage boot loader is running, which is good.

 It looks for a couple of files which should be there, which is OK.
 (fpga.bin and system.dtb)

 Then it tries to load u-boot.img which it doesn't find. This is bad.

 Can you put the card in a PC and send the list of file in the FAT
 partition?

 Philip


>
> I got the above message for sdimage-8G-zc702.direct. I get no message
>> for
> the other image.
>
> What am I doing wrong?
>
> On Fri, Mar 13, 2015 at 11:22 AM, Philip Balister >>
> wrote:
>
>> On 03/13/2015 01:17 PM, Alireza Khodamoradi wrote:
>>> Hello everyone,
>>>
>>> I'm going through the instructions from here:
>>>
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq
>>
>> I should go over those carefully, but in the mentime I have some
>> images
>> built for the zedbaord here:
>>
>>

>> https://www.dropbox.com/sh/yfbpj63pcenqatr/AAAt0s3xFXs47I7q5pNopheHa?dl=0
>>
>> Take the zedboard one, uncompress it and write it to an sd card. Be
>> sure
>> to unmount (not eject) the sd card and run:
>>
>> sudo dd if=sdimage-8G-zedboard.direct of=/dev/sdX
>>
>> where sdx is the device the sd card is on.
>>
>> Philip
>>
>>>
>>> to get a working image with gnu radio for my zedboard.
>>>
>>> Unfortunately I can't get the board to boot with this image. I was
>>> wondering if someone can help me.
>>>
>>> what I tried so far ( all failed - can't boot from the SDCard):
>>>
>>> - default settings in the instructions
>>> - renaming u-boot.bin to boot.bin
>>> - renaming u-boot.bin to BOOT.BIN
>>> - renaming uImage--zedboard-zynq7.dtb to devicetree.dtb
>>> - I tried command line as well as gparted gui.
>>>
>>> what I checked:
>>>
>>> - download a linux from XillyBus and boot the board with SDCard ->
 works
>>>
>>> v/r
>>> Alireza
>>>
>>>
>>>
>>> ___
>>> 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] GNU Radio on Zedboard

[Alireza Khodamoradi]

Thank you Philip!

I also don't have the audio jack working. Should I ask it on the
meta-xilinx list?

On Wed, Apr 1, 2015 at 4:50 PM, Philip Balister  wrote:

> On 03/31/2015 11:39 AM, Alireza Khodamoradi wrote:
> > Philip,
> >
> > I got it working. For some reason if I use *Ubuntu's Archive Manager* on
> my
> > laptop to uncompress the .xz file, it doesn't work!
> >
> > I had to uncompress it by this command: *unxz -d
> > sdimage-8G-zedboard.direct.xz* in order to get it work.
> >
> > Now I have a linux running on the zedboard with the gnu-radio. But I
> can't
> > get the VGA to work - I have to use UART to connect to the linux - I saw
> it
> > has *startx* , is there any way for me to get the VGA working?
>
> I'd ask on the meta-xilinx list. We use hte BSP from Xilinx, which I do
> not think has support for the video display. For that you need a special
> driver (and I believe you need some stuff in the fpga). The build we
> have doesn't depend on anything loaded in the fpga.
>
> Philip
>
> >
> > Thank you,
> > Alireza
> >
> > On Fri, Mar 20, 2015 at 6:54 AM, Philip Balister 
> > wrote:
> >
> >> On 03/19/2015 10:48 AM, Alireza Khodamoradi wrote:
> >>> Here are the files I have in the FAT partition (boot):
> >>>
> >>> 1- boot.bin
> >>> 2- u-boot.img
> >>> 3- uEnv.txt
> >>> 4- uImage
> >>> 5- zc702-zynq7.dtb
> >>>
> >>> * I used this image: *sdimage-8G-zc702.direct*
> >>
> >> So this all looks correct. When you put the card in the PC both the FAT
> >> and roofs partitions are mounted OK? You did use an 8G card?
> >>
> >> I'm not sure what to say at this point. Everything looks OK. I am
> >> traveling and away from borads for a few weeks.
> >>
> >> Philip
> >>
> >>>
> >>> On Thu, Mar 19, 2015 at 6:41 AM, Philip Balister 
> >>> wrote:
> >>>
>  On 03/18/2015 10:44 PM, Alireza Khodamoradi wrote:
> > Philip,
> >
> > Thank you for letting me using your images. I tried both of them with
>  the *dd
> > *command, it took me around 2000 seconds (30 mins) each and after
> using
> > them on the board I get the following message via the UART:
> >
> > *U-Boot SPL 2014.01 (Jan 09 2015 - 20:24:45)*
> > *mmc boot*
> > *reading fpga.bin*
> > *spl: error reding image fpga.bin, err - -1*
> > *reading system.dtb*
> > *spl: error reading image system.dtb, err - -1*
> > *reading u-boot.img*
> > *spl: error reading image u-boot.img, err - -1*
> > *### ERROR ### Please RESET the board ###*
> 
>  So the first stage boot loader is running, which is good.
> 
>  It looks for a couple of files which should be there, which is OK.
>  (fpga.bin and system.dtb)
> 
>  Then it tries to load u-boot.img which it doesn't find. This is bad.
> 
>  Can you put the card in a PC and send the list of file in the FAT
>  partition?
> 
>  Philip
> 
> 
> >
> > I got the above message for sdimage-8G-zc702.direct. I get no message
> >> for
> > the other image.
> >
> > What am I doing wrong?
> >
> > On Fri, Mar 13, 2015 at 11:22 AM, Philip Balister <
> phi...@balister.org
> >>>
> > wrote:
> >
> >> On 03/13/2015 01:17 PM, Alireza Khodamoradi wrote:
> >>> Hello everyone,
> >>>
> >>> I'm going through the instructions from here:
> >>>
> >>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq
> >>
> >> I should go over those carefully, but in the mentime I have some
> >> images
> >> built for the zedbaord here:
> >>
> >>
> 
> >>
> https://www.dropbox.com/sh/yfbpj63pcenqatr/AAAt0s3xFXs47I7q5pNopheHa?dl=0
> >>
> >> Take the zedboard one, uncompress it and write it to an sd card. Be
> >> sure
> >> to unmount (not eject) the sd card and run:
> >>
> >> sudo dd if=sdimage-8G-zedboard.direct of=/dev/sdX
> >>
> >> where sdx is the device the sd card is on.
> >>
> >> Philip
> >>
> >>>
> >>> to get a working image with gnu radio for my zedboard.
> >>>
> >>> Unfortunately I can't get the board to boot with this image. I was
> >>> wondering if someone can help me.
> >>>
> >>> what I tried so far ( all failed - can't boot from the SDCard):
> >>>
> >>> - default settings in the instructions
> >>> - renaming u-boot.bin to boot.bin
> >>> - renaming u-boot.bin to BOOT.BIN
> >>> - renaming uImage--zedboard-zynq7.dtb to devicetree.dtb
> >>> - I tried command line as well as gparted gui.
> >>>
> >>> what I checked:
> >>>
> >>> - download a linux from XillyBus and boot the board with SDCard ->
>  works
> >>>
> >>> v/r
> >>> Alireza
> >>>
> >>>
> >>>
> >>> ___
> >>> Discuss-gnuradio mailing list
> >>> Discuss-gnuradio@gnu.org
> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>
> >>
> >
> 
> >>>
> >>
> >
>
_

Re: [Discuss-gnuradio] GNU Radio on Zedboard

[Philip Balister]

On 04/01/2015 04:53 PM, Alireza Khodamoradi wrote:
> Thank you Philip!
> 
> I also don't have the audio jack working. Should I ask it on the
> meta-xilinx list?

Bug them. It is also likely a driver issue. My understanding is there
are a bunch of analog devices parts on the board that they wrote drivers
for. I'm not sure if those drivers made it into upstream Linux, and then
you have the issue of the best kernel for our purposes is about 3.14.

Philip

> 
> On Wed, Apr 1, 2015 at 4:50 PM, Philip Balister  wrote:
> 
>> On 03/31/2015 11:39 AM, Alireza Khodamoradi wrote:
>>> Philip,
>>>
>>> I got it working. For some reason if I use *Ubuntu's Archive Manager* on
>> my
>>> laptop to uncompress the .xz file, it doesn't work!
>>>
>>> I had to uncompress it by this command: *unxz -d
>>> sdimage-8G-zedboard.direct.xz* in order to get it work.
>>>
>>> Now I have a linux running on the zedboard with the gnu-radio. But I
>> can't
>>> get the VGA to work - I have to use UART to connect to the linux - I saw
>> it
>>> has *startx* , is there any way for me to get the VGA working?
>>
>> I'd ask on the meta-xilinx list. We use hte BSP from Xilinx, which I do
>> not think has support for the video display. For that you need a special
>> driver (and I believe you need some stuff in the fpga). The build we
>> have doesn't depend on anything loaded in the fpga.
>>
>> Philip
>>
>>>
>>> Thank you,
>>> Alireza
>>>
>>> On Fri, Mar 20, 2015 at 6:54 AM, Philip Balister 
>>> wrote:
>>>
 On 03/19/2015 10:48 AM, Alireza Khodamoradi wrote:
> Here are the files I have in the FAT partition (boot):
>
> 1- boot.bin
> 2- u-boot.img
> 3- uEnv.txt
> 4- uImage
> 5- zc702-zynq7.dtb
>
> * I used this image: *sdimage-8G-zc702.direct*

 So this all looks correct. When you put the card in the PC both the FAT
 and roofs partitions are mounted OK? You did use an 8G card?

 I'm not sure what to say at this point. Everything looks OK. I am
 traveling and away from borads for a few weeks.

 Philip

>
> On Thu, Mar 19, 2015 at 6:41 AM, Philip Balister 
> wrote:
>
>> On 03/18/2015 10:44 PM, Alireza Khodamoradi wrote:
>>> Philip,
>>>
>>> Thank you for letting me using your images. I tried both of them with
>> the *dd
>>> *command, it took me around 2000 seconds (30 mins) each and after
>> using
>>> them on the board I get the following message via the UART:
>>>
>>> *U-Boot SPL 2014.01 (Jan 09 2015 - 20:24:45)*
>>> *mmc boot*
>>> *reading fpga.bin*
>>> *spl: error reding image fpga.bin, err - -1*
>>> *reading system.dtb*
>>> *spl: error reading image system.dtb, err - -1*
>>> *reading u-boot.img*
>>> *spl: error reading image u-boot.img, err - -1*
>>> *### ERROR ### Please RESET the board ###*
>>
>> So the first stage boot loader is running, which is good.
>>
>> It looks for a couple of files which should be there, which is OK.
>> (fpga.bin and system.dtb)
>>
>> Then it tries to load u-boot.img which it doesn't find. This is bad.
>>
>> Can you put the card in a PC and send the list of file in the FAT
>> partition?
>>
>> Philip
>>
>>
>>>
>>> I got the above message for sdimage-8G-zc702.direct. I get no message
 for
>>> the other image.
>>>
>>> What am I doing wrong?
>>>
>>> On Fri, Mar 13, 2015 at 11:22 AM, Philip Balister <
>> phi...@balister.org
>
>>> wrote:
>>>
 On 03/13/2015 01:17 PM, Alireza Khodamoradi wrote:
> Hello everyone,
>
> I'm going through the instructions from here:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Zynq

 I should go over those carefully, but in the mentime I have some
 images
 built for the zedbaord here:


>>

>> https://www.dropbox.com/sh/yfbpj63pcenqatr/AAAt0s3xFXs47I7q5pNopheHa?dl=0

 Take the zedboard one, uncompress it and write it to an sd card. Be
 sure
 to unmount (not eject) the sd card and run:

 sudo dd if=sdimage-8G-zedboard.direct of=/dev/sdX

 where sdx is the device the sd card is on.

 Philip

>
> to get a working image with gnu radio for my zedboard.
>
> Unfortunately I can't get the board to boot with this image. I was
> wondering if someone can help me.
>
> what I tried so far ( all failed - can't boot from the SDCard):
>
> - default settings in the instructions
> - renaming u-boot.bin to boot.bin
> - renaming u-boot.bin to BOOT.BIN
> - renaming uImage--zedboard-zynq7.dtb to devicetree.dtb
> - I tried command line as well as gparted gui.
>
> what I checked:
>
> - download a linux from XillyBus and boot the board with SDCard ->

[Discuss-gnuradio] Failed to install gnuradio with PyBOMBS

[Activecat]

Dear Sir,

Recently I failed to install GNU Radio using PyBOMBS.
Error message:

/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:750:95:
error: ‘volk_32fc_s32fc_multiply_32fc’ was not declared in this scope
/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:756:72:
error: cannot convert ‘gr_complex* {aka std::complex*}’ to ‘const
int*’ in argument passing
/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:780:71:
error: ‘volk_32fc_x2_multiply_conjugate_32fc’ was not declared in this scope
/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:785:62:
error: cannot convert ‘gr_complex* {aka std::complex*}’ to ‘const
int*’ in argument passing
make[2]: ***
[gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o]
Error 1
make[1]: *** [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
Linking CXX executable fcd_nfm_rx
[ 91%] Built target fcd_nfm_rx
Linking CXX shared module _qtgui_swig.so
[ 91%] Built target _qtgui_swig
Linking CXX shared module _digital_swig.so
[ 91%] Built target _digital_swig
make: *** [all] Error 2
Build failed. See output above for error messages.


The complete installation log is at
https://github.com/activecat/gnuradio/blob/master/installation_log_001.txt

I am using Debian 7.8 64bit.
Further details of system info is at
https://github.com/activecat/gnuradio/blob/master/system_info.txt

Please advise me how to solve this installation error.
Thank you very much.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Failed to install gnuradio with PyBOMBS

[Ron Economos]

I know what's causing this error. It's a function of using the GCC 4.7 
compiler. It works with GCC 4.8 or later because the define "complex" in 
 is undefined in .


I'll have a fix for this soon.

Ron

On 04/01/2015 04:57 PM, Activecat wrote:

Dear Sir,

Recently I failed to install GNU Radio using PyBOMBS.
Error message:

/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:750:95: 
error: 'volk_32fc_s32fc_multiply_32fc' was not declared in this scope
/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:756:72: 
error: cannot convert 'gr_complex* {aka std::complex*}' to 
'const int*' in argument passing
/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:780:71: 
error: 'volk_32fc_x2_multiply_conjugate_32fc' was not declared in this 
scope
/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:785:62: 
error: cannot convert 'gr_complex* {aka std::complex*}' to 
'const int*' in argument passing
make[2]: *** 
[gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o] 
Error 1

make[1]: *** [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
Linking CXX executable fcd_nfm_rx
[ 91%] Built target fcd_nfm_rx
Linking CXX shared module _qtgui_swig.so
[ 91%] Built target _qtgui_swig
Linking CXX shared module _digital_swig.so
[ 91%] Built target _digital_swig
make: *** [all] Error 2
Build failed. See output above for error messages.


The complete installation log is at 
https://github.com/activecat/gnuradio/blob/master/installation_log_001.txt


I am using Debian 7.8 64bit.
Further details of system info is at 
https://github.com/activecat/gnuradio/blob/master/system_info.txt


Please advise me how to solve this installation error.
Thank you very much.



___
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] Failed to install gnuradio with PyBOMBS

[Johnathan Corgan]

I believe Michael Dickens will have a comprehensive fix for issues like
this soon.

On Wed, Apr 1, 2015 at 5:44 PM, Ron Economos  wrote:

>  I know what's causing this error. It's a function of using the GCC 4.7
> compiler. It works with GCC 4.8 or later because the define "complex" in
>  is undefined in .
>
> I'll have a fix for this soon.
>
> Ron
>
>
> On 04/01/2015 04:57 PM, Activecat wrote:
>
> Dear Sir,
>
>  Recently I failed to install GNU Radio using PyBOMBS.
> Error message:
>
>  
> /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:750:95:
> error: ‘volk_32fc_s32fc_multiply_32fc’ was not declared in this scope
> /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:756:72:
> error: cannot convert ‘gr_complex* {aka std::complex*}’ to ‘const
> int*’ in argument passing
> /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:780:71:
> error: ‘volk_32fc_x2_multiply_conjugate_32fc’ was not declared in this scope
> /home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:785:62:
> error: cannot convert ‘gr_complex* {aka std::complex*}’ to ‘const
> int*’ in argument passing
> make[2]: ***
> [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o]
> Error 1
> make[1]: *** [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> Linking CXX executable fcd_nfm_rx
> [ 91%] Built target fcd_nfm_rx
> Linking CXX shared module _qtgui_swig.so
> [ 91%] Built target _qtgui_swig
> Linking CXX shared module _digital_swig.so
> [ 91%] Built target _digital_swig
> make: *** [all] Error 2
> Build failed. See output above for error messages.
>
>
>  The complete installation log is at
> https://github.com/activecat/gnuradio/blob/master/installation_log_001.txt
>
>  I am using Debian 7.8 64bit.
> Further details of system info is at
> https://github.com/activecat/gnuradio/blob/master/system_info.txt
>
>  Please advise me how to solve this installation error.
> Thank you very much.
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Failed to install gnuradio with PyBOMBS

[Michael Dickens]

I'm not sure my forthcoming pull request directly addresses these
specific issues, but it does a bunch of others for C++11 compliance in
std::complex -- whether or not you're using C++11; it's backward
compatible with C++0x and earlier, and should be forward compatible as
well. Before we address these specific issues, let's get my patches in
place -- they remove all of the GCC extensions to std::complex, so they
might have an impact on these issues. I should be able to do the PR
tomorrow; still testing on various systems tonight. - MLD

On Wed, Apr 1, 2015, at 09:24 PM, Johnathan Corgan wrote:
> I believe Michael Dickens will have a comprehensive fix for issues
> like this soon.

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

Re: [Discuss-gnuradio] Failed to install gnuradio with PyBOMBS

[Ron Economos]

In your previous pull request, you deleted the line:

#include 

in gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc

This would directly fix the build issues reported by Activecat and 
Marcus Leech.


Ron

On 04/01/2015 06:34 PM, Michael Dickens wrote:
I'm not sure my forthcoming pull request directly addresses these 
specific issues, but it does a bunch of others for C++11 compliance in 
std::complex -- whether or not you're using C++11; it's backward 
compatible with C++0x and earlier, and should be forward compatible as 
well. Before we address these specific issues, let's get my patches in 
place -- they remove all of the GCC extensions to std::complex, so 
they might have an impact on these issues. I should be able to do the 
PR tomorrow; still testing on various systems tonight. - MLD

On Wed, Apr 1, 2015, at 09:24 PM, Johnathan Corgan wrote:
I believe Michael Dickens will have a comprehensive fix for issues 
like this soon.



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

Re: [Discuss-gnuradio] Failed to install gnuradio with PyBOMBS

[Michael Dickens]

Ok; my PR will remove that header, so hopefully it'll take care of the
issue. - MLD

On Wed, Apr 1, 2015, at 09:49 PM, Ron Economos wrote:
> In your previous pull request, you deleted the line:
> 
> #include 
> 
> in gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc
> 
> This would directly fix the build issues reported by Activecat and 
> Marcus Leech.i

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

Re: [Discuss-gnuradio] Failed to install gnuradio with PyBOMBS

[Activecat]

Dear Sir,

I have comment out the "#include ", but still has error, as
below:

[ 80%] Building CXX object
gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o
[ 86%] Built target gnuradio-qtgui
[ 86%] Built target fcd_nfm_rx
[ 87%] Built target test_atsci
[ 87%] Built target _atsc_swig
[ 87%] Built target _qtgui_swig
[ 88%] Built target gnuradio-channels
[ 88%] Built target _channels_swig
[ 92%] Built target gnuradio-digital
[ 92%] Built target _digital_swig
[ 98%] Built target gnuradio-trellis
[ 98%] Built target _trellis_swig

/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:
In member function ‘virtual int gr::dtv::dvbt2_paprtr_cc_impl::work(int,
gr_vector_const_void_star&, gr_vector_void_star&)’:

/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:770:102:
error: ‘_Complex_I’ was not declared in this scope

/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:771:37:
error: ‘cexp’ was not declared in this scope

/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:772:48:
error: ‘creal’ was not declared in this scope

/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:773:49:
error: ‘cimag’ was not declared in this scope
make[2]: ***
[gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o]
Error 1
make[1]: *** [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/all] Error 2
make: *** [all] Error 2
Build failed. See output above for error messages.


The complete log is at
https://github.com/activecat/gnuradio/blob/master/installation_log_003.txt
Please advise, thanks.


On Thu, Apr 2, 2015 at 9:49 AM, Ron Economos  wrote:

> In your previous pull request, you deleted the line:
>
> #include 
>
> in gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc
>
> This would directly fix the build issues reported by Activecat and Marcus
> Leech.
>
> Ron
>
> On 04/01/2015 06:34 PM, Michael Dickens wrote:
>
>> I'm not sure my forthcoming pull request directly addresses these
>> specific issues, but it does a bunch of others for C++11 compliance in
>> std::complex -- whether or not you're using C++11; it's backward compatible
>> with C++0x and earlier, and should be forward compatible as well. Before we
>> address these specific issues, let's get my patches in place -- they remove
>> all of the GCC extensions to std::complex, so they might have an impact on
>> these issues. I should be able to do the PR tomorrow; still testing on
>> various systems tonight. - MLD
>> On Wed, Apr 1, 2015, at 09:24 PM, Johnathan Corgan wrote:
>>
>>> I believe Michael Dickens will have a comprehensive fix for issues like
>>> this soon.
>>>
>>
>
> ___
> 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] Failed to install gnuradio with PyBOMBS

[Marcus D. Leech]

On 04/01/2015 09:24 PM, Johnathan Corgan wrote:
I believe Michael Dickens will have a comprehensive fix for issues 
like this soon.
Ah, this probably explains my failure earlier today for apparently the 
same reason.





On Wed, Apr 1, 2015 at 5:44 PM, Ron Economos > wrote:


I know what's causing this error. It's a function of using the GCC
4.7 compiler. It works with GCC 4.8 or later because the define
"complex" in  is undefined in .

I'll have a fix for this soon.

Ron


On 04/01/2015 04:57 PM, Activecat wrote:

Dear Sir,

Recently I failed to install GNU Radio using PyBOMBS.
Error message:


/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:750:95:
error: 'volk_32fc_s32fc_multiply_32fc' was not declared in this scope

/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:756:72:
error: cannot convert 'gr_complex* {aka std::complex*}' to
'const int*' in argument passing

/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:780:71:
error: 'volk_32fc_x2_multiply_conjugate_32fc' was not declared in
this scope

/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:785:62:
error: cannot convert 'gr_complex* {aka std::complex*}' to
'const int*' in argument passing
make[2]: ***
[gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o]
Error 1
make[1]: *** [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
Linking CXX executable fcd_nfm_rx
[ 91%] Built target fcd_nfm_rx
Linking CXX shared module _qtgui_swig.so
[ 91%] Built target _qtgui_swig
Linking CXX shared module _digital_swig.so
[ 91%] Built target _digital_swig
make: *** [all] Error 2
Build failed. See output above for error messages.


The complete installation log is at
https://github.com/activecat/gnuradio/blob/master/installation_log_001.txt

I am using Debian 7.8 64bit.
Further details of system info is at
https://github.com/activecat/gnuradio/blob/master/system_info.txt

Please advise me how to solve this installation error.
Thank you very much.



___
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




--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com


___
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] Failed to install gnuradio with PyBOMBS

[Ron Economos]

The actual fix is a little more complicated. You can download a patched 
file from here:


http://www.w6rz.net/dvbt2_paprtr_cc_impl.cc

w6rz.net is my personal website.

Ron

On 04/01/2015 07:11 PM, Activecat wrote:

Dear Sir,

I have comment out the "#include ", but still has error, as 
below:


[ 80%] Building CXX object 
gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o

[ 86%] Built target gnuradio-qtgui
[ 86%] Built target fcd_nfm_rx
[ 87%] Built target test_atsci
[ 87%] Built target _atsc_swig
[ 87%] Built target _qtgui_swig
[ 88%] Built target gnuradio-channels
[ 88%] Built target _channels_swig
[ 92%] Built target gnuradio-digital
[ 92%] Built target _digital_swig
[ 98%] Built target gnuradio-trellis
[ 98%] Built target _trellis_swig
/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc: 
In member function ‘virtual int 
gr::dtv::dvbt2_paprtr_cc_impl::work(int, gr_vector_const_void_star&, 
gr_vector_void_star&)’:
/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:770:102: 
error: ‘_Complex_I’ was not declared in this scope
/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:771:37: 
error: ‘cexp’ was not declared in this scope
/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:772:48: 
error: ‘creal’ was not declared in this scope
/home/sgku/download/gnuradio/pybombs/src/gnuradio/gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc:773:49: 
error: ‘cimag’ was not declared in this scope
make[2]: *** 
[gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/dvbt2/dvbt2_paprtr_cc_impl.cc.o] 
Error 1

make[1]: *** [gr-dtv/lib/CMakeFiles/gnuradio-dtv.dir/all] Error 2
make: *** [all] Error 2
Build failed. See output above for error messages.


The complete log is at 
https://github.com/activecat/gnuradio/blob/master/installation_log_003.txt

Please advise, thanks.


On Thu, Apr 2, 2015 at 9:49 AM, Ron Economos > wrote:


In your previous pull request, you deleted the line:

#include 

in gr-dtv/lib/dvbt2/dvbt2_paprtr_cc_impl.cc

This would directly fix the build issues reported by Activecat and
Marcus Leech.

Ron

On 04/01/2015 06:34 PM, Michael Dickens wrote:

I'm not sure my forthcoming pull request directly addresses
these specific issues, but it does a bunch of others for C++11
compliance in std::complex -- whether or not you're using
C++11; it's backward compatible with C++0x and earlier, and
should be forward compatible as well. Before we address these
specific issues, let's get my patches in place -- they remove
all of the GCC extensions to std::complex, so they might have
an impact on these issues. I should be able to do the PR
tomorrow; still testing on various systems tonight. - MLD
On Wed, Apr 1, 2015, at 09:24 PM, Johnathan Corgan wrote:

I believe Michael Dickens will have a comprehensive fix
for issues like this soon.



___
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] Weird build-gnuradio failures on Ubuntu

[Marcus D. Leech]

Got around to looking at build failures on Ubuntu today (on versions 
where it previously worked).


It turns out that Ubuntu *renamed* the libzmq packages to libzmq1 and 
the --ignore-missing directive isn't really what you expect it to be--it 
only
  ignores *repo* failures, NOT "I've never heard of this package 
before".  This combination of these two things is, IMHO, horrific. But I 
don't
  have a say, so I updated build-gnuradio to use the new package names 
for libzmq.   A distribution retroactively changing package names is just

  *totally wrong*, in my opinion.  But again, I don't really have a say.



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