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] query regarding store transmitted signal

[Maitry Raval]

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

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

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

[Jonas Manthey]

Hi Maitry,

If you just want to store and load after with GNURadio you can use file sink 
and file source directly as Markus said. Just set the output and input type 
correctly. The data format is "stupid" binary so the samples are written as is 
on the disk, so it also does not matter what happened before signal processing 
wise. 

If you want other formats I'd suggest to write a converter in python, you can 
easily convert to csv or Matlab readable files like that.

P.S.: .DAT as a file ending does not really say what format it is. Actually, 
you can name your file in GNURadio whatever you want.

Cheers,
Jonas

-Original Message-
From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+jonas.manthey=u-blox@gnu.org] On Behalf Of 
Maitry Raval
Sent: Freitag, 17. Mai 2019 13:37
To: Marcus Müller, CEL 
Cc: discuss-gnuradio 
Subject: Re: [Discuss-gnuradio] query regarding store transmitted signal

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

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

Re: [Discuss-gnuradio] 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] 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

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

[tom sutherland]

Is there a way to take the output from ablock and make it appear as though that 
signal is a variable? e.g. take theoutput from a “signal source” block and sink 
it into a block that creates a“variable” named ‘myfreqvar”. Then use 
“myfreqvar” as a parameter in otherblocks.

Tom

___
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

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

[Sebastian Sahlin]

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

Re: [Discuss-gnuradio] Problems writing an OOT block

[Michael Dickens]

Hi mehtap - You can certainly do what you're asking for, but I'd wonder if 
there isn't a better algorithm to do whatever it is you require. Here are my 
thoughts based on personal experience implementing something like what you're 
trying to do (and, thus, why I ask whether there might be a better algorithm).

I'd say to inherit from "gr::block" and then yes you'll need to implement 
"forecast" to get things going. If you implement using the "naive" approach 
(literally just what you wrote), what you'll find is that you'll end up with 
virtually all "1"s (for when no input), and very little "inverse of the input". 
Throttling will be required either within your block or external and 
immediately downstream, to keep the "1"s from totally saturation the rest of 
the flowgraph.

The more clever approach is to add a settable parameter for how many "1"s to 
produce during any specific all to "work" when there is no input; this value 
will of course maximally be whatever actual output buffer space allows. This 
parameter is for how often to look at the inputs to see if there's anything 
there: the smaller the number, the more often checked and the more CPU time 
spent looping through this cycle (and, related, the lower the possible data 
throughput through the block); the higher the number the less often checked & 
the less CPU time spent looping (and, related, the higher the possible data 
throughput through the block). This parameter should generally be about 1/10 of 
the nominal sample rate of the data expected downstream, excepting of course 
when 1/10 is way above the output buffer size -- in which case increase the 
output buffer size && decrease this value of this parameter as a "happy medium".

If you insist on going this route, give the above a try & then if you need more 
assistance provide us with a public repo we can view to see and test your 
actual code.

Hope this is useful! - MLD

On Fri, May 17, 2019, at 12:20 AM, mehtap özkan wrote:
> Dear All,
>  I want to write ablock where:
> The output is the the Inverse of the input,
> The output is "1" if there is no input.(It acts like a source)
> 
> I am confused how to implement the part where the Block behaves like a Source.
> In one mode you need an Input to produce an output (ninput_items_required=1)
> and in one mode you need no Input to produce an output 
> (ninput_items_required=0) .
> I have looked at the `forecast()` function where the "relationship between 
> noutput_items and the requirements for each input stream" is defined.
> Also I could not figure out how the next block requests samples from the 
> curent block.
> Can anybody help?
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr_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

[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]

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]

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

[Discuss-gnuradio] Fwd: Fwd: UC Berkeley seeks postdoctoral researchers

[Philip Balister]

Open source related position at berkeley.

Philip


 Forwarded Message 
Subject: Fwd: UC Berkeley seeks postdoctoral researchers
Date: Fri, 17 May 2019 10:45:18 -0400
From: Mike Balister 
To: Philip Balister 



> Begin forwarded message:
> 
> From: Jeff Mangum 
> Subject: UC Berkeley seeks postdoctoral researchers
> Date: May 17, 2019 at 9:20:50 AM EDT
> To: ursi-usn...@googlegroups.com
> 
> USNC-URSI Commission J,
> 
> See below for two postdoctoral opportunities offered by Dan Werthimer at UC 
> Berkeley.
> 
> -- Jeff
> 
> 
> we are hoping you can help us post a couple of job openings at berkeley's 
> radio astronomy lab,  
> for researchers to develop infrastructure and digital instrumentation for the 
> radio astronomy community.  
> 
> for more information and application/enquiry, please see
> 
> https://aprecruit.berkeley.edu/JPF02137 
> (phd not required) 
> https://aprecruit.berkeley.edu/JPF02148 
> (phd or equivalent required) 
> 
> 
> thanks for your help. 
> 
>  best wishes,
> 
> dan (and dave, jack and aaron) 
> 
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "URSI-USNC-J" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to ursi-usnc-j+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to ursi-usn...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/ursi-usnc-j/d8ebfce9-4fc3-2f38-415e-c0177ce68048%40nrao.edu
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .



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

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

[Toby Flynn]

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

Re: [Discuss-gnuradio] Two instances of the same custom block walk into a bar

[Brad Hein]

Thank you Ben, and others for capturing the true essence of what makes
gnuradio and its community so great. Although it spans a great range of
disciplines and requires tremendous work (for some) to use and extend, the
community is normally quite friendly and willing to help. Of course each
individual should spend time doing the legwork to solve their own issues,
not over-relying on the community. The project has on occasion been
referred to as "Grad-ware" because so commonly it is used by students in
grad-school, and requires an equivalent level of sophistication to use and
extend. I know my journey with Gnuradio started 10-15 years ago and it has
taken me as many years to finally get to the point where I can build some
of the logic that I had been contemplating for so many years. Some of my
greater ambitions will take another 5-10 years yet.

By the way the C++ suggestions that were so kindly provided were quite
useful in helping me get on the right foot, and with a bit of refactoring
my block is up and running - and  is thread-safe now. I studied C++ in
college many years ago, and haven't had to use it since then, except for my
hobby projects in Gnuradio, so I am immensely appreciative of those who
have the patience to not only read the mailing list inquiries, but to also
offer their insights, without which some of us would never be able to use
and extend Gnuradio for useful purposes.

The more people that use the platform, the more the platform grows both in
community and in extensions and add-ons (custom blocks).










On Thu, May 9, 2019 at 5:04 PM Ben Hilburn  wrote:

> The topic of "what kinds of questions go on gnuradio-discuss" has come up
> a couple of times over the last few weeks, and we've had a lot of fresh
> subscriptions over the same period (I get all the subscribe / unsub
> notices), so I'll take this opportunity to quickly answer the question.
> What Marcus and Albin have said are both correct, but I want to clarify
> things for anyone new =)
>
> It is our intention that users feel welcome and free to post any question
> related to GNU Radio usage to this list. SDR is a tremendously complex
> technology, and involves everything from electronics manufacturing to web
> development. There is no such thing as a person that is an expert in all of
> these things, and we can't and don't expect users to necessarily have the
> expertise to know exactly where a problem lies.
>
> At the same time, we do expect people asking for help to be willing to
> spend the necessary time to debug their issue, and respect guidance given
> on-list when referrals are made to non-GNU Radio tutorials (e.g., a
> programming language or communications theory).
>
> It really is quite common for, say, a signal processing engineer who is an
> expert algorithm developer to try to build something in GNU Radio, only to
> discover that they need to use Linux and they have no idea what that means.
> They might very well ask a basic question on this list, as from their
> perspective, they just want to use GNU Radio. That's fine. It's also fine
> for someone to respond to them and point them to a Linux tutorial (kindly).
> And if someone feels especially generous and wants to tutor them through
> the process, that's great! It's better done off-list, though.
>
> When referring someone to non-GNU Radio material, please do it in a way
> that is actually useful. If someone is trying to figure out how to build
> something from source, saying, "Here's a book on computer science." is not
> terribly useful. Sending them to a tutorial on compiling software in Linux
> would be, though.
>
> I keep meaning to add this to the wiki and just haven't gotten to it. We
> actually had a page on the old Redmine site about the sorts of advice you
> can get on-list, etc., but it got lost in the move. That said, even the old
> page wasn't as complete as it ought to be. We answer enough of these
> questions that it's probably worthwhile having a list of useful tutorials
> for various topics that we can recommend.
>
> As always, everyone on this list should be treated with respect and
> kindness. If you get frustrated by a question or discussion, simply don't
> respond, and if you think something steps over the line, please refer it to
> me or Martin.
>
> Cheers,
> Ben
>
> On Thu, May 9, 2019 at 4:33 PM Marcus D. Leech 
> wrote:
>
>> On 05/09/2019 04:18 PM, Albin Stigö wrote:
>>
>> I absolutely agree with you. There are also other completely unrelated
>> issues that keep coming up like Linux, python and x11. But I don't think
>> there's any great harm in ending a topic by ever-so-gently pointing people
>> in the right direction.
>>
>> Oh, indeed, and I don't want to discourage people from "diving right in",
>> but that needs to be balanced with keeping the "support envelope"
>>   for this forum manageable.
>>
>> It is the case that being really successful with a framework like Gnu
>> Radio requires non-trivial facility in a number of different dis

Re: [Discuss-gnuradio] Could This Be A Speed Problem? How Can I Make It Faster

[P C]

Kyeong Su Shin,

Wow, I think your "answer" gives a far more elegant solution to my problem.
I didn't know anything about Python Blocks.  I have been trudging 
through the "GNU Radio Manual and C++ API Reference" but haven't gotten 
close to that section yet.  I have done some searching but the hits that 
are returned are just a source of confusion because of incorrect or 
obsolete information or just lack of experience on my part.

Your search string displays better information then I have ever found.

As for the Throttle block, I don't think I need it.  I just stuck it in 
there to get rid of the warning.  My input File Source stream is created 
by the command line:

rtl_sdr -f 34500 -s 100 /tmp/stream

I believe that if rtl_sdr command is creating samples at 1M/s and I 
decimate by 4 then convert to UChar I should be creating 250k bytes/sec 
to the File Sink.  If I understand things correctly that is.


Thanks,
Pete

On 5/17/2019 1:33 AM, Kyeong Su Shin wrote:


Hello Pete,


This is not really an asnwer to your question lists, but  if you want 
to continuosly process data generated by GNU Radio using Python, you 
can simply write a GNU Radio Python block (using a 'Python Block' on 
GNU Radio Companion, or by creating a custom module). In that way, you 
do not need to use a File Sink, TCP, ZMQ, or whatever that is needed 
to transfer the data from GNU Radio to your own Python code. There are 
a few examples on the Internet ( 
https://www.google.com/search?client=firefox-b-d&q=embedded+python+block+gnuradio 
).



Also, if the rate of the flow graph is limited by the incoming file 
stream (i am not 100% certain, but I think that could be the case), I 
recommend try dropping the Throttle block in your flow graph. It is 
only used when the rate of the program is not limitted by any other 
blocks.



In my experience, Python IS a bit slow for real-time data processing 
applications, IF the processing is not handled by external libraries. 
Writing programs in C/C++ does help if you cannot get the jobs done 
using existing libraries.



Regards,

Kyeong Su Shin



*보낸 사람:* P C  대신 Discuss-gnuradio 


*보낸 날짜:* 2019년 5월 17일 금요일 오전 4:13:43
*받는 사람:* GNURadio Discussion List
*제목:* [Discuss-gnuradio] Could This Be A Speed Problem? How Can I Make 
It Faster

I have what I think is a problem with processing speed.
I want to run the attached flow graph on my Raspberry Pi 3B.
It captures a serial bit stream.

The lower File Sink is a FIFO type file that is read and processed in
real time (I hope) by the Python script decoder.py (attached). Actually
decoder.py is a dummed down script I am using to isolate the problem.
The script I hope to use is ~100 lines long.

The upper File Sink just writes a file that is processed off line by a
different script.

Note that in decoder.py there is a variable delay.  If I make delay
small, like 0 or 1, I believe the flow graph runs successfully.  But if
I make delay larger things start to fall apart.  By that I mean bits are
dropped.  Also the Time Sink falls behind. I test that by manually
changing the bit stream.  What I see is, if delay is small, the Time
Sink displays the changed bit stream immediately.   If delay is 2 or 3
the change to the bit stream is delayed 5 or 6 seconds.

Also, in the larger  delay case, the file Capture.sec is also missing
bits.  It seems that if decoder isn't taking bytes out of the FIFO fast
enough, the "backup" reflects back to the output of the Multiply
Constant.   I separated the paths to the File Sinks hoping that I could
avoid this effect but no luck.

So, I guess my questions are:
(1) Is my analysis correct?
(2) Is it reasonable that just one or two times through that "while"
loop could be such a problem?
(3) Would it be useful to rewrite the processing script as a C program?
Keeping in mind that the program I really want to use is 10 or 20 times
longer.
(4) Am I doing things in a way that slows things down and could be fixed
by some manipulation?
(5) Shouldn't a FIFO be able to "absorb" the data flow?
(6) Would using something like ZMQ get around this problem?

Thanks,

Pete





___
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

[Discuss-gnuradio] multiplexing multiple file sources without losing synchronization to file start

[Lundberg, Daniel]

I am trying to multiplex a number of signal sources where alignment to the 
start of each signal source is important.  These need to be a mix of static 
file sources with real-time diagnostic data interleaved, i.e., what I want to 
achieve is:
Signal 1,
Short chunk of diagnostic information
Signal 2
Short chunk of diagnostic information
Signal 3
Short chunk of diagnostic information
...(repeat)...

If I connect 3 repeating file sources, interleaved with the diagnostic data 
source to a stream mux block with 6 inputs and correctly set the lengths of 
those files/diagnostic data in the stream mux lengths field, they do cycle in 
the correct order, but the random dead time at the start of the flowgraph is 
consumed by the first input on the mux block, resulting in a permanent offset.  
So I end up with:

Garbage + Most of Signal 1
Short chunk of diagnostic information
Rest of Signal 1 + Most of Signal 2
Short chunk of diagnostic information
Rest of Signal 2 + Most of Signal 3
Short chunk of diagnostic information
Rest of Signal 3 + Most of Signal 1
Short chunk of diagnostic information
Rest of Signal 1 + Most of Signal 2
Short chunk of diagnostic information
Rest of Signal 2 + Most of Signal 3
Short chunk of diagnostic information
Rest of Signal 3 + Most of Signal 1
...(repeat)

I have a couple of ideas on how to approach this problem, but I could use 
feedback on how hare-brained they are.

1)   This seems like the sort of thing that might be possible to address 
via stream tags, but I haven't really wrapped my head around those completely.  
What I really want is something like using the tagged stream mux block in a way 
that doesn't start the first mux counter until a tag associated with the start 
of the first file shows up, i.e., I want it to ignore the garbage data present 
at the start of the flow graph.  This would also let the system periodically 
recover if it drops some samples and needs to resynch.

2)  A brute force switch that just lets the garbage data pass through the 
system for some period of time (1-2 seconds), then switches to the start of the 
first file source and continues on its merry way.

Thoughts?
Thank you,

Dan

___
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

[Toby Flynn]

Marcus,
Thank you for the quick reply.  I cannot get to the computer with the
full Yocto command until maybe Monday, I will send a response with that
command when I can get to the computer.
 I believe the issue is with CMake and not Python.   CMake makes the file
'build/gnuradio-runtime/swig/CMakeFiles/Export/lib/cmake/gnuradio/runtime_swigTargets-release.cmake',
as part of the GNURadio build.  What is missing on the cross-compile is the
string ${_IMPORT_PREFIX} on 2 lines in the file giving the path to
_runtime_swig.so, I had missed one in my earlier email .  Adding that
string to the file in the OOT sysroot allows the OOT targets to build,
which can be a workaround until the issue can be better understood and
corrected.  This is the only .cmake file built with the command CMAKE
install(EXPORT in the CMakeLists.txt file, so the build for the .cmake
file is different than the rest of the files in GNU Radio.

 As far as the OOT modules, I have tried gr-paint38 and my gr3.8 branch of
gr-iio, https://github.com/flynn378/gr-iio.  Both have the same error.

I am aware of the issue with GRC / python and I am currently fixing that
manually until I get the time to investigate a correct solution.

Thanks
Toby


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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio