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

[Piotr Krysik]

W dniu 25.03.2015 o 16:48, Tom Rondeau pisze:
> On Wed, Mar 25, 2015 at 3:11 AM, Piotr Krysik  > wrote:
>
> W dniu 16.02.2015 o 17:29, Tom Rondeau pisze:
> > On Sat, Feb 14, 2015 at 3:34 PM, Piotr Krysik  
> > >> wrote:
> >
> > W dniu 29.04.2014 o 16:20, Tom Rondeau pisze:
> > > On Tue, Apr 29, 2014 at 9:33 AM, Perper   >
> > > 
>  > >
> > > Hi all,
> > >
> > > I want to use message passing blocks for operations
> where strict
> > > synchronization is not necessary. However in flowgraphs
> > using message
> > > passing with "Run to completion" option turned on the
> > program doesn't
> > > exit on last processed sample. Is this a bug?
> > >
> > > I want to use message passing in my programs (mainly in
> > > https://github.com/Jakotako/gr-gsm) but completion after
> > processing of
> > > all input data is also very important for me.
> > >
> > > --
> > > Piotr Krysik
> > >
> > >
> > >
> > > Yes, this is a known issue and we are working on it.
> > >
> > > Tom
> > >
> > Hi Tom,
> >
> > In GNU Radio 3.7.6 this is still an issue. It's quite
> serious because
> > whole class of applications that would use message passing
> and rely on
> > the processing in the flowgraph to end after processing of chunk
> > of the
> > signal (i.e. to change the flowgraph in known conditions) is not
> > possible.
> >
> > I'm working on a simple gsm network monitor application based on
> > gr-gsm
> > (https://github.com/ptrkrysik/gr-gsm) and have quite hard
> time because
> > of this issue.
> >
> > Is this some general problem where the source of it is that
> GNU Radio
> > was meant primarily to process stream of samples? Or is it some
> > simpler
> > matter?
> >
> > I've attached vary simple flowgraph that demonstrates the
> problem.
> >
> > Best Regards,
> > Piotr Krysik
> >
> >
> > The fix for this was pushed a couple of weeks ago and will make
> it in
> > the 3.7.7 release. We're looking to see any side effects and
> might be
> > able to back-port it for the next 3.7.6 maint release. Commit here:
> >
> >
> 
> https://github.com/gnuradio/gnuradio/commit/035b9d016dffefec890323bd0b24dbaf23aa9186
> >
> > Tom
> >
>
> I've tied gnuradio compiled with and without this commit. I didn't
> observe difference - run to completion doesn't seem to work with
> message
> passing. I've attached the gnuradio-companion flowgraph that I've used
> for the test.
>
> Question to the list: does "Run to completion" feature work for you in
> the attached example or in any other case of a flowgraph with message
> passing?
>
> --
> Piotr
>
>
> Ah, well there's the problem. In GRC open up "Help"->"Types". The
> blocks you are using are the old Message Queue based blocks, not the
> new asynchronous message passing interface. The commit that I was
> talking about was specific to the async message passing, so yeah, it'd
> have no bearing on this.
>
> This is definitely confusing since they are both "message" based even
> though it's a completely different system. The old style used here
> will likely be removed at some point, though it's use persists in a
> few places. For your stuff, I'd avoid using this (anything with that
> dark grey port) and use the new async messages (the light grey ports).
>
> Tom
>  
Tom,

The attached flowgraph was an example. I wanted to prepare something
small that uses only GNU Radio's message blocks, to avoid situation
where I messed something in C++. The blocks that I selected were not
appropriate for the situation.

However in
https://github.com/ptrkrysik/gr-gsm/blob/master/apps/airprobe_file.grc
I'm using only message passing interface, but can't get "Run to
completion" to work as it should.

Can you show an example of GRC flowgraph that uses message passing and
exit when the input signal is over? I would greatly appreciate that as
I'm a little bit stuck on this problem.

--
Piotr

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

Re: [Discuss-gnuradio] Definition of "radians per sample"

[Daniele Nicolodi]

Hello Mohamed,

I didn't consider the difference between baseband and passband bw, but
isn't the difference by a factor two going in the wrong direction here?

If I assume that the PLL blocks want the bw defined as passband, when I
get the signal out of the PLL blocks at baseband, I should see a bw that
is half of the one I specified at passband, not twice it.

If I assume that the PLL blocks want the bw defined as baseband, I
should see no difference in bw.

I'm still puzzled.

Cheers,
Daniele


On 25/03/15 15:25, Mohamed ABOUZRAR wrote:
> Hi Daniele,
> 
> I'm quite sure that there is a miss understanding of  the bandwidth
> notion here,
> Your first formula is certainly the right known one, so make sure you
> use the baseband bandwidth, which is equal to half passband bw.
> hope that helps.
> 
> Regards,
> Mohamed
> 
> 
> 
> On Wed, Mar 25, 2015 at 2:09 PM, Daniele Nicolodi  > wrote:
> 
> Hello,
> 
> the documentation for the PLL blocks in GNURadio says: "All settings
> max_freq and min_freq are in terms of radians per sample, NOT HERTZ."
> 
> Therefore I thought that to specify a bandwidth `bw` it would have to
> converted from natural frequency units (Hz) into radians per sample with
> something like:
> 
> bw_rad_per_sample = bw * 2*pi / sampl_rate
> 
> where `sampl_rate` is of course the sampling rate in Hz.
> 
> However, looking at the PSD of the input and outputs to the PLL blocks,
> it looks like my understanding is wrong and that the bandwidth should be
> computed as
> 
> bw_rad_per_sample = bw * pi / sampl_rate
> 
> which differs from the former by a factor of 2.
> 
> Is the documentation right, and my understanding of it wrong, or the
> documentation is wrong?  In the former case, I think it would be better
> to clarify it a bit.
> 
> Thanks! Cheers,
> Daniele
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> -- 
> /*MSc, Supélec,*/
> /*Ingénieur d'Etat, INPT.*/


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

Re: [Discuss-gnuradio] Switching flow between two paths.

[Kevin Reid]

On Mar 25, 2015, at 2:15, Marcus Müller  wrote:

> source -+--> custom_block0 ---> encoder0 ---> add -->
> +--> custom_block1 ---> encoder1 --^
> 
> you'd need to implement custom_block in python or C++, that would either
> pass through items, just like the block does that comes out of
> gr_modtool add -l python -t sync
> or set the output items to 0. You'd toggle that behavior exactly at the
> sample that you get a tag.

Note that if you don't actually need the switch to happen at a specific point 
in the stream, but you still want the switch to be atomic (guaranteed not to 
drop or repeat any items), the existing multiply_matrix block can do the 
switching in this flowgraph: it would be configured with one input and two 
outputs, and setting the matrix to either [[0, 1]] or [[1, 0]].

(Of course, the disadvantage of either of these strategies is that you're 
paying the CPU cost of both encoders all of the time.)

-- 
Kevin Reid  


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

Re: [Discuss-gnuradio] pybombs, gnuradio, libprotobuf issues PLEASE HELP ME

[ben Gee]

thanks rich. I think at this point its some ghost-in-the-machine file or
config that's outside the pybombs directory. That makes little sense
because pybombs should be self-contained, therefore when i delete the
pybombs and target directories it should not have any difference. That
being said, it's just not working.

i'm going to re-install ubuntu and follow the directions that Iluta sent
 me. Her instructions seem to also have details on fixing the fosphor
issues i was having which was what started this whole mess in the first
place.

thanks,
-b

On Wed, Mar 25, 2015 at 4:38 PM, Richard Bell 
wrote:

> I think you might be referring to the config.dat file that was created
> after your first attempt at installing with pybombs? When you first clone
> pybombs, there is no config.dat, only a config.default. When you go through
> the install process, pybombs creates a config.dat that saves the choices
> you made. Now if you try and re-install with the same pybombs as before,
> all of your previous answers will be used during the setup.
>
> Delete the config.dat file in the pybombs directory if you want to start
> from scratch.
>
> Rich
>
> On Wed, Mar 25, 2015 at 1:31 PM, ben Gee  wrote:
>
>> richard,
>> yes, i setup the environment variables. i noticed something strange
>> though, in my initial (working) install, when i pulled the pybombs source
>> using:
>> git clone git://github.com/pybombs/pybombs and cd into pybombs
>> in my initial configuration i was able to set my prefix dir to
>> /home/profile_name/pybombs , but now it forces me to use the prefix
>> /home/profile_name/target or it says it can't install gnuradio in that
>> location unless i fix my permissions. I'm not sure what's wrong with my
>> permissions though, if anything.
>>
>> On Wed, Mar 25, 2015 at 3:01 PM, Richard Bell 
>> wrote:
>>
>>> Did you run ./pybombs env and setup your environment variables?
>>>
>>> Rich
>>>
>>> On Wed, Mar 25, 2015 at 11:52 AM, ben Gee  wrote:
>>>
 ok, so editing the .cc file worked now and i got it to stop throwing
 the compile error, but its still not working.

 gnuradio-companion still isn't installed correctly as i can't call it
 from the command line. when i run swig -version i get:

 http://pastebin.com/xWU4d5i3

 i have a second computer with a completely working gnuradio pybombs
 system that i originally installed alongside this one (which was working,
 until i reinstalled gnruadio and pybombs) so this is super frustrating that
 i can't duplicate it on a literally identical machine from the wiki
 instructions. i hate to perform brain surgery with a bazooka here, but i'm
 considering reinstalling ubuntu and starting over completely at this point.

 any thoughts?



 On Wed, Mar 25, 2015 at 2:20 PM, ben Gee  wrote:

> thanks ron, my swig version is now updated.
> so, if i run ./pybombs install gnuradio and it reports the error with
> atsc_interleaver_impl.cc, i then go in and add "#include ",
> but now when i rerun ./pybombs install gnuradio, it still throws an error
> about the stdio commands not being included. is there a way to 'make 
> clean'
> manually or something in pybombs?
>
>
> On Tue, Mar 24, 2015 at 7:30 PM, Ron Economos 
> wrote:
>
>>  I've submitted a pull request for the compile issue in gr-dtv.
>> However, it takes a little while for requests to get merged.
>>
>> You're missing gnuradio-companion because your version of
>> SWIG is failing the version check. See line 982 in your first
>> pastebin. The minimum SWIG version required is 1.3.31.
>> You can see what version of SWIG you have with:
>>
>> swig -version
>>
>> Ron
>>
>> On 03/24/2015 04:03 PM, ben Gee wrote:
>>
>> > NEW ISSUE - no GRC??. I can't call it from the target, home or
>> pybombs
>> > directory and there's no recipe for it. any thoughts?
>>
>> GRC comes with gnuradio itself.
>>
>> *that's what i thought as it's always been that way.*
>>
>> If it's not there, something failed during the cmake/build step, but
>> without the full logs, can't really say anything.
>>
>> *yes, i agree about the build log. It would be a huge help if someone
>> on the forum board could help me out,*
>> *as i have looked through most of the files in the installation and
>> can't find a build log*
>>
>>  *i piped my terminal output of ./pybombs install gnuradio -v to
>> this file:*
>>
>> http://pastebin.com/1fPwEDbQ
>>
>>  *the same compile error showed up on the terminal for *
>> gnuradio/gr-dtv/lib/atsc/atsc_interleaver_impl.cc* cause no one's
>> fixed the repo yet. I fixed that and re-ran ./pybombs install gnuradio
>> which gave this output:*
>>
>>  http://pastebin.com/gJuqvU1Q
>>
>>  *same issues as before. uhd is installed no problem, grc doesn't
>>

[Discuss-gnuradio] OFDM TX/RX with large packet_len size

[Mohd Fadzli]

Hi,

I've problem to use a large packet_len size (ie; 1500 bytes) in OFDM
Flowgraph as in the digital folder examples. I got this error:

sched:  is requesting more input data
  than we can provide.
  ninput_items_required = 34
  max_possible_items_available = 31
  If this is a filter, consider reducing the number of taps.


My setup is:

FFT=256
Packet_len=1512
header_mod=QPSK
payload_mod=QAM16
min output buffer in cyclic prefix=10

Btw, if i'm using FFT=64, it does works fine when I increase the kernel
shmax value. I attached the GRC that i'm using. Please kindly advice for
this problem. My objective is to make this OFDM flowgraph to works with
UDP/TCP packets. Or maybe there is another workaround to implement this?

Another question, is this OFDM TX/RX example is working good for QAM16?
I've try this with my b200, it seems I got lots of packet lost when I'm
trying to transmit a file or some random source.

Thanks


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

[Discuss-gnuradio] GNU Radio Cross Reference Tool

[Richard Bell]

Hi everyone,

This is a very nice online tool that was recently introduced to me. I think
it's valuable enough that it should be shared to everyone.

http://code.metager.de/source/xref/gnu/gnuradio/

It lets you search all gnuradio directories (of the metager hosted online
server setup) for keywords, and will then show you any files that contain
the keyword in their name OR contain the keyword in their contents. It will
also show you a snippet of the file contents around the keyword you
searched for.

If you've ever need to search for source, this is the tool for you.

I don't know how often that servers gnuradio install is updated, or any
details on their situation at all.

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

Re: [Discuss-gnuradio] GNU Radio Cross Reference Tool

[Martin Braun]

Thanks, Richard, I didn't know this tool existed.

That said, there are excellent tools for searching the source tree 
available through the command line. My favourite is 'ack' (which is 
packaged by all big distros, and has a plugin for at least vim), but 
'git grep' is also very useful and sometimes works better than ack when 
you just want to search indexed items.


Also, many editors have a feature that allows you to open files by fuzzy 
file name search (For Vim, Ctrl-P does this, although I know this was 
copied from some other editor).


During coding, there are several tools you can use to auto-complete 
modules. Again, this depends on your editor, but out-of-the box, I think 
Eclipse comes with most of these.


Cheers,
M


On 26.03.2015 09:55, Richard Bell wrote:

Hi everyone,

This is a very nice online tool that was recently introduced to me. I
think it's valuable enough that it should be shared to everyone.

http://code.metager.de/source/xref/gnu/gnuradio/

It lets you search all gnuradio directories (of the metager hosted
online server setup) for keywords, and will then show you any files that
contain the keyword in their name OR contain the keyword in their
contents. It will also show you a snippet of the file contents around
the keyword you searched for.

If you've ever need to search for source, this is the tool for you.

I don't know how often that servers gnuradio install is updated, or any
details on their situation at all.

v/r,
Rich


___
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] ESA Summer of Code in Space proposal

[Johannes Demel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello GNU Radio'ers,

You're probably all well aware that SOCIS is coming up. Although
application deadline is April 30 [1], I want to publish my SOCIS
proposal today. You can find it on github [2]. I hope it is
well-received by the community and I can get valuable feddback. I hope
I can use this feedback to improve my proposal and thus make it
successful.

happy hacking
Johannes




[1] http://sophia.estec.esa.int/socis/?q=timeline
[2] https://github.com/jdemel/socis-proposal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVFF6jAAoJEO7fmkDsqywMsskQAJyJSMbVLc9KnKSM292O7BkX
gX1bLMM40vTl/LgtUjas5QMizZsRGm6dDkuOjiv+uIIQ/jIVL11x6qK+1gySAkOZ
DXqjCEyAEkCfpIeLoabqCbAw5nIkqLXsGKIDcOmJfjMxrfDNflhYq8c5ulOdwTef
Ug/0usA4OnraV6iFVWAfNtRaM9TU/eqVcMgqE1EuHO8QUf2Khxp99tlBaR1Z5Z6j
Jc2mgosXdSn6Pm1IBrQhGDtinvoFm8lRBlDP4qAQ9jXxDs4Eh6v/sVpNULGji6BG
0e5YLNPNMiW6cxR9/04+7VFcHw7/D6oNs2OJjZ5JXakUmYqr6lBB1Ob+uXzODB0R
KeSo/+Y9LkT3p+b0+9lCCkc+D5wuxy3n91v3c+1qgtXkd39R30Iu6h2E5vRbok3H
y1xJpWvEb3bV5QUTP1A9k4024e3b/gvEg7L/Bjv0BbKrh1YF66L+XEXRwpbXv6ga
2+03aE7vz+2ud/4z43cwhgxPQ86fx88D52WJxVLQsE/QMABbUsDDZzqGU5qWAYP5
pS3H8ewr6Y+sPia3h78gMsr3q4uPy2hBbN48mTYx/5gYAn436oYVJUJqmWW9wSbG
ObFT1yaOZ1VZV6B6bEQAumA0BmDHRRkITFLxABf3o1U4350gwR/gCw0dB/HZqR1i
DUTCYGTIjmlX1eR1bync
=Q9Tv
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Switching flow between two paths.

[Jeon]

After thinking about it for a couple of days, I've decided not to use two
separated RLL blocks.
Instead, I made a block as below:

In work() function:

get_tags_in_range(tags, 0, nitems_read(0),
nitems_read(0) + ninput_items[0],
pmt::mp("rll_coding"));
RLL_CODE rll_code = (RLL_CODE)pmt::to_long(tags[0].value);

// ... omitted trivial things

switch (rll_code) {
case RLLMANCHESTER:
for(int i = 0; i < ninput_items[0]; i++) {
out[2 * i] = !!in[i];
out[2 * i + 1] =  !in[i];
}
break;
case RLL4B6B:
for(int i = 0; i < ninput_items[0] / 4; i += 4) {
int rll4B = 0;
for (int j = 0; j < 4; j++) {
// make four bits into one bytes
rll4B |= (in[i + j] & 1) << j;
}
for (int j = 0; j < 6; j++) {
// put six bits corresponding to rll4B
out[6 * i + j] = !!(rll4B6B[rll4B] & (1 << j));
}
}
break;
}

// mapping definition

const char rll4B6B[16] = {
0b011100,0b101100,0b110010,0b011010,
0b101010,0b110001,0b011001,0b101001,
0b100110,0b010110,0b001110,0b100011,
0b010011,0b100101,0b010101,0b001101
};

If the code are not formatted well and hard to read, please refer:
https://gist.github.com/gsongsong/f3e34991a55f29dac5d2
There might be some syntax violation and variable definitions missing, I
apologize for that.
And please note that each in[i] is either 0b or 0b0001.

By using a tag, RLL coding scheme are not changing during the stream.
Currently, I haven't built it and tested yet.

What do you think of it?

I will make some notes after build and test the entire system.

Regrads,
Jeon.

2015-03-26 23:17 GMT+09:00 Kevin Reid :

> On Mar 25, 2015, at 2:15, Marcus Müller  wrote:
>
> > source -+--> custom_block0 ---> encoder0 ---> add -->
> > +--> custom_block1 ---> encoder1 --^
> >
> > you'd need to implement custom_block in python or C++, that would either
> > pass through items, just like the block does that comes out of
> > gr_modtool add -l python -t sync
> > or set the output items to 0. You'd toggle that behavior exactly at the
> > sample that you get a tag.
>
> Note that if you don't actually need the switch to happen at a specific
> point in the stream, but you still want the switch to be atomic (guaranteed
> not to drop or repeat any items), the existing multiply_matrix block can do
> the switching in this flowgraph: it would be configured with one input and
> two outputs, and setting the matrix to either [[0, 1]] or [[1, 0]].
>
> (Of course, the disadvantage of either of these strategies is that you're
> paying the CPU cost of both encoders all of the time.)
>
> --
> Kevin Reid  
>
>
> ___
> 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