[Discuss-gnuradio] Pybombs 2.1.0 test w/Ubuntu 16.04LTS

[Gregory W. Ratcliff]

Greetings,
Noticed in PyBOMBS 2.1.0Fresh and stock Ubuntu 16.04 on intel 4 core.

https://github.com/apache/thrift.git.
PyBOMBS.Fetcher - ERROR - [Errno 2] No such file or directory: 
'/home/gratcliff/gnuradio/.pybombs/inventory.yml'
PyBOMBS.Packager.source - ERROR - Problem occurred while building package 
apache-thrift:
Unable to fetch recipe apache-thrift
PyBOMBS.install_manager - ERROR - Error installing package apache-thrift. 
Aborting.

 Gregory W. Ratcliff




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

[Discuss-gnuradio] Problems compiling gnuradio 3.7.9.2 on Redhat Linux 6u6

[David Meleedy]

I have made a lot of progress but am now at a sticking point.

I am using the version of Qt that comes with RHEL6u6, which is version 4.6.2

Scanning dependencies of target gnuradio-qtgui
[ 77%] Building CXX object 
gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/__/include/gnuradio/qtgui/moc_spectrumdisplayform.cxx.o
:0:3: warning: missing whitespace after the macro name 
[enabled by default]

:0:3: error: expected identifier before ‘-’ token
/cpd/src/gnu/gnuradio/gnuradio-3.7.9.2/gnuradio-runtime/include/gnuradio/thread/thread.h:42:11: 
note: in expansion of macro ‘gr’

 namespace gr {
   ^
:0:3: error: expected unqualified-id before ‘-’ token
/cpd/src/gnu/gnuradio/gnuradio-3.7.9.2/gnuradio-runtime/include/gnuradio/thread/thread.h:42:11: 
note: in expansion of macro ‘gr’

 namespace gr {
   ^
gmake[2]: *** 
[gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/__/include/gnuradio/qtgui/moc_spectrumdisplayform.cxx.o] 
Error 1

gmake[1]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
gmake: *** [all] Error 2


Any help with this would be greatly appreciated.

Thanks,

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

Re: [Discuss-gnuradio] [SOCIS] TensorFlow

[Christopher Richardson]

Hi Martin,

I'm just going to have a look through a number of their publications at
https://wireless.vt.edu/publications.html

I'm now looking at http://arxiv.org/abs/1602.04105# too which looks very
interesting!

If you have any other URLs regarding Virginia Tech & TensorFlow, I'd be
very interested to hear too.

At the moment I'm aiming to make the GNU Radio block which uses TensorFlow,
work in a generic fashion, by enabling
people to load TensorFlow graphs, so that more sophisticated models can be
created too.

Cheers
Chris

On Wed, Jun 29, 2016 at 5:24 PM, Martin Braun 
wrote:

> Christopher,
>
> there's a bunch of researchers at Virginia Tech using Tensor Flow (and
> other ML techniques) for signal classification, and other DSP related
> tasks. Have you looked into their efforts? It would be a shame to see
> time going into duplicate work.
>
> Cheers,
> Martin
>
> On 06/29/2016 01:23 AM, Christopher Richardson wrote:
> > Hi Everyone,
> >
> > I've just posted a blog article on what I've been working on
> > recently -
> https://signalsintelligence.wordpress.com/2016/06/24/tensorflow/
> >
> > I'm now going to work on making a block for GNU Radio, which makes use
> > of TensorFlow to classify signals.
> >
> > cheers
> >
> > Chris
> >
> >
> > ___
> > 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] [SOCIS] TensorFlow

[Martin Braun]

Christopher,

there's a bunch of researchers at Virginia Tech using Tensor Flow (and
other ML techniques) for signal classification, and other DSP related
tasks. Have you looked into their efforts? It would be a shame to see
time going into duplicate work.

Cheers,
Martin

On 06/29/2016 01:23 AM, Christopher Richardson wrote:
> Hi Everyone,
> 
> I've just posted a blog article on what I've been working on
> recently - https://signalsintelligence.wordpress.com/2016/06/24/tensorflow/
> 
> I'm now going to work on making a block for GNU Radio, which makes use
> of TensorFlow to classify signals.
> 
> cheers
> 
> Chris
> 
> 
> ___
> 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] proper use of start(), stop(), and wait() to interact with program flow

[Ed Coleman]

Kevin:

Thank you for the quick and complete reply, I appreciate the help!

-Ed

On Wed, Jun 29, 2016 at 11:04 AM, Kevin Reid  wrote:

> On Jun 29, 2016, at 07:50, Ed Coleman  wrote:
> > if __name__ == '__main__':
> > simpleTone().run()
> >
> > The code above works fine, however if I make the following substitution:
> >
> > if __name__ == '__main__':
> > simpleTone().start()
> > simpleTone().wait()
> > #time.sleep(3)
> > simpleTone().stop()
> >
> > The result is that the file runs, and ends after 3 seconds but no audio
> is produced.
>
> Your problem is that you're constructing three unrelated top blocks: you
> have three separate occurrences of "simpleTone()". Instead you need to
> create one and continue to use it, like so:
>
> tb = simpleTone()
> tb.start()
> ...
> tb.stop()
>
> You have another problem, too, which you will find after fixing the first
> one. .wait() means to wait for the flowgraph to finish all processing, and
> your flowgraph has no elements within it to finish such as a Head block, so
> the .stop() will never be reached.
>
> Instead, you need to proceed like this:
>
> tb = simpleTone()
> tb.start()
> # the flowgraph is now running independently
> time.sleep(3)
> tb.stop()
> tb.wait()
>
> The final .wait() is not actually necessary in this case -- what it does
> is wait for the flowgraph to finish, which will happen shortly after
> .stop() is called, but if you later wish to start the same top block again,
> you must have called .wait() before you call .start(), so always having a
> matched set of [start, stop, wait] or [start, wait, stop] is good practice.
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [RFNoC] Announcing tutorials at GRCon

[Martin Braun]

Hi everyone,

we're very happy to announce that we will be doing another set of
tutorials at this year's GRCon. The tutorial is free, and will happen on
the new user's day at GRCon (Mon, September 12th), *but* it requires
that you purchase a ticket for the new user's day, should you have not
already done so.

There's a limited headcount, so if you want to attend, please head over
to the registration page and get your tutorial ticket (and, if
necessary, your new user's day ticket):

https://www.eventbrite.com/e/gnu-radio-conference-2016-tickets-24257809762

Note: If you register for the tutorial without having registered for the
new user's day, we might have to un-register you and give the seat to
other participants, should there be a waitlist. I therefore recommend
you get your new user's day ticket at the same time as the RFNoC
tutorial ticket, should you require one.

We will follow up with details on the tutorial, but it will be a
hands-on introduction to RFNoC development. Participants will create
their own block and run it on an embedded device.
We will provide all the hardware and a bootable USB drive containing all
the required software. We might also provide laptops, but that remains
to be figured out.

If you're already a somewhat experienced user of RFNoC, you most likely
won't get all that much out of the tutorial, since we'll be focussing on
getting people started. A large portion of Ettus R will be at GRCon
and you can grab us and ask us questions outside of the tutorial, too.

Cheers,
Martin

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

Re: [Discuss-gnuradio] Channel model - the identity channel

[Martin Braun]

This is not the first time this has come up, and yes, patches are
welcome. The simplest fix might be to add a factory-time argument that
disables the resampler entirely -- this will guarantee no sample
offsets, ever, but of course will not allow to change the timing offset
at runtime.

M

On 06/28/2016 07:47 PM, Raj Bhattacharjea wrote:
> Thanks for the hints for where to look and why this happens from a code
> perspective. I don't think it makes sense from a semantic perspective
> (if the user says taps=1, she should get the unity gain delay free
> channel) but I'm guessing "patches are welcome" is the appropriate
> response to this minor usability issue.
> 
> On Tuesday, June 28, 2016, Andrej Rode  > wrote:
> 
> Hey Raj,
> 
> > introduces a delay that can be corrected by applying the taps
> [0,0,0,1].
> > See the attached flowgraph that subtracts the signals before and after
> > the channel model; if you let taps = 1, the two signals don't
> cancel. If
> > you use taps = [0,0,0,1], they do.
> 
> The delay you are seeing is introduced by the fractional_resapmler
> inside the channel_model block. The FIR filter inside the fractional
> resampler needs to build up and therefore introduces a initial delay of
> three samples.
> 
> If you want to know more about the insides of the channel model I
> suggest you look at the sources [0][1] yourself.
> 
> Greetings,
> Andrej
> 
> [0] ./gr-channels/lib/channel_model_impl.cc
> [1] ./gr-channels/lib/channel_model_impl.h
> 
> 
> 
> -- 
> Raj Bhattacharjea, PhD
> Georgia Tech Research Institute
> Information and Communications Laboratory
> http://www.prism.gatech.edu/~rb288/ 
> 404.407.6622
> 
> 
> 
> ___
> 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] proper use of start(), stop(), and wait() to interact with program flow

[Kevin Reid]

On Jun 29, 2016, at 07:50, Ed Coleman  wrote:
> if __name__ == '__main__':
> simpleTone().run()
> 
> The code above works fine, however if I make the following substitution:
> 
> if __name__ == '__main__':
> simpleTone().start()
> simpleTone().wait()
> #time.sleep(3)
> simpleTone().stop()
> 
> The result is that the file runs, and ends after 3 seconds but no audio is 
> produced.

Your problem is that you're constructing three unrelated top blocks: you have 
three separate occurrences of "simpleTone()". Instead you need to create one 
and continue to use it, like so:

tb = simpleTone()
tb.start()
...
tb.stop()

You have another problem, too, which you will find after fixing the first one. 
.wait() means to wait for the flowgraph to finish all processing, and your 
flowgraph has no elements within it to finish such as a Head block, so the 
.stop() will never be reached.

Instead, you need to proceed like this:

tb = simpleTone()
tb.start()
# the flowgraph is now running independently
time.sleep(3)
tb.stop()
tb.wait()

The final .wait() is not actually necessary in this case -- what it does is 
wait for the flowgraph to finish, which will happen shortly after .stop() is 
called, but if you later wish to start the same top block again, you must have 
called .wait() before you call .start(), so always having a matched set of 
[start, stop, wait] or [start, wait, stop] is good practice.


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

[Discuss-gnuradio] proper use of start(), stop(), and wait() to interact with program flow

[Ed Coleman]

I'm experimenting with writing GNUradio scripts in python. My eventual goal
is to have a routine that periodically writes a floating point result from
within a GNUradio process to the serial port. As a first step I wanted to
try and interact with a simple routine by simply pausing after a short time
period.  I started with the the following code that plays a 1kHz tone thru
the sound card:

#!/usr/bin/env python
##
# Gnuradio Python Flow Graph
# Title: simpleTone
# Generated: Wed Jun 29 07:26:02 2016
##

from gnuradio import analog
from gnuradio import audio
from gnuradio import blocks
from gnuradio import gr
import time

class simpleTone(gr.top_block):

def __init__(self):
gr.top_block.__init__(self)

##
# Variables
##
self.samp_rate = samp_rate = 32000

##
# Blocks
##
#self.blocks_throttle_0 = blocks.throttle(gr.sizeof_float*1,
samp_rate)
self.audio_sink_0 = audio.sink(samp_rate, "", True)
self.analog_sig_source_x_0 = analog.sig_source_f(samp_rate,
analog.GR_COS_WAVE, 1000, 1, 0)

##
# Connections
##
#self.connect((self.analog_sig_source_x_0, 0),
(self.blocks_throttle_0, 0))
#self.connect((self.blocks_throttle_0, 0), (self.audio_sink_0, 0))
self.connect((self.analog_sig_source_x_0, 0), (self.audio_sink_0, 0))


if __name__ == '__main__':
simpleTone().run()



The code above works fine, however if I make the following substitution:



if __name__ == '__main__':
simpleTone().start()
simpleTone().wait()
#time.sleep(3)
simpleTone().stop()



The result is that the file runs, and ends after 3 seconds but no audio is
produced.

I'm sure I've missed something fairly basic, any help would be appreciated.
Thanks.

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

Re: [Discuss-gnuradio] [SOCIS] TensorFlow

[Christopher Richardson]

Hi Stefan,

Thanks for your reply.

I'm currently working on a GNU Radio block which will be able to load any
TensorFlow
graph, which would allow different types of models to be utilised.

At the moment in my repository only a single hidden layer is utilised with
no convolutional
layers.

cheers

Chris

On Wed, Jun 29, 2016 at 1:23 PM, Stefan Wunsch <
stefan.wun...@student.kit.edu> wrote:

> Hi,
>
> The classification accuracy looks good! But some questions:
>
> Will you compare the performance with non-tensorflow machine learning
> algorithms such as boosted decision trees or support vector machines
> (e.g. provided by scikit-learn or xgboost)?
>
> Your model is a deep neural network, so there is a convolutional layer
> in this model to make use of the 2D representation of the spectral
> coherence function? DNN implies for me only a bunch of hidden layers. As
> well, convolution layer(s) makes the classificator translation invariant
> (do you need this?).
>
> Greetings,
> Stefan
>
> On 06/29/2016 10:23 AM, Christopher Richardson wrote:
> > Hi Everyone,
> >
> > I've just posted a blog article on what I've been working on
> > recently -
> https://signalsintelligence.wordpress.com/2016/06/24/tensorflow/
> >
> > I'm now going to work on making a block for GNU Radio, which makes use
> > of TensorFlow to classify signals.
> >
> > cheers
> >
> > Chris
> >
> >
> > ___
> > 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] [SOCIS] TensorFlow

[Stefan Wunsch]

Hi,

The classification accuracy looks good! But some questions:

Will you compare the performance with non-tensorflow machine learning
algorithms such as boosted decision trees or support vector machines
(e.g. provided by scikit-learn or xgboost)?

Your model is a deep neural network, so there is a convolutional layer
in this model to make use of the 2D representation of the spectral
coherence function? DNN implies for me only a bunch of hidden layers. As
well, convolution layer(s) makes the classificator translation invariant
(do you need this?).

Greetings,
Stefan

On 06/29/2016 10:23 AM, Christopher Richardson wrote:
> Hi Everyone,
> 
> I've just posted a blog article on what I've been working on
> recently - https://signalsintelligence.wordpress.com/2016/06/24/tensorflow/
> 
> I'm now going to work on making a block for GNU Radio, which makes use
> of TensorFlow to classify signals.
> 
> cheers
> 
> Chris
> 
> 
> ___
> 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] [SOCIS] TensorFlow

[Christopher Richardson]

Hi Everyone,

I've just posted a blog article on what I've been working on
recently - https://signalsintelligence.wordpress.com/2016/06/24/tensorflow/

I'm now going to work on making a block for GNU Radio, which makes use of
TensorFlow to classify signals.

cheers

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

Re: [Discuss-gnuradio] Appending SYNC block to data

[Ron Economos]

Here's an example block that's very similar to what you want to do.

https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/lib/catv/catv_frame_sync_enc_bb_impl.cc

Note the use of set_output_multiple() and the forecast function.

Ron

On 06/28/2016 10:48 AM, Olivier Goyette wrote:

I did a simple test :

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include 
#include 
#include "ADD_SYNC_impl.h"

#define TAB_SIZE 420

namespace gr {
  namespace UAT {

ADD_SYNC::sptr
ADD_SYNC::make()
{
  return gnuradio::get_initial_sptr
(new ADD_SYNC_impl());
}

/*
 * The private constructor
 */
ADD_SYNC_impl::ADD_SYNC_impl()
  : gr::block("ADD_SYNC",
  gr::io_signature::make(1, 1, sizeof(unsigned char)),
  gr::io_signature::make(1, 1, sizeof(unsigned char)))
{}

/*
 * Our virtual destructor.
 */
ADD_SYNC_impl::~ADD_SYNC_impl()
{
}

void
ADD_SYNC_impl::forecast (int noutput_items, gr_vector_int 
_items_required)

{
  /* <+forecast+> e.g. ninput_items_required[0] = noutput_items */
}

int
ADD_SYNC_impl::general_work (int noutput_items,
   gr_vector_int _items,
   gr_vector_const_void_star _items,
   gr_vector_void_star _items)
{
  const unsigned char *in = (const unsigned char *) input_items[0];
  char *out = (char *) output_items[0];
  //unsigned long preamble = 0b111010101100110111011010010011100010;
  //unsigned char tab[TAB_SIZE] = 
{1,1,1,0,1,0,1,0,1,1,0,0,1,1,0,1,1,1,0,1,1,0,1,0,0,1,0,0,1,1,1,0,0,0,1,0};


  for(int i = 0; i < noutput_items; i++)
  {
  out[i] = in[i];
  }

  for(int x = 0; x < TAB_SIZE; x++)
  {
  printf("%u", out[x]);
  printf(" ");
  }
  printf("\n\n");


  consume_each (noutput_items);

  // Tell runtime system how many output items we produced.
  return noutput_items;
}

  } /* namespace UAT */
} /* namespace gr */

I'm printing the input to the output directly and here is the results :

Generating: '/home/lassena/Documents/top_block.py'

Generating: '/home/lassena/Documents/top_block.py'

Executing: /usr/bin/python2 -u /home/lassena/Documents/top_block.py

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 

Re: [Discuss-gnuradio] Appending SYNC block to data

[Johannes Demel]

Hi Olivier,

I can't find anything in your code that checks if you actually print 
valid data. See [0] for a description of C++ GNU Radio blocks and how 
they work.


Since you use a block of type 'block', make sure you get an idea of 
'general_work' parameters, its return value and 'consume_each'. And how 
that relates to the input and output buffer.


Cheers
Johannes

[0] 
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_C++


On 28.06.2016 19:48, Olivier Goyette wrote:

I did a simple test :

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include 
#include 
#include "ADD_SYNC_impl.h"

#define TAB_SIZE 420

namespace gr {
   namespace UAT {

 ADD_SYNC::sptr
 ADD_SYNC::make()
 {
   return gnuradio::get_initial_sptr
 (new ADD_SYNC_impl());
 }

 /*
  * The private constructor
  */
 ADD_SYNC_impl::ADD_SYNC_impl()
   : gr::block("ADD_SYNC",
   gr::io_signature::make(1, 1, sizeof(unsigned char)),
   gr::io_signature::make(1, 1, sizeof(unsigned char)))
 {}

 /*
  * Our virtual destructor.
  */
 ADD_SYNC_impl::~ADD_SYNC_impl()
 {
 }

 void
 ADD_SYNC_impl::forecast (int noutput_items, gr_vector_int
_items_required)
 {
   /* <+forecast+> e.g. ninput_items_required[0] = noutput_items */
 }

 int
 ADD_SYNC_impl::general_work (int noutput_items,
gr_vector_int _items,
gr_vector_const_void_star _items,
gr_vector_void_star _items)
 {
   const unsigned char *in = (const unsigned char *) input_items[0];
   char *out = (char *) output_items[0];
   //unsigned long preamble = 0b111010101100110111011010010011100010;
   //unsigned char tab[TAB_SIZE] =
{1,1,1,0,1,0,1,0,1,1,0,0,1,1,0,1,1,1,0,1,1,0,1,0,0,1,0,0,1,1,1,0,0,0,1,0};

   for(int i = 0; i < noutput_items; i++)
   {
   out[i] = in[i];
   }

   for(int x = 0; x < TAB_SIZE; x++)
   {
   printf("%u", out[x]);
   printf(" ");
   }
   printf("\n\n");


   consume_each (noutput_items);

   // Tell runtime system how many output items we produced.
   return noutput_items;
 }

   } /* namespace UAT */
} /* namespace gr */

I'm printing the input to the output directly and here is the results :

Generating: '/home/lassena/Documents/top_block.py'

Generating: '/home/lassena/Documents/top_block.py'

Executing: /usr/bin/python2 -u /home/lassena/Documents/top_block.py

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0