Forum: GNU Radio DIGITAL RX and TX?

Ec16783e32983d56b55da855481595a3?d=identicon&s=25 Joel Mayer (Guest)
on 2012-10-23 13:36
(Received via mailing list)
Dear Mister Ahmed Zaheer-

You might find answers to your questions about receiving and
transmitting in Digital at the DECT project website.

https://dedected.org/trac<https://dedected.org/trac>

Have A Nice Day!
  ----- Original Message -----
  From:
discuss-gnuradio-request@gnu.org<mailto:discuss-gnuradio-request@gnu.org>
  To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
  Sent: Monday, October 22, 2012 5:24 PM
  Subject: Discuss-gnuradio Digest, Vol 119, Issue 24


  Send Discuss-gnuradio mailing list submissions to
  discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>

  To subscribe or unsubscribe via the World Wide Web, visit
  https://lists.gnu.org/mailman/listinfo/discuss-gnu...
  or, via email, send a message with subject or body 'help' to
  discuss-gnuradio-request@gnu.org<mailto:discuss-gnuradio-request@gnu.org>

  You can reach the person managing the list at
  discuss-gnuradio-owner@gnu.org<mailto:discuss-gnuradio-owner@gnu.org>

  When replying, please edit your Subject line so it is more specific
  than "Re: Contents of Discuss-gnuradio digest..."


  Today's Topics:

     1. Re: Blocks missing from GRC after pre-cog installation
        (Sakib Chowdhury)
     2. Northern hemisphere notice: Winter is approaching (Patrik Tast)
     3. Re: Very weird about my N210 board. (Nowlan, Sean)
     4. No Digital Modulation Working (Ahmed Zaheer)
     5. Re: Problems passing the control between blocks - message
        passing (Jose Torres Diaz)


  ----------------------------------------------------------------------

  Message: 1
  Date: Mon, 22 Oct 2012 16:52:13 -0400
  From: Sakib Chowdhury
<sakib.others@gmail.com<mailto:sakib.others@gmail.com>>
  To: josh@joshknows.com<mailto:josh@joshknows.com>
  Cc: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
  Subject: Re: [Discuss-gnuradio] Blocks missing from GRC after pre-cog
  installation
  Message-ID:
  <CACmXc5cL-jEfee3gfiY1xD7inh6ZLS9ivFSfROUUjgtFP2Ns5w@mail.gmail.com<mailto:CACmXc5cL-jEfee3gfiY1xD7inh6ZLS9ivFSfROUUjgtFP2Ns5w@mail.gmail.com>>
  Content-Type: text/plain; charset="iso-8859-1"

  Hi,

  I cannot figure out the source of the problem. I don't have multiple
  installations of gnuradio. While I'm installing gnuradio and grextras
  (either by the installation script from gnuradio.org website or by
  manually), I run git clone commands in ~/Downloads directory. Thus I
have
  gnuradio and grextras folders in ~/Downloads folder. So, in the usual
way I
  proceed to install, and they are properly installed in /usr/local/ . I
run
  GRC and get all the blocks. I attached the screenshot. Then I run git
clone
  command for pre-cog in ~/Downloads folder, so I have a pre-cog folder
in
  ~/Downloads. I then proceed to install it in usual manner (mkdir
build,
  cmake, make etc.) and it is properly installed. Then if I run GRC,
blocks
  are missing, those that start with gr_*.xml. I have attached the
screenshot
  too.

  Is there any other specific installation instructions?

  Thanks.


  On Thu, Oct 18, 2012 at 9:44 PM, Josh Blum
<josh@joshknows.com<mailto:josh@joshknows.com>> wrote:

  >
  >
  > On 10/18/2012 11:07 AM, Sakib Chowdhury wrote:
  > > Hi,
  > >
  > > Unfortunately reinstalling didn't solve the problem. I tried twice
  > already.
  > > What I did is first I removed all relevant gnuradio and uhd files
and
  > > folders from /usr/* folders and installed gnuradio, uhd, grextras
using
  > the
  > > script linked on gnuradio.org website:
  >
  > Would you perhaps have multiple installs of gnuradio both in /usr
and
  > /usr/local? That could be one issue
  >
  > Also, while its ok to put gnuradio in /usr and grextras and pre-cog
into
  > /usr/local. You will need to set the GRC_BLOCKS_PATH environment
  > variable to have entries for both block paths. The paths would be
  > your_install_prefix/share/gnuradio/grc/blocks
  >
  > -josh
  >
  > >
http://www.sbrac.org/files/build-gnuradio<http://w...
. I opened GRC and found some
  > > newer blocks (obviously because of some updates to the source)
along with
  > > my previously missing blocks. So, everything is fine. Then I
installed
  > > pre-cog using the set of commands at the end of the page:
  > >
https://github.com/buoyboy/pre-cog/wiki/Installati...
. After that I
  > opened
  > > GRC and blocks that start with gr_*.xml are gone.
  > >
  > > Please let me know if I'm doing something wrong with the
installation.
  > > Isn't pre-cog supposed to be installed in this way? Or if pre-cog
is
  > > required, I have to install gnuradio in some other way apart from
using
  > > that script?
  > >
  > > Thanks.
  > >
  > >
  > > On Wed, Oct 17, 2012 at 5:32 PM, Johnathan Corgan
  > >
<johnathan@corganlabs.com>wrote<mailto:johnathan@corganlabs.com%3Ewrote>:
  > >
  > >> On Wed, Oct 17, 2012 at 2:30 PM, Sakib Chowdhury <
  > sakib.others@gmail.com>wrote<mailto:sakib.others@gmail.com%3Ewrote>:
  > >>
  > >>
  > >>> I noticed that actually all block files (xml) are still there
  > >>> in /usr/local/share/gnuradio/grc/blocks/ . What GRC is not
displaying
  > are
  > >>> the blocks whose names start with gr_*.xml . I'll try to
reinstall.
  > >>>
  > >>
  > >> This was a recently fixed bug on GNU Radio master branch, related
to the
  > >> gr-blocks work Josh mentioned.
  > >>
  > >> Johnathan
  > >>
  > >>
  > >
  >
  -------------- next part --------------
  An HTML attachment was scrubbed...
  URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio...
  -------------- next part --------------
  A non-text attachment was scrubbed...
  Name: Before pre-cog installation.png
  Type: image/png
  Size: 37113 bytes
  Desc: not available
  URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio...
  -------------- next part --------------
  A non-text attachment was scrubbed...
  Name: After pre-cog installation.png
  Type: image/png
  Size: 27936 bytes
  Desc: not available
  URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio...

  ------------------------------

  Message: 2
  Date: Mon, 22 Oct 2012 23:58:58 +0300
  From: Patrik Tast
<patrik@poes-weather.com<mailto:patrik@poes-weather.com>>
  To: Discuss-GNURadio
<discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>>
  Subject: [Discuss-gnuradio] Northern hemisphere notice: Winter is
  approaching
  Message-ID:
<1350939538.1811.41.camel@devel.poes-weather.com<mailto:1350939538.1811.41.camel@devel.poes-weather.com>>
  Content-Type: text/plain; charset="UTF-8"

  A note for those who receive >= 1 GHz and have their antennas outside
at
  >60 North (I'm at +63 North). Water/Ice/Snow will attenuate your
signal
  dramatically if you don't protect your antenna.

  A sample when air temperature was +2C and dish temperature was -1C
(1.5m
  prime focus).
  http://poes-weather.com/~patrik/1.7GHz/Screenshot%...
  2020:50:49.png

  The signal should have been (left/right) straight arc lines *not hairy
  FFT*. But now it was full of ice and erroneous since it was uncovered.

  A simple solution could be to cover it with foam and have a fan
blowing
  in +C air and one sucking out. The dish/antenna should always be dry
  (>1013 mbar)

  Just a reminder when receiving microwave up North,
  Patrik




  ------------------------------

  Message: 3
  Date: Mon, 22 Oct 2012 21:24:02 +0000
  From: "Nowlan, Sean"
<Sean.Nowlan@gtri.gatech.edu<mailto:Sean.Nowlan@gtri.gatech.edu>>
  To: Ben Hilburn <ben@ettus.com<mailto:ben@ettus.com>>,
"josh@ettus.com<mailto:josh@ettus.com>"
<josh@ettus.com<mailto:josh@ettus.com>>
  Cc: "discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>"
<discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>>
  Subject: Re: [Discuss-gnuradio] Very weird about my N210 board.
  Message-ID:
<195933287DC65748BA7AE867BA8E430B622E5301@apatlisdmbx02<mailto:195933287DC65748BA7AE867BA8E430B622E5301@apatlisdmbx02>>
  Content-Type: text/plain; charset="utf-8"

  Sorry for the late reply here, but 1 more thing to check: is the
device getting consistent power? We?ve noticed that if the voltage is
too low or the connector is loose, the radio can be thrown into a state
that produces those errors.

  From:
discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org<mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org>
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech.edu@gnu.org] On
Behalf Of Ben Hilburn
  Sent: Monday, October 15, 2012 3:11 PM
  To: josh@ettus.com<mailto:josh@ettus.com>
  Cc: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
  Subject: Re: [Discuss-gnuradio] Very weird about my N210 board.

  Also, are you using Network Manager on your PC? If so, have you told
it to ignore the ethernet interface? If not, NM will try to re-negotiate
DHCP on that interface over and over, bringing down your link every
time.

  Cheers,
  Ben
  On Mon, Oct 15, 2012 at 9:40 AM, Josh Blum
<josh@ettus.com<mailto:josh@ettus.com<mailto:josh@ettus.com%3Cmailto:josh@ettus.com>>>
wrote:


  On 10/15/2012 09:36 AM, Pan wrote:
  > Hi,
  >
  > Sorry for bothering you guys. I encountered some very weird thing
about my
  > N210 board.
  >
  > When the board is powered up, it seems very thing works well.
Actually, I
  > can even ping this board. However, if I run any applications in the
  > applications?such as uhd_fft? uhd/siggen  in the /usr/local/bin
folder, the
  > terminal shows there are many errors as following.  After that, this
board
  > reset again and again for several minutes. It is very weird! Is
there
  > anyone can tell me what happened with my N210 board. Any suggestion
or hint
  > will be very appreciated. Thank you so much.
  >
  Looks like the ethernet link is dying on you. Could be an issue w/ the
  driver for your ethernet card. Can you try a different ethernet or PC
  and see if the problem follows?

  > Best,
  >
  > Pan
  >
  >
  >
  >
pan@pan-XPS-8300:/usr/local/bin$<mailto:pan@pan-XPS-8300:/usr/local/bin$>
./uhd_siggen
  > linux; GNU C++ version 4.6.3; Boost_104601;
UHD_003.004.003-255-gc7054ce5
  >
  > -- Opening a USRP2/N-Series device...
  > -- Current recv frame size: 1472 bytes
  > -- Current send frame size: 1472 bytes
  > -- Detecting internal GPSDO.... not found
  >
  > UHD Error:
  >     The daughterboard manager encountered a recoverable error in
init.
  >     Loading the "unknown" daughterboard implementations to continue.
  >     The daughterboard cannot operate until this error is resolved.
  >     RuntimeError: fifo ctrl timed out looking for acks
  >
  > UHD Error:
  >     Control packet attempt 0, sequence number 318:
  >     RuntimeError: no control response, possible packet loss
  >
  > UHD Error:
  >     Control packet attempt 1, sequence number 319:
  >     RuntimeError: no control response, possible packet loss
  >
  > UHD Error:
  >     Control packet attempt 2, sequence number 320:
  >     RuntimeError: no control response, possible packet loss
  >
  > UHD Error:
  >     An unexpected exception was caught in a task loop.
  >     The task loop will now exit, things may not work.
  >     RuntimeError: link dead: timeout waiting for control packet ACK
  >
  > UHD Error:
  >     Control packet attempt 0, sequence number 321:
  >     RuntimeError: no control response, possible packet loss
  >
  > UHD Error:
  >     Control packet attempt 1, sequence number 322:
  >     RuntimeError: no control response, possible packet loss
  >
  > UHD Error:
  >     Control packet attempt 2, sequence number 323:
  >     RuntimeError: no control response, possible packet loss
  > RuntimeError: fifo ctrl timed out looking for acks
  >
pan@pan-XPS-8300:/usr/local/bin$<mailto:pan@pan-XPS-8300:/usr/local/bin$>
./uhd_fft
  > linux; GNU C++ version 4.6.3; Boost_104601;
UHD_003.004.003-255-gc7054ce5
  >
  > Traceback (most recent call last):
  >   File "./uhd_fft", line 337, in <module>
  >     main ()
  >   File "./uhd_fft", line 333, in main
  >     app = stdgui2.stdapp(app_top_block, "UHD FFT", nstatus=1)
  >   File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
  > line 38, in __init__
  >     wx.App.__init__ (self, redirect=False)
  >   File
"/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
  > line 7981, in __init__
  >     self._BootstrapApp()
  >   File
"/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
  > line 7555, in _BootstrapApp
  >     return _core_.PyApp__BootstrapApp(*args, **kwargs)
  >   File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
  > line 42, in OnInit
  >     self._max_noutput_items)
  >   File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
  > line 64, in __init__
  >     self.panel = stdpanel (self, self, top_block_maker, max_nouts)
  >   File
"/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py",
  > line 86, in __init__
  >     self.top_block = top_block_maker (frame, self, vbox, sys.argv)
  >   File "./uhd_fft", line 91, in __init__
  >     otw_format=options.wire_format, args=options.stream_args))
  >   File
"/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
  > line 116, in constructor_interceptor
  >     return old_constructor(*args)
  >   File
"/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
  > line 2834, in usrp_source
  >     return _uhd_swig.usrp_source(*args)
  > RuntimeError: LookupError: KeyError: No devices found for ----->
  > Empty Device Address
  >
pan@pan-XPS-8300:/usr/local/bin$<mailto:pan@pan-XPS-8300:/usr/local/bin$>
  >
  >
  >
  > _______________________________________________
  > Discuss-gnuradio mailing list
  >
Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org%3Cmailto:Discuss-gnuradio@gnu.org>>
  >
https://lists.gnu.org/mailman/listinfo/discuss-gnu...
  >

  _______________________________________________
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org%3Cmailto:Discuss-gnuradio@gnu.org>>
  https://lists.gnu.org/mailman/listinfo/discuss-gnu...

  -------------- next part --------------
  An HTML attachment was scrubbed...
  URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio...

  ------------------------------

  Message: 4
  Date: Mon, 22 Oct 2012 15:03:02 -0700 (PDT)
  From: Ahmed Zaheer
<ghumman1988@yahoo.com<mailto:ghumman1988@yahoo.com>>
  To: "discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>"
<discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>>
  Subject: [Discuss-gnuradio] No Digital Modulation Working
  Message-ID:
  <1350943382.54821.YahooMailNeo@web160206.mail.bf1.yahoo.com<mailto:1350943382.54821.YahooMailNeo@web160206.mail.bf1.yahoo.com>>
  Content-Type: text/plain; charset="iso-8859-1"

  Hi all,?
  I was trying to make a transceiver working on any digital modulation.
I have tried GMSK, PSK, QPSK, QAM and other blocks available in gnuradio
companion. But non of them works. All of them works in loop back manner
but when ever I try to transmit and receive on air it simply doesn't
work. In the attached file I am using GMSK while transmitting a video
file. I have also tried audio file, and even a simple sine wave but all
in vain. I am using USRP N210 with SBX daugherboard with VERT 2450
antenna. All of the equipment works as I was succeeded in transmitting
my voice while doing frequency modulation. If anybody can tell me about
any mistake while seeing the attached file or provide me with any
transceiver using any digital modulation which should work on latest
gnuradio with USRP N210 that would really be a great help.?
  I really appreciate your help.
  Regards.
  Ahmed.
  -------------- next part --------------
  An HTML attachment was scrubbed...
  URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio...
  -------------- next part --------------
  A non-text attachment was scrubbed...
  Name: GMSK_Trans_Receive.png
  Type: image/png
  Size: 273347 bytes
  Desc: not available
  URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio...

  ------------------------------

  Message: 5
  Date: Tue, 23 Oct 2012 08:54:38 +1030
  From: Jose Torres Diaz
<torresdiaz.jose@gmail.com<mailto:torresdiaz.jose@gmail.com>>
  To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
  Subject: Re: [Discuss-gnuradio] Problems passing the control between
  blocks - message passing
  Message-ID:
  <CANLn+iuxhzRaPv1CkEwJ6ugcxopw_eQZ+RjkSbiJABfzpQnOBA@mail.gmail.com<mailto:CANLn+iuxhzRaPv1CkEwJ6ugcxopw_eQZ+RjkSbiJABfzpQnOBA@mail.gmail.com>>
  Content-Type: text/plain; charset="iso-8859-1"

  Hi Community,

  In following up this issue, we've tried different options (ie. returns
0,
  yield or returns -1 in work function). What is happening is the block
are
  running exactly once. In other words, the work() function never comes
back
  and run again.

  Anyone can suggest a way to solve this issue?.

  Thanks for your comments,

  Jose.

  On Mon, Oct 22, 2012 at 5:55 PM, Jose Torres Diaz
<torresdiaz.jose@gmail.com<mailto:torresdiaz.jose@gmail.com>
  > wrote:

  > Hi John,
  >
  > Also, I am trying to use boost::this_thread::yield() between blocks,
but
  > when I add a third block into the chain, the control passes between
BLOCK 1
  > <-> BLOCK 2. When they finish, the control is passed to BLOCK 3.
  >
  > Thanks again for your suggestions,
  >
  > Jose
  >
  >
  > On Mon, Oct 22, 2012 at 9:17 AM, Jose Torres Diaz <
  > torresdiaz.jose@gmail.com<mailto:torresdiaz.jose@gmail.com>> wrote:
  >
  >> Hi John,
  >>
  >> Please, find attached the codes (.cc) for BLOCK 1 and BLOCK 2. I'm
still
  >> unable to control the correct order of them, when I generated an
infinite
  >> loop.
  >>
  >> Thanks a lot for your help in this issue,
  >>
  >> Regards,
  >>
  >> Jose
  >>
  >>
  >> On Thu, Oct 18, 2012 at 9:58 AM, John Malsbury
<john.malsbury@ettus.com>wrote<mailto:john.malsbury@ettus.com%3Ewrote>:
  >>
  >>> Can you send me the files?
  >>>
  >>> -John
  >>>
  >>>
  >>>
  >>>
  >>> On Wed, Oct 17, 2012 at 4:16 PM, Jose Torres Diaz <
  >>> torresdiaz.jose@gmail.com<mailto:torresdiaz.jose@gmail.com>>
wrote:
  >>>
  >>>> Hi John,
  >>>>
  >>>> Yes, I also checked the examples in your branch. In regards to
your
  >>>> questions.
  >>>>
  >>>> *1.* BLOCK 2 is processing the data from BLOCK 1, but only when
BLOCK
  >>>> 1 has finished the routine "N times". Let me post a piece of code
from
  >>>> BLOCK 1:
  >>>>
  >>>>
  >>>>
  >>>> int work(
  >>>>         const InputItems &,
  >>>>         const OutputItems &
  >>>>     ){
  >>>>
  >>>>
  >>>>         for (int i = 0; i < d_pkt_len; i++) {
  >>>>                if (d_mode == 2)
  >>>>           { elements[i] = ((i % d_pkt_len) + d_num_pkts_output) &
0xff;
  >>>>                   }
  >>>>         else if (d_mode == 0)
  >>>>           {elements[i]=0;
  >>>>                  }
  >>>>              else // ones
  >>>>         {elements[i]=0xFF;
  >>>>         }
  >>>>         num_output++;
  >>>>       } //End of for
  >>>>       d_num_pkts_output++;
  >>>>
  >>>>       //(4.1) adding data into the dictionary
  >>>>       dictionary = pmt::pmt_dict_add(dictionary, data_key,
vector_data);
  >>>>       std::cout << std::endl << "(4) Now, the dictionary is" <<
  >>>> dictionary <<std::endl;
  >>>>
  >>>>
  >>>>       //Posting a message downstream
  >>>>       this->post_msg(0, AMSG_KEY, dictionary, _d_my_unique_id);
  >>>>       std::cout << std::endl << "posting the message downstream "
  >>>> <<std::endl;
  >>>>
  >>>>       return -1;  // <--The problem seems to be here
  >>>>
  >>>>    }
  >>>>
  >>>>
  >>>> *2.* N is the number of packet that I want to transmit from BLOCK
1.
  >>>> In my code, I'm using the variable d_max_pkts. So, when
d_num_pkts_output
  >>>> >= d_max_pkts, the program stops:
  >>>>
  >>>>     if (d_num_pkts_output >= d_max_pkts)
  >>>>       return 0;
  >>>>
  >>>> 3. Yes, my BLOCK 1 is as follows:
  >>>>
  >>>> block(
  >>>>           //"gr uhd amsg source",
  >>>>           "BLOCK 1",
  >>>>             gr_make_io_signature(0, 0, 0),
  >>>>             gr_make_io_signature(0, 0, 0),
  >>>>             msg_signature(false, 1)
  >>>>
  >>>>
  >>>> Thanks again for your advice,
  >>>>
  >>>> Regards,
  >>>>
  >>>> Jose
  >>>>
  >>>>
  >>>> On Wed, Oct 17, 2012 at 5:14 PM, John Malsbury
<john.malsbury@ettus.com<mailto:john.malsbury@ettus.com>
  >>>> > wrote:
  >>>>
  >>>>> So, block 2 is never processing the data?  What are you using to
set
  >>>>> the "N"?  Does the uhd_amsg_source have the same i/o as the
original block
  >>>>> - no inputs, one msg output?
  >>>>>
  >>>>> If you're looking to something to generate periodic msg's with
  >>>>> arbirtrary key and value, the heart_beat block in my pre-cog
branch might
  >>>>> help...
  >>>>>
  >>>>> -John
  >>>>>
  >>>>>
  >>>>>
  >>>>>
  >>>>>
  >>>>> On Tue, Oct 16, 2012 at 11:34 PM, Jose Torres Diaz <
  >>>>> torresdiaz.jose@gmail.com<mailto:torresdiaz.jose@gmail.com>>
wrote:
  >>>>>
  >>>>>> Hi John,
  >>>>>>
  >>>>>> I wrote the code in C++ based on UHD_AMsg_source.cc, provided
in
  >>>>>> GRExtras. In my work function, I've finished it using return -1
(ie. the
  >>>>>> block has finished processing correctly) as shown below:
  >>>>>>
  >>>>>> int work(
  >>>>>>         const InputItems &,
  >>>>>>         const OutputItems &
  >>>>>>     ){
  >>>>>>       //work definition here (ie. generate a packet and post
  >>>>>> downstream)
  >>>>>>       return -1; //done running, work done status
  >>>>>>     }
  >>>>>>
  >>>>>> However, in that way the block in GNU Radio Companion runs only
once.
  >>>>>> The other possibility is not to use "return" at all, but in
that case what
  >>>>>> I have is:
  >>>>>>
  >>>>>> 1. BLOCK 1 generates a packet
  >>>>>> 2. BLOCK 1 post the packet downstream
  >>>>>>
  >>>>>> Step 1 and 2 repeats "N times". When finishes, it gives the
control
  >>>>>> to BLOCK 2 to process the message. However, I need a sequence
as follows:
  >>>>>>
  >>>>>> 1. BLOCK 1 generates a packet
  >>>>>> 2. BLOCK 1 post the packet downstream
  >>>>>> 3. BLOCK 2 process the packet
  >>>>>> 4. BLOCK 2 post the message again downstream and so on...
  >>>>>>
  >>>>>> Step 1 to 4 should repeat "N times".
  >>>>>>
  >>>>>> Thanks again for your help,
  >>>>>>
  >>>>>> Jose
  >>>>>>
  >>>>>>
  >>>>>> On Wed, Oct 17, 2012 at 4:52 PM, John Malsbury <
  >>>>>> john.malsbury@ettus.com<mailto:john.malsbury@ettus.com>> wrote:
  >>>>>>
  >>>>>>> Jose,
  >>>>>>>
  >>>>>>> Try a while(1) with a block and  a blocking call to pop msg's
off
  >>>>>>> the queue:
  >>>>>>>
  >>>>>>> self.pop_msg_queue()
  >>>>>>>
  >>>>>>> Should help you avoid the return -1
  >>>>>>>
  >>>>>>> Or maybe I've misunderstood your problem...?
  >>>>>>>
  >>>>>>> -John
  >>>>>>>
  >>>>>>>
  >>>>>>>
  >>>>>>> On Tue, Oct 16, 2012 at 11:18 PM, Jose Torres Diaz <
  >>>>>>> torresdiaz.jose@gmail.com<mailto:torresdiaz.jose@gmail.com>>
wrote:
  >>>>>>>
  >>>>>>>> Hi All,
  >>>>>>>>
  >>>>>>>> I'm working with 2 blocks that I've created using
"UHD_AMsg_Source"
  >>>>>>>> as a reference model. In these blocks, I am passing pmt_dict
type as
  >>>>>>>> messages, ie:
  >>>>>>>>
  >>>>>>>>  this->post_msg(0, AMSG_KEY, dictionary,_id);
  >>>>>>>>
  >>>>>>>> Where, dictionary contains data/metadata that I can read in
the
  >>>>>>>> next block downstream.
  >>>>>>>>
  >>>>>>>> BLOCK 1  -- (pmt_dict included in the message) -->  BLOCK 2
  >>>>>>>>
  >>>>>>>> The blocks are working ok, but the problem is that when I
want to
  >>>>>>>> generate several packets and post them downstream, BLOCK 1
runs until
  >>>>>>>> finishes and then BLOCK 2 takes the control until finishes.
The problem is
  >>>>>>>> the "return" sentence in my work function. I did 2 possible
ways
  >>>>>>>>
  >>>>>>>> Option 1: Using -1
  >>>>>>>>
  >>>>>>>> work {
  >>>>>>>> //work here
  >>>>>>>> return -1
  >>>>>>>> }
  >>>>>>>>
  >>>>>>>> In this way BLOCK 1 stops working after one iteration and it
does
  >>>>>>>> not run as many times as I want.
  >>>>>>>>
  >>>>>>>> Option 1: Not using return
  >>>>>>>>
  >>>>>>>> work {
  >>>>>>>> //work here
  >>>>>>>> }
  >>>>>>>>
  >>>>>>>> In this way BLOCK 1 runs many times and posts messages
downstream
  >>>>>>>> all those times, but it gives the control to BLOCK 2 when it
finishes.
  >>>>>>>> Then, BLOCK 2 takes the messages from the message queue.
However, this
  >>>>>>>> implementation is not useful for me. BLOCK 1 should post a
message
  >>>>>>>> downstream and then, BLOCK 2 takes the message and work with
the packet.
  >>>>>>>>
  >>>>>>>> Any suggestion is welcome, thanks a lot for your time,
  >>>>>>>>
  >>>>>>>> Regards,
  >>>>>>>>
  >>>>>>>> Jose
  >>>>>>>>
  >>>>>>>> _______________________________________________
  >>>>>>>> Discuss-gnuradio mailing list
  >>>>>>>> Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
  >>>>>>>>
https://lists.gnu.org/mailman/listinfo/discuss-gnu...
  >>>>>>>>
  >>>>>>>>
  >>>>>>>
  >>>>>>
  >>>>>>
  >>>>>>
  >>>>>
  >>>>
  >>>>
  >>>>
  >>>
  >>
  >>
  >>
  >>
  >
  >
  >
  -------------- next part --------------
  An HTML attachment was scrubbed...
  URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio...

  ------------------------------

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


  End of Discuss-gnuradio Digest, Vol 119, Issue 24
  *************************************************
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.