Re: [Discuss-gnuradio] Store in a variable the output of the grinspector's blocks.

[CEL]

Oh, or try

from pmt.pmt_to_python import pmt_to_python as p2p

vector = p2p(message)
for elem in vector:
do_stuff_with_elem


On Wed, 2019-06-12 at 10:56 -0500, Daniel Andres Palacios wrote:
> Thanks Marcus, thats a good idea. I got the message from the debug block but, 
> is there a way to iterate over that message recieved? 
> When I pass pmt.is_vector(message) i got True, but then I can't get a 
> specific object in the vector because it hasn't a get attribute. 
> 
> sorry for the insistence, I kind of beginner and the PMT python API is not 
> specific enough
> 
> On Tue, Jun 11, 2019 at 12:27 PM Daniel Andres Palacios  
> wrote:
> > Ok. Thank you.
> >  I managed to get the messages from the debug block. Now, I have to deal 
> > with types conversation. 
> > 
> > Thanks 
> > 
> > On Tue, Jun 11, 2019 at 7:59 AM Müller, Marcus (CEL)  
> > wrote:
> > > But the debug block does exactly what you need: store the data and thus
> > > allow for analysis. Why don't you want to use it? Sounds like the right
> > > tool.
> > > 
> > > 
> > > On Tue, 2019-06-11 at 03:03 -0500, Daniel Andres Palacios wrote:
> > > > Hi. Thanks for your reply.
> > > > 
> > > > The signal extractor block's output is a vector of tuples with center 
> > > > frequency an band width. I want to know the length of the vector 
> > > > without using the debug block. And store the data for further 
> > > > processing.
> > > > 
> > > > On Tue, Jun 11, 2019, 02:22 Müller, Marcus (CEL)  
> > > > wrote:
> > > > > There's the function probes.
> > > > > 
> > > > > Using that is almost always a sign of bad design; what do you want to
> > > > > achieve that way?
> > > > > 
> > > > > Best regards,
> > > > > Marcus
> > > > > 
> > > > > On Sun, 2019-06-09 at 19:23 -0500, Daniel Andres Palacios wrote:
> > > > > > 
> > > > > > Hi everyone
> > > > > > it is there a way to get and store in a variable the output of gr-
> > > > > > inspector's blocks. 
> > > > > > 
> > > > > > -- 
> > > > > > Daniel Andrés Palacios Carabalí
> > > > > > Student of Telemathics engineering
> > > > > > Icesi University- Cali, Colombia
> > > > > > 
> > > > > > ___
> > > > > > 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
> > 
> > 
> > -- 
> > Daniel Andrés Palacios Carabalí
> > Student of Telemathics engineering
> > Icesi University- Cali, Colombia
> > ===
> > Estudiante de Ingeniería Telemática
> > Universidad Icesi. - Cali, Colombia
> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Store in a variable the output of the grinspector's blocks.

[CEL]

From the top of my head:

for i in range(pmt.length(message)):
 value = pmt.vector_ref(message, i)

PMT is not a beautiful construct in Python, sorry :(

Best regards,
Marcus

On Wed, 2019-06-12 at 10:56 -0500, Daniel Andres Palacios wrote:
> Thanks Marcus, thats a good idea. I got the message from the debug block but, 
> is there a way to iterate over that message recieved? 
> When I pass pmt.is_vector(message) i got True, but then I can't get a 
> specific object in the vector because it hasn't a get attribute. 
> 
> sorry for the insistence, I kind of beginner and the PMT python API is not 
> specific enough
> 
> On Tue, Jun 11, 2019 at 12:27 PM Daniel Andres Palacios  
> wrote:
> > Ok. Thank you.
> >  I managed to get the messages from the debug block. Now, I have to deal 
> > with types conversation. 
> > 
> > Thanks 
> > 
> > On Tue, Jun 11, 2019 at 7:59 AM Müller, Marcus (CEL)  
> > wrote:
> > > But the debug block does exactly what you need: store the data and thus
> > > allow for analysis. Why don't you want to use it? Sounds like the right
> > > tool.
> > > 
> > > 
> > > On Tue, 2019-06-11 at 03:03 -0500, Daniel Andres Palacios wrote:
> > > > Hi. Thanks for your reply.
> > > > 
> > > > The signal extractor block's output is a vector of tuples with center 
> > > > frequency an band width. I want to know the length of the vector 
> > > > without using the debug block. And store the data for further 
> > > > processing.
> > > > 
> > > > On Tue, Jun 11, 2019, 02:22 Müller, Marcus (CEL)  
> > > > wrote:
> > > > > There's the function probes.
> > > > > 
> > > > > Using that is almost always a sign of bad design; what do you want to
> > > > > achieve that way?
> > > > > 
> > > > > Best regards,
> > > > > Marcus
> > > > > 
> > > > > On Sun, 2019-06-09 at 19:23 -0500, Daniel Andres Palacios wrote:
> > > > > > 
> > > > > > Hi everyone
> > > > > > it is there a way to get and store in a variable the output of gr-
> > > > > > inspector's blocks. 
> > > > > > 
> > > > > > -- 
> > > > > > Daniel Andrés Palacios Carabalí
> > > > > > Student of Telemathics engineering
> > > > > > Icesi University- Cali, Colombia
> > > > > > 
> > > > > > ___
> > > > > > 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
> > 
> > 
> > -- 
> > Daniel Andrés Palacios Carabalí
> > Student of Telemathics engineering
> > Icesi University- Cali, Colombia
> > ===
> > Estudiante de Ingeniería Telemática
> > Universidad Icesi. - Cali, Colombia
> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Serial to parallel conversion

[CEL]

You want a vector to stream (not to "stream*s*") block.

The reality is that what OFDM block diagrams typically show as
"parallel to serial" block is usually not actually there in software or
hardware architecture. Authors just put these in there to say "hey,
look, we consider these consecutive data symbols as entries in a vector
now". I really don't know why the serial-to-parallel symbol stuck –
maybe because in hardware, smallish FFTs are often implemented in a
fully parallel fashion. 

Really, think of that block just as a "we hack our consecutive sample
stream into vectors of fixed length".

Best regards,
Marcus

On Wed, 2019-06-12 at 15:00 +0200, Sneha vasan wrote:
> Hi Everyone,
> 
>  I am currently trying to transmit and receive random signal using ofdm 
> modulation.
> So I generated the transmit signal using the MATLAB. Transmit this signal to 
> USRP and receive it.  So in order to demodulate the signal using ofdm scheme, 
> Firstly I am trying to convert this signal from serial to parallel 
> conversion. So in order to do that I am thinking to use vector to streams 
> block. Any suggestion on this? and also as the signal from the usrp is in 
> complex float , how do I convert it into the complex in order to connect the 
> vector to streams tag. 
> 
> Here I am trying to convert the vector into 4 streams and each stream of 
> length 16.
> 
> Regards,
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RTTY receiver

[CEL]

Hi Barry,

On Wed, 2019-06-12 at 06:59 -0400, ba...@dcsmail.net wrote:
> Hi Kyeong,
> 
> 1) In lib/radioteletype/baudot_encode_bb.h I tried replacing "static 
> const char" with "static const signed char", but it caused complications 
> in radioteletype/baudot_encode_bb.cc, so I took an alternate approach:

Wait, these filenames don't align with the ones I'm looking at – could
you verify we're both looking at the code from github.com/bitglue/gr-
radioteletype ?

Since this really just "spells out" the original code's intent, there
shouldn't be *any* problems at all with that. Maybe we should have a
look at these problems that arose?

> /*
>   * modified by Barry Duggan KV4FV
>   * 11 June 2019
>   * with RaspberryPi compiler, an error is produced comparing char and 
> signed char values.
>   * to circumvent this problem, I have changed all "-1" entries to "0x7f" 

Hm, -1 would be 0xFF in my math, wouldn't it? 0x7F is plain 127!

> in the table
>   * and in the code
>   */

By the way, spot the experienced old-school programmer: That's a
classical beautiful changelog comment from the pre-git era. Kudos :)
Always a pleasure to see. 

> So now the 'make' works without errors.

I presume that also includes the negative number comparisons in
lib/baudot_encode_bb_impl.cc 's general_work() function?

> 
> 2) In 'sudo make install' I got the following:
> -- Installing: 
> /usr/local/lib/python2.7/dist-packages/radioteletype/_radioteletype_swig.so
> -- Set runtime path of 
> "/usr/local/lib/python2.7/dist-packages/radioteletype/_radioteletype_swig.so" 
> to ""
> which leads to a run-time error...
> Traceback (most recent call last):
>File "/home/pi/gr-radioteletype/examples/rtty_demod.py", line 30, in 
> 
>  from radioteletype.demodulators import rtty_demod_cb
>File 
> "/usr/local/lib/python2.7/dist-packages/radioteletype/demodulators.py", 
> line 9, in 
>  from radioteletype_swig import (
>File 
> "/usr/local/lib/python2.7/dist-packages/radioteletype/radioteletype_swig.py", 
> line 21, in 
>  _radioteletype_swig = swig_import_helper()
>File 
> "/usr/local/lib/python2.7/dist-packages/radioteletype/radioteletype_swig.py", 
> line 20, in swig_import_helper
>  return importlib.import_module('_radioteletype_swig')
>File "/usr/lib/python2.7/importlib/__init__.py", line 37, in 
> import_module
>  __import__(name)
> ImportError: No module named _radioteletype_swig
> 
> So, where should '_radioteletype_swig.so' go, and how do I specify it?

That file should have gotten installed just OK if it was successfully
built. Are we sure that the build itself is successful? Sometimes, SWIG
(which generates our C++/Python glue half-automatedly) gets stuck, so
you really have to "make clean; make; make install". It's a bummer, but
I've seen it get nearly extinct over the years.

> 
> 3) When I loaded 'examples/rtty_demod.grc', there was a missing block 
> 'pulseaudio_pa_sink'. 

That seems to be a block from a different out-of-tree module. 

However, you really don't need a pulseaudio block to speak to that most
common Linux user audio subsystem. Just replace that block with the
"audio sink" that GNU Radio brings itself.

> Where is it, and what does it do? 

Its purpose is probably to send audio to your Sound card, in the end.

> Since it didn't 
> seem directly required for the rest of the example to work, I deleted it 
> and the two blocks feeding it.
> 
> 4) I really appreciate all that you and the others are doing to help 
> with this.

We really appreciate you asking here, so keep up the good work!

Cheers,
Marcus


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Live fm detection gr-inspector

[CEL]

Hi Daniel,

please remember to be specific when asking a question: "best way" is a
bit ambiguous, and "I'm not getting a good result" definitely is
insufficient for us to help you make things work better. What doesn't
work sufficiently well? What happens instead? 

Best regards,
Marcus

On Tue, 2019-06-11 at 12:36 -0500, Daniel Andres Palacios wrote:
> Hi to everyone.
> 
> What is the best way to receive all fm modifications. I'm usigin an B200 USRP.
> I think that putting the center frequency at 98M and a bandwidth of 20M is a 
> good way,but I'm not getting a good result. 
> 
> The idea is to detect all fm center frequencies using gr-inspector 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnuradio life cycle

[CEL]

Hi Daniel,

no, that's not right. 

In your program, whatever that is, if it wants to use GNU Radio:

You set up a bunch of blocks – to even instantiate them, their
constructors must return – and then tell the GNU Radio top_block to
connect them. After you've done with that, you tell the top_block to
run() or start() (and wait() until finished). 

That in turn allocates all the buffers between blocks, and then calls
every block's start() method (most blocks you'll see don't even
implement that) to make the block "ready".

After that, the scheduler starts doing its thing, which is calling all
the blocks' work() (or general_work()) methods, whenever there's new
input for a block and/or enough output space. 

Maybe [1] helps a bit.

Best regards,
Marcus


[1] https://www.gnuradio.org/blog/2017-01-05-buffers/
On Tue, 2019-06-11 at 12:30 -0500, Daniel Andres Palacios wrote:
> Hello to everyone.
> 
> Could somebody explain me what is the life cycle of a gnuradio program? I 
> understand that all the action occurs in the constructor of the main class. 
> Am I right?
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Output files in the VITA 49 format

[CEL]

Hi Sara,

stock GNU Radio indeed doesn't include any VITA49 I/O capabilities.

I'm not aware of any GNU Radio out-of-tree module that you could use to
gain that.

I know that Josh Blum wrote a VITA49 serializer for GREX, but that's
not compatible with GNU Radio. It might serve you as inspiration for
writing your own block, however: 

Since you only need to write very basic VITA49 packets, writing such a
block should be no big deal – Josh simply pieces together the binary
header manually in his grex/network/serializer.cpp; I find that
aesthetically unpleasing, to be honest. (I hope Josh doesn't mind me
saying that.) 

However, Eric Blossom, former GNU Radio maintainer of lore, has written
https://github.com/eblossom/vita-49, which should be an easy to use C++
library. But really, a C struct with bit alignment specifiers would
probably do for your limited use case. Upstream contributions more than
welcome!

Best regards,
Marcus M

On Tue, 2019-06-11 at 09:22 -0400, Sara Kim wrote:
> Hi,
> I'm very new to gnu radio. I have gnu radio companion running in Ubuntu on a 
> VM via VirtualBox. I'm using a USRPB200. I'm not understanding how I take the 
> raw IQ data received by my USRP B200 and output it into a file that's in the 
> VITA 49 format within gnu radio companion. There are some file sinks 
> available within gnu radio companion, but they don't seem to be what I am 
> looking for, or are they?
> 
> Thanks!
> Sara
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] names to use for ubuntu package manager to get install GNURadio

[CEL]

Hi,

a full agreement from my side: especially when using Ubuntu 19.04, you
get a pretty recent GNU Radio. If you want to talk to your hackRF, you
need gr-osmosdr, too, so

sudo apt install gnuradio gr-osmosdr

and the thing is set up.

Best regards,
Marcus

On Tue, 2019-06-11 at 10:18 -0400, Michael Dickens wrote:
> Hi geraldfenkell -
> 
> On modern Ubuntu, you should be able to just issue "sudo apt install 
> gnuradio" and after some ado GNU Radio will be installed. See also < 
> https://wiki.gnuradio.org/index.php/InstallingGR#Linuxux >.
> 
> The HackRF software interface should be pretty easily installable on Ubuntu 
> (or any other UNIX-y system), and then you can use a GR out-of-tree (OOT) 
> such as "gr-osmosdr" to get a GR interface to your HackRF One.
> 
> Hope this is useful & good luck! - MLD
> 
> On Tue, Jun 11, 2019, at 10:05 AM, geraldfenkell wrote:
> > 2019-06-11
> >  
> > I have successfully installed GNURadio on my Windows 10 machine and also 
> > have a live usb thumb drive for two 
> > versions of ubuntu (18.04.2 and 19.04).  I now wish to use the package 
> > manager for these ubuntu systems to apt get install
> > GNURadio and companion.  I do not know the names to use for the package nor 
> > how to find them out.
> >  
> > Help would be appreciated.
> >  
> > Please note that after I do that, I want to install (from his git 
> > repository) the Michael Ossmann add on
> > for GNURadio to use HackRF One with GNURadio to follow his course.  I have 
> > not had any success with
> > getting a working version of Pentoo Linux to a Live USB Drive and/or 
> > getting Live SDR of GNURadio (which
> > does contain the necessary blocks) but says in its wikipedea that it is 
> > "retired". i.e. not available. I presume
> > that I will run into some problems  with dependencies (but will gain 
> > experience) when I try to "compile" the
> > material from his Git repository.  
> >  
> > Thank you
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Store in a variable the output of the grinspector's blocks.

[CEL]

But the debug block does exactly what you need: store the data and thus
allow for analysis. Why don't you want to use it? Sounds like the right
tool.


On Tue, 2019-06-11 at 03:03 -0500, Daniel Andres Palacios wrote:
> Hi. Thanks for your reply.
> 
> The signal extractor block's output is a vector of tuples with center 
> frequency an band width. I want to know the length of the vector without 
> using the debug block. And store the data for further processing.
> 
> On Tue, Jun 11, 2019, 02:22 Müller, Marcus (CEL)  wrote:
> > There's the function probes.
> > 
> > Using that is almost always a sign of bad design; what do you want to
> > achieve that way?
> > 
> > Best regards,
> > Marcus
> > 
> > On Sun, 2019-06-09 at 19:23 -0500, Daniel Andres Palacios wrote:
> > > 
> > > Hi everyone
> > > it is there a way to get and store in a variable the output of gr-
> > > inspector's blocks. 
> > > 
> > > -- 
> > > Daniel Andrés Palacios Carabalí
> > > Student of Telemathics engineering
> > > Icesi University- Cali, Colombia
> > > 
> > > ___
> > > 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


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Store in a variable the output of the grinspector's blocks.

[CEL]

There's the function probes.

Using that is almost always a sign of bad design; what do you want to
achieve that way?

Best regards,
Marcus

On Sun, 2019-06-09 at 19:23 -0500, Daniel Andres Palacios wrote:
> 
> Hi everyone
> it is there a way to get and store in a variable the output of gr-
> inspector's blocks. 
> 
> -- 
> Daniel Andrés Palacios Carabalí
> Student of Telemathics engineering
> Icesi University- Cali, Colombia
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RTTY receiver

[CEL]

Yeah, char signedness is compiler-dependent (and can be configured with
-f[un]signed-char in GCC). Neither C nor C++ specify a "default"
signedness in the standard.

So, if you want to do arithmetic on chars, you need to specify which
data type you'd want – signed char or unsigned char. 
That's what Kyeong's change does. 

If it works without, it's by luck.

If you look into embedded software, you'll often find that C developers
prefer to use `int8_t` instead of `signed char` and `uint8_t` instead
of `unsigned char` if they're using these datatypes to (logically)
transport bytes of data or actually numbers, as opposed to dealing with
character data ("text" in the human sense, not the ld sense).

Here it's kind of a hybrid, so explicity saying you want unsigned char
is probably the most intuitive :)

Thanks for this discussion!

Best regards,
Marcus

On Mon, 2019-06-10 at 23:27 -0700, Cinaed Simson wrote:
> On 6/10/19 9:05 PM, Kyeong Su Shin wrote:
> > Hello Barry,
> > 
> > 
> > Apparantly, the module has portability issues (will build on x86
> > but
> > won't build on ARM) due to data type issues.
> 
> It builds find on my ARM 64 Odroid running jessie. Maybe it just
> doesn't
> build on the raspberry pi 3. I'm running a slightly dated version of
> gnuradio - 3.7.12git-295-ga0adcd33.
> 
> -- Cinaed
> 
>  To build the package, you
> > will have to edit lib/baudot_encode_bb_impl.h:
> > 
> > 
> > "static const char ascii_to_letters[128]" should become
> > 
> > 
> > "static const *signed* char ascii_to_letters[128]",  and
> > 
> > 
> > "static const char ascii_to_figures[128]" should become
> > 
> > 
> > "static const *signed* char ascii_to_figures[128]".
> > 
> > 
> > That will allow the module to build, although you may have to make
> > further changes to get "Boudot Encode" block working correctly (I
> > didn't
> > test that; maybe I should make a pull request after that).
> > 
> > 
> > Regards,
> > 
> > Kyeong Su Shin
> > 
> > 
> > -
> > ---
> > *보낸 사람:* ba...@dcsmail.net 
> > *보낸 날짜:* 2019년 6월 11일 화요일 오전 2:56:02
> > *받는 사람:* Kyeong Su Shin
> > *참조:* discuss-gnuradio@gnu.org
> > *제목:* Re: [Discuss-gnuradio] RTTY receiver
> >  
> > Thank you for your response. Since this is my first issue on
> > 'discuss-gnuradio', I am not sure how to get my reply to you posted
> > in
> > the thread. This looks like it might work. If not, please let me
> > know
> > what to do.
> > 
> > I did the "sudo ldconfig" and it got rid of the "include could not
> > find
> > load file: GrPython", but not the other problem, so I decided to
> > start
> > from scratch.
> > 
> > I have
> > Raspberry Pi 3 B+
> > Rasbian Linux (v2)
> > 
> > I deleted the folder 'gr-radioteletype'
> > download zip from https://github.com/bitglue/gr-radioteletype
> > 
> > 
> > GitHub - bitglue/gr-radioteletype: GNU Radio blocks for RTTY and
> > PSK31
> > 
> > github.com
> > GNU Radio blocks for RTTY and PSK31. Contribute to
> > bitglue/gr-radioteletype development by creating an account on
> > GitHub.
> > 
> > 
> > extract zip to /home/pi
> > cd ~/gr-radioteletype-master
> > mkdir build
> > cd build
> > cmake ../
> > make
> > [  5%] Building CXX object
> > lib/CMakeFiles/gnuradio-
> > radioteletype.dir/async_word_extractor_bb_impl.cc.o
> > [ 10%] Building CXX object
> > lib/CMakeFiles/gnuradio-
> > radioteletype.dir/baudot_decode_bb_impl.cc.o
> > [ 15%] Building CXX object
> > lib/CMakeFiles/gnuradio-
> > radioteletype.dir/baudot_encode_bb_impl.cc.o
> > In file included from
> > /home/pi/gr-radioteletype-master/lib/baudot_encode_bb_impl.cc:26:0:
> > /home/pi/gr-radioteletype-master/lib/baudot_encode_bb_impl.h:65:5:
> > error: narrowing conversion of ‘-1’ from ‘int’ to ‘char’ inside { }
> > [-Wnarrowing]
> >   };
> >   ^
> > /home/pi/gr-radioteletype-master/lib/baudot_encode_bb_impl.h:100:5:
> > error: narrowing conversion of ‘-1’ from ‘int’ to ‘char’ inside { }
> > [-Wnarrowing]
> >   };
> >   ^
> > /home/pi/gr-radioteletype-master/lib/baudot_encode_bb_impl.h:100:5:
> > error: narrowing conversion of ‘-1’ from ‘int’ to ‘char’ inside { }
> > [-Wnarrowing]
> > lib/CMakeFiles/gnuradio-radioteletype.dir/build.make:110: recipe
> > for
> > target
> > 'lib/CMakeFiles/gnuradio-
> > radioteletype.dir/baudot_encode_bb_impl.cc.o'
> > failed
> > make[2]: ***
> > [lib/CMakeFiles/gnuradio-
> > radioteletype.dir/baudot_encode_bb_impl.cc.o]
> > Error 1
> > CMakeFiles/Makefile2:137: recipe for target
> > 'lib/CMakeFiles/gnuradio-radioteletype.dir/all' failed
> > make[1]: *** [lib/CMakeFiles/gnuradio-radioteletype.dir/all] Error
> > 2
> > Makefile:138: recipe for target 'all' failed
> > make: *** [all] Error 2
> > 
> > Both of the error messages were repeated *many* times. I looked at
> > the
> > code for baudot_encode_bb_impl.h, but could not see any problems
> > with
> > it.
> > 
> > I appreciate any

Re: [Discuss-gnuradio] Determining distance from OFDM signals

[CEL]

Hi Qasim,

a) it's so nice to see you drop in here from time to time :)
b) that's true! But reality is even better; the back and forth exchange
isn't strictly necessary.
c) I finally find the time to write down what I wanted to write.

## First, agreeing with you:

One can basically emulate the principle of a correlation-based radar by
making the other end "reflect" info with a known delay.

All one needs to do is ensure that a reply packet is sent a *fixed*
amount of time after a packet is received. That interval doesn't have
to be necessarily short, just known.

From the reply, and its knowledge of the original transmission's time,
the original transmitter can deduce the double of the one-way
transmission latency; that can, given enough bandwidth, SNR and
processing gain, be enough to resolve integer wavelength ambiguities.
In practice, passband bandwidth will often be the fundamentally
limiting factor.

With the phase estimate done on the reply, and info on the phase
estimate done by the replying party, both sides would have relative
phase CSI, and the original transmitter a distance estimate. 

## Then, disagreeing with you (just a little bit):

Now, while the above works with any transmission that allows phase
recovery, OFDM frames have the advantage of allowing a two-dimensional
DFT to be used to estimate range through the time-shift property of the
DFT. However, that requires knowledge of the transmitted symbols at the
receiver – which luckily is recoverable in case of successful OFDM
communication¹.

In fact, that's how OFDM radar works very nicely; it's explained in
[1].

Imagine a receiver with knowledge of the transmitted signal. While
lacking a common time base, a receiver can infer distance from the
development of the phases of entries of a sufficiently large (in both
number of OFDM symbols and number of subcarriers) OFDM frame.

The idea is simple: assume you know the symbols at the transmitter. The
speed-of-light induced delay is constant across all subcarriers.
The resulting phase shift, thus, is proportional to the subcarrier
frequency, and hence the subcarrier number.
Therefor, when you observe linear channel phase change over subcarrier,
you can get a distance estimate. Phase being a linear function of index
implies we're dealing with a sinusoid – and a DFT in subcarrier
direction will give us a range plot.

Same idea for Doppler, but with phase on the same subcarrier, but for
consecutive and hence constant-interval OFDM symbols; do another DFT
for each subcarrier across OFDM symbols, and get a doppler plot.

Overall: Write down your received OFDM symbols as column vectors of a
matrix, point-wise divide by the transmitted symbols (normalize
amplitude if helpful); the result is a matrix full of complex numbers
with the channel phase for each subcarrier at each symbol time. 
Do an appropriate 2D-DFT, get a range/doppler plane "image". Find the
peak; use clever interpolation / post-processing to increase resolution
and/or reduce estimate variance.

Cheers,
Marcus

¹  (unless someone inexplicably decided to use differential PSK on the
subcarriers – looking at DAB, there.)

[1] https://publikationen.bibliothek.kit.edu/138892

On Sat, 2019-06-08 at 14:21 +1000, Qasim Chaudhari wrote:
> Phase information is preserved whether the Rx architecture is zero-IF 
> or not. The OP I guess is already using a back and forth exchange
> between two USRPs, from which the distance information can be
> extracted in case of OFDM signals.
> 
> Cheers,
> Qasim
> 
> 
> On Sat, Jun 8, 2019 at 4:05 AM 
> wrote:
> > Send Discuss-gnuradio mailing list submissions to
> > discuss-gnuradio@gnu.org
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > or, via email, send a message with subject or body 'help' to
> > discuss-gnuradio-requ...@gnu.org
> > 
> > You can reach the person managing the list at
> > discuss-gnuradio-ow...@gnu.org
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Discuss-gnuradio digest..."
> > 
> > 
> > Today's Topics:
> > 
> >1. Re: test message please ignore (Marcus Müller)
> >2. Help with sound output (Sara Kim)
> >3. Re: Help with sound output (Michael Dickens)
> >4. Re: Getting a Runtime Error: gr::tuntap_pdu::make: tun_alloc
> >   failed (Adrian Musceac)
> >5. Re: query regarding wav file recording through wav file sink
> >   block (Maitry Raval)
> >6. Re: query regarding wav file recording through wav file sink
> >   block (Müller)
> >7. Re: query regarding wav file recording through wav file sink
> >   block (Maitry Raval)
> >8. Re: Request for comment: FFT optimizations (Müller)
> >9. Re: query regarding wav file recording through wav file sink
> >   block (Müller)
> >   10. Re: query regarding wav file recording through wav file sink
> >   block (Maitry Raval)
> >   

Re: [Discuss-gnuradio] Determining distance from OFDM signals

[CEL]

Well, you can go ahead and at least to a degree enforce a known
relative phase between transmitter and receiver, but yeah, without
extensive external synchronization effort (e.g. GPSDOs – hi there, u-
blox :) ), the receiver phase is random relative to the transmitter's
phase. So, the distance can't be recovered from a one-way transmission.

Best regards,
Marcus

On Fri, 2019-06-07 at 10:21 +, Jonas Manthey wrote:
> Hi Andrew,
>  
> What do you mean by “information from the carrier data”? I’m no OFDM expert, 
> but my intuition tells me that in a zero-IF architecture (which I assume your 
> USRP has) any carrier phase information is lost. There’s some results when 
> googling for “OFDM ranging” maybe that helps.
>  
> Cheers,
> Jonas
>  
> From: Discuss-gnuradio 
> [mailto:discuss-gnuradio-bounces+jonas.manthey=u-blox@gnu.org] On Behalf 
> Of Andrew Wolfram
> Sent: Donnerstag, 6. Juni 2019 01:20
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] Determining distance from OFDM signals
>  
> Hi,
>  
> I'm trying to alter the file ofdm_txrx.py 
> (https://github.com/gnuradio/gnuradio/blob/master/gr-digital/python/digital/ofdm_txrx.py)
>  to get phase information from the carrier data so I can calculate an 
> approximate distance between two USRP devices. Ideally I want to grab data 
> from one of the blocks in the rx pipeline in the above python file after the 
> frequency/timing corrections have been applied. I tried using the data after 
> the serializer block, but it appears that this has no phase information. I 
> tried with the equalizer block output but I'm not sure how to interpret its 
> output data. For my particular payload with 300 occupied carriers and an fft 
> size of 512 only the first 214 items of the equalizer output vector have any 
> phase information, so I'm somewhat confused. Any ideas?
>  
> Thanks,
> Andrew
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

[CEL]

Hello,

On Fri, 2019-06-07 at 12:40 +0530, Maitry Raval wrote:
> Hello,
> 
> I am using USRP-B200 mini, and as I want to use USRP offline, that's
> why I am trying to record the transmitted modulated signal through
> UHD USRP source to some file, Is it ok to use .txt file for this?

Again, the filename says *nothing* about a file's contents. So it's OK,
it's just utterly misleading, because there's absolutely no text
inside.

> And the problem arise in this is , when the signal is being recorded
> in a wav file through wav file sink, then the recorded wav file's
> amplitude is lower than the the signal I have seen during simulation
> in time sink and FFt sink.
> 

Wait, the amplitude of the wav file saved with the wav file sink is
different when you open it with a wav file source? Or how do you open
it?

Reminder, again: Files are *interpreted* by the reading software. GNU
Radio maps -1 to +1 to the full scale of the wav file's sample format.
Other software might do something else.

Best regards,
Marcus

> With Best Regards,
> Maitry Raval,
> 
> 
> - Original Message -
> From: "Marcus Müller, CEL" 
> To: "maitry raval" 
> Cc: "discuss-gnuradio" 
> Sent: Friday, 7 June, 2019 06:42:44
> Subject: Re: query regarding wav file recording through wav file sink
> block
> 
> 256 kHz is not a sampling rate supported by many devices. What USRP
> are
> you using?
> 
> Also, the filename doesn't matter to its content at all, so this is
> fine, but using .txt for a file that contains raw binary samples is
> questionable.
> 
> So, back to your original problem: can you describe how the result of
> the operation is different from what you're expecting? I still must
> admit I don't get where the problem lies.
> 
> Best regards,
> Marcus
> 
> On Fri, 2019-06-07 at 10:04 +0530, Maitry Raval wrote:
> > Hello,
> > 
> > PLease find attached flowgraph for other end of txt file writing,
> > as
> > I have received the transmitted signal through UHD USRP source
> > block
> > and record it in a text file at 256k sample rate and then this
> > recorded text file is being used in next flow graph for converting
> > it
> > into wav file.
> > 
> > that means I have received the modulated transmitted signal, record
> > it in txt file and remove noise as well resample it to 48k in order
> > to save that downcoverted signal to wav file sink.
> > 
> > With Best Regards,
> > Maitry Raval,
> > 
> > - Original Message -
> > From: "Marcus Müller, CEL" 
> > To: "maitry raval" 
> > Cc: "discuss-gnuradio" 
> > Sent: Wednesday, 5 June, 2019 07:09:42
> > Subject: Re: query regarding wav file recording through wav file
> > sink
> > block
> > 
> > we really need both your Wav writing (we've got that) and Wav
> > reading
> > flow graph to make any qualified statement. 
> > 
> > Again, the file name in your file source is suspicious. 
> > 
> > Best regards,
> > Marcus
> > 
> > On Wed, 2019-06-05 at 10:54 +0530, Maitry Raval wrote:
> > > Hello,
> > > 
> > > Please check the flowgraph, as there is a wav file sink at output
> > > side, that record the incoming signal, but when I use that same
> > > recorded wav file in wav file source and check the output in time
> > > sink and FFT sink, then amplitude changes.
> > > 
> > > With Best Regards,
> > > Maitry Raval,
> > > 
> > > 
> > > - Original Message -
> > > From: "Marcus Müller, CEL" 
> > > To: "maitry raval" 
> > > Cc: "discuss-gnuradio" 
> > > Sent: Tuesday, 4 June, 2019 13:01:55
> > > Subject: Re: query regarding wav file recording through wav file
> > > sink
> > > block
> > > 
> > > Ok, there's no Wave file involved here; instead, you read a file
> > > as
> > > complex 2×3bit floating point binary that has a .txt ending. Have
> > > you
> > > read [1]?
> > > Then, you're doing *way* more than just multiplying with a
> > > constant,
> > > so
> > > really, I'm not sure this flow graph has *anything* to do with
> > > your
> > > question.
> > > 
> > > [1] 
> > > https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F
> > > 
> > > On Tue, 2019-06-04 at 15:17 +0530, Maitry Raval wrote:
> > > > 

Re: [Discuss-gnuradio] Request for comment: FFT optimizations

[CEL]

Hi Johannes,

always remember that the "f" suffix after fftw is just for "float",
without that suffix you use the double precision FFTw.

> fftwf_execute_dft(plan, *in, *out) 

http://www.fftw.org/fftw3_doc/New_002darray-Execute-Functions.html

> fftwf_alignment_of()

same page, and

http://www.fftw.org/fftw3_doc/Planner-Flags.html#index-fftw_005falignment_005fof

under "FFTW_UNALIGNED".

also, and this might be a bit of a downer: use the source, Luke!

(also, this might even be more of a downer:)
fftw3/kernel/align.c, reduced by all false #if:

#define ALGN 16
int X(ialignment_of)(R *p)
{
 return (int)(((uintptr_t) p) % ALGN);
}

or in other words:

address % 16

However, we should really be using the fftw function for that, in case
they get around to writing say AVX7 FFT kernels, which need 2048-byte
aligned memory instructions or so¹.

Best regards,
Marcus

¹if you're from the year 2028, and are reading up on intels new AVX7
instruction on the GNU Radio mailing list archive: this is a joke.
Obviously, AVX7 only needs 1024-byte alignment and that you only use
right-hand quantum registers.

On Fri, 2019-06-07 at 07:51 +, Johannes Demel wrote:
> Hi Marcus,
> 
> do you have any online resources that point to the official 
> documentation of `fftwf_execute_dft(plan, *in, *out)` and 
> `fftwf_alignment_of()`? (for the latter this mail thread is on the
> first 
> page of my Google results.)
> All the documentation I could find is [0] and this seems like some
> Intel 
> wrapper that is not part of FFTW?!
> 
> Cheers
> Johannes
> 
> [0] 
> http://sep.stanford.edu/sep/claudio/Research/Prst_ExpRefl/ShtPSPI/intel/mkl/10.0.3.020/interfaces/fftw3xf/wrappers/fftwf_execute_dft.c
> 
> Am 06.06.19 um 14:57 schrieb Müller, Marcus (CEL):
> > Hi Albin,
> > 
> > no, it's not been discussed on the list, as far as my memory
> > reaches.
> > We're talking about gr:fft:fft_vcc, right?
> > 
> > Because that output memory shifting only happens when you set shift
> > = 1
> > in the constructor. I don't have any hard feelings about whether to
> > shift the output or perform an exp(j π n) frequency shift (a.k.a.
> > multiplying with +1 -1 …). My gut feeling is that copying blocks of
> > memory is probably significantly faster than accessing all elements
> > of
> > said blocks through the CPU sequentially. Memcpy implementations
> > are
> > heavily hand-assembler optimized!
> > 
> > However, the actual FFT would access these elements most
> > definitely,
> > so, for amounts of input samples smaller than the available CPU
> > cache,
> > the +1 -1 variant would act like an elegant prefetcher and probably
> > be
> > a bit more efficient, but for sizes larger, it would probably even
> > thrash the caches a bit and mean one additional loop over all data.
> > So, honestly, in many cases I'd expect a small improvement, in some
> > a
> > performance degradation. Not quite sure whether looking into that
> > is
> > clever.
> > 
> > I'd however say that it should be obvious to do the +1 -1 input
> > multiplication instead of the memcpy output shift if a window is
> > applied, because the +1 -1 can be absorbed into the window in that
> > case. (Watch out for the odd-length corner case where you get two
> > different windows depending on whether you do an odd- or an even-
> > numbered transform.)
> > 
> > There's another easy way we can optimize things at nearly zero
> > cost:
> > 
> > The memcpy to the FFTW input buffer only happens so that data is
> > properly aligned for FFTW to be able to use SIMD. Obviously, that
> > copy
> > could be avoided alltogether if the input *is* already aligned.
> > 
> > FFTW does have a fftwf_alignment_of() that you can use to compare
> > the
> > alignment of the especially aligned fftw plan input buffer, and the
> > current workload input pointer.
> > Same applies to the output buffer of the fftw plan and the output
> > pointer.
> > 
> > If the input buffer and the work input pointer, and the output
> > buffer
> > and the work output pointer, are of the same aligment, one could
> > simply
> > use fftwf_execute_dft(plan, *in, *out) instead of
> > fftwf_execute(plan),
> > and not memcpy anything (unless the user requests shifting).
> > 
> > Chances are that, considering our circular buffers are page-
> > aligned,
> > and that fft_length mod 4 = 0, for most applications,
> > 
> > fft_length * sizeof(gr_complex_float) = (fft_length/4) * 4 * 64
> > 
> > are typically already 256-byte ali

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

[CEL]

256 kHz is not a sampling rate supported by many devices. What USRP are
you using?

Also, the filename doesn't matter to its content at all, so this is
fine, but using .txt for a file that contains raw binary samples is
questionable.

So, back to your original problem: can you describe how the result of
the operation is different from what you're expecting? I still must
admit I don't get where the problem lies.

Best regards,
Marcus

On Fri, 2019-06-07 at 10:04 +0530, Maitry Raval wrote:
> Hello,
> 
> PLease find attached flowgraph for other end of txt file writing, as
> I have received the transmitted signal through UHD USRP source block
> and record it in a text file at 256k sample rate and then this
> recorded text file is being used in next flow graph for converting it
> into wav file.
> 
> that means I have received the modulated transmitted signal, record
> it in txt file and remove noise as well resample it to 48k in order
> to save that downcoverted signal to wav file sink.
> 
> With Best Regards,
> Maitry Raval,
> 
> - Original Message -
> From: "Marcus Müller, CEL" 
> To: "maitry raval" 
> Cc: "discuss-gnuradio" 
> Sent: Wednesday, 5 June, 2019 07:09:42
> Subject: Re: query regarding wav file recording through wav file sink
> block
> 
> we really need both your Wav writing (we've got that) and Wav reading
> flow graph to make any qualified statement. 
> 
> Again, the file name in your file source is suspicious. 
> 
> Best regards,
> Marcus
> 
> On Wed, 2019-06-05 at 10:54 +0530, Maitry Raval wrote:
> > Hello,
> > 
> > Please check the flowgraph, as there is a wav file sink at output
> > side, that record the incoming signal, but when I use that same
> > recorded wav file in wav file source and check the output in time
> > sink and FFT sink, then amplitude changes.
> > 
> > With Best Regards,
> > Maitry Raval,
> > 
> > 
> > - Original Message -
> > From: "Marcus Müller, CEL" 
> > To: "maitry raval" 
> > Cc: "discuss-gnuradio" 
> > Sent: Tuesday, 4 June, 2019 13:01:55
> > Subject: Re: query regarding wav file recording through wav file
> > sink
> > block
> > 
> > Ok, there's no Wave file involved here; instead, you read a file as
> > complex 2×3bit floating point binary that has a .txt ending. Have
> > you
> > read [1]?
> > Then, you're doing *way* more than just multiplying with a
> > constant,
> > so
> > really, I'm not sure this flow graph has *anything* to do with your
> > question.
> > 
> > [1] 
> > https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F
> > 
> > On Tue, 2019-06-04 at 15:17 +0530, Maitry Raval wrote:
> > > Hello,
> > > 
> > > Please check the flow graph.
> > > 
> > > 
> > > With Best Regards,
> > > Maitry Raval,
> > > 
> > > 
> > > - Original Message -
> > > From: "Marcus Müller, CEL" 
> > > To: "maitry raval" 
> > > Cc: "discuss-gnuradio" 
> > > Sent: Tuesday, 4 June, 2019 08:56:22
> > > Subject: Re: query regarding wav file recording through wav file
> > > sink block
> > > 
> > > Frankly, multiplication with a constant doesn't offer any
> > > benefit.
> > > The
> > > numbers stay the same, just scaled.
> > > 
> > > However, 8 bit might be the giveaway here: are you maybe trying
> > > to
> > > multiply 8 bit numbers with a constant that leads to values
> > > larger
> > > than
> > > what can be represented in 8 bits?
> > > 
> > > A screenshot of your flowgraph rather than just its result would
> > > be
> > > most interesting here.
> > > On Tue, 2019-06-04 at 13:58 +0530, Maitry Raval wrote:
> > > > Hello,
> > > > 
> > > > Thanks for your response.
> > > > 
> > > > My requirement is to use GNU generated wav file into MATLAB.
> > > > But
> > > > when I record the wav file with 48k sample rate and 8 bits per
> > > > sample, my recorded wavfile shows a very low amplitude signal,
> > > > the screenshot is attached, please check.
> > > > 
> > > > 
> > > > With Best Regards,
> > > > Maitry Raval,
> > > > 
> > > > 
> > > > - Original Message -
> > > > From: "

Re: [Discuss-gnuradio] Request for comment: FFT optimizations

[CEL]

Hi Albin,

no, it's not been discussed on the list, as far as my memory reaches.
We're talking about gr:fft:fft_vcc, right?

Because that output memory shifting only happens when you set shift = 1
in the constructor. I don't have any hard feelings about whether to
shift the output or perform an exp(j π n) frequency shift (a.k.a.
multiplying with +1 -1 …). My gut feeling is that copying blocks of
memory is probably significantly faster than accessing all elements of
said blocks through the CPU sequentially. Memcpy implementations are
heavily hand-assembler optimized!

However, the actual FFT would access these elements most definitely,
so, for amounts of input samples smaller than the available CPU cache,
the +1 -1 variant would act like an elegant prefetcher and probably be
a bit more efficient, but for sizes larger, it would probably even
thrash the caches a bit and mean one additional loop over all data.
So, honestly, in many cases I'd expect a small improvement, in some a
performance degradation. Not quite sure whether looking into that is
clever. 

I'd however say that it should be obvious to do the +1 -1 input
multiplication instead of the memcpy output shift if a window is
applied, because the +1 -1 can be absorbed into the window in that
case. (Watch out for the odd-length corner case where you get two
different windows depending on whether you do an odd- or an even-
numbered transform.)

There's another easy way we can optimize things at nearly zero cost:

The memcpy to the FFTW input buffer only happens so that data is
properly aligned for FFTW to be able to use SIMD. Obviously, that copy
could be avoided alltogether if the input *is* already aligned.

FFTW does have a fftwf_alignment_of() that you can use to compare the
alignment of the especially aligned fftw plan input buffer, and the
current workload input pointer.
Same applies to the output buffer of the fftw plan and the output
pointer.

If the input buffer and the work input pointer, and the output buffer
and the work output pointer, are of the same aligment, one could simply
use fftwf_execute_dft(plan, *in, *out) instead of fftwf_execute(plan),
and not memcpy anything (unless the user requests shifting).

Chances are that, considering our circular buffers are page-aligned,
and that fft_length mod 4 = 0, for most applications,

fft_length * sizeof(gr_complex_float) = (fft_length/4) * 4 * 64 

are typically already 256-byte aligned, and things are "inherently
good". 


Cheers,
Marcus

On Thu, 2019-06-06 at 11:13 +0200, Albin Stigö wrote:
> Hi,
> 
> There's a lot of memcpy/memmove going on in the FFT kernel which I
> suspect degrades performance quite a bit... This is partly because
> some platforms requires buffers to be aligned for SIMD to work and
> partly because DC is not normally centered (which is normally what you
> would like to see in a spektrum).
> 
> For ARM in particular the alignment requirements are less strict so
> that would get rid of at least one memcpy for that platform.
> 
> For centering an FFT at DC there's a nice trick, you just rotate the
> input by pi, that is multiply by 1, -1, 1, -1... I suspect that would
> be quite a bit faster than two memcpy and should be available on all
> platforms.
> 
> Has this been discussed on the list before?
> 
> 
> --Albin
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

[CEL]

we really need both your Wav writing (we've got that) and Wav reading
flow graph to make any qualified statement. 

Again, the file name in your file source is suspicious. 

Best regards,
Marcus

On Wed, 2019-06-05 at 10:54 +0530, Maitry Raval wrote:
> Hello,
> 
> Please check the flowgraph, as there is a wav file sink at output
> side, that record the incoming signal, but when I use that same
> recorded wav file in wav file source and check the output in time
> sink and FFT sink, then amplitude changes.
> 
> With Best Regards,
> Maitry Raval,
> 
> 
> - Original Message -
> From: "Marcus Müller, CEL" 
> To: "maitry raval" 
> Cc: "discuss-gnuradio" 
> Sent: Tuesday, 4 June, 2019 13:01:55
> Subject: Re: query regarding wav file recording through wav file sink
> block
> 
> Ok, there's no Wave file involved here; instead, you read a file as
> complex 2×3bit floating point binary that has a .txt ending. Have you
> read [1]?
> Then, you're doing *way* more than just multiplying with a constant,
> so
> really, I'm not sure this flow graph has *anything* to do with your
> question.
> 
> [1] 
> https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F
> 
> On Tue, 2019-06-04 at 15:17 +0530, Maitry Raval wrote:
> > Hello,
> > 
> > Please check the flow graph.
> > 
> > 
> > With Best Regards,
> > Maitry Raval,
> > 
> > 
> > - Original Message -
> > From: "Marcus Müller, CEL" 
> > To: "maitry raval" 
> > Cc: "discuss-gnuradio" 
> > Sent: Tuesday, 4 June, 2019 08:56:22
> > Subject: Re: query regarding wav file recording through wav file
> > sink block
> > 
> > Frankly, multiplication with a constant doesn't offer any benefit.
> > The
> > numbers stay the same, just scaled.
> > 
> > However, 8 bit might be the giveaway here: are you maybe trying to
> > multiply 8 bit numbers with a constant that leads to values larger
> > than
> > what can be represented in 8 bits?
> > 
> > A screenshot of your flowgraph rather than just its result would be
> > most interesting here.
> > On Tue, 2019-06-04 at 13:58 +0530, Maitry Raval wrote:
> > > Hello,
> > > 
> > > Thanks for your response.
> > > 
> > > My requirement is to use GNU generated wav file into MATLAB. But
> > > when I record the wav file with 48k sample rate and 8 bits per
> > > sample, my recorded wavfile shows a very low amplitude signal,
> > > the screenshot is attached, please check.
> > > 
> > > 
> > > With Best Regards,
> > > Maitry Raval,
> > > 
> > > 
> > > - Original Message -
> > > From: "Marcus Müller, CEL" 
> > > To: "maitry raval" 
> > > Cc: "discuss-gnuradio" 
> > > Sent: Tuesday, 4 June, 2019 08:02:48
> > > Subject: Re: query regarding wav file recording through wav file
> > > sink block
> > > 
> > > I assume you do the multiplication with a constance to change the
> > > amplitude, and so that's right.
> > > 
> > > A multiplication with a constant does however not change the
> > > shape of
> > > the signal at all, unless you're running into numerical limits. 
> > > 
> > > We'll need more info on what exactly you're doing and what
> > > exactly
> > > you're seeing.
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > On Tue, 2019-06-04 at 10:22 +0530, Maitry Raval wrote:
> > > > Hello,
> > > > And when I use multiply constant block in order to increase the
> > > > amplitude of the wav file, It slightly change the amplitude and
> > > > change the shape of the signal. PLease someone guide.
> > > > 
> > > > 
> > > > With Best Regards,
> > > > Maitry Raval,
> > > > 
> > > > - Original Message -
> > > > From: "Maitry Raval" 
> > > > To: "Marcus Müller, CEL" 
> > > > Cc: "discuss-gnuradio" 
> > > > Sent: Monday, 3 June, 2019 10:14:11
> > > > Subject: Re: [Discuss-gnuradio] query regarding store
> > > > transmitted signal
> > > > 
> > > > Hello,
> > > > 
> > > > PLease someone guide about wav file recording signal's
> > > > amplitude. as I have a requir

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

[CEL]

Ok, there's no Wave file involved here; instead, you read a file as
complex 2×3bit floating point binary that has a .txt ending. Have you
read [1]?
Then, you're doing *way* more than just multiplying with a constant, so
really, I'm not sure this flow graph has *anything* to do with your
question.

[1] 
https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F

On Tue, 2019-06-04 at 15:17 +0530, Maitry Raval wrote:
> Hello,
> 
> Please check the flow graph.
> 
> 
> With Best Regards,
> Maitry Raval,
> 
> 
> - Original Message -
> From: "Marcus Müller, CEL" 
> To: "maitry raval" 
> Cc: "discuss-gnuradio" 
> Sent: Tuesday, 4 June, 2019 08:56:22
> Subject: Re: query regarding wav file recording through wav file sink block
> 
> Frankly, multiplication with a constant doesn't offer any benefit. The
> numbers stay the same, just scaled.
> 
> However, 8 bit might be the giveaway here: are you maybe trying to
> multiply 8 bit numbers with a constant that leads to values larger than
> what can be represented in 8 bits?
> 
> A screenshot of your flowgraph rather than just its result would be
> most interesting here.
> On Tue, 2019-06-04 at 13:58 +0530, Maitry Raval wrote:
> > Hello,
> > 
> > Thanks for your response.
> > 
> > My requirement is to use GNU generated wav file into MATLAB. But when I 
> > record the wav file with 48k sample rate and 8 bits per sample, my recorded 
> > wavfile shows a very low amplitude signal, the screenshot is attached, 
> > please check.
> > 
> > 
> > With Best Regards,
> > Maitry Raval,
> > 
> > 
> > - Original Message -
> > From: "Marcus Müller, CEL" 
> > To: "maitry raval" 
> > Cc: "discuss-gnuradio" 
> > Sent: Tuesday, 4 June, 2019 08:02:48
> > Subject: Re: query regarding wav file recording through wav file sink block
> > 
> > I assume you do the multiplication with a constance to change the
> > amplitude, and so that's right.
> > 
> > A multiplication with a constant does however not change the shape of
> > the signal at all, unless you're running into numerical limits. 
> > 
> > We'll need more info on what exactly you're doing and what exactly
> > you're seeing.
> > 
> > Best regards,
> > Marcus
> > 
> > On Tue, 2019-06-04 at 10:22 +0530, Maitry Raval wrote:
> > > Hello,
> > > And when I use multiply constant block in order to increase the amplitude 
> > > of the wav file, It slightly change the amplitude and change the shape of 
> > > the signal. PLease someone guide.
> > > 
> > > 
> > > With Best Regards,
> > > Maitry Raval,
> > > 
> > > - Original Message -
> > > From: "Maitry Raval" 
> > > To: "Marcus Müller, CEL" 
> > > Cc: "discuss-gnuradio" 
> > > Sent: Monday, 3 June, 2019 10:14:11
> > > Subject: Re: [Discuss-gnuradio] query regarding store transmitted signal
> > > 
> > > Hello,
> > > 
> > > PLease someone guide about wav file recording signal's amplitude. as I 
> > > have a requirement of using GNU generated wav file to my application, but 
> > > as amplitude of wav file is very low, I couldnot use that in my 
> > > application.
> > > 
> > > Thanks for your support in advance.
> > > 
> > > With Best Regards,
> > > Maitry Raval,
> > > 
> > > - Original Message -
> > > From: "Maitry Raval" 
> > > To: "Marcus Müller, CEL" 
> > > Cc: "discuss-gnuradio" 
> > > Sent: Monday, 20 May, 2019 05:16:52
> > > Subject: Re: [Discuss-gnuradio] query regarding store transmitted signal
> > > 
> > > Hello,
> > > 
> > > there is a amplitude change in signal source and wav file sink(recorded 
> > > wav file), please check the screenshots as well. I think, because of that 
> > > when I use the recorded wav file as source for transmission, I didnot get 
> > > the sucessful reception. Please guide how to record wav file with the 
> > > same amplitude as signal source.
> > > 
> > > Thanks for your support in advance.
> > > 
> > > 
> > > With Best Regards,
> > > Maitry Raval,
> > > 
> > > 
> > > - Original Message -
> > > From: "Maitry Raval" 
> > > 

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

[CEL]

Frankly, multiplication with a constant doesn't offer any benefit. The
numbers stay the same, just scaled.

However, 8 bit might be the giveaway here: are you maybe trying to
multiply 8 bit numbers with a constant that leads to values larger than
what can be represented in 8 bits?

A screenshot of your flowgraph rather than just its result would be
most interesting here.
On Tue, 2019-06-04 at 13:58 +0530, Maitry Raval wrote:
> Hello,
> 
> Thanks for your response.
> 
> My requirement is to use GNU generated wav file into MATLAB. But when I 
> record the wav file with 48k sample rate and 8 bits per sample, my recorded 
> wavfile shows a very low amplitude signal, the screenshot is attached, please 
> check.
> 
> 
> With Best Regards,
> Maitry Raval,
> 
> 
> ----- Original Message -
> From: "Marcus Müller, CEL" 
> To: "maitry raval" 
> Cc: "discuss-gnuradio" 
> Sent: Tuesday, 4 June, 2019 08:02:48
> Subject: Re: query regarding wav file recording through wav file sink block
> 
> I assume you do the multiplication with a constance to change the
> amplitude, and so that's right.
> 
> A multiplication with a constant does however not change the shape of
> the signal at all, unless you're running into numerical limits. 
> 
> We'll need more info on what exactly you're doing and what exactly
> you're seeing.
> 
> Best regards,
> Marcus
> 
> On Tue, 2019-06-04 at 10:22 +0530, Maitry Raval wrote:
> > Hello,
> > And when I use multiply constant block in order to increase the amplitude 
> > of the wav file, It slightly change the amplitude and change the shape of 
> > the signal. PLease someone guide.
> > 
> > 
> > With Best Regards,
> > Maitry Raval,
> > 
> > - Original Message -
> > From: "Maitry Raval" 
> > To: "Marcus Müller, CEL" 
> > Cc: "discuss-gnuradio" 
> > Sent: Monday, 3 June, 2019 10:14:11
> > Subject: Re: [Discuss-gnuradio] query regarding store transmitted signal
> > 
> > Hello,
> > 
> > PLease someone guide about wav file recording signal's amplitude. as I have 
> > a requirement of using GNU generated wav file to my application, but as 
> > amplitude of wav file is very low, I couldnot use that in my application.
> > 
> > Thanks for your support in advance.
> > 
> > With Best Regards,
> > Maitry Raval,
> > 
> > - Original Message -
> > From: "Maitry Raval" 
> > To: "Marcus Müller, CEL" 
> > Cc: "discuss-gnuradio" 
> > Sent: Monday, 20 May, 2019 05:16:52
> > Subject: Re: [Discuss-gnuradio] query regarding store transmitted signal
> > 
> > Hello,
> > 
> > there is a amplitude change in signal source and wav file sink(recorded wav 
> > file), please check the screenshots as well. I think, because of that when 
> > I use the recorded wav file as source for transmission, I didnot get the 
> > sucessful reception. Please guide how to record wav file with the same 
> > amplitude as signal source.
> > 
> > Thanks for your support in advance.
> > 
> > 
> > With Best Regards,
> > Maitry Raval,
> > 
> > 
> > - Original Message -
> > From: "Maitry Raval" 
> > To: "Marcus Müller, CEL" 
> > Cc: "discuss-gnuradio" 
> > Sent: Saturday, 18 May, 2019 08:29:16
> > Subject: Re: [Discuss-gnuradio] query regarding store transmitted signal
> > 
> > Hello,
> > 
> > Thanks for your reply.
> > I have successfully record one modulated signal transmitted from USRP into 
> > .txt file and done demodulation offline, i.e of that stored data and 
> > receive audio from that.
> > But, I have all this done with wav file which is 48k sampled. but my 
> > requiremnet is to do AM modulation of 600Hz audio file. for that, I have 
> > done the following.
> > 
> > signal source(600Hz,8K)- wav file sink
> > 
> > AM transmission of this wav file from USRP.
> > 
> > record AM modulated transmitted signal in .txt file.
> > 
> > and demodulate it in order to receive 600Hz, 8k wav file. during 
> > demodulation, I saw signal in scope sink and figure out frequency of that 
> > signal through FFT sink, biut when I record received 600Hz signal as wav 
> > file through wav file sink, then, that wav file's scope is blank, I get 
> > blank wva file, when am I doing wrong. I think, at transmitter side, 
> > amplitude of my original wav file source's amplitude is too low.
> > PLease guide.
&g

Re: [Discuss-gnuradio] query regarding wav file recording through wav file sink block

[CEL]

I assume you do the multiplication with a constance to change the
amplitude, and so that's right.

A multiplication with a constant does however not change the shape of
the signal at all, unless you're running into numerical limits. 

We'll need more info on what exactly you're doing and what exactly
you're seeing.

Best regards,
Marcus

On Tue, 2019-06-04 at 10:22 +0530, Maitry Raval wrote:
> Hello,
> And when I use multiply constant block in order to increase the amplitude of 
> the wav file, It slightly change the amplitude and change the shape of the 
> signal. PLease someone guide.
> 
> 
> With Best Regards,
> Maitry Raval,
> 
> - Original Message -
> From: "Maitry Raval" 
> To: "Marcus Müller, CEL" 
> Cc: "discuss-gnuradio" 
> Sent: Monday, 3 June, 2019 10:14:11
> Subject: Re: [Discuss-gnuradio] query regarding store transmitted signal
> 
> Hello,
> 
> PLease someone guide about wav file recording signal's amplitude. as I have a 
> requirement of using GNU generated wav file to my application, but as 
> amplitude of wav file is very low, I couldnot use that in my application.
> 
> Thanks for your support in advance.
> 
> With Best Regards,
> Maitry Raval,
> 
> - Original Message -
> From: "Maitry Raval" 
> To: "Marcus Müller, CEL" 
> Cc: "discuss-gnuradio" 
> Sent: Monday, 20 May, 2019 05:16:52
> Subject: Re: [Discuss-gnuradio] query regarding store transmitted signal
> 
> Hello,
> 
> there is a amplitude change in signal source and wav file sink(recorded wav 
> file), please check the screenshots as well. I think, because of that when I 
> use the recorded wav file as source for transmission, I didnot get the 
> sucessful reception. Please guide how to record wav file with the same 
> amplitude as signal source.
> 
> Thanks for your support in advance.
> 
> 
> With Best Regards,
> Maitry Raval,
> 
> 
> - Original Message -
> From: "Maitry Raval" 
> To: "Marcus Müller, CEL" 
> Cc: "discuss-gnuradio" 
> Sent: Saturday, 18 May, 2019 08:29:16
> Subject: Re: [Discuss-gnuradio] query regarding store transmitted signal
> 
> Hello,
> 
> Thanks for your reply.
> I have successfully record one modulated signal transmitted from USRP into 
> .txt file and done demodulation offline, i.e of that stored data and receive 
> audio from that.
> But, I have all this done with wav file which is 48k sampled. but my 
> requiremnet is to do AM modulation of 600Hz audio file. for that, I have done 
> the following.
> 
> signal source(600Hz,8K)- wav file sink
> 
> AM transmission of this wav file from USRP.
> 
> record AM modulated transmitted signal in .txt file.
> 
> and demodulate it in order to receive 600Hz, 8k wav file. during 
> demodulation, I saw signal in scope sink and figure out frequency of that 
> signal through FFT sink, biut when I record received 600Hz signal as wav file 
> through wav file sink, then, that wav file's scope is blank, I get blank wva 
> file, when am I doing wrong. I think, at transmitter side, amplitude of my 
> original wav file source's amplitude is too low.
> PLease guide.
> 
> 
> With Best Regards,
> Maitry Raval,
> 
> - Original Message -
> From: "Marcus Müller, CEL" 
> To: "maitry raval" 
> Cc: "discuss-gnuradio" 
> Sent: Friday, 17 May, 2019 11:57:45
> Subject: Re: [Discuss-gnuradio] query regarding store transmitted signal
> 
> https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F
> On Fri, 2019-05-17 at 17:06 +0530, Maitry Raval wrote:
> > Hello,
> > 
> > Thanks for your reply.
> > 
> > I.e It is possible to store the transmitted modulated signal (for ex AM 
> > modulated signal) through USRP as per below, 
> > USRP source - file sink. but in which format, this data can be stored? 
> > (.txt, .pdf)_ I have seen.DAT file in one of the example,but when I tried , 
> > it does not give proper output.
> > 
> > Actually, my requirement is to receive the modulated signal through USRP 
> > source, store it in a file. and later, I can be able to do demodulation 
> > offline from that particular stored data. it will be grateful, if you 
> > provide guidance.
> > 
> > 
> > With Best Regards,
> > Maitry Raval,
> > 
> > - Original Message -
> > From: "Marcus Müller, CEL" 
> > To: "discuss-gnuradio" , "maitry raval" 
> > 
> > Sent: Friday, 17 May, 2019 10:50:00
> > Subje

Re: [Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

[CEL]

Ah, I thought  (hurrhurr, a pun) in Q1.15: 15 bits of -0.252525 and
+0.252525 are the same, just the sign bit flips. If it's really just an
interpretation of integers: well, call it 16i 
On Fri, 2019-05-31 at 11:45 +0200, Albin Stigö wrote:
> > two's complement being the standard way of
> > dealing with numbers
> 
> Signed numbers at least...
> 
> Signed Q values are (at least in all cases I've seen) stored in two's
> complement format. It's just like any other signed integer with an
> implied comma.
> 
> The Wikipedia article is fairly good:
> https://en.wikipedia.org/wiki/Q_(number_format)
> 
> 
> --Albin
> 
> On Fri, May 31, 2019 at 11:40 AM Müller, Marcus (CEL)  wrote:
> > 
> > Hm, wait, realizing something:
> > Q1.31 differs from what a x86 CPU can reasonably deal with in that it's
> > not 2's complement for negative numbers; since I'd guess the same
> > situation applies to ARM (two's complement being the standard way of
> > dealing with numbers), maybe we should just have one VOLK kernel /
> > routine to be used within VOLK kernels
> > 
> > volk_q1.31_convert_32i
> > 
> > to get a number format that CPU instructions can actually deal with,
> > and then implement the rest of fixed point arithmetic with that.
> > Is that sensible?
> > 
> > Best regards,
> > Marcus
> > On Fri, 2019-05-31 at 11:34 +0200, Albin Stigö wrote:
> > > What about naming these functions... any ideas? Here are some
> > > suggestions of the top of my head:
> > > 
> > > volk_32i_convert_32f
> > > volk_q1.32_convert_32f
> > > volk_q1_32_convert_32f
> > > 
> > > 
> > > --Albin
> > > 
> > > On Fri, May 31, 2019 at 10:30 AM Albin Stigö  
> > > wrote:
> > > > 
> > > > Thanks for the feedback Marcus!
> > > > 
> > > > Pretty much all SDRs I've seen use either 8, 16 or 32 bit full range
> > > > integers (or 24 bits packed in the most significant bits of a 32 bit
> > > > int so can use same conversion as 32 bit).
> > > > 
> > > > Yes Q1.15 means 1 sign bit and 15 fractional bits, in practice this
> > > > just means that a full range int16_t will map to +-1.0. An N-tap FIR
> > > > filter which has L-bit data values and M-bit coefficients requires L +
> > > > M + log2(N) bits in the accumulator.
> > > > 
> > > > A CIC decimator/interpolator might also be interesting, although I'm
> > > > not sure if there's already an implementation.
> > > > 
> > > > 
> > > > --Albin
> > > > 
> > > > On Fri, May 31, 2019 at 10:13 AM Müller, Marcus (CEL)  
> > > > wrote:
> > > > > 
> > > > > Hi Albin,
> > > > > 
> > > > > I'd love this, especially if we end up with a kernel that we can use 
> > > > > to
> > > > > build decimating FIR filters that inherently convert to 
> > > > > higher-bitwidth
> > > > > int or floating point.
> > > > > 
> > > > > I think this could be super useful in hardware flow graphs, where one
> > > > > would get integer numbers from hardware anyway; in a low-SNR scenario
> > > > > only processing gain (e.g. through filtering / correlation) would make
> > > > > it sensible to use a larger integer or floating point's larger dynamic
> > > > > range.
> > > > > 
> > > > > Not quite sure how that would preferably look like, but I'd imagine
> > > > > Q1.15 going in, getting weighted internally with Q1.15 (or Q1.31 with
> > > > > limited amplitude) coefficients to add Q1.31 numbers to a Q1.31
> > > > > accumulator. (I'm assuming Q1.15 means 15 fractional binary digits and
> > > > > one sign bit.)
> > > > > 
> > > > > (Oh, and yes, x86_64 / SIMD extensions have relatively nice conversion
> > > > > instructions.)
> > > > > 
> > > > > Best regards,
> > > > > Marcus
> > > > > 
> > > > > On Fri, 2019-05-31 at 09:50 +0200, Albin Stigö wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Volk has functions for converting between int and float by casting 
> > > > > > and
> > > > > > multiplying with a scalar. I'd like to purpose functions for the
> > > > 

Re: [Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

[CEL]

Hm, wait, realizing something: 
Q1.31 differs from what a x86 CPU can reasonably deal with in that it's
not 2's complement for negative numbers; since I'd guess the same
situation applies to ARM (two's complement being the standard way of
dealing with numbers), maybe we should just have one VOLK kernel /
routine to be used within VOLK kernels

volk_q1.31_convert_32i

to get a number format that CPU instructions can actually deal with,
and then implement the rest of fixed point arithmetic with that.
Is that sensible?

Best regards,
Marcus
On Fri, 2019-05-31 at 11:34 +0200, Albin Stigö wrote:
> What about naming these functions... any ideas? Here are some
> suggestions of the top of my head:
> 
> volk_32i_convert_32f
> volk_q1.32_convert_32f
> volk_q1_32_convert_32f
> 
> 
> --Albin
> 
> On Fri, May 31, 2019 at 10:30 AM Albin Stigö  wrote:
> > 
> > Thanks for the feedback Marcus!
> > 
> > Pretty much all SDRs I've seen use either 8, 16 or 32 bit full range
> > integers (or 24 bits packed in the most significant bits of a 32 bit
> > int so can use same conversion as 32 bit).
> > 
> > Yes Q1.15 means 1 sign bit and 15 fractional bits, in practice this
> > just means that a full range int16_t will map to +-1.0. An N-tap FIR
> > filter which has L-bit data values and M-bit coefficients requires L +
> > M + log2(N) bits in the accumulator.
> > 
> > A CIC decimator/interpolator might also be interesting, although I'm
> > not sure if there's already an implementation.
> > 
> > 
> > --Albin
> > 
> > On Fri, May 31, 2019 at 10:13 AM Müller, Marcus (CEL)  
> > wrote:
> > > 
> > > Hi Albin,
> > > 
> > > I'd love this, especially if we end up with a kernel that we can use to
> > > build decimating FIR filters that inherently convert to higher-bitwidth
> > > int or floating point.
> > > 
> > > I think this could be super useful in hardware flow graphs, where one
> > > would get integer numbers from hardware anyway; in a low-SNR scenario
> > > only processing gain (e.g. through filtering / correlation) would make
> > > it sensible to use a larger integer or floating point's larger dynamic
> > > range.
> > > 
> > > Not quite sure how that would preferably look like, but I'd imagine
> > > Q1.15 going in, getting weighted internally with Q1.15 (or Q1.31 with
> > > limited amplitude) coefficients to add Q1.31 numbers to a Q1.31
> > > accumulator. (I'm assuming Q1.15 means 15 fractional binary digits and
> > > one sign bit.)
> > > 
> > > (Oh, and yes, x86_64 / SIMD extensions have relatively nice conversion
> > > instructions.)
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > On Fri, 2019-05-31 at 09:50 +0200, Albin Stigö wrote:
> > > > Hi,
> > > > 
> > > > Volk has functions for converting between int and float by casting and
> > > > multiplying with a scalar. I'd like to purpose functions for the
> > > > special case where scalar is 1/INT32_MAX (and 1/INT16_MAX etc) as this
> > > > is a very common use case and might be available to an optimization.
> > > > Certain CPUs (armv8 in particular [1], not sure about x86? [2]) has
> > > > hardware instructions for converting fixed point to float and back.
> > > > 
> > > > In particular I'm interested in adding the common Q1.31 and Q1.15
> > > > formats (full range signed int32_t and full range int16_t to
> > > > (-1.0)-1.0 float).
> > > > 
> > > > Would be grateful for input regarding this and in particular ideas for
> > > > naming the functions.
> > > > 
> > > > 
> > > > --Albin
> > > > 
> > > > [1] 
> > > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801h/pge1427897637493.html
> > > > [2] 
> > > > https://software.intel.com/en-us/articles/fast-floating-point-to-integer-conversions
> > > > 
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Request for comment: Adding fixed point to VOLK

[CEL]

Hi Albin,

I'd love this, especially if we end up with a kernel that we can use to
build decimating FIR filters that inherently convert to higher-bitwidth 
int or floating point.

I think this could be super useful in hardware flow graphs, where one
would get integer numbers from hardware anyway; in a low-SNR scenario
only processing gain (e.g. through filtering / correlation) would make
it sensible to use a larger integer or floating point's larger dynamic
range.

Not quite sure how that would preferably look like, but I'd imagine
Q1.15 going in, getting weighted internally with Q1.15 (or Q1.31 with
limited amplitude) coefficients to add Q1.31 numbers to a Q1.31
accumulator. (I'm assuming Q1.15 means 15 fractional binary digits and
one sign bit.)

(Oh, and yes, x86_64 / SIMD extensions have relatively nice conversion
instructions.)

Best regards,
Marcus

On Fri, 2019-05-31 at 09:50 +0200, Albin Stigö wrote:
> Hi,
> 
> Volk has functions for converting between int and float by casting and
> multiplying with a scalar. I'd like to purpose functions for the
> special case where scalar is 1/INT32_MAX (and 1/INT16_MAX etc) as this
> is a very common use case and might be available to an optimization.
> Certain CPUs (armv8 in particular [1], not sure about x86? [2]) has
> hardware instructions for converting fixed point to float and back.
> 
> In particular I'm interested in adding the common Q1.31 and Q1.15
> formats (full range signed int32_t and full range int16_t to
> (-1.0)-1.0 float).
> 
> Would be grateful for input regarding this and in particular ideas for
> naming the functions.
> 
> 
> --Albin
> 
> [1] 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801h/pge1427897637493.html
> [2] 
> https://software.intel.com/en-us/articles/fast-floating-point-to-integer-conversions
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GTK related segmentation fault when running GRC

[CEL]

Great to hear you've got it to work. 

You might want to open a bug report at Ubuntu's Launchpad and/or at
gtk3-nocsd's github page – this really has not much to do with GNU
Radio, other than GRC using GTK3, which gets hotpatched by gtk3-nocsd.

Best regards,
Marcus

On Thu, 2019-05-30 at 16:42 -0600, Jason Fritz, PhD wrote:
> That appears to have done the trick! Thank you!
> 
> If it happens again, I'll follow up, but hopefully you won't see any 
> responses on this topic.
> 
> Jason
> 
> On 5/30/2019 2:45 PM, Müller, Marcus (CEL) wrote:
> > Hi Jason,
> > 
> > that backtrace didn't quite tell me anything, but then I googled the
> > library in which the segfault happens (gtk3-nocsd).
> > The github page to that library literally describes it as "A hack to
> > disable gtk+ 3 client side decoration"; the readme says it's
> > automatically being preloaded into the system after installation.
> > 
> > I guess I found my prime suspect. Can you try uninstalling
> > 
> > apt remove libgtk3-nocsd0
> > 
> > logging out and back in (essentially: killing all GTK3 programs) and
> > see whether the problem persists?
> > 
> > Best regards,
> > Marcus
> >   
> > On Thu, 2019-05-30 at 14:28 -0600, Jason Fritz wrote:
> > > I've the high level source of the problem, but not the root. If I
> > > simply change my Desktop from Mate to Ubuntu's default, then GRC runs
> > > fine and doesn't seg fault. So it seems there's something with Mate
> > > on Ubuntu that conflicts with something in gnuradio-companion causing
> > > it to seg fault, but I have no idea how to figure out what that might
> > > be so I can fix it. I'm not sure I'd call it a bug, but there's
> > > definitely a problem. Perhaps a gnuradio developer can test this on a
> > > box running Mate? I'm not sure if it has to be Ubuntu or if it could
> > > be any other distro. If anyone has any clues on how to fix this (I'd
> > > really prefer using Mate over Unity) please let me know, or if you
> > > need me to get more diagnostics to debug.
> > > 
> > > On Wed, May 22, 2019 at 4:54 PM Jason Fritz  wrote:
> > > > Problem: When I run gnuradio-companion and then just select the
> > > > window and move the mouse around or try to resize the window, the
> > > > program generates a segmentation fault. I don't even have the
> > > > opportunity to load any models and usually only have to wait <10
> > > > seconds before the crash.
> > > > 
> > > > OS: Ubuntu 18.04
> > > > 
> > > > I did read about other seg faults with GRC, but none quite matched
> > > > my situation. One suggested running gdb to get a backtrace, which I
> > > > did and why I believe the problem is GTK related. The backtrace is
> > > > given below from PyBOMBS installation.
> > > > 
> > > > My initial gnuradio installation was via apt-get. Thinking that was
> > > > the problem, I removed it and used PyBOMBS following the
> > > > instructions at
> > > > https://www.gnuradio.org/blog/2016-06-19-pybombs-the-what-the-how-and-the-why/
> > > > , which matches others I've found. When that still didn't solve the
> > > > problem, I tried compiling from source, although I tested it before
> > > > running 'make install'. No luck there either, and I couldn't figure
> > > > out how to get some of the dependencies so I'd prefer to use the
> > > > Pybombs version.
> > > > 
> > > > I'm not ruling out a conflict somewhere, but the backtrace seems to
> > > > indicate a GTK problem. Any ideas? Need more info?
> > > > 
> > > > Thanks!
> > > > 
> > > > > which python
> > > > 
> > > > /usr/bin/python
> > > > > python --version
> > > > 
> > > > Python 2.7.15rc1
> > > > > which gnuradio-companion
> > > > 
> > > > /usr/local/src/prefix/default/bin/gnuradio-companion
> > > > 
> > > > > gbd --args python $(which gnuradio-companion)
> > > > 
> > > > run
> > > > *** move mouse around window until it crashes about 5 seconds later
> > > > ***
> > > > (gdb) bt
> > > > #0  0x0154 in  ()
> > > > #1  0x77bd0c2b in gdk_window_set_decorations () at
> > > > /usr/lib/x86_64-linux-gnu/l

Re: [Discuss-gnuradio] GTK related segmentation fault when running GRC

[CEL]

Hi Jason,

that backtrace didn't quite tell me anything, but then I googled the
library in which the segfault happens (gtk3-nocsd).
The github page to that library literally describes it as "A hack to
disable gtk+ 3 client side decoration"; the readme says it's
automatically being preloaded into the system after installation.

I guess I found my prime suspect. Can you try uninstalling 

apt remove libgtk3-nocsd0

logging out and back in (essentially: killing all GTK3 programs) and
see whether the problem persists?

Best regards,
Marcus
 
On Thu, 2019-05-30 at 14:28 -0600, Jason Fritz wrote:
> I've the high level source of the problem, but not the root. If I
> simply change my Desktop from Mate to Ubuntu's default, then GRC runs
> fine and doesn't seg fault. So it seems there's something with Mate
> on Ubuntu that conflicts with something in gnuradio-companion causing
> it to seg fault, but I have no idea how to figure out what that might
> be so I can fix it. I'm not sure I'd call it a bug, but there's
> definitely a problem. Perhaps a gnuradio developer can test this on a
> box running Mate? I'm not sure if it has to be Ubuntu or if it could
> be any other distro. If anyone has any clues on how to fix this (I'd
> really prefer using Mate over Unity) please let me know, or if you
> need me to get more diagnostics to debug.
> 
> On Wed, May 22, 2019 at 4:54 PM Jason Fritz  wrote:
> > Problem: When I run gnuradio-companion and then just select the
> > window and move the mouse around or try to resize the window, the
> > program generates a segmentation fault. I don't even have the
> > opportunity to load any models and usually only have to wait <10
> > seconds before the crash.
> > 
> > OS: Ubuntu 18.04
> > 
> > I did read about other seg faults with GRC, but none quite matched
> > my situation. One suggested running gdb to get a backtrace, which I
> > did and why I believe the problem is GTK related. The backtrace is
> > given below from PyBOMBS installation.
> > 
> > My initial gnuradio installation was via apt-get. Thinking that was
> > the problem, I removed it and used PyBOMBS following the
> > instructions at 
> > https://www.gnuradio.org/blog/2016-06-19-pybombs-the-what-the-how-and-the-why/
> > , which matches others I've found. When that still didn't solve the
> > problem, I tried compiling from source, although I tested it before
> > running 'make install'. No luck there either, and I couldn't figure
> > out how to get some of the dependencies so I'd prefer to use the
> > Pybombs version. 
> > 
> > I'm not ruling out a conflict somewhere, but the backtrace seems to
> > indicate a GTK problem. Any ideas? Need more info?
> > 
> > Thanks!
> > 
> > > which python
> > /usr/bin/python
> > > python --version
> > Python 2.7.15rc1
> > > which gnuradio-companion
> > /usr/local/src/prefix/default/bin/gnuradio-companion
> > 
> > > gbd --args python $(which gnuradio-companion)
> > run
> > *** move mouse around window until it crashes about 5 seconds later
> > ***
> > (gdb) bt
> > #0  0x0154 in  ()
> > #1  0x77bd0c2b in gdk_window_set_decorations () at
> > /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
> > #2  0x7fff94ce16f3 in  () at /usr/lib/x86_64-linux-gnu/libgtk-
> > x11-2.0.so.0
> > #3  0x7fff8e04a277 in  () at /usr/lib/x86_64-linux-gnu/gtk-
> > 2.0/modules/libappmenu-gtk-module.so
> > #4  0x7fff9558310d in g_closure_invoke () at /usr/lib/x86_64-
> > linux-gnu/libgobject-2.0.so.0
> > #5  0x7fff9559612e in  () at /usr/lib/x86_64-linux-
> > gnu/libgobject-2.0.so.0
> > #6  0x7fff9559e715 in g_signal_emit_valist () at
> > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> > #7  0x7fff9559f12f in g_signal_emit () at /usr/lib/x86_64-
> > linux-gnu/libgobject-2.0.so.0
> > #8  0x7fff94cd53d8 in gtk_widget_realize () at /usr/lib/x86_64-
> > linux-gnu/libgtk-x11-2.0.so.0
> > #9  0x7fff94cdfa5d in  () at /usr/lib/x86_64-linux-gnu/libgtk-
> > x11-2.0.so.0
> > #10 0x7fff9558310d in g_closure_invoke () at /usr/lib/x86_64-
> > linux-gnu/libgobject-2.0.so.0
> > #11 0x7fff9559612e in  () at /usr/lib/x86_64-linux-
> > gnu/libgobject-2.0.so.0
> > #12 0x7fff9559e715 in g_signal_emit_valist () at
> > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
> > #13 0x7fff9559f12f in g_signal_emit () at /usr/lib/x86_64-
> > linux-gnu/libgobject-2.0.so.0
> > #14 0x7fff94cd4b96 in gtk_widget_show () at /usr/lib/x86_64-
> > linux-gnu/libgtk-x11-2.0.so.0
> > #15 0x7fff8e2569da in  () at /usr/lib/x86_64-linux-gnu/gtk-
> > 2.0/modules/liboverlay-scrollbar.so
> > #16 0x7fff960f7d03 in  () at /usr/lib/x86_64-linux-gnu/libglib-
> > 2.0.so.0
> > #17 0x7fff960f7285 in g_main_context_dispatch () at
> > /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> > #18 0x7fff960f7650 in  () at /usr/lib/x86_64-linux-gnu/libglib-
> > 2.0.so.0
> > #19 0x7fff960f7962 in g_main_loop_run () at /usr/lib/x86_64-
> > linux-gnu/libglib-2.0.so.0
> > #20 0x7fff94bb6a37 in gtk_main () at /usr

Re: [Discuss-gnuradio] [EXT] Re: complaints about missing volk.h

[CEL]

Scroll up in the CMake output and read it: It will say so in the
individual sections these modules.
On Wed, 2019-05-29 at 13:18 +, Chesir, Aaron M. wrote:
> Marcus,
> 
> I took a look at the trace of the output.
> 
> I saw the following:
> 
> 
> -- ##
> -- # Gnuradio disabled components
> -- ##
> --   * sphinx
> --   * gnuradio-companion
> --   * gr-comedi
> --   * gr-qtgui
> --   * gr-video-sdl
> 
> 
> Why would GRC and the QT GUI be disabled?
> 
> Thanks for your help,
> 
> Aaron
> 
> 
> -Original Message-
> From: Discuss-gnuradio  
> On Behalf Of Chesir, Aaron M.
> Sent: Wednesday, May 29, 2019 9:11 AM
> To: Müller, Marcus (CEL) 
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] [EXT] Re: complaints about missing volk.h
> 
> Marcus,
> 
> As you can see from the attached, I ran cmake, and then make, and was greeted 
> at the end with the same (what appear to be) C++ errors.
> 
> What *exactly* can I do to get a good "make", followed by a good "make 
> install" ?
> 
> Aaron
> 
> -Original Message-
> From: Müller, Marcus (CEL) 
> Sent: Tuesday, May 28, 2019 4:59 PM
> To: Chesir, Aaron M. ; discuss-gnuradio@gnu.org
> Subject: Re: [EXT] Re: [Discuss-gnuradio] complaints about missing volk.h
> 
> Please stay on the mailing list.
> 
> Running make without successfully running CMake is meaningless.
> Also errors pertaining to third party libraries are in 99% of cases simply 
> caused by the user having competing versions of the same library installed, 
> and that will likely be the case here for UHD.
> 
> Next step: purge all conflicting installation of things that you both built 
> from source and directly or indirectly installed via packages.
> The quickest way to do that is running on a clean slate system.
> 
> Best regards,
> Marcus
> 
> On Tue, 2019-05-28 at 19:04 +, Chesir, Aaron M. wrote:
> > Marcus,
> > 
> > Thank you for your willingness to help.
> > 
> > I followed your instructions, and was able to run cmake, but when I 
> > ran "make", although it did progress to 99% completion, it complained 
> > about syntax errors in the code - most of which involve UHD (see 
> > attached).
> > 
> > What should be my next step?
> > 
> > Thanks,
> > 
> > Aaron
> > 
> > 
> > -Original Message-
> > From: Müller, Marcus (CEL) 
> > Sent: Tuesday, May 28, 2019 1:41 PM
> > To: Chesir, Aaron M. ; discuss-gnuradio@gnu.org
> > Subject: [EXT] Re: [Discuss-gnuradio] complaints about missing volk.h
> > 
> > Seems you didn't quite install things into a place CMake looks into by 
> > default; quite possibly, there will be needs to tell CMake about 
> > /usr/local/include/volk (which is what I guess is the default 
> > installation prefix if you build from source manually).
> > 
> > Anyway, this wouldn't have helped you! Please don't install a random 
> > VOLK, that doesn't work; instead, uninstall what you've installed now, 
> > and
> > 
> > git clone --recursive https://github.com/gnuradio/gnuradio
> > /home/xroot/GNUradio2/
> > cd /home/xroot/GNUradio2/
> > mkdir build
> > cd build
> > cmake ..
> > 
> > Due to the recursive clone, you get an in-tree copy of VOLK that 
> > matches exactly your GNU Radio version.
> > CMake will recognize the presence of that, and then build VOLK 
> > alongside with GNU Radio.
> > 
> > Again, I've said this multiple times: going for the source build on 
> > CentOS 7 is not what I'd like to recommend. That's why I have the repo 
> > with an RPM package that I referred you to before.
> > 
> > Best regards,
> > Marcus
> > 
> > On Tue, 2019-05-28 at 17:27 +, Chesir, Aaron M. wrote:
> > > Folks,
> > >  
> > > I am trying to install GNUradio from source:
> > > I downloaded a copy of the gnuradio master repository into my local 
> > > folder /home/xroot/GNUradio2/, I created a subdirectory called 
> > > "build", within that sub-directory, I can execute "cmake ../".
> > >  
> > > When I execute "make", I keep getting the (attached) error about 
> > > missing "volk.h"
> > >  
> > > I then installed VOLK from source (cmake, make, sudo make install), 
> > > and then went back to my attempt at building GNUradio:
> > > I went back to the "build" directory, I ran "make clean", I ran 
> > > "cmake ../"
> > > I ran "make"
> > >  
> > > …and I keep getting the very same error message.
> > >  
> > > Help.
> > >  
> > > Thanks,
> > >  
> > > Aaron
> > >  
> > >  
> > > When I execute
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [EXT] Re: complaints about missing volk.h

[CEL]

Please stay on the mailing list.

Running make without successfully running CMake is meaningless.
Also errors pertaining to third party libraries are in 99% of cases
simply caused by the user having competing versions of the same library
installed, and that will likely be the case here for UHD.

Next step: purge all conflicting installation of things that you both
built from source and directly or indirectly installed via packages.
The quickest way to do that is running on a clean slate system.

Best regards,
Marcus

On Tue, 2019-05-28 at 19:04 +, Chesir, Aaron M. wrote:
> Marcus,
> 
> Thank you for your willingness to help.
> 
> I followed your instructions, and was able to run cmake, but when I
> ran "make", although it did progress to 99% completion, it complained
> about syntax errors in the code - most of which involve UHD (see
> attached).
> 
> What should be my next step?
> 
> Thanks,
> 
> Aaron
> 
> 
> -Original Message-
> From: Müller, Marcus (CEL)  
> Sent: Tuesday, May 28, 2019 1:41 PM
> To: Chesir, Aaron M. ; discuss-gnuradio@gnu.org
> Subject: [EXT] Re: [Discuss-gnuradio] complaints about missing volk.h
> 
> Seems you didn't quite install things into a place CMake looks into
> by
> default; quite possibly, there will be needs to tell CMake about
> /usr/local/include/volk (which is what I guess is the default
> installation prefix if you build from source manually).
> 
> Anyway, this wouldn't have helped you! Please don't install a random
> VOLK, that doesn't work; instead, uninstall what you've installed
> now,
> and 
> 
> git clone --recursive https://github.com/gnuradio/gnuradio
> /home/xroot/GNUradio2/
> cd /home/xroot/GNUradio2/
> mkdir build
> cd build
> cmake ..
> 
> Due to the recursive clone, you get an in-tree copy of VOLK that
> matches exactly your GNU Radio version. 
> CMake will recognize the presence of that, and then build VOLK
> alongside with GNU Radio.
> 
> Again, I've said this multiple times: going for the source build on
> CentOS 7 is not what I'd like to recommend. That's why I have the
> repo with an RPM package that I referred you to before.
> 
> Best regards,
> Marcus
> 
> On Tue, 2019-05-28 at 17:27 +, Chesir, Aaron M. wrote:
> > Folks,
> >  
> > I am trying to install GNUradio from source:
> > I downloaded a copy of the gnuradio master repository into my local
> > folder /home/xroot/GNUradio2/,
> > I created a subdirectory called "build",
> > within that sub-directory, I can execute "cmake ../".
> >  
> > When I execute "make", I keep getting the (attached) error about
> > missing "volk.h"
> >  
> > I then installed VOLK from source (cmake, make, sudo make install),
> > and then went back to my attempt at building GNUradio:
> > I went back to the "build" directory,
> > I ran "make clean",
> > I ran "cmake ../"
> > I ran "make"
> >  
> > …and I keep getting the very same error message.
> >  
> > Help.
> >  
> > Thanks,
> >  
> > Aaron
> >  
> >  
> > When I execute
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] complaints about missing volk.h

[CEL]

Seems you didn't quite install things into a place CMake looks into by
default; quite possibly, there will be needs to tell CMake about
/usr/local/include/volk (which is what I guess is the default
installation prefix if you build from source manually).

Anyway, this wouldn't have helped you! Please don't install a random
VOLK, that doesn't work; instead, uninstall what you've installed now,
and 

git clone --recursive https://github.com/gnuradio/gnuradio 
/home/xroot/GNUradio2/
cd /home/xroot/GNUradio2/
mkdir build
cd build
cmake ..

Due to the recursive clone, you get an in-tree copy of VOLK that matches 
exactly your GNU Radio version. 
CMake will recognize the presence of that, and then build VOLK alongside with 
GNU Radio.

Again, I've said this multiple times: going for the source build on CentOS 7 is 
not what I'd like to recommend. That's why I have the repo with an RPM package 
that I referred you to before.

Best regards,
Marcus

On Tue, 2019-05-28 at 17:27 +, Chesir, Aaron M. wrote:
> Folks,
>  
> I am trying to install GNUradio from source:
> I downloaded a copy of the gnuradio master repository into my local folder 
> /home/xroot/GNUradio2/,
> I created a subdirectory called "build",
> within that sub-directory, I can execute "cmake ../".
>  
> When I execute "make", I keep getting the (attached) error about missing 
> "volk.h"
>  
> I then installed VOLK from source (cmake, make, sudo make install), and then 
> went back to my attempt at building GNUradio:
> I went back to the "build" directory,
> I ran "make clean",
> I ran "cmake ../"
> I ran "make"
>  
> …and I keep getting the very same error message.
>  
> Help.
>  
> Thanks,
>  
> Aaron
>  
>  
> When I execute
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] AttributeError: No constructor defined for tagged_stream_block (Python)

[CEL]

You can't actually control it, but you can set a minimum number, yes.
However, for tagging in invervals, you wouldn't even need that, just
look for the thing that initiates your tagging, and add new tags every
so and so many items. You can just keep the count between calls to
work. A function has no memory, that's right (superficially), but that
work function is a *method of a class object*, so you can store things
in self.* !


On Tue, 2019-05-28 at 16:34 +0200, Sebastian Sahlin wrote:
> Hmm ok, I feel like perhaps I've misunderstood some fundamental mechanic of 
> GNURadio.. is it within my power to define the exact number of samples that 
> should be available on the next call to the work function of e.g. a sync 
> block?
> 
> Den tis 28 maj 2019 kl 16:28 skrev Müller, Marcus (CEL) :
> > But you're free to do that in any block you desire, so you can write a
> > normal sync block and just always consume all input :)
> > On Tue, 2019-05-28 at 16:26 +0200, Sebastian Sahlin wrote:
> > > Hi,
> > > 
> > > I suppose not - I just figured that using a tagged stream block would be 
> > > useful since then I'd be able to iterate over the entire packet in one 
> > > work function call.
> > > 
> > > Den tis 28 maj 2019 kl 16:22 skrev Müller, Marcus (CEL) :
> > > > But that block doesn't have to be a Tagged Stream Block itself, right?
> > > > On Tue, 2019-05-28 at 16:14 +0200, Sebastian Sahlin wrote:
> > > > > Hi Marcus,
> > > > > 
> > > > > Aha, that explains it.. bummer! Perhaps you could advise me on an 
> > > > > alternative solution to my problem. What I am trying to achieve with 
> > > > > the tagged stream block is to apply tags at an interval on a packet; 
> > > > > the values are taken from an array that I want to iterate over. 
> > > > > However, since the work function has no "memory" I am unsure how to 
> > > > > solve iterating over the array.  
> > > > > 
> > > > > Den tis 28 maj 2019 kl 16:04 skrev Müller, Marcus (CEL) 
> > > > > :
> > > > > > Hi Sebastian,
> > > > > > 
> > > > > > I must admit that I don't remember whether the TSB block base was
> > > > > > correctly wrapped for Python (darn it, first I write something, and
> > > > > > then you find a glaring counterexample); in fact, there's not a 
> > > > > > single
> > > > > > test case for that in the main GNU Radio tree, which probably means
> > > > > > "no".
> > > > > > 
> > > > > > Best regards,
> > > > > > Marcus
> > > > > > 
> > > > > > On Tue, 2019-05-28 at 14:41 +0200, Sebastian Sahlin wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I'm attempting to create a tagged stream block in Python using 
> > > > > > > the following constructor:
> > > > > > > 
> > > > > > > class test_tagged_stream(gr.tagged_stream_block):
> > > > > > > def __init__(self, test_param):
> > > > > > > gr.tagged_stream_block.__init__(self,
> > > > > > > name="test_tagged_stream",
> > > > > > > in_sig=[numpy.complex64],
> > > > > > > out_sig=[numpy.complex64],
> > > > > > > length_tag_key="test_tag")
> > > > > > > 
> > > > > > > However Python is throwing "AttributeError: No constructor 
> > > > > > > defined" at me. Is there some glaringly obvious error in the 
> > > > > > > above code? I am using the input argument list as defined at 
> > > > > > > https://www.gnuradio.org/doc/doxygen/classgr_1_1tagged__stream__block.html#a601cd4073e9c3e6317b5ecc5e2e5871b
> > > > > > > 
> > > > > > > Regards
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ___
> > > > > > > Discuss-gnuradio mailing list
> > > > > > > Discuss-gnuradio@gnu.org
> > > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] AttributeError: No constructor defined for tagged_stream_block (Python)

[CEL]

But you're free to do that in any block you desire, so you can write a
normal sync block and just always consume all input :)
On Tue, 2019-05-28 at 16:26 +0200, Sebastian Sahlin wrote:
> Hi,
> 
> I suppose not - I just figured that using a tagged stream block would be 
> useful since then I'd be able to iterate over the entire packet in one work 
> function call.
> 
> Den tis 28 maj 2019 kl 16:22 skrev Müller, Marcus (CEL) :
> > But that block doesn't have to be a Tagged Stream Block itself, right?
> > On Tue, 2019-05-28 at 16:14 +0200, Sebastian Sahlin wrote:
> > > Hi Marcus,
> > > 
> > > Aha, that explains it.. bummer! Perhaps you could advise me on an 
> > > alternative solution to my problem. What I am trying to achieve with the 
> > > tagged stream block is to apply tags at an interval on a packet; the 
> > > values are taken from an array that I want to iterate over. However, 
> > > since the work function has no "memory" I am unsure how to solve 
> > > iterating over the array.  
> > > 
> > > Den tis 28 maj 2019 kl 16:04 skrev Müller, Marcus (CEL) :
> > > > Hi Sebastian,
> > > > 
> > > > I must admit that I don't remember whether the TSB block base was
> > > > correctly wrapped for Python (darn it, first I write something, and
> > > > then you find a glaring counterexample); in fact, there's not a single
> > > > test case for that in the main GNU Radio tree, which probably means
> > > > "no".
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > > > On Tue, 2019-05-28 at 14:41 +0200, Sebastian Sahlin wrote:
> > > > > Hi,
> > > > > 
> > > > > I'm attempting to create a tagged stream block in Python using the 
> > > > > following constructor:
> > > > > 
> > > > > class test_tagged_stream(gr.tagged_stream_block):
> > > > > def __init__(self, test_param):
> > > > > gr.tagged_stream_block.__init__(self,
> > > > > name="test_tagged_stream",
> > > > > in_sig=[numpy.complex64],
> > > > > out_sig=[numpy.complex64],
> > > > > length_tag_key="test_tag")
> > > > > 
> > > > > However Python is throwing "AttributeError: No constructor defined" 
> > > > > at me. Is there some glaringly obvious error in the above code? I am 
> > > > > using the input argument list as defined at 
> > > > > https://www.gnuradio.org/doc/doxygen/classgr_1_1tagged__stream__block.html#a601cd4073e9c3e6317b5ecc5e2e5871b
> > > > > 
> > > > > Regards
> > > > > 
> > > > > 
> > > > > 
> > > > > ___
> > > > > Discuss-gnuradio mailing list
> > > > > Discuss-gnuradio@gnu.org
> > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] AttributeError: No constructor defined for tagged_stream_block (Python)

[CEL]

But that block doesn't have to be a Tagged Stream Block itself, right?
On Tue, 2019-05-28 at 16:14 +0200, Sebastian Sahlin wrote:
> Hi Marcus,
> 
> Aha, that explains it.. bummer! Perhaps you could advise me on an alternative 
> solution to my problem. What I am trying to achieve with the tagged stream 
> block is to apply tags at an interval on a packet; the values are taken from 
> an array that I want to iterate over. However, since the work function has no 
> "memory" I am unsure how to solve iterating over the array.  
> 
> Den tis 28 maj 2019 kl 16:04 skrev Müller, Marcus (CEL) :
> > Hi Sebastian,
> > 
> > I must admit that I don't remember whether the TSB block base was
> > correctly wrapped for Python (darn it, first I write something, and
> > then you find a glaring counterexample); in fact, there's not a single
> > test case for that in the main GNU Radio tree, which probably means
> > "no".
> > 
> > Best regards,
> > Marcus
> > 
> > On Tue, 2019-05-28 at 14:41 +0200, Sebastian Sahlin wrote:
> > > Hi,
> > > 
> > > I'm attempting to create a tagged stream block in Python using the 
> > > following constructor:
> > > 
> > > class test_tagged_stream(gr.tagged_stream_block):
> > > def __init__(self, test_param):
> > > gr.tagged_stream_block.__init__(self,
> > > name="test_tagged_stream",
> > > in_sig=[numpy.complex64],
> > > out_sig=[numpy.complex64],
> > > length_tag_key="test_tag")
> > > 
> > > However Python is throwing "AttributeError: No constructor defined" at 
> > > me. Is there some glaringly obvious error in the above code? I am using 
> > > the input argument list as defined at 
> > > https://www.gnuradio.org/doc/doxygen/classgr_1_1tagged__stream__block.html#a601cd4073e9c3e6317b5ecc5e2e5871b
> > > 
> > > Regards
> > > 
> > > 
> > > 
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] AttributeError: No constructor defined for tagged_stream_block (Python)

[CEL]

Hi Sebastian,

I must admit that I don't remember whether the TSB block base was
correctly wrapped for Python (darn it, first I write something, and
then you find a glaring counterexample); in fact, there's not a single
test case for that in the main GNU Radio tree, which probably means
"no".

Best regards,
Marcus

On Tue, 2019-05-28 at 14:41 +0200, Sebastian Sahlin wrote:
> Hi,
> 
> I'm attempting to create a tagged stream block in Python using the following 
> constructor:
> 
> class test_tagged_stream(gr.tagged_stream_block):
> def __init__(self, test_param):
> gr.tagged_stream_block.__init__(self,
> name="test_tagged_stream",
> in_sig=[numpy.complex64],
> out_sig=[numpy.complex64],
> length_tag_key="test_tag")
> 
> However Python is throwing "AttributeError: No constructor defined" at me. Is 
> there some glaringly obvious error in the above code? I am using the input 
> argument list as defined at 
> https://www.gnuradio.org/doc/doxygen/classgr_1_1tagged__stream__block.html#a601cd4073e9c3e6317b5ecc5e2e5871b
> 
> Regards
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Need help with gr-eventstream

[CEL]

I'm sure Team Platypus is awesome and will do the FOSS thing and
contribute that block to gr-eventstream?

On Sun, 2019-05-26 at 15:46 -0600, U L wrote:
> Team Platypus ran into this precise problem at the DARPA Hackfest.  The only 
> solution was to code it up ourselves.  It's non-trivial, but not too much 
> code.
> 
> Jared.
> 
> On Thu, May 23, 2019 at 1:48 PM Chesir, Aaron M.  wrote:
> > Folks,
> >  
> > I am using the gr-eventstream package in GNUradio, and I need help with the 
> > EventStream Source block. This is a block that takes a PDU as a message 
> > input and produces a data stream as an output. My problem is this: I am 
> > trying to feed the data stream output to a USRP Sink as an input, such that 
> > the tags in the data that is part of the original PDU input to the 
> > EventStream Source block get propagated out of the EventStream Source 
> > output, so that the embedded tags, which change the center frequency of the 
> > USRP transmitter to effect frequency hopping, get propagated through. It is 
> > clear that the EventStream Source block is *not* propagating the tags 
> > through.
> >  
> > Does anyone have a solution to this?
> >  
> > Thanks,
> >  
> > Aaron Chesir
> >
> > ___
> > 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


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with the Message API in Python

[CEL]

Hey,

got nothing to do with patience – I like what I'm doing, and that
especially includes conversing with you :)

So, yeah, most of the ways you interact with GNU Radio from Python is
to make Python-wrapped C++ code do what you want. For many things, that
wrapping is relatively thin (e.g. when you set a property of a GNU
Radio block written in C++, all that happens is some type conversions
and the call to the underlying C++ method of the block class), for some
there's a bit more magic involved:

In the case of writing your own block, GNU Radio's Python API tries to
be as close to what the C++ blocks do, logically. So, you can inherent
from the gr.block class and override (nearly) all the things a C++
block could override, too, be it the work() function, or be it the
housekeeping start().

So, yes, if you want to know what something does, the C++ documentation
is generally a good place to look.

That being said, things aren't perfect in GNU Radio land when it comes
to documentation. But Marc has an exciting project underway – he, we,
are generating a "block-wise" documentation that differs in its scope
from the C++ API documentation: It documents each block, including
explanations, usage guidance, and a neat integration into the GNU Radio
companion.

To me, that's big news, because obviously, I want GNU Radio to run on
every computer that belongs to someone who thinks that live processing
of signals is a good thing.

Best regards,
Marcus

On Sun, 2019-05-26 at 14:45 +0200, Sebastian Sahlin wrote:
> Hi again,
> 
> Thanks for the info and for being patient Marcus. I suppose as a
> general rule you need to be able to interpret C++ documentation if
> you're going the Python route in GR?
> 
> Regards
> 
> Den fre 24 maj 2019 kl 17:50 skrev Müller, Marcus (CEL) <
> muel...@kit.edu>:
> > Oh, I nearly forgot you asked for documentation:
> > 
> > 
> > https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a7f58745d1374b30a7b866406dc97850f
> > 
> > Best regards,
> > Marcus
> > On Fri, 2019-05-24 at 15:53 +0200, Sebastian Sahlin wrote:
> > > Okay, this appears to work:
> > > 
> > > def start(self):
> > > threading.Thread(target=self.send_message('Hello World')).start()
> > > return true
> > > 
> > > However I am unsure why the return value is necessary (figured it
> > out through an error message). Is there somewhere in the
> > documentation you can point me to find more info about this?
> > > 
> > > Regards
> > > 
> > > 
> > > Den fre 24 maj 2019 kl 14:45 skrev Sebastian Sahlin <
> > seb.sah...@gmail.com>:
> > > > Hi Marcus,
> > > > 
> > > > Aha! I saw hints of this in the documentation but couldn't
> > fully connect the dots. 
> > > > 
> > > > Would this be the start() function of top_block, or the block
> > in question? How would the syntax look like then?
> > > > 
> > > > Regards
> > > > 
> > > > Den tors 23 maj 2019 kl 18:32 skrev Müller, Marcus (CEL) <
> > muel...@kit.edu>:
> > > > > Hi Sebastian,
> > > > > 
> > > > > classic one!
> > > > > 
> > > > > You send the messages in the block's constructor in an
> > endless loop.
> > > > > 
> > > > > So, that constructor never finishes.
> > > > > 
> > > > > Thus, the block never can get message-connected. Thus, your
> > messages
> > > > > disappear.
> > > > > 
> > > > > You can't publish message in a constructor. Spawn off a
> > thread in the
> > > > > `start()` method to do that.
> > > > > 
> > > > > Best regards,
> > > > > Marcus
> > > > > 
> > > > > On Thu, 2019-05-23 at 17:42 +0200, Sebastian Sahlin wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > For learning purposes I'm trying to replicate the
> > functionality of the Message Strobe block in Python, however I'm
> > stumped by what should be a very basic function. I'm simply
> > attempting to publish a message every x seconds:
> > > > > > 
> > > > > > def __init__(self, period):
> > > > > > gr.basic_block.__init__(self,
> > > > > > name="msg_strobe",
> > > > > > in_sig=None,
> > > > > > out_sig=None)
> > > > >

Re: [Discuss-gnuradio] Clarification on the subject gnuradio‏

[CEL]

Dear Moon Light,

there's no such course. Get yourself familiar with GNU Radio; the usage
of these blocks should be relatively self-explanatory and illustrated
by the examples with GNU Radio. Feel free to ask specific questions
related to the blocks you want to use on the mailing list.

Best regards,
Marcus

On Sat, 2019-05-25 at 15:07 +0300, Moon Light wrote:
> Dear Mr
> Ok, I will. 
> 
> 
> 
> ‫في السبت، 25 مايو 2019 في 2:30 م تمت كتابة ما يلي بواسطة ‪Müller,
> Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > Dear Moon light,
> > 
> > Please stay on the mailing list.
> > 
> > Best regards,
> > Marcus
> > On Sat, 2019-05-25 at 14:19 +0300, Moon Light wrote:
> > > Dear Mr
> > > i am need course to explain for example gr-dvbs2 blocks and 
> > > Anything like him
> > > Best regards
> > > 
> > > ‫في الخميس، 23 مايو 2019 في 3:29 م تمت كتابة ما يلي بواسطة
> > ‪Müller,
> > > Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > > > Dear Moon Light,
> > > > 
> > > > Please stay on the mailing list.
> > > > The guided tutorials *are* a course through GNU Radio.
> > > > If you need an introduction to digital communications and DSP,
> > > > typically I'd say "these are subjects in every electrical
> > > > engineering
> > > > program", but since you're asking:
> > > > https://wiki.gnuradio.org/index.php/SuggestedReading
> > > > 
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > > > On Thu, 2019-05-23 at 15:19 +0300, Moon Light wrote:
> > > > > Dear Mr
> > > > > i am want to explain for block digital communcaition and
> > digital
> > > > signal processing
> > > > > i am need  course online Is there 
> > > > > Sincerely
> > > > > 
> > > > > ‫في الخميس، 23 مايو 2019 في 3:05 م تمت كتابة ما يلي بواسطة
> > > > ‪Müller, Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > > > > > Dear Moon Light,
> > > > > > 
> > > > > > the "Guided Tutorials" on
> > > > > > 
> > > > > > https://tutorials.gnuradio.org
> > > > > > 
> > > > > > Best regards,
> > > > > > Marcus Müller
> > > > > > 
> > > > > > On Thu, 2019-05-23 at 14:55 +0300, Moon Light wrote:
> > > > > > > Dear Mr
> > > > > > > I am a new student with software defined radio
> > > > > > > I would like to learn sdr with gnuradio 
> > > > > > > Where I followed your projects on github
> > > > > > > But I want a course that explains the mechanics of
> > dealing
> > > > with the block in gnuradio or any material Explain this
> > > > > > > 
> > > > > > > Sincerely
> > > > > > > 
> > > > > > > ___
> > > > > > > Discuss-gnuradio mailing list
> > > > > > > Discuss-gnuradio@gnu.org
> > > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clarification on the subject gnuradio‏

[CEL]

Dear Moon light,

Please stay on the mailing list.

Best regards,
Marcus
On Sat, 2019-05-25 at 14:19 +0300, Moon Light wrote:
> Dear Mr
> i am need course to explain for example gr-dvbs2 blocks and 
> Anything like him
> Best regards
> 
> ‫في الخميس، 23 مايو 2019 في 3:29 م تمت كتابة ما يلي بواسطة ‪Müller,
> Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > Dear Moon Light,
> > 
> > Please stay on the mailing list.
> > The guided tutorials *are* a course through GNU Radio.
> > If you need an introduction to digital communications and DSP,
> > typically I'd say "these are subjects in every electrical
> > engineering
> > program", but since you're asking:
> > https://wiki.gnuradio.org/index.php/SuggestedReading
> > 
> > 
> > Best regards,
> > Marcus
> > 
> > On Thu, 2019-05-23 at 15:19 +0300, Moon Light wrote:
> > > Dear Mr
> > > i am want to explain for block digital communcaition and digital
> > signal processing
> > > i am need  course online Is there 
> > > Sincerely
> > > 
> > > ‫في الخميس، 23 مايو 2019 في 3:05 م تمت كتابة ما يلي بواسطة
> > ‪Müller, Marcus (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > > > Dear Moon Light,
> > > > 
> > > > the "Guided Tutorials" on
> > > > 
> > > > https://tutorials.gnuradio.org
> > > > 
> > > > Best regards,
> > > > Marcus Müller
> > > > 
> > > > On Thu, 2019-05-23 at 14:55 +0300, Moon Light wrote:
> > > > > Dear Mr
> > > > > I am a new student with software defined radio
> > > > > I would like to learn sdr with gnuradio 
> > > > > Where I followed your projects on github
> > > > > But I want a course that explains the mechanics of dealing
> > with the block in gnuradio or any material Explain this
> > > > > 
> > > > > Sincerely
> > > > > 
> > > > > ___
> > > > > Discuss-gnuradio mailing list
> > > > > Discuss-gnuradio@gnu.org
> > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with the Message API in Python

[CEL]

Oh, I nearly forgot you asked for documentation:


https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#a7f58745d1374b30a7b866406dc97850f

Best regards,
Marcus
On Fri, 2019-05-24 at 15:53 +0200, Sebastian Sahlin wrote:
> Okay, this appears to work:
> 
> def start(self):
> threading.Thread(target=self.send_message('Hello World')).start()
> return true
> 
> However I am unsure why the return value is necessary (figured it out through 
> an error message). Is there somewhere in the documentation you can point me 
> to find more info about this?
> 
> Regards
> 
> 
> Den fre 24 maj 2019 kl 14:45 skrev Sebastian Sahlin :
> > Hi Marcus,
> > 
> > Aha! I saw hints of this in the documentation but couldn't fully connect 
> > the dots. 
> > 
> > Would this be the start() function of top_block, or the block in question? 
> > How would the syntax look like then?
> > 
> > Regards
> > 
> > Den tors 23 maj 2019 kl 18:32 skrev Müller, Marcus (CEL) :
> > > Hi Sebastian,
> > > 
> > > classic one!
> > > 
> > > You send the messages in the block's constructor in an endless loop.
> > > 
> > > So, that constructor never finishes.
> > > 
> > > Thus, the block never can get message-connected. Thus, your messages
> > > disappear.
> > > 
> > > You can't publish message in a constructor. Spawn off a thread in the
> > > `start()` method to do that.
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > On Thu, 2019-05-23 at 17:42 +0200, Sebastian Sahlin wrote:
> > > > Hi,
> > > > 
> > > > For learning purposes I'm trying to replicate the functionality of the 
> > > > Message Strobe block in Python, however I'm stumped by what should be a 
> > > > very basic function. I'm simply attempting to publish a message every x 
> > > > seconds:
> > > > 
> > > > def __init__(self, period):
> > > > gr.basic_block.__init__(self,
> > > > name="msg_strobe",
> > > > in_sig=None,
> > > > out_sig=None)
> > > > 
> > > > self.message_port_register_out(pmt.intern('msg_out'))
> > > > 
> > > > while(True):
> > > > self.send_message('Hello World')
> > > > time.sleep(period)
> > > > 
> > > > def send_message(self, string):
> > > > self.message_port_pub(pmt.intern('msg_out'), pmt.intern(string))
> > > > 
> > > > However there is no message published to the Message Debug block.  
> > > > 
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with the Message API in Python

[CEL]

The start() function is something every block is free to override, and
is meant to allow any GNU Radio block to do internal setup just before
the flow graph starts to run. 
Its return value is true for "hey, I'm ready" and false for "no, sorry,
something went wrong, the flow graph incorporating me can't start".

Best regards,
Marcus

On Fri, 2019-05-24 at 15:53 +0200, Sebastian Sahlin wrote:
> Okay, this appears to work:
> 
> def start(self):
> threading.Thread(target=self.send_message('Hello World')).start()
> return true
> 
> However I am unsure why the return value is necessary (figured it out through 
> an error message). Is there somewhere in the documentation you can point me 
> to find more info about this?
> 
> Regards
> 
> 
> Den fre 24 maj 2019 kl 14:45 skrev Sebastian Sahlin :
> > Hi Marcus,
> > 
> > Aha! I saw hints of this in the documentation but couldn't fully connect 
> > the dots. 
> > 
> > Would this be the start() function of top_block, or the block in question? 
> > How would the syntax look like then?
> > 
> > Regards
> > 
> > Den tors 23 maj 2019 kl 18:32 skrev Müller, Marcus (CEL) :
> > > Hi Sebastian,
> > > 
> > > classic one!
> > > 
> > > You send the messages in the block's constructor in an endless loop.
> > > 
> > > So, that constructor never finishes.
> > > 
> > > Thus, the block never can get message-connected. Thus, your messages
> > > disappear.
> > > 
> > > You can't publish message in a constructor. Spawn off a thread in the
> > > `start()` method to do that.
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > On Thu, 2019-05-23 at 17:42 +0200, Sebastian Sahlin wrote:
> > > > Hi,
> > > > 
> > > > For learning purposes I'm trying to replicate the functionality of the 
> > > > Message Strobe block in Python, however I'm stumped by what should be a 
> > > > very basic function. I'm simply attempting to publish a message every x 
> > > > seconds:
> > > > 
> > > > def __init__(self, period):
> > > > gr.basic_block.__init__(self,
> > > > name="msg_strobe",
> > > > in_sig=None,
> > > > out_sig=None)
> > > > 
> > > > self.message_port_register_out(pmt.intern('msg_out'))
> > > > 
> > > > while(True):
> > > > self.send_message('Hello World')
> > > > time.sleep(period)
> > > > 
> > > > def send_message(self, string):
> > > > self.message_port_pub(pmt.intern('msg_out'), pmt.intern(string))
> > > > 
> > > > However there is no message published to the Message Debug block.  
> > > > 
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] VOLK pre-built option

[CEL]

don't forget to uninstall uhd and uhd-devel after "yum-builddep" and
before building UHD from source, though, because the build depencies of
GNU Radio of course include UHD.

Best regards,
Marcus

On Thu, 2019-05-23 at 21:55 +, Müller, Marcus (CEL) wrote:
> Haven't used PyBOMBS in a while, but I remember getting it to run under
> CentOS 7 was about as much effort as getting UHD and GNU Radio to
> compile from source (because CentOS has "yum-builddep uhd gnuradio",
> which takes care of all the build dependencies).
> 
> Best regards,
> Marcus
> 
> On Thu, 2019-05-23 at 10:46 -0700, Chris Kuethe wrote:
> > Oh, I meant to add: does pybombs not work for you? There are a ton of
> > modules available through pybombs that may not be prepackaged in the
> > repos. It should take care of installing all the dependencies
> > including, but not limited to, installing uhd and volk.
> > 
> > https://github.com/gnuradio/pybombs  for info and a quickstart guide.
> > My general expectation is that you should be able to do "pybombs
> > install gqrx", which should complete without error, and then you
> > should be able to plug in pretty much any common SDR, and immediately
> > start tuning in stuff like commercial FM stations.
> > 
> > On Thu, May 23, 2019 at 9:57 AM Nick Hansen  
> > wrote:
> > > 
> > > Marcus, Chris,
> > > 
> > > Thanks for the link, this might help.
> > > Following the guide to get the UHD drivers for USRP devices has led me to 
> > > want to compile GR from source. Actually I was able to do it before, so 
> > > I'm not sure why this setup is so much harder.
> > > This isn't a VOLK thing anymore, so I need a new email thread, but I've 
> > > summarized where I reached in the post linked.
> > > 
> > > Thanks,
> > > Nick
> > > 
> > > 
> > > 
> > > 
> > > On Tue, May 21, 2019 at 5:39 PM Müller, Marcus (CEL)  
> > > wrote:
> > > > 
> > > > Also: The version match between the volk you're using and the GNU Radio
> > > > you're trying to build is pretty close, so chances are a packaged VOLK
> > > > wouldn't help you build an arbitrary GNU Radio version :(
> > > > Furthermore, VOLK is dependency-wise like GNU Radio light: if you can't
> > > > build VOLK, chances are slim GNU Radio will work out.
> > > > 
> > > > Maybe we could help you with building either? Or, first riddle me this:
> > > > why are you compiling GNU Radio from source in the first place?
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > On Tue, 2019-05-21 at 13:13 -0700, Chris Kuethe wrote:
> > > > > Andrej did a huge amount of work on packaging at the hackfest last
> > > > > week. Maybe this helps?
> > > > > 
> > > > > https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio
> > > > > 
> > > > > On Tue, May 21, 2019 at 12:28 PM Nick Hansen <
> > > > > hansen.n.ja...@gmail.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Working on Ubuntu 18.04, is there a way to get VOLK apart from
> > > > > > compiling it from github? I'm working on compiling gnu radio from
> > > > > > source. I would take 'no' for an answer, just wondering if it's
> > > > > > available through apt.
> > > > > > 
> > > > > > Thanks
> > > > > > Nick
> > > > > > ___
> > > > > > 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


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] VOLK pre-built option

[CEL]

Haven't used PyBOMBS in a while, but I remember getting it to run under
CentOS 7 was about as much effort as getting UHD and GNU Radio to
compile from source (because CentOS has "yum-builddep uhd gnuradio",
which takes care of all the build dependencies).

Best regards,
Marcus

On Thu, 2019-05-23 at 10:46 -0700, Chris Kuethe wrote:
> Oh, I meant to add: does pybombs not work for you? There are a ton of
> modules available through pybombs that may not be prepackaged in the
> repos. It should take care of installing all the dependencies
> including, but not limited to, installing uhd and volk.
> 
> https://github.com/gnuradio/pybombs  for info and a quickstart guide.
> My general expectation is that you should be able to do "pybombs
> install gqrx", which should complete without error, and then you
> should be able to plug in pretty much any common SDR, and immediately
> start tuning in stuff like commercial FM stations.
> 
> On Thu, May 23, 2019 at 9:57 AM Nick Hansen  wrote:
> > 
> > Marcus, Chris,
> > 
> > Thanks for the link, this might help.
> > Following the guide to get the UHD drivers for USRP devices has led me to 
> > want to compile GR from source. Actually I was able to do it before, so I'm 
> > not sure why this setup is so much harder.
> > This isn't a VOLK thing anymore, so I need a new email thread, but I've 
> > summarized where I reached in the post linked.
> > 
> > Thanks,
> > Nick
> > 
> > 
> > 
> > 
> > On Tue, May 21, 2019 at 5:39 PM Müller, Marcus (CEL)  
> > wrote:
> > > 
> > > Also: The version match between the volk you're using and the GNU Radio
> > > you're trying to build is pretty close, so chances are a packaged VOLK
> > > wouldn't help you build an arbitrary GNU Radio version :(
> > > Furthermore, VOLK is dependency-wise like GNU Radio light: if you can't
> > > build VOLK, chances are slim GNU Radio will work out.
> > > 
> > > Maybe we could help you with building either? Or, first riddle me this:
> > > why are you compiling GNU Radio from source in the first place?
> > > 
> > > Best regards,
> > > Marcus
> > > On Tue, 2019-05-21 at 13:13 -0700, Chris Kuethe wrote:
> > > > Andrej did a huge amount of work on packaging at the hackfest last
> > > > week. Maybe this helps?
> > > > 
> > > > https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio
> > > > 
> > > > On Tue, May 21, 2019 at 12:28 PM Nick Hansen <
> > > > hansen.n.ja...@gmail.com> wrote:
> > > > > Hi,
> > > > > 
> > > > > Working on Ubuntu 18.04, is there a way to get VOLK apart from
> > > > > compiling it from github? I'm working on compiling gnu radio from
> > > > > source. I would take 'no' for an answer, just wondering if it's
> > > > > available through apt.
> > > > > 
> > > > > Thanks
> > > > > Nick
> > > > > ___
> > > > > Discuss-gnuradio mailing list
> > > > > Discuss-gnuradio@gnu.org
> > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > > 
> > > > 
> 
> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issue with the Message API in Python

[CEL]

Hi Sebastian,

classic one!

You send the messages in the block's constructor in an endless loop.

So, that constructor never finishes.

Thus, the block never can get message-connected. Thus, your messages
disappear.

You can't publish message in a constructor. Spawn off a thread in the
`start()` method to do that.

Best regards,
Marcus

On Thu, 2019-05-23 at 17:42 +0200, Sebastian Sahlin wrote:
> Hi,
> 
> For learning purposes I'm trying to replicate the functionality of the 
> Message Strobe block in Python, however I'm stumped by what should be a very 
> basic function. I'm simply attempting to publish a message every x seconds:
> 
> def __init__(self, period):
> gr.basic_block.__init__(self,
> name="msg_strobe",
> in_sig=None,
> out_sig=None)
> 
> self.message_port_register_out(pmt.intern('msg_out'))
> 
> while(True):
> self.send_message('Hello World')
> time.sleep(period)
> 
> def send_message(self, string):
> self.message_port_pub(pmt.intern('msg_out'), pmt.intern(string))
> 
> However there is no message published to the Message Debug block.  
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with OFDM_tx OFDM_rx

[CEL]

So, you lose one packet; that might be due to synchronization having to
lock, or due to simulated or real-world noise.

Best regards,
Marcus

On Thu, 2019-05-23 at 15:50 +0100, farid mihoub wrote:
> Hello,
>  
> I am using OFDM_tx and OFDM_rx examples in gr-digital, at the reception
> I am always loosing "1x packet_len" of bytes that I have transmitted.
>  
> thank you.
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clarification on the subject gnuradio‏

[CEL]

Dear Moon Light,

Please stay on the mailing list.
The guided tutorials *are* a course through GNU Radio.
If you need an introduction to digital communications and DSP,
typically I'd say "these are subjects in every electrical engineering
program", but since you're asking:
https://wiki.gnuradio.org/index.php/SuggestedReading


Best regards,
Marcus

On Thu, 2019-05-23 at 15:19 +0300, Moon Light wrote:
> Dear Mr
> i am want to explain for block digital communcaition and digital signal 
> processing
> i am need  course online Is there 
> Sincerely
> 
> ‫في الخميس، 23 مايو 2019 في 3:05 م تمت كتابة ما يلي بواسطة ‪Müller, Marcus 
> (CEL)‬‏ <‪muel...@kit.edu‬‏>:‬
> > Dear Moon Light,
> > 
> > the "Guided Tutorials" on
> > 
> > https://tutorials.gnuradio.org
> > 
> > Best regards,
> > Marcus Müller
> > 
> > On Thu, 2019-05-23 at 14:55 +0300, Moon Light wrote:
> > > Dear Mr
> > > I am a new student with software defined radio
> > > I would like to learn sdr with gnuradio 
> > > Where I followed your projects on github
> > > But I want a course that explains the mechanics of dealing with the block 
> > > in gnuradio or any material Explain this
> > > 
> > > Sincerely
> > > 
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] building 3.8

[CEL]

probably your log4cpp installation fine; at first I thought
"waaaitaminute, the actual liblog4cpp.so is missing", but then I
realized that the find search string wouldn't look for that.
To check, do the following:

1. run 

pkg-config --libs --cflags log4cpp

This should yield something like "-llog4cpp -lnsl"

2. Do something like

cd /tmp
echo "int main(){}" > empty.cc
g++ $(pkg-config --libs --cflags log4cpp) empty.cc

Does that work?

Best regards,
Marcus

PS: what Linux Distro are we talking about? I see you're on ARM, so I'm
naturally curious.
On Wed, 2019-05-22 at 17:45 +0200, Hans Kurscheidt wrote:
> Hi,
> 
> I abandonned my previous thread, because I was building 3.7.
> 
> I cloned 3.8 (I hope) from https://github.com/gnuradio/gnuradio
> 
> Now trying to build 3.8,  I ran into the following problem:
> 
> CMake Error at cmake/Modules/FindLOG4CPP.cmake:46 (message):
>Could NOT find LOG4CPP library
> 
> I had previously installed log4cpp and the following was installed:
> 
> sudo find / -name log4cpp*
> /usr/include/log4cpp
> /usr/bin/log4cpp-config
> /usr/lib/arm-linux-gnueabihf/pkgconfig/log4cpp.pc
> /usr/share/man/man1/log4cpp-config.1.gz
> /usr/share/aclocal/log4cpp.m4
> 
> These are the only pkg, I can find in my Linux distro. Do I need 
> something different? where 2find??
> 
> Rgds
> 
> hk
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clarification on the subject gnuradio‏

[CEL]

Dear Moon Light,

the "Guided Tutorials" on

https://tutorials.gnuradio.org

Best regards,
Marcus Müller

On Thu, 2019-05-23 at 14:55 +0300, Moon Light wrote:
> Dear Mr
> I am a new student with software defined radio
> I would like to learn sdr with gnuradio 
> Where I followed your projects on github
> But I want a course that explains the mechanics of dealing with the block in 
> gnuradio or any material Explain this
> 
> Sincerely
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problems installing BOOST

[CEL]

Hi Aaron, 

considering this is a problem while bulding UHD, I'd argue that this
isn't really a question for the GNU Radio mailing list – more likely
for the UHD mailing list.

However, knowing CentOS 7, I know that just "yum install gnuradio"
gives you GNU Radio 3.7.11 (which is a bit dusty, indeed, but not too
bad) and UHD 3.10.1.0, which is more than sufficient to use a B210.

By the way, building a newer UHD from source means that you'll have to
uninstall gnuradio, uhd as installed through yum, and also build
gnuradio from source. Not an ideal start you're off to!

So, I'd really go with "solve the original issue rather than trying to
build UHD from source". So, original problem is almost certainly that
you don't have access to the USB device: if "sudo uhd_usrp_probe" finds
the USRP with the "native" CentOS UHD, then that's exactly the case.

Best regards,
Marcus

On Wed, 2019-05-22 at 23:27 +, Chesir, Aaron M. wrote:
> Folks,
>  
> I am trying to get my GNUradio Companion UHD Source to recognize a USRP B210 
> connected on a USB port of my CentOS 7.0 laptop. GR complains that it cannot 
> find the device. Following the Internet advice, I decided to (re-)installed 
> my UHD code from source. I followed the advice exactly, but when I ran cmake, 
> my computer complained that I did not have BOOST. I then followed the 
> Internet advice on installing BOOST, which seemed error-free, but when I went 
> back to re-run the cmake to build UHD, I received the very same complaint as 
> before.
>  
> It may matter that I had installed GNUradio to a directory under my HOME 
> directory.
>  
> In any case, can someone please tell me a known-goo-and-tested method for 
> installing boost on CentOS, so that I can run cmake to update my UHD code?
>  
> Thanks,
>  
> Aaron Chesir
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] VOLK pre-built option

[CEL]

Exactly what I was saying: VOLK's dependencies are a true subset of GNU
Radio's dependencies. If you can't build VOLK, then you can't build GNU
Radio, either. 

On Tue, 2019-05-21 at 23:10 +0200, Andrej Rode wrote:
> On Tue, 21 May 2019 20:39:11 +0000
> "Müller, Marcus (CEL)"  wrote:
> > Furthermore, VOLK is dependency-wise like GNU Radio light:
> > if you can't build VOLK, chances are slim GNU Radio will work out.
> 
> Huh?
> 
> VOLK depends on almost nothing.   
> 
> Cheers
> Andrej
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Cross-Compile issue with GNU Radio 3.8: cmake is building an incorrect file

[CEL]

A-Ha! So, that leads us the next bigger question: How can we make
GR_PYTHON_DIR a relative path? I'm taking Andrej into CC, because he
did a lot of the actual "modern CMake" conversion and is back home :)

Best regards,
Marcus
On Tue, 2019-05-21 at 14:34 -0400, Toby Flynn wrote:
> Marcus,
>   I think I have found the issue, just not a correct solution yet. 
> Based on the bug report:
> https://cmake.org/Bug/print_bug_page.php?bug_id=14367
> Which is  marked as not a bug, but explains the issue I am seeing
> very well. 
> gnuradio-runtime.swig/CMakeLists.txt uses an absolute path for the
> DESTINATION ( or something that gets turned into an absolute path) in
> the lines:
> install(
>   TARGETS runtime_swig
>   EXPORT runtime_swig-export
>   DESTINATION ${GR_PYTHON_DIR}/gnuradio/gr
>   ) 
> 
> The DESTINATION should point to a relative path, based on the above
> bug report.
> 
> For testing I changed the last line to:
> DESTINATION lib/python3.5/site-packages/gnuradio/gr
> And rebuild gnuradio for cross-compiling. 
> I then build OOT modules gr-iio from my fork and gr-paint38, both
> successful built.  I have not tried executing the code yet.
> 
> I am not sure of the correct way to create a variable which will
> point to the relative path only of GR_PYTHON_DIR within the CMake
> process, and I think that is what is needed to correctly fix the
> issue. This may show up because the installed path is /usr/lib/... on
> the sysroot and not an actual PREFIX.
> 
> Thanks
> Toby
> 
> On Mon, May 20, 2019 at 1:44 PM Toby Flynn <
> campingandski...@gmail.com> wrote:
> > Marcus,
> >The last file differences I sent are in a file created from
> > CMakeLists.txt, lines 74-78.  Swig builds with no issues, it is
> > when I link an OOT that the file _runtime_swig.so cannot be found
> > because the runtime_swigTargets-release.cmake file has the wrong
> > directory location, somehow it lost the variable which allows for a
> > PREFIX, ${_IMPORT_PREFIX}.  Looking at the difference it may be
> > that _IMPORT_PREFIX is not getting set correctly somewhere.  I am
> > still working on this issue.
> > 
> > Toby
> > 
> > On Mon, May 20, 2019 at 11:55 AM Müller, Marcus (CEL) <
> > muel...@kit.edu> wrote:
> > > Hi Toby,
> > > 
> > > I don't really doubt it's a CMake issue; to be precise, I think
> > > it's an
> > > issue in the triangle between CMake, CMake instructing SWIG and
> > > detecting the right Python libs along the way.
> > > 
> > > Anyway, I'll take a minute to literally parse your email :)
> > > 
> > > Thanks!
> > > Marcus
> > > 
> > > On Mon, 2019-05-20 at 09:09 -0400, Toby Flynn wrote:
> > > > Marcus,
> > > >I think what you want to see if the configuration for CMake,
> > > the actual build line is fairly normal.  This is the contents of
> > > the file which configures CMake.  I believe this is a CMake
> > > issue, not a Python issue.   It is only the creation of one
> > > .cmake file which leads to OOT building errors.
> > > > Thanks
> > > > Toby
> > > > 
> > > > # CMake system name must be something like "Linux".
> > > > # This is important for cross-compiling.
> > > > 
> > > > set( CMAKE_SYSTEM_NAME Linux )
> > > > set( CMAKE_SYSTEM_PROCESSOR aarch64 )
> > > > set( CMAKE_C_COMPILER aarch64-poky-linux-gcc )
> > > > set( CMAKE_CXX_COMPILER aarch64-poky-linux-g++ )
> > > > set( CMAKE_ASM_COMPILER aarch64-poky-linux-gcc )
> > > > set( CMAKE_AR aarch64-poky-linux-ar CACHE FILEPATH "Archiver" )
> > > > set( CMAKE_C_FLAGS "  --
> > > sysroot=/home/builduser/Development/38test/ultra/oe/build/tmp/wor
> > > k/aarch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-
> > > r0/recipe-sysroot  -O2 -pipe -g -feliminate-unused-debug-types
> > > -fdebug-prefix-
> > > map=/home/builduser/Development/38test/ultra/oe/build/tmp/work/aa
> > > rch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-
> > > r0=/usr/src/debug/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0
> > > -fdebug-prefix-
> > > map=/home/builduser/Development/38test/ultra/oe/build/tmp/work/aa
> > > rch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0/recipe-
> > > sysroot= -fdebug-prefix-
> > > map=/home/builduser/Development/38test/ultra/oe/build/tmp/work/aa
> > > rch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0/recipe-
> > > sysroot-native=--
> &g

Re: [Discuss-gnuradio] VOLK pre-built option

[CEL]

Also: The version match between the volk you're using and the GNU Radio
you're trying to build is pretty close, so chances are a packaged VOLK
wouldn't help you build an arbitrary GNU Radio version :(
Furthermore, VOLK is dependency-wise like GNU Radio light: if you can't
build VOLK, chances are slim GNU Radio will work out.

Maybe we could help you with building either? Or, first riddle me this:
why are you compiling GNU Radio from source in the first place?

Best regards,
Marcus
On Tue, 2019-05-21 at 13:13 -0700, Chris Kuethe wrote:
> Andrej did a huge amount of work on packaging at the hackfest last
> week. Maybe this helps?
> 
> https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio
> 
> On Tue, May 21, 2019 at 12:28 PM Nick Hansen <
> hansen.n.ja...@gmail.com> wrote:
> > Hi,
> > 
> > Working on Ubuntu 18.04, is there a way to get VOLK apart from
> > compiling it from github? I'm working on compiling gnu radio from
> > source. I would take 'no' for an answer, just wondering if it's
> > available through apt.
> > 
> > Thanks
> > Nick
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with File source/sink

[CEL]

That's almost certainly not a problem with the file sink or source, but
of the rest of the flow graph.

Best regards,
Marcus
On Mon, 2019-05-20 at 14:08 +0100, farid mihoub wrote:
> Hello,
> I have an issue with file source/sink, I am loosing some amount of data at 
> the beginning of transmission (even in simulation),
> so at the reception; files like JPEG, PDF... will be damaged.
> Is there any way to solve this problem, .
>  
> Thank you.
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Cross-Compile issue with GNU Radio 3.8: cmake is building an incorrect file

[CEL]

p=/home/builduser/Development/38test/ultra/oe/build/tmp/work/aarch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0=/usr/src/debug/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0
>  
> -fdebug-prefix-map=/home/builduser/Development/38test/ultra/oe/build/tmp/work/aarch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0/recipe-sysroot=
>  
> -fdebug-prefix-map=/home/builduser/Development/38test/ultra/oe/build/tmp/work/aarch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0/recipe-sysroot-native=
>   -fvisibility-inlines-hidden   
> --sysroot=/home/builduser/Development/38test/ultra/oe/build/tmp/work/aarch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0/recipe-sysroot
>  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed" CACHE STRING "LDFLAGS" )
> 
> # only search in the paths provided so cmake doesnt pick
> # up libraries and tools from the native build machine
> set( CMAKE_FIND_ROOT_PATH 
> /home/builduser/Development/38test/ultra/oe/build/tmp/work/aarch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0/recipe-sysroot
>  
> /home/builduser/Development/38test/ultra/oe/build/tmp/work/aarch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0/recipe-sysroot-native
> )
> set( CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY )
> set( CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY )
> set( CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY )
> set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY )
> 
> # Use qt.conf settings
> set( ENV{QT_CONF_PATH} 
> /home/builduser/Development/38test/ultra/oe/build/tmp/work/aarch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0/qt.conf
>  )
> 
> # We need to set the rpath to the correct directory as cmake does not provide 
> any
> # directory as rpath by default
> set( CMAKE_INSTALL_RPATH  )
> 
> # Use native cmake modules
> list(APPEND CMAKE_MODULE_PATH 
> "/home/builduser/Development/38test/ultra/oe/build/tmp/work/aarch64-poky-linux/gnuradio/3.8.0+gitAUTOINC+72aa97daab-r0/recipe-sysroot/usr/share/cmake/Modules/")
> 
> # add for non /usr/lib libdir, e.g. /usr/lib64
> set( CMAKE_LIBRARY_PATH /usr/lib /lib)
> 
> 
> On Fri, May 17, 2019 at 4:46 PM Müller, Marcus (CEL)  wrote:
> > Hi Toby,
> > 
> > what's the verbatim cmake command line Yocto is executing? 
> > 
> > Since it's impossible for the build system to know by itself what the
> > target python will be, unless you tell it which, we'll have to figure
> > out a way to consistently set Python used during CMake, Python used
> > during build, and Python used on target.
> > It's a complicated thing, actually – the python that the build system
> > internally (a lot!) doesn't have to be the one the used to link SWIG
> > files against.
> > So, I see no way but to set the PYTHON_LIBRARIES and
> > PYTHON_INCLUDE_DIRS explitly in the cmake command line. (If anyone
> > could point me towards an easier solution that doesn't trade project
> > sanity for having one argument fewer in a OE layer, I'd be very happy.)
> > 
> > Now, I don't know if all this is related to your problem. But then
> > again, I don't know anything about the OOT module you're trying to
> > build. So far, we don't have overly many 3.8-compatible OOTs, so if you
> > can point us to the one you're working with, that would be highly
> > appreciated. One of the main reasons of breakage is that the old CMake
> > constructs we used to employ in GNU Radio have been replaced by more
> > modern CMake patterns, which especially means that the notion of
> > component dependencies and hence install targets has changed.
> > 
> > Best regards,
> > Marcus
> > 
> > On Fri, 2019-05-17 at 13:21 -0400, Toby Flynn wrote:
> > > I am attempting to install OOT modules using a Yocto/Openembedded
> > > enviroment and the latest GNURadio 3.8.  This process was working
> > > before the latest cmake changes to 3.8 were incorporated.  I am now
> > > having issues with the cross-complitaion.  I have tracked the issue
> > > down to a file I believe is created by cmake:
> > > build/gnuradio-
> > > runtime/swig/CMakeFiles/Export/lib/cmake/gnuradio/runtime_swigTargets
> > > -release.cmake
> > > 
> > > When building directly on a computer this file has difference, line
> > > 10 than the one build using Yocto.
> > > Direct build on a computer the line is:
> > > IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/python3.6/dist-
> > > packages/gnuradio/gr/_runtime_swig.so"
> > > 
> > > On the Yocto build the line is:
> > > 
> > > IMPORTED_LOCATION_RELEASE "/usr/lib/python3.5/site-
> > > packages/gnuradio/gr/_runtime_swig.so"
> > > 
> > > The missing ${_IMPORT_PREFIX} leads to cmake issues since
> > > _runtime_swig.so cannot be found.
> > > 
> > > Does anyone have a suggestion for something I can try to fix the
> > > issue.
> > > 
> > > Thanks
> > > Toby
> > > 
> > > 
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building an OOT from the Tutorial

[CEL]

Oh!
Good catch! Sorry, I just didn't read closely enough.

On Mon, 2019-05-20 at 05:27 +, Kyeong Su Shin wrote:
> Dear Pete,
> 
> To me, it sounds like that you are inputting 
> 
> ```
> gr-howto % gr_modtool add -t general -l cpp square_ff
> ```
> instead of 
> 
> ```
> gr_modtool add -t general -l cpp square_ff
> ```
> .
> 
> That "gr-howto %" is part of the terminal prompt (saying that you are
> in the "gr-howto" directory), and shall not be inputted. 
> 
> Regards,
> Kyeong Su Shin
> 보낸 사람: P C  대신 Discuss-gnuradio <
> discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org>
> 보낸 날짜: 2019년 5월 20일 월요일 오전 5:19:03
> 받는 사람: GNURadio Discussion List
> 제목: [Discuss-gnuradio] Building an OOT from the Tutorial
>  
> I'm having a problem following the Tutorial at:
> 
> https://wiki.gnuradio.org/index.php/OutOfTreeModules
> 
> At the step where it says, "Creating the files", as instructed, I
> type 
> the line:
> 
> "gr-howto % gr_modtool add -t general -l cpp square_ff"
> 
> But I get:
> 
> "bash: gr-howto: command not found"
> 
> I did some searching and found:
> 
> https://www.scribd.com/document/375870432/OOT-Tutorial
> 
> which said to use:
> 
> "gr-howto$ gr_modtool add -t general square_ff" But I get the same 
> results. I found this link from 2013 on this list that I am sure is 
> obsolete: 
> https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00357.html 
> I also tried: 
> https://sites.google.com/a/microembedded.com/gnuradio/outoftreemodules 
> Where it said to use:
> |"~/tmp % gr_modtool.py create howto" I guess I have to resort to 
> bothering you folks. Where can I find an example of how to build an
> OOT 
> for dummies? Thanks, Pete |
> 
> 
> ___
> 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


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building an OOT from the Tutorial

[CEL]

Hi PCZZS,

I'm a bit surprised, this document still attracts so much attention.
I'd generally recommend simply going through the guided tutorials
starting by chapter 1; chapter 4 introduces out-of-tree modules and
gr_modtool.

Anyway, what you're encountering sounds a lot like an installation
problem. How did you install GNU Radio? Are you maybe having a
different gr_modtool that remained from an older installation?

Best regards,
Marcus
On Sun, 2019-05-19 at 15:19 -0500, P C wrote:
> I'm having a problem following the Tutorial at:
> 
> https://wiki.gnuradio.org/index.php/OutOfTreeModules
> 
> At the step where it says, "Creating the files", as instructed, I
> type 
> the line:
> 
> "gr-howto % gr_modtool add -t general -l cpp square_ff"
> 
> But I get:
> 
> "bash: gr-howto: command not found"
> 
> I did some searching and found:
> 
> https://www.scribd.com/document/375870432/OOT-Tutorial
> 
> which said to use:
> 
> "gr-howto$ gr_modtool add -t general square_ff" But I get the same 
> results. I found this link from 2013 on this list that I am sure is 
> obsolete: 
> https://lists.gnu.org/archive/html/discuss-gnuradio/2013-01/msg00357.html 
> I also tried: 
> https://sites.google.com/a/microembedded.com/gnuradio/outoftreemodules 
> Where it said to use:
> > "~/tmp % gr_modtool.py create howto" I guess I have to resort to 
> bothering you folks. Where can I find an example of how to build an
> OOT 
> for dummies? Thanks, Pete |
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Cross-Compile issue with GNU Radio 3.8: cmake is building an incorrect file

[CEL]

Hi Toby,

what's the verbatim cmake command line Yocto is executing? 

Since it's impossible for the build system to know by itself what the
target python will be, unless you tell it which, we'll have to figure
out a way to consistently set Python used during CMake, Python used
during build, and Python used on target.
It's a complicated thing, actually – the python that the build system
internally (a lot!) doesn't have to be the one the used to link SWIG
files against.
So, I see no way but to set the PYTHON_LIBRARIES and
PYTHON_INCLUDE_DIRS explitly in the cmake command line. (If anyone
could point me towards an easier solution that doesn't trade project
sanity for having one argument fewer in a OE layer, I'd be very happy.)

Now, I don't know if all this is related to your problem. But then
again, I don't know anything about the OOT module you're trying to
build. So far, we don't have overly many 3.8-compatible OOTs, so if you
can point us to the one you're working with, that would be highly
appreciated. One of the main reasons of breakage is that the old CMake
constructs we used to employ in GNU Radio have been replaced by more
modern CMake patterns, which especially means that the notion of
component dependencies and hence install targets has changed.

Best regards,
Marcus

On Fri, 2019-05-17 at 13:21 -0400, Toby Flynn wrote:
> I am attempting to install OOT modules using a Yocto/Openembedded
> enviroment and the latest GNURadio 3.8.  This process was working
> before the latest cmake changes to 3.8 were incorporated.  I am now
> having issues with the cross-complitaion.  I have tracked the issue
> down to a file I believe is created by cmake:
> build/gnuradio-
> runtime/swig/CMakeFiles/Export/lib/cmake/gnuradio/runtime_swigTargets
> -release.cmake
> 
> When building directly on a computer this file has difference, line
> 10 than the one build using Yocto.
> Direct build on a computer the line is:
> IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/python3.6/dist-
> packages/gnuradio/gr/_runtime_swig.so"
> 
> On the Yocto build the line is:
> 
> IMPORTED_LOCATION_RELEASE "/usr/lib/python3.5/site-
> packages/gnuradio/gr/_runtime_swig.so"
> 
> The missing ${_IMPORT_PREFIX} leads to cmake issues since
> _runtime_swig.so cannot be found.
> 
> Does anyone have a suggestion for something I can try to fix the
> issue.
> 
> Thanks
> Toby
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_modtool error when attempting to create Python tagged_stream block

[CEL]

Hi Sebastian,
in the future, could you please emails to the mailing list instead of
only to me? Others will be interested, too :) 
Thank you! 

Yeah, no, PyBOMBS was an attempt to solve the issue that we basically
had no recent packaging on any platform. We've luckily been able to
change that, or rather, good things happened to us. PyBOMBS is still a
cool tool, if you need to work with a prefix for embedded development.

No, that issue being raised for 3.8 is not sufficient, because there's
significant difference between the templates for these versions. 

Cheers,
Marcus

On Fri, 2019-05-17 at 17:16 +0200, Sebastian Sahlin wrote:
> Hi,
> 
> 1. The issue has already been raised, albeit for 3.8, perhaps that is 
> sufficient? https://github.com/gnuradio/gnuradio/issues/2489
> 2. I was under the impression that using PyBombs was to be preferred in order 
> to get the latest stable releases :P 
> 
> By the way: using apt to install GR on Ubuntu 18.04.2 got me 3.7.11, and I 
> receive the same error with gr_modtool trying to create a tagged_stream 
> block. 
> 
> Regards
> 
> Den fre 17 maj 2019 kl 16:58 skrev Müller, Marcus (CEL) :
> > Ah, nice, so that's the latest maint-3.7 version (i.e. the latest
> > released version).
> > 
> > Two realizations set in:
> > 
> > 1. Unlike 3.8-tech-preview, where we still expect a bit of breakage,
> > this is surprising. You should definitely be able to do this. We'll
> > look into this. If you want, you can set up an issue on Github yourself
> > (advantage: you get notified when we have a solution), or we do that.
> > What would you prefer?
> > 2. If you're not after developing GNU Radio itself, but really only
> > using it, I'd really recommend using your Linux distro's package
> > manager (looking at your file paths, that's likely "apt") to install
> > GNU Radio next time (assuming you've got Ubuntu>18.10 or current
> > debian). Less hassle than building it from source using PyBOMBS, same
> > result. 
> > 
> > Best regards,
> > Marcus
> > 
> > On Fri, 2019-05-17 at 14:44 +, Müller, Marcus (CEL) wrote:
> > >  Forwarded Message 
> > > > Hi Marcus,
> > > > 
> > > > The output from gnuradio-config-info --version is the follwing: 3.7.13.5
> > > > 
> > > > Regards
> > > > 
> > > > 
> > > > Den fre 17 maj 2019 kl 16:15 skrev Müller, Marcus (CEL) 
> > > > :
> > > > > Hi Sebastian,
> > > > > 
> > > > > I know this sounds a bit silly, but could you actually tell us the
> > > > > version that `gnuradio-config-info --version` reports? We're kind of 
> > > > > in
> > > > > the process of getting new versions out, and I'm not quite sure what
> > > > > different people get when they use PyBOMBS.
> > > > > (also, almost certain you shouldn't have to use PyBOMBS if you just
> > > > > want to install a non-development version of GNU Radio; if you just
> > > > > want to install GNU Radio, use a recent Linux distro or OS X, you get 
> > > > > a
> > > > > modern GNU Radio that works through the usual apt,dnf,pac,…
> > > > > installation method.)
> > > > > 
> > > > > Thank you,
> > > > > Marcus
> > > > > On Fri, 2019-05-17 at 16:00 +0200, Sebastian Sahlin wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I get the following output when trying to create a tagged stream 
> > > > > > block with the modtool using Python as the language: 
> > > > > > https://pastebin.com/D6gKJ2aS
> > > > > > 
> > > > > > GNURadio and gr_modtool version is the latest as installed with 
> > > > > > pybombs.
> > > > > > 
> > > > > > Regards,
> > > > > > Sebastian
> > > > > > 
> > > > > >  
> > > > > > ___
> > > > > > Discuss-gnuradio mailing list
> > > > > > Discuss-gnuradio@gnu.org
> > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > 
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_modtool error when attempting to create Python tagged_stream block

[CEL]

Ah, nice, so that's the latest maint-3.7 version (i.e. the latest
released version).

Two realizations set in:

1. Unlike 3.8-tech-preview, where we still expect a bit of breakage,
this is surprising. You should definitely be able to do this. We'll
look into this. If you want, you can set up an issue on Github yourself
(advantage: you get notified when we have a solution), or we do that.
What would you prefer?
2. If you're not after developing GNU Radio itself, but really only
using it, I'd really recommend using your Linux distro's package
manager (looking at your file paths, that's likely "apt") to install
GNU Radio next time (assuming you've got Ubuntu>18.10 or current
debian). Less hassle than building it from source using PyBOMBS, same
result. 

Best regards,
Marcus

On Fri, 2019-05-17 at 14:44 +, Müller, Marcus (CEL) wrote:
>  Forwarded Message 
> > Hi Marcus,
> > 
> > The output from gnuradio-config-info --version is the follwing: 3.7.13.5
> > 
> > Regards
> > 
> > 
> > Den fre 17 maj 2019 kl 16:15 skrev Müller, Marcus (CEL) :
> > > Hi Sebastian,
> > > 
> > > I know this sounds a bit silly, but could you actually tell us the
> > > version that `gnuradio-config-info --version` reports? We're kind of in
> > > the process of getting new versions out, and I'm not quite sure what
> > > different people get when they use PyBOMBS.
> > > (also, almost certain you shouldn't have to use PyBOMBS if you just
> > > want to install a non-development version of GNU Radio; if you just
> > > want to install GNU Radio, use a recent Linux distro or OS X, you get a
> > > modern GNU Radio that works through the usual apt,dnf,pac,…
> > > installation method.)
> > > 
> > > Thank you,
> > > Marcus
> > > On Fri, 2019-05-17 at 16:00 +0200, Sebastian Sahlin wrote:
> > > > Hi,
> > > > 
> > > > I get the following output when trying to create a tagged stream block 
> > > > with the modtool using Python as the language: 
> > > > https://pastebin.com/D6gKJ2aS
> > > > 
> > > > GNURadio and gr_modtool version is the latest as installed with pybombs.
> > > > 
> > > > Regards,
> > > > Sebastian
> > > > 
> > > >  
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [Fwd: Re: gr_modtool error when attempting to create Python tagged_stream block]

[CEL]

 Forwarded Message 
> Hi Marcus,
> 
> The output from gnuradio-config-info --version is the follwing: 3.7.13.5
> 
> Regards
> 
> 
> Den fre 17 maj 2019 kl 16:15 skrev Müller, Marcus (CEL) :
> > Hi Sebastian,
> > 
> > I know this sounds a bit silly, but could you actually tell us the
> > version that `gnuradio-config-info --version` reports? We're kind of in
> > the process of getting new versions out, and I'm not quite sure what
> > different people get when they use PyBOMBS.
> > (also, almost certain you shouldn't have to use PyBOMBS if you just
> > want to install a non-development version of GNU Radio; if you just
> > want to install GNU Radio, use a recent Linux distro or OS X, you get a
> > modern GNU Radio that works through the usual apt,dnf,pac,…
> > installation method.)
> > 
> > Thank you,
> > Marcus
> > On Fri, 2019-05-17 at 16:00 +0200, Sebastian Sahlin wrote:
> > > Hi,
> > > 
> > > I get the following output when trying to create a tagged stream block 
> > > with the modtool using Python as the language: 
> > > https://pastebin.com/D6gKJ2aS
> > > 
> > > GNURadio and gr_modtool version is the latest as installed with pybombs.
> > > 
> > > Regards,
> > > Sebastian
> > > 
> > >  
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_modtool error when attempting to create Python tagged_stream block

[CEL]

Hi Sebastian,

I know this sounds a bit silly, but could you actually tell us the
version that `gnuradio-config-info --version` reports? We're kind of in
the process of getting new versions out, and I'm not quite sure what
different people get when they use PyBOMBS.
(also, almost certain you shouldn't have to use PyBOMBS if you just
want to install a non-development version of GNU Radio; if you just
want to install GNU Radio, use a recent Linux distro or OS X, you get a
modern GNU Radio that works through the usual apt,dnf,pac,…
installation method.)

Thank you,
Marcus
On Fri, 2019-05-17 at 16:00 +0200, Sebastian Sahlin wrote:
> Hi,
> 
> I get the following output when trying to create a tagged stream block with 
> the modtool using Python as the language: https://pastebin.com/D6gKJ2aS
> 
> GNURadio and gr_modtool version is the latest as installed with pybombs.
> 
> Regards,
> Sebastian
> 
>  
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Create a "virtual" variable using outputs from another block

[CEL]

It's possible through the "Probe" thing; I don't like that block,
because it leads to bad flowgraph design in 90% of cases. 
However, it should solve the problem you're having :)

Best regards,
Marcus

On Fri, 2019-05-17 at 13:31 +, tom sutherland wrote:
> Is there a way to take the output from a block and make it appear as though 
> that signal is a variable? e.g. take the output from a “signal source” block 
> and sink it into a block that creates a “variable” named ‘myfreqvar”. Then 
> use “myfreqvar” as a parameter in other blocks.
> Tom
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question on processor micro-architecture and GNU Radio

[CEL]

Hi Ali,

well, since GNU Radio does high-rate realtime signal processing, code
optimization is important to us. 
So much, that we strive to separate the most CPU-intense algorithms
into a separate library[1] that contains hand-optimized code for
different architectures (e.g. NEON, MMX, SSE2, SSE4.2…).

-march=native doesn't affect us as FOSS project very much, because
while that is fine for you if you compile stuff for your own computer,
you can't do that when you're compiling code for someone else's
computer, which might not have the same CPU microarch as you.

So, if you're a project, and you're having a build system, which all
large projects have, you must *never* enforce -march=native in your
build system by default. Someone will take your build system and build
a binary, put it into a package and ship it out to the users. And that
doesn't work out, since the user doesn't have the same CPU as the
computer building the binary.
So, by definition, that flag is interesting only to the end-user that
compiles the code her/himself; those are, in large projects, a minority
of users.

> There seems to be conflicting opinions online, ranging from "it's
does nothing" to "it can break code".

Well, there's also opinions online that the earth is flat :D

A lot of time and money goes into optimization of the machine code
generated by compiler suites like clang/LLVM and GCC. Of course that
means that if you use -march=native on a x86_64 with AVX2 and SSE up to
4.2, then your vector multiplications are going to be faster; yay!
So, if you're compiling GNU Radio on your supercomputing cluster's
build nodes to run a HPC simulation on a lot of identical nodes, by all
means, use -march=native. 

I wouldn't expect breakage; that sounds like unfounded rumors.
Compilers are comparatively mature these days. That doesn't mean that
bugs do not happen, but I'd surprised if I were the one to discover
some.
Of course, code compiled with -march=native is only for the machine it
was compiled on, not for any other machine. If you copy that executable
to your neighbor's PC, well, you're the one breaking the code, not the
compiler. The compiler was told that it can expect a machine that
supports exactly the ISA it sees on its own CPU.

Best regards,
Marcus

[1] https://libvolk.org
On Thu, 2019-05-16 at 14:30 -0700, Ali Dormiani wrote:
> Hello all,
> 
> I was wondering how the compiler option "-march=native" effects large FOOS 
> projects like GNU Radio.
> 
> There seems to be conflicting opinions online, ranging from "it's does 
> nothing" to "it can break code".
> 
> Would GNU Radio (and VOLK by extension) benefit from this compiler option for 
> AVX512 (or other advanced x68-64 ISA) compliant chips? 
> 
> Thank you for your time,
> 
> Ali
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] query regarding store transmitted signal

[CEL]

https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F
On Fri, 2019-05-17 at 17:06 +0530, Maitry Raval wrote:
> Hello,
> 
> Thanks for your reply.
> 
> I.e It is possible to store the transmitted modulated signal (for ex AM 
> modulated signal) through USRP as per below, 
> USRP source - file sink. but in which format, this data can be stored? (.txt, 
> .pdf)_ I have seen.DAT file in one of the example,but when I tried , it does 
> not give proper output.
> 
> Actually, my requirement is to receive the modulated signal through USRP 
> source, store it in a file. and later, I can be able to do demodulation 
> offline from that particular stored data. it will be grateful, if you provide 
> guidance.
> 
> 
> With Best Regards,
> Maitry Raval,
> 
> - Original Message -
> From: "Marcus Müller, CEL" 
> To: "discuss-gnuradio" , "maitry raval" 
> 
> Sent: Friday, 17 May, 2019 10:50:00
> Subject: Re: [Discuss-gnuradio] query regarding store transmitted signal
> 
> Hi Maitry,
> 
> sorry, we have no idea what lab you're referring to! However, yes, that
> sounds exactly what File Sinks are meant to do.
> 
> Best regards,
> Marcus
> 
> On Fri, 2019-05-17 at 12:01 +0530, Maitry Raval wrote:
> > Hello,
> > 
> > I want to store the modulated transmitted signal through USRP such as given 
> > in lab -3 receiving AM signal and store it as .DAT file. Is it possible to 
> > store transmitted signal as .DAT file through USRP source and file sink? 
> > and use that stored data from file source to do demodulation.
> > thanks for your support in advance.
> > 
> > 
> > With Best Regards,
> > Maitry Raval,
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] query regarding store transmitted signal

[CEL]

Hi Maitry,

sorry, we have no idea what lab you're referring to! However, yes, that
sounds exactly what File Sinks are meant to do.

Best regards,
Marcus

On Fri, 2019-05-17 at 12:01 +0530, Maitry Raval wrote:
> Hello,
> 
> I want to store the modulated transmitted signal through USRP such as given 
> in lab -3 receiving AM signal and store it as .DAT file. Is it possible to 
> store transmitted signal as .DAT file through USRP source and file sink? and 
> use that stored data from file source to do demodulation.
> thanks for your support in advance.
> 
> 
> With Best Regards,
> Maitry Raval,
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Continous Transmission using GNU RADIO. Is it really possible?

[CEL]

https://web.archive.org/web/20170423012135/https://oshearesearch.com/index.php/page/2/#post-194
might be of interest, too.
On Mon, 2019-05-13 at 10:55 -0700, Joe K wrote:
> Hi,
> 
> Hopefully I'm not hijacking Mehtap's thread too badly but it seems that the 
> website with gr-eventstream documentation is no longer available.  It doesn't 
> seem that there's much inline documentation or anything else in the git repo. 
>  Am I missing something?  Does anybody have cached copies of the 
> documentation?  It sounds like gr-eventstream could be useful to me but 
> without much saying what, exactly, it does, it's a bit difficult to parse.  
> The GRC blocks don't have inline documentation available for the most part 
> and their ports aren't immediately clear as to what they're doing.  Google 
> isn't coming up with much either.
> 
> Thanks and sorry if the info is already out there and I'm just not seeing it.
> 
> Joe
> 
> On Mon, May 13, 2019 at 5:46 AM Müller, Marcus (CEL)  wrote:
> > Hi Mehtap, please answer on the list.
> > 
> > The purpose of gr-eventstream is exactly to enable what you're trying.
> > 
> > Best regards,
> > Marcus
> > 
> > On Mon, 2019-05-13 at 15:40 +0300, mehtap özkan wrote:
> > > Thank you Marcus,
> > >  I have looked at gr-eventstream and found it useful for bursty 
> > > transmissions not continous ones.
> > > Maybe there is a way to produce  '0's and add/ xor them with real data?
> > > Any advice on that? 
> > > 
> > > Müller, Marcus (CEL) , 13 May 2019 Pzt, 15:23 tarihinde 
> > > şunu yazdı:
> > > > Dear Mehtap,
> > > > 
> > > > On Mon, 2019-05-13 at 15:03 +0300, mehtap özkan wrote:
> > > > > Dear All,
> > > > >  I have implemented a CPFSK transmitter succesfully using GNU RADIO.
> > > > 
> > > > Cool!
> > > > 
> > > > > The blocks are PRBS Source->Scrambler (G3RUH)-> CPFSK Mod-> UHD Sink. 
> > > > > The reference HW receiver receives and demodulates the signal quite 
> > > > > well.
> > > > 
> > > > It's always a nice feeling when something works with real hardware :)
> > > > 
> > > > >  
> > > > > Then I remove the PRBS Source and place a UDP Source+UART block as 
> > > > > the data source.
> > > > > When the connected client sends continous data, everything is fine 
> > > > > (except at the start of transmission where the receiver needs time to 
> > > > > lock to the incoming signal).
> > > > > When I send some bytes from the client and stop sending, the 
> > > > > transmission becomes burst-like and the receiver can demodulate 
> > > > > pretty much nothing.
> > > > > I found the culprit which is the Scrambler, when there is no input to 
> > > > > the Scrambler, there is no output, so there is no RF output.
> > > > 
> > > > Well, I wouldn't call it a "culprit", since it does what it's designed
> > > > to do: Scramble data. 
> > > > 
> > > > >  I have also developed a FPGA Continous CPFSK transmitter in the past 
> > > > > and the scrambler there was producing output every clock cycle as 
> > > > > there was 0 in its Input, so that guaranteed continous output.
> > > > >  The real problem is: What should I do to force some Input bits to 
> > > > > the Scrambler, even there is no real data?
> > > > 
> > > > The gr-eventstream module might be of interest to you!
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Continous Transmission using GNU RADIO. Is it really possible?

[CEL]

Hi,

you're right, the webserver seems down. Are you looking for


https://web.archive.org/web/20170422112538/https://oshearesearch.com/index.php/2015/05/31/building-a-burst-fsk-modem-in-gnu-radio-with-message-lambda-blocks-and-eventstream/

Best regards,
Marcus

On Mon, 2019-05-13 at 10:55 -0700, Joe K wrote:
> Hi,
> 
> Hopefully I'm not hijacking Mehtap's thread too badly but it seems that the 
> website with gr-eventstream documentation is no longer available.  It doesn't 
> seem that there's much inline documentation or anything else in the git repo. 
>  Am I missing something?  Does anybody have cached copies of the 
> documentation?  It sounds like gr-eventstream could be useful to me but 
> without much saying what, exactly, it does, it's a bit difficult to parse.  
> The GRC blocks don't have inline documentation available for the most part 
> and their ports aren't immediately clear as to what they're doing.  Google 
> isn't coming up with much either.
> 
> Thanks and sorry if the info is already out there and I'm just not seeing it.
> 
> Joe
> 
> On Mon, May 13, 2019 at 5:46 AM Müller, Marcus (CEL)  wrote:
> > Hi Mehtap, please answer on the list.
> > 
> > The purpose of gr-eventstream is exactly to enable what you're trying.
> > 
> > Best regards,
> > Marcus
> > 
> > On Mon, 2019-05-13 at 15:40 +0300, mehtap özkan wrote:
> > > Thank you Marcus,
> > >  I have looked at gr-eventstream and found it useful for bursty 
> > > transmissions not continous ones.
> > > Maybe there is a way to produce  '0's and add/ xor them with real data?
> > > Any advice on that? 
> > > 
> > > Müller, Marcus (CEL) , 13 May 2019 Pzt, 15:23 tarihinde 
> > > şunu yazdı:
> > > > Dear Mehtap,
> > > > 
> > > > On Mon, 2019-05-13 at 15:03 +0300, mehtap özkan wrote:
> > > > > Dear All,
> > > > >  I have implemented a CPFSK transmitter succesfully using GNU RADIO.
> > > > 
> > > > Cool!
> > > > 
> > > > > The blocks are PRBS Source->Scrambler (G3RUH)-> CPFSK Mod-> UHD Sink. 
> > > > > The reference HW receiver receives and demodulates the signal quite 
> > > > > well.
> > > > 
> > > > It's always a nice feeling when something works with real hardware :)
> > > > 
> > > > >  
> > > > > Then I remove the PRBS Source and place a UDP Source+UART block as 
> > > > > the data source.
> > > > > When the connected client sends continous data, everything is fine 
> > > > > (except at the start of transmission where the receiver needs time to 
> > > > > lock to the incoming signal).
> > > > > When I send some bytes from the client and stop sending, the 
> > > > > transmission becomes burst-like and the receiver can demodulate 
> > > > > pretty much nothing.
> > > > > I found the culprit which is the Scrambler, when there is no input to 
> > > > > the Scrambler, there is no output, so there is no RF output.
> > > > 
> > > > Well, I wouldn't call it a "culprit", since it does what it's designed
> > > > to do: Scramble data. 
> > > > 
> > > > >  I have also developed a FPGA Continous CPFSK transmitter in the past 
> > > > > and the scrambler there was producing output every clock cycle as 
> > > > > there was 0 in its Input, so that guaranteed continous output.
> > > > >  The real problem is: What should I do to force some Input bits to 
> > > > > the Scrambler, even there is no real data?
> > > > 
> > > > The gr-eventstream module might be of interest to you!
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UART block in GNU RADIO?

[CEL]

I doubt you'd find a ready-made block. However, writing that would take
literal minutes in Python or C++!

https://wiki.gnuradio.org/index.php/Guided_Tutorials Chapters 2,3,4 and
5 should be an easy read for you at this point.

Best regards,
Marcus

On Mon, 2019-05-13 at 23:09 +0300, mehtap özkan wrote:
> Dear All,
>  Is there an OOT block where the input is UnPacked Data and the output is 
> UART formatted UnPacked data.
> The UART Protocol is shown in 
> http://www.circuitbasics.com/wp-content/uploads/2016/01/Introduction-to-UART-Packet-Frame-and-Bits-2.png.
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Continous Transmission using GNU RADIO. Is it really possible?

[CEL]

Hi Mehtap, please answer on the list.

The purpose of gr-eventstream is exactly to enable what you're trying.

Best regards,
Marcus

On Mon, 2019-05-13 at 15:40 +0300, mehtap özkan wrote:
> Thank you Marcus,
>  I have looked at gr-eventstream and found it useful for bursty transmissions 
> not continous ones.
> Maybe there is a way to produce  '0's and add/ xor them with real data?
> Any advice on that? 
> 
> Müller, Marcus (CEL) , 13 May 2019 Pzt, 15:23 tarihinde şunu 
> yazdı:
> > Dear Mehtap,
> > 
> > On Mon, 2019-05-13 at 15:03 +0300, mehtap özkan wrote:
> > > Dear All,
> > >  I have implemented a CPFSK transmitter succesfully using GNU RADIO.
> > 
> > Cool!
> > 
> > > The blocks are PRBS Source->Scrambler (G3RUH)-> CPFSK Mod-> UHD Sink. The 
> > > reference HW receiver receives and demodulates the signal quite well.
> > 
> > It's always a nice feeling when something works with real hardware :)
> > 
> > >  
> > > Then I remove the PRBS Source and place a UDP Source+UART block as the 
> > > data source.
> > > When the connected client sends continous data, everything is fine 
> > > (except at the start of transmission where the receiver needs time to 
> > > lock to the incoming signal).
> > > When I send some bytes from the client and stop sending, the transmission 
> > > becomes burst-like and the receiver can demodulate pretty much nothing.
> > > I found the culprit which is the Scrambler, when there is no input to the 
> > > Scrambler, there is no output, so there is no RF output.
> > 
> > Well, I wouldn't call it a "culprit", since it does what it's designed
> > to do: Scramble data. 
> > 
> > >  I have also developed a FPGA Continous CPFSK transmitter in the past and 
> > > the scrambler there was producing output every clock cycle as there was 0 
> > > in its Input, so that guaranteed continous output.
> > >  The real problem is: What should I do to force some Input bits to the 
> > > Scrambler, even there is no real data?
> > 
> > The gr-eventstream module might be of interest to you!
> > 
> > Best regards,
> > Marcus
> > 


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Continous Transmission using GNU RADIO. Is it really possible?

[CEL]

Dear Mehtap,

On Mon, 2019-05-13 at 15:03 +0300, mehtap özkan wrote:
> Dear All,
>  I have implemented a CPFSK transmitter succesfully using GNU RADIO.

Cool!

> The blocks are PRBS Source->Scrambler (G3RUH)-> CPFSK Mod-> UHD Sink. The 
> reference HW receiver receives and demodulates the signal quite well.

It's always a nice feeling when something works with real hardware :)

>  
> Then I remove the PRBS Source and place a UDP Source+UART block as the data 
> source.
> When the connected client sends continous data, everything is fine (except at 
> the start of transmission where the receiver needs time to lock to the 
> incoming signal).
> When I send some bytes from the client and stop sending, the transmission 
> becomes burst-like and the receiver can demodulate pretty much nothing.
> I found the culprit which is the Scrambler, when there is no input to the 
> Scrambler, there is no output, so there is no RF output.

Well, I wouldn't call it a "culprit", since it does what it's designed
to do: Scramble data. 

>  I have also developed a FPGA Continous CPFSK transmitter in the past and the 
> scrambler there was producing output every clock cycle as there was 0 in its 
> Input, so that guaranteed continous output.
>  The real problem is: What should I do to force some Input bits to the 
> Scrambler, even there is no real data?

The gr-eventstream module might be of interest to you!

Best regards,
Marcus



smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC2019]: First report from Bowen

[CEL]

Hi Johannes,

I've agreed with Bowen that for the time being, he'll be developing an
OOT for the versions available currently through Linux distros. So,
3.7.13.x it is – the porting to 3.8 OOTs can be done later.

As much I need people to test the 3.8 OOT structure, it's my
responsibility to shield Bowen from trying to many untested things at
once; hope you understand.

Generally, in the GNU Radio world I envision, people will very rarely
be forced to do a source build of GNU Radio itself :)

Best regards,
Marcus

On Mon, 2019-05-13 at 08:28 +, Johannes Demel wrote:
> Hi Bowen,
> 
> it's great that you start to work on your project right away. Since you 
> want to implement a new feature for GNU Radio, I'd suggest to use the 
> latest GNU Radio version which is the one in the repository. To rephrase 
> it, I recommend to use GNU Radio 3.8. Though, I assume you already 
> discussed this with your mentors or will do so.
> Therefore I suggest to use a source build/install instead of the version 
> provided by your distribution.
> 
> Cheers
> Johannes
> 
> Am 12.05.19 um 18:18 schrieb Bowen Hu:
> > Hi all,
> > 
> > I am happy to be accepted by GSoC 2019 working on cycle-accurate 
> > simulation of Verilog. Here 
> > ; 
> > (https://b0wen-hu.github.io/2019/05/12/First-report/) 
> > is my first report.
> > 
> > 
> > ## Progress this week
> > I have set up the working environment and read some tutorials for GNU 
> > Radio development in the last few days.
> > 
> > My current working environment is Ubuntu 18.04 LTS installed GNU Radio 
> > version 3.7.11 by apt, but I am considering switch to newest Ubuntu 
> > 19.04 which shipped with GNU Radio version 3.7.13 by apt.
> > 
> > I am following the tutorial and created my first module gr-howto (This 
> > may not be a good name, so I will change the module name in the coming 
> > week). I will continue to read tutorials, hopefully I could finish them 
> > (from chapter 2 to chapter 7) in the next week.
> > 
> > I also managed to run the simulation of a simple Verilog module with 
> > Verilator, it works as anticipated, you can find it here. This is just a 
> > standalone simulation program, in order to let the GNU Radio work with 
> > the Verilator-generated file, there are much work to do.
> > 
> > ## Plan next week
> > Finish all the tutorials from chapter 2 to chapter 7.
> > 
> > Try to make the Verilator related header file available in GNU Radio 
> > blocks. A source block like this (flicker.v) would be a good start.
> > 
> > ## Issue(s)
> > The module name gr-howto need to be changed.
> > 
> > 
> > Best regards,
> > Bowen
> > 
> > ___
> > 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


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installing gnuradio on docker

[CEL]

That is a very generic problem: Programs from your docker container
can't connect to the host's X server. Google that error – there's
plenty of articles on how to make X programs work within a docker
container.

Again, I'd strongly advise you to use something less ancient than
Ubuntu 16.04.

Best regards,
Marcus

On Thu, 2019-05-09 at 11:41 -0400, amani alshawabkeh wrote:
> Hi, and thanks a lot for your reply, 
> 
> please find below two of the errors I am getting:
> 1-  dpsk_loopback.py example used and I got:
> dpsk_loopback.py: cannot connect to X server
> 
> 2- I used one of the modified codes that uses gr-ieee802.11 I got something 
> like
> File "/wifi_rx.py", line 79, in __init__
> self.connect((self.ieee802_11_sync_short_0, 1), (self.blocks_delay_1, 0))
>   File 
> "/root/gnuradio/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 
> 47, in wrapped
> func(self, src, src_port, dst, dst_port)
>   File 
> "/root/gnuradio/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 
> 110, in connect
> self.primitive_connect(*args)
>   File 
> "/root/gnuradio/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", 
> line 5336, in primitive_connect
> return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
> ValueError: port number 1 exceeds max of 0
> 
> thanks a lot for your help
> amani
> 
> 
> 
> On Thu, May 9, 2019 at 11:19 AM Müller, Marcus (CEL)  wrote:
> > Since the whole purpose of using a docker container is to isolate the
> > contents of the container: 
> > Please use something less ancient than Ubuntu 16.04.
> > 
> > Best regards,
> > Marcus Müller
> > 
> > PS: "I get errors" is probably not a sufficient description to help you
> > in any way! Please be more verbose :)
> > 
> > On Thu, 2019-05-09 at 11:03 -0400, amani alshawabkeh wrote:
> > > > Hi all,
> > > > 
> > > > I am trying to install and run latest Gnuradio version (3.7.13.4) on 
> > > > Ubuntu 16.04 docker. I tried using pybombs and from source installation 
> > > > but after the installing gnuradio and trying to run any example I am 
> > > > getting errors.
> > > > 
> > > > Any suggestions? Is there any dependency that I need to install other 
> > > > than the ones mentioned in gnuradio page.
> > > > 
> > > > Thanks,
> > > > Amani
> > > > **
> > > > 
> > > 
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installing gnuradio on docker

[CEL]

Since the whole purpose of using a docker container is to isolate the
contents of the container: 
Please use something less ancient than Ubuntu 16.04.

Best regards,
Marcus Müller

PS: "I get errors" is probably not a sufficient description to help you
in any way! Please be more verbose :)

On Thu, 2019-05-09 at 11:03 -0400, amani alshawabkeh wrote:
> > Hi all,
> > 
> > I am trying to install and run latest Gnuradio version (3.7.13.4) on Ubuntu 
> > 16.04 docker. I tried using pybombs and from source installation but after 
> > the installing gnuradio and trying to run any example I am getting errors.
> > 
> > Any suggestions? Is there any dependency that I need to install other than 
> > the ones mentioned in gnuradio page.
> > 
> > Thanks,
> > Amani
> > **
> > 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC19] Accepted student projects announced!

[Wunsch, Felix (CEL)]

Hi all,


Google has announced the accepted student projects for GSoC 2019: Arpit Gupta 
and Bowen Hu will be contributing to GNU Radio during the summer - 
congratulations to both of them! Arpit will work on a tool for parsing GNU 
Radio header files to create YAML descriptions that can be used for GRC. His 
mentors are Nicolas Cuervo and Sebastian Koslowski. Marcus Müller will support 
Bowen who will work on cycle-accurate simulation of Verilog code.


Both are exciting projects that will bring new functionality to GNU Radio. 
Bowen and Arpit will keep you up-to-date about their progress in weekly blog 
posts. Expect the first posts later this week. Please welcome them in the 
community and give them feedback!


Arpit and Bowen, we are really happy to work with you and we are looking 
forward to seeing your contributions!


To all students who unfortunately could not be selected: Thank you for applying 
to GNU Radio and please try again next year! :)


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

Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

[CEL]

Hey Gary,
please keep things on the list! Good news:
That's the exact opposite of what I wanted to convey! *Use* GNU Radio's
existing portaudio interface; chances are that your GNU Radio
installation supports that (which is why I asked how you've installed
it).
https://www.gnuradio.org/doc/doxygen/page_audio.html tells us how to do
that:
you just need to find your GNU Radio configuration (for me as Unix user
it's in ~/.gnuradio/config.conf, but yours is probably somewhere else;
running `gnuradio-config-info --userprefsdir` should give you an idea
where to look). Add, if not already in there, the following:

[audio]
audio_module = portaudio

Done! That tells GNU Radio to not just try the first best guess of what
audio system you want to use (that being windows API under windows),
but to specifically use portaudio – and that should have the features
you're looking for.

Still, the windows source not working as it should is a pain. We should
fix that. 

Best regards,
Marcus

On Sat, 2019-05-04 at 08:05 +0100, gary.simpk...@gdscs.co.uk wrote:
> Many thanks for the explanation. Looks like I can go no further. I do
> not have the skills to develope the audio source. 
> 
> Gary
> 
> Sent from my Huawei Mobile
> 
> 
>  Original Message 
> Subject: Re: [Discuss-gnuradio] Audio source cannot use 2 outputs
> (Stereo) in
> windows
> From: "M黮ler, Marcus (CEL)" 
> To: discuss-gnuradio@gnu.org,gary.simpk...@gdscs.co.uk
> CC: 
> 
> 
> > Hi Gary!
> > 
> > > I have double checked and all the windows audio devices I have
> > > used 
> > > for the audio source are 2 channels.
> > 
> > I never doubted that – all I wanted to point out that the I think
> > it
> > was Windows that told the GNU Radio windows audio source it saw
> > only
> > one channel, and consequently the windows audio source only enabled
> > one
> > output port.
> > 
> > I was wrong, it turns out! When you look at gr-
> > audio/liob/windows/windows_source.cc, you'll find the number of
> > output
> > streams of the block to be hardcoded to be between 1 and 1, so...
> > 1:
> > 
> > 
> > windows_source::windows_source(int sampling_freq,
> > const std::string
> > device_name)
> > : sync_block("audio_windows_source",
> > io_signature::make(0, 0, 0),
> > io_signature::make(1, 1,
> > sizeof(float))),
> > 
> > The last line does that.
> > So, that's a um, underdeveloped feature in the windows audio
> > source.
> > 
> > > 
> > > They work fine with WSJT-X, or MAP65.
> > > 
> > > The stereo channels I wish to use are the I and Q outputs from
> > my 
> > > SDRPLay Duo using virtual cables
> > > 
> > > (I have tried the speaker outputs from the PC with GNURadio audio
> > > source 
> > > and get the same problem)
> > > 
> > > Does the audio source work with two channels on linux?
> > 
> > Yes, (haven't tried today, but it /used/ to work), but it sadly
> > shares
> > nearly no code with the windows audio source. That's due to fact
> > that
> > Linux' ALSA and Windows' sound API and OS X's Core Audio are pretty
> > different.
> > 
> > I do have an idea, though, which *might* be a solution to your
> > problem,
> > but: untested; don't expect wonders.
> > 
> > Has your GNU Radio build portaudio enabled? As said, it's not
> > tested,
> > but unlike the windows audio source, the portaudio source at least
> > from
> > the state of the source code (far as I can tell) enables as many
> > maximum output streams as your card has.
> > > 
> > > I am using the latest version of GNURadio 3.7.13.4 on a 64bit win
> > 10
> > > PC.
> > > 
> > 
> > Built from source, or where did you happen across it?
> > 
> > > I am really stuck here. Nothing I try allows the second output to
> > be 
> > > enabled.
> > > 
> > 
> > Sorry to hear that! We'll try to get you unstuck :)
> > 
> > Best regards,
> > Marcus


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

[CEL]

Hi Gary!

> I have double checked  and  all the windows audio devices I have
> used 
> for the audio source are 2 channels.

I never doubted that – all I wanted to point out that the I think it
was Windows that told the GNU Radio windows audio source it saw only
one channel, and consequently the windows audio source only enabled one
output port.

I was wrong, it turns out! When you look at gr-
audio/liob/windows/windows_source.cc, you'll find the number of output
streams of the block to be hardcoded to be between 1 and 1, so... 1:


windows_source::windows_source(int sampling_freq,
   const std::string
device_name)
  : sync_block("audio_windows_source",
  io_signature::make(0, 0, 0),
  io_signature::make(1, 1,
sizeof(float))),

The last line does that.
So, that's a um, underdeveloped feature in the windows audio source.

> 
> They work fine with  WSJT-X, or MAP65.
> 
> The stereo channels I wish to use are the I and Q outputs from my 
> SDRPLay Duo using virtual cables
> 
> (I have tried the speaker outputs from the PC with GNURadio audio
> source 
> and get the same problem)
> 
> Does the audio source work with two channels on linux?

Yes, (haven't tried today, but it /used/ to work), but it sadly shares
nearly no code with the windows audio source. That's due to fact that
Linux' ALSA and Windows' sound API and OS X's Core Audio are pretty
different.

I do have an idea, though, which *might* be a solution to your problem,
but: untested; don't expect wonders.

Has your GNU Radio build portaudio enabled? As said, it's not tested,
but unlike the windows audio source, the portaudio source at least from
the state of the source code (far as I can tell) enables as many
maximum output streams as your card has.
> 
> I am using the latest version of GNURadio 3.7.13.4 on a 64bit win 10
> PC.
> 

Built from source, or where did you happen across it?

> I am really stuck here. Nothing I try allows the second output to be 
> enabled.
> 

Sorry to hear that! We'll try to get you unstuck :)

Best regards,
Marcus


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building on Windows 10

[CEL]

I want to second this! We've only been very stringent with versioning
starting in the last couple of years, but really, it should rarely
matter whether you use 3.7.13.4 or 3.7.2 for things that worked under
3.7.2 – so, please try with something less arcane!

Best regards,
Marcus

On Thu, 2019-05-02 at 07:31 +0100, Derek Kozel wrote:
> Hi Marc,
> 
> The most recommended way of building GNU Radio on Windows is documented
> here:
> https://wiki.gnuradio.org/index.php/WindowsInstall#Building_on_Windows_with_Native_Tools
> 
> That approach is only valid for versions after 3.7.9.2 though. If you
> need an earlier version I'm afraid that I don't have any advice. It is
> probably not possible (easy) currently to build under Eclipse.
> 
> Regards,
> Derek
> 
> On 02/05/2019 02:19, Marc Kaufman wrote:
> > I've installed cygwin, and I'm trying to build 3.7.2, but I keep
> > getting "configuring incomplete. errors occurred!"
> > 
> > I don't see any errors in CMakeOutput.log. According to terminal
> > output I seem to be missing Ice-3.5, alsa, jack, portaudio, comedilib,
> > PyQt4, uhd. I don't see any of these in the cygwin depot.
> > 
> > (extra point question: Is there a way to build under Eclipse?)
> > 
> > What am I missing? Thanks.
> > 
> > 
> > ___
> > 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


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Audio source stereo not working

[CEL]

Hi Gary, since we acutely changed things in the Windows audio sink:
What's your version of GNU Radio?

Generally, Windows seems to be of the conviction that the audio device
you're trying to record from only has one, not two channels. 

Best regards,
Marcus

On Thu, 2019-05-02 at 08:53 +0100, Gary.Simpkins wrote:
> Hi. Anyone who can help.
> 
> Try as I may I cannot get a second port working using the audio source 
> block.
> 
> When I set the number of outputs to 2 for stereo (as in the 
> documentation) I get the error below.
> 
> File "C:\Users\Gary\Documents\top_block.py", line 109, in 
>  main()
>File "C:\Users\Gary\Documents\top_block.py", line 97, in main
>  tb = top_block_cls()
>File "C:\Users\Gary\Documents\top_block.py", line 75, in __init__
>  self.connect((self.audio_source_0, 1), (self.audio_sink_1, 0))
>File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\hier_block2.py", 
> line 47, in wrapped
>  func(self, src, src_port, dst, dst_port)
>File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\hier_block2.py", 
> line 110, in connect
>  self.primitive_connect(*args)
>File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py", 
> line 5312, in primitive_connect
>  return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
> ValueError: port number 1 exceeds max of 0
> 
> Am I missing something?
> 
> Gary
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Modulation order of FSK

[CEL]

Dear Batu,

as I said: still: the Frequency modulator.

best regards,
Marcus

On Thu, 2019-05-02 at 00:27 +0300, Batu Kaplan wrote:
> Thanks for advice Ron. 
> 
> What should I do for getting M-FSK signal after the Chunks to Symbols
> block output?
> 
> Yours Sincerely.
> 
> Batu Kaplan , 26 Nis 2019 Cum, 16:46 tarihinde
> şunu yazdı:
> > Dear Marcus,
> > 
> > Thanks for your response. First of all, it is been a while
> > for answering your response and I am sorry about that. I could not
> > try your solution until these days. Unfortunately, I still couldn't
> > get over my problem on M-FSK modulation. When I try your solution,
> > "bits to symbols and after that using frequency modulator", I
> > managed to convert bits to integers using the packed to unpacked
> > block. However, after subtracting data from 1.5(for M=4), that
> > point I am stuck. Using frequency modulator will make an FSK
> > modulated signal? 
> > 
> > If you can still help, I will be appreciated. Thanks in advance.
> > 
> > Yours sincerely. 
> > 
> > 
> > Flowgraph
> > Bits2Integers
> > 
> > Müller, Marcus (CEL) , 6 Mar 2019 Çar, 23:13
> > tarihinde şunu yazdı:
> > > Really quickly, I need to get going:
> > > with unpacked-to-packed (or vice versa) you can convert your bit
> > > stream
> > > to integers between 0 and 3. Convert to float, subtract 1.5, use
> > > with
> > > frequency modulator?
> > > 
> > > Best regards,
> > > Marcus
> > > On Wed, 2019-03-06 at 18:14 +0300, Batu Kaplan wrote:
> > > > Hello, Marcus.
> > > > First of all, I'm very grateful for your answer. But how I can
> > > make a
> > > > connection between the bits and the "baseband frequency values"
> > > that
> > > > you mentioned in the mail? 
> > > > For example, I have a 000110 bit series for 4FSK. And then, I
> > > think I
> > > > need to pack into 2 bits like 00-01-10. But then how can I turn
> > > the
> > > > bits to appropriate form for implement the frequency modulation
> > > > block? After that, am I going to apply to the frequency
> > > modulation
> > > > block for each group of symbols? Can you share a flow chart for
> > > > understand better? like file txt ---> packed --->frequency mod
> > > >
> > > > sink.
> > > > 
> > > >  Yours sincerely.
> > > > -Batuhan Kaplan
> > > > 
> > > > Batu Kaplan , 5 Mar 2019 Sal, 12:09
> > > tarihinde
> > > > şunu yazdı:
> > > > > Hello, Marcus.
> > > > > First of all, I'm very grateful for your answer. But how I
> > > can make
> > > > > a connection between the bits and the "baseband frequency
> > > values"
> > > > > that you mentioned in the mail? 
> > > > > For example, I have 000110 bit series for 4FSK. And then, I
> > > think I
> > > > > need to pack into 2 bits like 00-01-10. But then how can I
> > > turn the
> > > > > bits to appropriate form for implement the frequency
> > > modulation
> > > > > block? After that, am I going to apply to the frequency
> > > modulation
> > > > > block for each group of symbols? Can you share a flow chart
> > > for us
> > > > > to understand better? like file txt ---> packed --->
> > > frequency mod
> > > > > > sink.
> > > > > 
> > > > >  Yours sincerely.
> > > > > -Batuhan Kaplan
> > > > > 
> > > > > Müller, Marcus (CEL) , 1 Mar 2019 Cum, 21:42
> > > > > tarihinde şunu yazdı:
> > > > > > Hi Batu,
> > > > > > 
> > > > > > a really intuitive way of implementing FSKs is to convert
> > > your
> > > > > > bit
> > > > > > groups to baseband frequency values (e.g. -1.5, -0.5, 0.5,
> > > 1.5)
> > > > > > and use
> > > > > > them with the frequency mod block.
> > > > > > 
> > > > > > Best regards,
> > > > > > Marcus
> > > > > > 
> > > > > > Marcus
> > > > > > 
> > > > > > On Fri, 2019-03-01 at 16:59 +0300, Batu Kaplan wrote:
> > > > > > > I am implementing the binary FSK with GFSK block and I
> > > think it
> > > > > > is working correctly. For the next step I want to increase
> > > my
> > > > > > modulation order of FSK modulation, like 4-FSK and 8-FSK,
> > > > > > however, I could not move forward from the file source
> > > block. How
> > > > > > can I implement the 4-FSK and 8-FSK on 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


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Half band decimator/interpolator

[CEL]

Hi Albin,

Don't know what Derek suggested, but be aware that our "straight" FIR
filter decimators are already polyphase implementations, and use SIMD
(through VOLK) heavily (run volk_profile if you want to make maximum
use of that advantage); it might be that on paper, the number of
operations are unnecessarily high, but in CPU practice, some cures are
worse than the disease.

For example, I haven't tried, but it's thoroughly possible that albeit
the classical case of "half your tap memory by only storing one half of
your symmetrical FIR" performs worse than just working with the full
(half redundant) tap vector, simply because doing so avoids nonlinear
memory access patterns.

Best regards,
Marcus

On Tue, 2019-04-23 at 19:06 +0200, Albin Stigö wrote:
> Thanks for the reply Marcus. Interesting approach for sure! Will have to 
> think about it...
> 
> Derek, your solution works but it will be 4 times slower than the example I 
> linked to.
> 
> 
> --Albin
> 
> 
> On Tue, Apr 23, 2019, 18:24 Müller, Marcus (CEL)  wrote:
> > Hi Albin,
> > 
> > I'm very very tired right now, but me and Felix came to the following
> > conclusions on our *Whiteboard Of Wisdom, Smarts, Expertise,
> > Rationality and Science* (WOWSERS):
> > 
> > 1. A Nyquist-M bandpass filter, esp. a halfband, has zeros on every
> > other tap – except for the one center tap, which is at the maximum of
> > the sinc that you window your prototype filter with. 
> > 2. you'd thus implement that filter as polyphase filter with two
> > different polyphase components:
> >   1. one polyphase component that contains all the zeros, and the
> >  single center tap that's not
> >   2. one component that contains all the non-zero taps
> > 3. you'd thus need to "deinterleave" your input stream into two:
> >   1. Delay by half the number of taps (and multiply by the maximum
> >   2. filter with all the non-zero taps
> > 4. sum up the results
> > 
> > So, for all this, we already have blocks – yay!
> > 
> > Best regards,
> > Marcus
> > 
> > On Tue, 2019-04-23 at 17:45 +0200, Albin Stigö wrote:
> > > Just checking before I write one, is there a half band 
> > > decimator/interpolator in gnuradio I haven't been able to find...
> > > 
> > > Optimized like this:
> > > http://liquidsdr.org/doc/resamp2/
> > > 
> > > Or is there an even better option for interpolation by 2?
> > > 
> > > 
> > > --Albin
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installing GNURadio On Raspberry Pi

[CEL]

Hi,

On Tue, 2019-04-23 at 19:31 -0700, lists wrote:
> https://wiki.gnuradio.org/index.php/Download

uhhh that wiki page is ... dated. It also doesn't solve the issue of
not being able to import gr-osmosdr, which isn't part of GNU Radio
itself!

Also, clearly *not* the way I'd recommend on a raspberry Pi:

What lazygranch recommends is a source build, which takes roughly
forever on a raspberry Pi, and requires use of copious amount of swap
memory, due to the limited amount of RAM of a Raspberry Pi. 

So, if you can, get a binary installation of GNU Radio. It seems you
already have one!

Then, you'll need to make sure you've got a working gr-osmosdr
installation on your Pi. How did you install GNU Radio and gr-osmosdr
on your Raspberry Pi so far?

Best regards,
Marcus



smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Half band decimator/interpolator

[CEL]

Hi Albin,

I'm very very tired right now, but me and Felix came to the following
conclusions on our *Whiteboard Of Wisdom, Smarts, Expertise,
Rationality and Science* (WOWSERS):

1. A Nyquist-M bandpass filter, esp. a halfband, has zeros on every
other tap – except for the one center tap, which is at the maximum of
the sinc that you window your prototype filter with. 
2. you'd thus implement that filter as polyphase filter with two
different polyphase components:
  1. one polyphase component that contains all the zeros, and the
 single center tap that's not
  2. one component that contains all the non-zero taps
3. you'd thus need to "deinterleave" your input stream into two:
  1. Delay by half the number of taps (and multiply by the maximum
  2. filter with all the non-zero taps
4. sum up the results

So, for all this, we already have blocks – yay!

Best regards,
Marcus

On Tue, 2019-04-23 at 17:45 +0200, Albin Stigö wrote:
> Just checking before I write one, is there a half band decimator/interpolator 
> in gnuradio I haven't been able to find...
> 
> Optimized like this:
> http://liquidsdr.org/doc/resamp2/
> 
> Or is there an even better option for interpolation by 2?
> 
> 
> --Albin
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNUradio installation problems (UHD? Python?)

[CEL]

Hi Chesir,

might be the case that CentOS 7's default SWIG is too old. Check that
you've got a recent SWIG!

However, if GNU Radio 3.7.11 is recent enough for you (and it would be,
for first steps): Simply `yum install gnuradio` after enabling EPEL
should do the trick :)

If you need something more recent, I've got an __experimental__ GNU
Radio 3.7.13.4 repo for CentOS 7: 

https://copr.fedorainfracloud.org/coprs/marcusmueller/gnuradio/

Best regards,
Marcus

On Mon, 2019-04-22 at 15:01 +, Chesir, Aaron M. wrote:
> Folks,
>  
> I do not know if this is the correct forum for this plea for help,
> but for now, I do not know of another choice:
>  
> I tried installing GNUradio on my Centos 7 laptop, using PyBombs.
>  
> As you can see from the attached, it ran quite far but then
> collapsed.
>  
> The error messages all refer to something called
> “uhd_swigPYTHON_wrap.cxx”. I have no idea what that is.
>  
> Can one of you please guide me as to my error, or what I should be
> doing differently?
>  
> My computer is running CentOS Linux 7, 64-bit.
>  
> Thank you in advance,
>  
> Aaron Chesir
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ber calculation

[CEL]

Hi Anubhav,

we have absolutely no idea what you're looking at. You'll have to
describe what you're doing in great detail.

Best regards,
Marcus

On Mon, 2019-04-22 at 12:29 +0530, ANUBHAV CHOUDHARY wrote:
> Can someone please help in calculating the ber?
> I think there Is delay mismatch in ref signal port and input signal
> port so how to calculate that delay?
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC19] Student application period is over, reviews started

[Wunsch, Felix (CEL)]

Hi all,


the student application period for this year's GSoC is now over and we have 
received some promising proposals! Right now we are reviewing them and hope to 
get enough student slots from Google to accommodate all the students we want to 
select. The final decisions will be announced on May 6 by Google. We are not 
allowed to give out any information about the selection before that date, so 
there will be no update until then.


Cheers,
Felix?

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

Re: [Discuss-gnuradio] GSOC proposal for android

[Wunsch, Felix (CEL)]

Hi Jaspreet,

it is your job to create a proposal so we can see that you know what you're up 
to and what your vision for the project is! If you go to our website, we have 
listed what we want to see in a proposal and there's also an old (successful) 
one you can have a look at.

Cheers?,
Felix?



Von: Discuss-gnuradio  
im Auftrag von Jaspreet Singh 
Gesendet: Freitag, 5. April 2019 05:42
An: discuss-gnuradio@gnu.org
Betreff: [Discuss-gnuradio] GSOC proposal for android

Hi,

Is there any publicly available gsoc proposal for android?
I would be making one from scratch otherwise & send here.

Thank you

Jaspreet Singh
Delhi, India
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC19] Application deadline approaching!

[Wunsch, Felix (CEL)]

?Hi all,


this is a gentle reminder to all prospective GSoC students that the application 
deadline (April 9) is rapidly approaching! Get your proposals ready and we'll 
try to give you feedback. And, of course, earlier upload means higher chance of 
getting feedback that you can use to improve your proposal and hence your 
chances for approval ;).


Cheers,
Felix (GSoC Org Admin 2019)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC19] Student Application Period begins!

[Wunsch, Felix (CEL)]

?Hi all,


today, the student application period for GSoC 19 begins. I'm really happy that 
we already have a lot of GSoC-related activity on this mailing list and I'm 
looking forward to reading all those proposals!


Make sure you apply until April 9, which is usually a strictly enforced 
deadline. But please don't wait until the last second - share your draft with 
us so we can discuss your ideas, your tools, your milestones, etc.


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

Re: [Discuss-gnuradio] [Announcement] Ctrlport is broken -> potential candidate for removal in 3.8 -> RPC discussion

[CEL]

Hi Johannes!

let me answer in-text real quick:
On Mon, 2019-03-25 at 10:13 +, Johannes Demel wrote:
> Hi Marcus,
> 
> it seems like Thrift is a painful dependency. So, this is a pro
> ctrlport 
> removal. Though, what else does ctrlport removal entail?

Removal of Ctrlport and the tools dependent on it.

> Is it really only used for monitoring and control?

I'm only speaking for in-tree code, but yes.
Speaking for the whole ecosystem: I'm by now aware of 1 (one) external
project that uses CtrlPort. We're in contact.

> Just for clarification, the zeromq blocks are not affected?

Not affected.

> How will the performance monitor be preserved?

At this point, I have no clue. Suggestions welcome!

>  I really like to look at 
> the statistics to get a first idea where to look for problems and 
> analyze my system with it.

That's a fair point. But to be honest, you don't really need an RPC
framework running in a separate process to query perfcounters, do you.
A very valid model would be having a tiny perfcounter-server (e.g.
behind a req/rep zeromq socket). It wouldn't be a general RPC
framework, but it could do ctrlport's job for this very limited scope!

> 
> Also, in case ctrlport is removed, we should have a GREP to discuss
> what 
> we want and how we want ctrlport back in some other form.

YE! Want to (co)author that?

Best regards,
Marcus

> 
> Cheers
> Johannes
> 
> Am 24.03.19 um 20:26 schrieb Marcus Müller:
> > Dear GNU Radio community,
> > 
> > we've got an outstanding breakage in our controlport
> > infrastructure.
> > Since fixing it seems to involve architectural changes to what
> > controlport does, and since making these changes would quite
> > possibly
> > break the semantics of using controlport anyway, we're considering
> > removing Controlport from the GNU Radio 3.8 release (this does NOT
> > apply to 3.7).
> > 
> > The negative effect of that would obviously be that we'd lose
> > controlport (which I'm not going to introduce here; if you don't
> > know
> > what it is, you haven't been using it). We would *not* lose the
> > performance counters, just the default way of querying them.
> > 
> > The most important upside would be the ability to remove the Apache
> > thrift dependency. Thrift has been the single worst thing we've
> > relied
> > on for as long as I can remember in terms of availability and
> > consistency across platforms. In fact, different distros build
> > completely different configurations of thrift, and noone seems to
> > be
> > able to build a "fully featured" thrift.
> > 
> > Another aspect to this is that albeit controlport is pretty cool in
> > theory – an adaptable RPC server within GNU Radio, with pluggable
> > RPC
> > backends – its adoption has been slow to say the least, and it
> > doesn't
> > really tie neatly into any GNU Radio applications I'd be aware of.
> > 
> > So, lest someone fixes the bug (I'll be describing it below), I'd
> > recommend we remove Controlport alltogether, and remove the thrift
> > dependency. I still stand by the very idea of controlport – having
> > RPC
> > access to what a flow graph does – but in the end, there's a
> > discussion
> > that we need to have:
> > 
> > How do we want to do RPC in a way that enables us to make GNU Radio
> > far
> > more machine-agnostic than it is? How does one not only allow for
> > gathering of statistics and calling of functions, but build an RPC
> > framework that makes heterogeneous and distributed GNU Radio really
> > feasible?
> > 
> > We've been addressing the question of what the scheduler needs to
> > become at the heterogeneous compute working group at GRCon'18. To
> > conclude, we need to get away from the "one buffer type fits all"
> > and
> > "all blocks are born equal and are just individual OS threads"
> > towards
> > domain-specific subschedulers and buffer managers. This is where
> > this
> > needs to tie in.
> > 
> > Hence: Is anyone seriously using ControlPort and needs it for 3.8?
> > Please raise a metaphorical hand on the mailing list or write a
> > private
> > one in response to this email.
> > 
> > Best regards,
> > Marcus
> > 
> > --
> > 
> > Bug: clang correctly has been complaining for quite a while now
> > that
> > the RPCAggregator stores a reference to a temporary object. It
> > seems
> > that in the past this just worked by chance – probably, libc never
> > really got around to reassign the memory of these temporary objects
> > and
> > all lived happily everafter. However, now on multiple platforms, we
> > just see aborts in various tests due to access to freed memory.
> > Probably memory protection just got smart enough to kick some sense
> > into this code.
> > All is fine as long as one doesn't actually use the code in
> > question.
> > 
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> 
> 

Re: [Discuss-gnuradio] GSoC and Android Idea

[CEL]

Hello Tarek,

https://wiki.gnuradio.org/index.php/GSoC has information on all this.
You're relatively late to the game!

Best regards,
Marcus

On Sun, 2019-03-24 at 18:08 +0200, Tarek Alabd - طارق العبد wrote:
> Hello everyone,
> I'm Tarek from Egypt and I'm studying Computer Engineering.
> I'm android developer using Java, I made some projects related and
> not related to the university.
> I took a lot of courses in java, oop, android development,
> networking, data storage and etc online and offline.
> I want to participate in GSoC : the android idea.
> I want to know more about the project and the proposal. Is there any
> template for the proposal ? and how to communicate with the mentors ?
> Thank you
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Selecting one of two sources

[CEL]

I'd recommend streams-to-vector and a matrix multiplier block.

Best regards,
Marcus

On Fri, 2019-03-22 at 23:34 +0300, mehtap özkan wrote:
> Dear All,
>  I have 2 modulators, A FSK and a BPSK one. Is there a block which can switch 
> the output of the desired modulator to a Sink. Something like a switch that 
> has 2 inputs and one output?
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Emails without subject stand a high chance of being ignored (was: (no subject))

[CEL]

Hello Faisal,

I pointed this out before: We're volunteers here. If you want us to
help you, please at the very least write emails with meaningful subject
lines. I personally consider that non-negotiable email etiquette.

Best regards,
Marcus

On Fri, 2019-03-22 at 15:13 +0400, faisal wrote:
> Hello Everyone
> I'm already built a spectrum sensing block daigram in gnuradio companion 
> using sdr rtl and gnuradio so what i want is only to sense if there is usage 
> of spectrum at sertain time or not then i need an external blocks to read the 
> 0 and 1 thats comes from energy detecore and save it  as 0 or 1 with that 
> time and keep scanning for a period of time and then analays the data and 
> decaide if the channel is used or not.
> The problom is i want you to provide me method that i can save the data and 
> time togather using gnuradio blocks without using coding keeping in maind 
> that the sample rate is very high reach to 20e6 Hz.
> Thank you
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Introduction

[CEL]

Hi Tucker!

Nice hearing from you :)
Have you met Travis? His gr-dpd[1], especially?

Cheers,
Marcus

[1] https://github.com/tfcollins/gr-dpd
On Thu, 2019-03-21 at 12:18 -0500, Tucker Reinhardt wrote:
> Hello all,
> 
> My name is Tucker Reinhardt and I am a Sophomore studying at Rice University. 
> I am pursuing a double major in Electrical Engineering and Computer Science 
> so working on GNU Radio sounds just up my alley and I hope to contribute this 
> year as part of GSoC.
> 
> Here at Rice great emphasis is put on Signal Processing early in our 
> Electrical Engineering course track. Additionally I have also been 
> learning/practicing writing algorithms and programs in Python, Java, and C as 
> part of the CS curriculum. Thus I am particularly interested in working on 
> the implementation of Digital Pre-Distortion in GNU Radio since it utilizes 
> all of these skills.
> 
> Furthermore a group at Rice has been doing research on DPD so there are 
> plenty of resources here for me to learn from.
> 
> Thanks for reading my spiel, and I hope to contribute soon!
> 
> 
> 
> 
> Tucker Reinhardt - Class of '21
> Electrical Engineering and Computer Science
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Distance Measurement by Correlation

[CEL]

I don't intimately know the BladeRF driver, but it seems unlikely that
the USRP is way more computationally intense than the BladeRF. Chances
are the BladeRF driver doesn't /show/ the same errors.

Be a bit careful about saving away the data: your storage must be up to
supporting the constant data rate even in a realistic worst-case
scenario – a storage device with high average rate might still have
high variance in write speed, and that might or might not be manageable
with some limited write buffers.

Best regards,
Marcus

On Sun, 2019-03-17 at 22:26 -0700, Jonathan Preheim wrote:
> Thanks for the advice all. It turns out the BladeRF is not transmitting 
> properly in this case. I probably should have figured that out long ago. An 
> equivalent flowgraph (for some reason my original did not work) performed as 
> expected at lower sample rates with a USRP b205.  
> 
> Follow up: It does not seem like GRC plots can keep up with incoming RX data 
> without having overflows from the USRP. I imagine all I can do about this is 
> save to a file and process (i.e. correlate and display) the data later? It 
> seems odd that that was not a problem with the BladeRF that I was aware of. 
> 
> Thanks,
> Jonathan
> 
> On Wed, Feb 27, 2019 at 4:17 PM Qasim Chaudhari  
> wrote:
> > To clarify a confusion in my last email, by "until the point in signal 
> > processing chain where you decimate the signal down to the symbol rate", I 
> > meant the stage just before quantization; otherwise carrier recovery in 
> > BPSK still needs to work with complex samples at symbol rate.
> > 
> > Cheers,
> > Qasim
> > 
> > 
> > On Thu, Feb 28, 2019 at 11:06 AM Qasim Chaudhari 
> >  wrote:
> > > Some pointer that might help you.
> > > 
> > > - No, the samples are not completely real in BPSK until the point in 
> > > signal processing chain where you decimate the signal down to the symbol 
> > > rate. From what I understand your problem, and given that your purpose is 
> > > to find the correlation peak instead of demodulating the data, you'd be 
> > > dealing with both I and Q samples.
> > > 
> > > - Be very careful with conjugation as they bring in both conjugation and 
> > > reversal in the other domain 
> > > (https://dsp.stackexchange.com/questions/23733/conjugation-in-fourier-transform).
> > >  Furthermore, you're correlating it with a clean copy that is stored in 
> > > your system so there is a usual discrimination between cross-correlation 
> > > and auto-correlation, the latter being the operation in which 
> > > conjugations remove the phase/frequency effects and not the former.
> > > 
> > > - Regarding the Costas loop, I usually do not trust the acquisition 
> > > range/acquisition time numbers from simulation to practice, as 
> > > simulations are done at a certain SNR with only one imperfection present. 
> > > Even if everything expected is simulated, the loop starting points cannot 
> > > be carefully controlled due to the unknown incoming phase! In addition, 
> > > acquisition is a highly non-linear operation which strongly depends on 
> > > both the Rx SNR and the loop SNR as well as the shape of the channel 
> > > frequency response. In this particular ranging application, I would 
> > > rather tune the frequency of one USRP receiving a test signal (e.g., 
> > > simple CW and employing a simple PLL) until I get the lock. Then in the 
> > > next experiment, I would initiate my ranging procedure and track small 
> > > changes from there. Also keep in mind that there is a finite acquisition 
> > > time for the loop to settle which might comprise of your entire sequence 
> > > to be correlated. At least it will certainly eat away some part of it.
> > > 
> > > Finally, Marcus' suggestion of starting with the simplest case and seeing 
> > > where your signal deviates from what you expect is probably the best way 
> > > to move forward.
> > > 
> > > Cheers,
> > > Qasim
> > > 
> > > 
> > > On Wed, Feb 27, 2019 at 6:58 PM Jonathan Preheim 
> > >  wrote:
> > > > Hi all,
> > > > 
> > > > Thanks for the responses. Ultimately, we won't be able to share a clock 
> > > > source directly, and I don't have the right cables right now to link 
> > > > them for troubleshooting. Even when I try to use the RF loopback modes 
> > > > though, I do not see a correlation peak. Firmware-based loopback works 
> > > > as expected. I've been trying to model a frequency offset with the 
> > > > Channel Model block, and compensate with the Costas loop block with a 
> > > > little success. But actually doing it on the radios does not work. 
> > > > 
> > > > The Costas loop handles frequency offsets up to 0.05 in simulations 
> > > > with an otherwise ideal channel. The chip rate is 1.25Mchip/s, so 
> > > > that's an offset of about 63kHz. The BladeRF's clock is 38.4MHz 
> > > > accurate to 1 ppm or 38.4Hz. Multiplied up to our carrier frequency of 
> > > > 910MHz, that's an expected accuracy of under 1kHz, so it's reasonable 
> > > > to expect that the 

Re: [Discuss-gnuradio] Strange "UUUU" pattern

[CEL]

Knowing the code, zooming in shouldn't really increase the
computational load significantly; a higher FFT length would do that!
On Fri, 2019-03-15 at 15:34 +, Chesir, Aaron M. wrote:
> Folks,
>  
> I found the error: The “U” characters indicated an underrun to my USRP 
> transmitter. I reduced the sample rate form 5e6 to 2e6, and the underrun 
> indicators went away.
>  
> My problem in my receiver was that I was zoomed in to much in frequency span 
> in my FFT display to see that I was indeed receiving my signal.
>  
> Aaron
>  
>  
> From: Chesir, Aaron M. 
> Sent: Friday, March 15, 2019 10:21 AM
> To: discuss-gnuradio@gnu.org
> Subject: Strange "" pattern
>  
> Folks,
>  
> I have a simple QPSK modulator feeding its output into the input of my USRP 
> transmitter. I notice two oddities:
> The status window at the bottom produces a sequence of “U” characters until I 
> stop the run, and
> The receiver does not detect any presence of any signal (I have a receive 
> process on another computer feeding the output of the RTL SDR to an FFT, and 
> is attached to this email)
>  
> When I replace the QPSK modulator at my transmitter with a simple cosine 
> generator, the receiver shows the presence of the signal with no problem, and 
> I don’t see those strange “U” characters at the source GRC process.
>  
> Can someone offer suggestions at what I should fix?
>  
> Thanks,
>  
> Aaron
>  
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] grc file -- display problem

[CEL]

Hi Parvathi!

> 1.  why the screen shot is displaying x-axis and y-axis as dB only
i.e.  2.03dB, -8.83dB.

Displaying the frequency (x-axis) in dB is most definitely a bug. Which
version of GNU Radio are you using (`gnuradio-config-info --version`
has the answer)? We've fixed that a while ago.

Displaying the y-axis in dB is a pretty common thing to do for PSD
estimates.

> 2.   How to interpret the magnitude of the output and on what basis

Not quite sure what you're asking here – that plot is a power density
estimate over frequency. The dB are relative to "full scale".

You're making mistakes when configuring the Qt GUI frequency sink –
your center frequency is simply what the center of your x-axis labeling
is shifted to; since you're dealing with baseband only, it needs to be
zero.

> 3. We would basically want to write the peak of the signal into a
file to record continuously and request you to give an example for the
same. 

That sounds like you want a spectral estimator, not a visualization!
So, you wouldn't do that with the Qt GUI frequency sink – which is just
something to look at, not something to generate data.

The operation done by the Qt GUI frequency sink is really just

stream to vector (length=1024) ->
FFT (length=1024) (including windowing) ->
complex to magnitude^2 ->
convert to logarithmic scale

You could do the same, write a small Python block to find the bin with
the maximum value, and write that bin's index to a file. Should be
pretty easy, if you know Python!

Generally, from a scientific point of view, it's questionable whether
this FFT-based route is an appropriate estimator for whatever you want
to do – in the end, you're quantizing your frequency in to FFT-length
number of steps, and you get horrendous leakage effects if a frequency
isn't exactly N·f_sample/L_FFT for some integer N.

But: the frequency estimator suitable for your problem can not be
advised on without knowing which problem you're trying to solve, or
which question to answer in the end.

Best regards,
Marcus

On Fri, 2019-03-15 at 09:48 +0530, Mrs.  Parvathi Piduparthi wrote:
> hello
> 
> We have installed gnu radio and working with ubuntu .  Attached is the grc 
> file and its output which basically gets a signal from source and tries to 
> display the fft  of the same as a spectrum. W.r. to these , kindly clarify 
> the following
> 
> 1.  why the screen shot is displaying x-axis and y-axis as dB only i.e.  
> 2.03dB, -8.83dB. 
> 
> 2.   How to interpret the magnitude of the output and on what basis
> 
> 3. We would basically want to write the peak of the signal into a file to 
> record continuously and request you to give an example for the same. 
> 
> thanks &  regards
> Parvathi 
> Scientist/Engineer 
> National Atmoshperic Research Laboratory , Department of Space
> Gadanki, Tirupathi
> Andhra Pradesh 
> India
> 
> Ph. 91 877 2500583
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Internship

[CEL]

Hi Rajpreet,

though it shares many characteristics of one, GSoC is not an
internship.
I'd recommend reading our GSoC Student info page[1] and the Google
Summer of Code FAQ [2]:

> > Is GSoC considered an internship, a job, or any form of employment?
> No. GSoC is an activity that the student performs as an independent
> developer for which they are paid a stipend.

We're expecting you to go through the list of ideas, pick one that
truly interests you and is within your realm of abilities to achieve
within the timeline, and deliver self-defined milestones that you
formulate in a proposal – in that sense, GSoC is really more like
applying for a project grant than an internship.
If you get accepted with your proposal for GSoC, your mentor will very
gladly guide you on a professional level – but you'll definitely be
more than an intern to a company. We're expecting a pretty high level
of independence from you!

Best regards,
Marcus

[1] https://wiki.gnuradio.org/index.php/GSoCStudentInfo
[2] https://developers.google.com/open-source/gsoc/faq
On Thu, 2019-03-14 at 15:59 -0400, RK G wrote:
> Hi everyone!
> 
> I am Rajpreet Kaur Gulati from Philadelphia. I am 3rd year student at Temple 
> University, Philadelphia.  I am very much interested in GNU radio  project of 
> gsoc. I have the knowledge of GNU radio and USRP boards. I want to work as an 
> intern under your guidance. If you have any project which is suitable for my 
> category please let me know.
> 
> Thank you
> Rajpreet
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Discussion regarding Android project for GSOC

[CEL]

AFAIK only the things linked to in my last replies to you – which
actually are pretty comprehensive, IMHO.
On Thu, 2019-03-14 at 23:21 +0530, Jaspreet Singh wrote:
> Hi, I tried to find if there is project for gnuradio android on github. Can 
> you please guide how are you planning to start it? It will help me write 
> proposal more accurate. Any related links would be very helpful..
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Spectrum sensing using gnuradio + hackrf one

[CEL]

Hi Faisal,

The link that Kyeong Su Shin shared actually *directly* leads to
scripts that can read the output of file sink. 

Best regards,
Marcus
On Wed, 2019-03-13 at 11:25 +0400, faisal wrote:
> Ok when i save it in sink file then the data can not be readable what
> to do for that please?
> 
> في الأربعاء، ١٣ مارس، ٢٠١٩ ٥:٤٠ ص Kyeong Su Shin <
> kss...@postech.ac.kr> كتب:
> > Hello faisal:
> > 
> > You can either just use "File Sink" blocks to dump the raw data
> > into files and convert them to human-readable format using
> > MATLAB/Octave ( 
> > https://github.com/gnuradio/gnuradio/tree/master/gr-utils/octave )
> > later, or write your own blocks (an embedded Python Block should be
> > sufficient if the data rate is low; you can find some tutorials on
> > Google. 
> > https://www.google.com/search?q=gnu+radio+embedded+python+block ). 
> > 
> > Regards,
> > Kyeong Su Shin
> > 
> > 보낸 사람: faisal  대신 Discuss-gnuradio <
> > discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org>
> > 보낸 날짜: 2019년 3월 13일 수요일 오전 12:31
> > 받는 사람: Discuss-gnuradio@gnu.org
> > 제목: [Discuss-gnuradio] Spectrum sensing using gnuradio + hackrf one
> >  
> > hello everyone
> > can anyone help me i want to save data which comes from average
> > block and threshold block.
> > how can we save a date in text file or in an excel file?
> > i attched the grc.file please have a look at it.
> > 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Spectrum sensing using gnuradio + hackrf one

[CEL]

You'd need to write your own block that can handle these formats.

A word of warning: When doing SDR, you deal with MEGASAMPLES per
second.

A 32 bit floating point number has circa 9 significant digits.
That makes 10 characters when you include the decimal dot.
Then you also need to write down the exponent, that's another 4
characters, and the sign (on average, half a character, you could omit
"+"). 
That makes on average 14.5 Bytes to represent a 4 Byte number.

You need one real and one imaginary part per sample, that's on average
29 Bytes.

Add one byte for the "," between these parts, and one byte for the
newline character.

You've just made 1 worth of samples at 1 MS/s take 31 MB on disk, where
it really only contains 4 MB of actual data, and still introduced
rounding errors.

Excell is not better. At least the modern excel format applies zip
afterwards.

And: no one will *ever* scroll through 1 Million samples in Excel.

Whatever the problem is, exporting millions of numbers to CSV or Excel
is not the solution; excel is really a tool primarily for accounting,
not for data analysis.

Best regards,
Marcus

On Tue, 2019-03-12 at 19:31 +0400, faisal wrote:
> hello everyone
> can anyone help me i want to save data which comes from average block
> and threshold block.
> how can we save a date in text file or in an excel file?
> i attched the grc.file please have a look at it.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_modtool for Windows?

[CEL]

Hi Aaron,

must admit, I haven't tried it.
Technically, modtool depends on very little more than Python to do its
thing.
But then again, its thing is using sane compiler environments to build
stuff (you can't use any of the Linux or Mac package managers as
sources, obviously). And while that probably works for most OOT
modules, your road will be very rocky for all the dependencies.

Other than that: XY Problem[1]! It's always best to describe what you
want to do in the bigger picture, so that experts can reply with a
well-informed recommendation based on what you need to do to achieve
your goal, rather than giving localized information to the exact
question you're asking, which in the end only sends you down a detour
or worst case a dead end, and thus only cost you time.

My guess: 
you're asking this to figure out how to easily install GNU Radio modulesand 
their dependencies, the answer really is: get a modern Linux, even in a VM.
You can literally install GNU Radio with a single command line,
and the same goes for libraries you need for some modules.
Best regards,
Marcus

[1] https://xyproblem.info

On Tue, 2019-03-12 at 18:48 +, Chesir, Aaron M. wrote:
> Folks,
>  
> Is there a way to install gr_modtool for Windows (10) ?
>  
> Thanks in advance,
>  
> Aaron
>  
>  
> Aaron Chesir
> The MITRE Corporation
> 200 Valley Road
> Mount Arlington, NJ 07856
> w: (973) 810-0612
> c: (908) 380-5798
> ache...@mitre.org
> “Ignorance is Bliss, but Knowledge is Power”
>  
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installation of gr-radar

[CEL]

Wait, are you doing this on ARM? 
On Mon, 2019-03-11 at 23:15 +0500, Talha Farooq wrote:
> Thanks Cinaed , I tried your method and it turns out that I have 
> 'libqwt6abi1/stable,now 6.1.2-6 armhf [installed]' and similarly I have QT 
> version of 'Using Qt version 5.7.1 in /usr/lib/arm-linux-gnueabihf ' 
> installed. The error in 'make' of gr-radar is still occurring. I don't know 
> the reason. I have shared the error details before but for convenience I am 
> sharing again.
> 
> 
> In file included from /home/pi/gr-radar/build/lib/moc_scatter_plot.cxx:9:0:
> /home/pi/gr-radar/build/lib/../../lib/scatter_plot.h:24:22: fatal error: 
> qwt_plot.h: No such file or directory
>  #include 
>   ^
> compilation terminated.
> lib/CMakeFiles/gnuradio-radar.dir/build.make:77: recipe for target 
> 'lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o' failed
> make[2]: *** [lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o] Error 
> 1
> CMakeFiles/Makefile2:137: recipe for target 
> 'lib/CMakeFiles/gnuradio-radar.dir/all' failed
> make[1]: *** [lib/CMakeFiles/gnuradio-radar.dir/all] Error 2
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> Regards
> Talha Farooq Hashmi
> 
> On Mon, Mar 11, 2019 at 2:21 AM Cinaed Simson  wrote:
> > Assuming you're running some fork of Debian, type
> > 
> >   apt list | grep libqwt6
> > 
> > to see if it's available.
> > 
> > If it's available but not installed type
> > 
> >   apt-get install libqwt6
> > 
> > -- Cinaed
> > 
> > 
> > 
> > On 3/10/19 12:53 PM, Talha Farooq wrote:
> > > Hi
> > > I am installing GNU gr-radar in Ubuntu. I installed all dependencies and
> > > now while in step of making build of gr-radar by command 'make' I am
> > > getting below mentioned error Though I upgraded QT to latest version
> > > which is "Using Qt version 5.7.1 in /usr/lib/arm-linux-gnueabih". I read
> > > in Issue#16 that you should use QT6 but I am unable to find any stable
> > > version of QT6 or how to install that.
> > > Error:
> > >  [  1%] Building CXX object
> > > lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o
> > > In file included from 
> > > /home/pi/gr-radar/build/lib/moc_scatter_plot.cxx:9:0:
> > > /home/pi/gr-radar/build/lib/../../lib/scatter_plot.h:24:22: fatal error:
> > > qwt_plot.h: No such file or directory
> > >  #include 
> > >   ^
> > > compilation terminated.
> > > lib/CMakeFiles/gnuradio-radar.dir/build.make:77: recipe for target
> > > 'lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o' failed
> > > make[2]: *** [lib/CMakeFiles/gnuradio-radar.dir/moc_scatter_plot.cxx.o]
> > > Error 1
> > > CMakeFiles/Makefile2:137: recipe for target
> > > 'lib/CMakeFiles/gnuradio-radar.dir/all' failed
> > > make[1]: *** [lib/CMakeFiles/gnuradio-radar.dir/all] Error 2
> > > Makefile:138: recipe for target 'all' failed
> > > make: *** [all] Error 2
> > > image.png
> > > Regards:
> > > Talha Farooq Hashmi
> > > 
> > > 
> > > ___
> > > 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


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio