Re: [Discuss-gnuradio] Proper block inheritance

[Nemanja Savic]

Actually my question is: is there any example where some block is derived
from two other blocks (for example from two sync blocks)?


On Tue, Sep 10, 2013 at 12:45 PM, Nemanja Savic  wrote:

> Thank you Josh. At the moment I wanted to make this as simple as possible.
> My idea was to make a new class(block type) and to make my impl class
> inherit that class also. In that new class I would store message port
> subscription and a method for sending message that deframer received valid
> message. The problem is i can't really figure out how to make a the new
> class that will be used only to be inheritted by my deframer block.
> Something simillar is done with filter blocks in gnuradio, there are few
> classes declared in fir_filter.h and other filters inherit that class.
>
> Cheers,
> Nemanja
>
>
> On Fri, Sep 6, 2013 at 1:07 AM, Josh Blum  wrote:
>
>>
>>
>> On 09/05/2013 02:12 AM, Nemanja Savic wrote:
>> > HI all guys,
>> >
>> > I have 3 different packet deframers, and now I would like them to be
>> able
>> > to send a message to a certain block about correct packet reception. In
>> > order to do that I want to make some "phantom" block that will have
>> message
>> > out port.
>>
>> Are you looking to have a sort of control block that can apply
>> configuration settings to these packet deframers? Either once at
>> init-time or at runtime based on some conditions? If so, this also might
>> make sense for you:
>>
>> In GRAS, your deframers would register calls for configuring packet
>> reception:
>> https://github.com/guruofquality/gras/wiki/Codeguide#method-registration
>>
>> In the top block, when you connect flows, you can also register the
>> blocks into a tree. The control block could then find the deframers at
>> runtime and apply new settings dynamically:
>>
>> https://github.com/guruofquality/gras/wiki/Codeguide#wiki-zero-configuration
>>
>>
>> Its all GRC friendly and thread safe. You could do this with messages
>> too, it really depends what works best or makes the most sense. Anyway,
>> I have just been thinking about this kind of stuff and I wanted to share.
>>
>> -josh
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Nemanja Savić
>



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

Re: [Discuss-gnuradio] Questions on rx_ofdm example in GR 3.7.1

[Martin Braun (CEL)]

On Tue, Sep 10, 2013 at 09:58:16PM +, Monahan-Mitchell, Tim wrote:
> GR 3.7.1
> gr-digital/examples/ofdm/rx_ofdm.grc
> 
> 1. The OFDM Frame Equalizer block that is downstream from the Header Stream 
> Virtual Source block has the Length Tag Key field set to length_tag_name, yet 
> all other blocks on the diagram with that field are set to length_tag_key 
> (which is the ID of a Variable block at the top of the diagram). Is that a 
> mistake? If someone will confirm, I can file the bug.

Hm. You make me look like a total scrub.

It seems you're right. However, on my machine, length_tag_name doesn't
throw an error. I just can't see why. GRC itself should figure this is a
problem.

> 2. When I try to run this flowgraph, modified for my target's custom source 
> block, I get this error:
> FATAL: Missing a required length tag on port 0 at item #0
> thread[thread-per-block[21]: ]: Missing 
> length tag.

That's good, actually -- it means your block is getting input, which
means it's receiving headers.

To be honest, the {rx,tx}_ofdm.grc files were more of an illustration of
how the OFDM chain works. I know I've used them successfully sometime in
the past, but I've changed some stuff in between.

Using the ofdm_tx and ofdm_rx hier blocks should, however, work. Can you
try those?

My main issues when transmitting OFDM is getting a clean spectrum. OFDM
doesn't like distortions at all.

MB

> Which led me to question (1) above. However, changing that block to match the 
> others does not correct the runtime error.
> 
> I found a couple of instances of the same error listed in (2) above in the 
> mailing list, but no one replied to them.

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpDLrjuFLj9Z.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Proper block inheritance

[Marcus Müller]

Hi Nemanja,

I don't think deriving from two blocks will work; C++ allows you two 
have multiple superclasses, sure enough, but what deriving from two 
subclasses of the same base class (at least gr::block in this case) will 
give you is the so-called diamond problem. As an example let's say 
you've got something of the like:

  class Nemajas_Block public gr::awesome_block, gr::coolness_block;
with both awesome_block and coolness_block not being abstract classes 
(thus, you can create instances of awesome_block and coolness_block).
As a matter of fact, an instance of Nemajas_Block will *contain* the 
data of an awesome_block and the coolness_block, and those two each 
contain an own gr::block object.*
So there's two basic_block s that represent your instance of 
Nemajas_Block, of which only one will be connected... I haven't tried 
this, but I'd think this will lead to the GR runtime telling you to 
connect the unconnected parts.


So long answer short: No, I don't think there is an example where a 
block is derived from two isolated working blocks, because that's not a 
good idea.
There are, however, examples, where, using the virtual inheritance 
method, a block is derived from a base block and gr::block directly; 
take gr::analog::pwr_squelch_ff. Look closely where they use the virtual 
inheritance method!


I'm not quite sure however, why, for your particular problem, you can't 
take either a) the gr::blocks::file_sink way (inherit from gr::block and 
from a non-block class) or b) just put your algorithmic implementation 
into subclasses of a common (non-block) deframer_algorithm_base_class, 
and have your block hold a pointer to an arbitrary one of those, calling 
that to deframe when needed.


Hope that was helpful
Marcus

*unless inheritance was defined as ":(public|private|protected|) virtual 
superclass" all the inheritance chain down, but from looking at the 
source, I'd think this is not usually the case (especially not for 
sync_block).


Am 11.09.2013 10:41, schrieb Nemanja Savic:
Actually my question is: is there any example where some block is 
derived from two other blocks (for example from two sync blocks)?



On Tue, Sep 10, 2013 at 12:45 PM, Nemanja Savic > wrote:


Thank you Josh. At the moment I wanted to make this as simple as
possible. My idea was to make a new class(block type) and to make
my impl class inherit that class also. In that new class I would
store message port subscription and a method for sending message
that deframer received valid message. The problem is i can't
really figure out how to make a the new class that will be used
only to be inheritted by my deframer block.
Something simillar is done with filter blocks in gnuradio, there
are few classes declared in fir_filter.h and other filters inherit
that class.

Cheers,
Nemanja


On Fri, Sep 6, 2013 at 1:07 AM, Josh Blum mailto:j...@joshknows.com>> wrote:



On 09/05/2013 02:12 AM, Nemanja Savic wrote:
> HI all guys,
>
> I have 3 different packet deframers, and now I would like
them to be able
> to send a message to a certain block about correct packet
reception. In
> order to do that I want to make some "phantom" block that
will have message
> out port.

Are you looking to have a sort of control block that can apply
configuration settings to these packet deframers? Either once at
init-time or at runtime based on some conditions? If so, this
also might
make sense for you:

In GRAS, your deframers would register calls for configuring
packet
reception:
https://github.com/guruofquality/gras/wiki/Codeguide#method-registration

In the top block, when you connect flows, you can also
register the
blocks into a tree. The control block could then find the
deframers at
runtime and apply new settings dynamically:

https://github.com/guruofquality/gras/wiki/Codeguide#wiki-zero-configuration


Its all GRC friendly and thread safe. You could do this with
messages
too, it really depends what works best or makes the most
sense. Anyway,
I have just been thinking about this kind of stuff and I
wanted to share.

-josh

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




-- 
Nemanja Savic'





--
Nemanja Savic'


___
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 block inheritance

[Tom Rondeau]

On Wed, Sep 11, 2013 at 6:44 AM, Marcus Müller  wrote:
> Hi Nemanja,
>
> I don't think deriving from two blocks will work; C++ allows you two have
> multiple superclasses, sure enough, but what deriving from two subclasses of
> the same base class (at least gr::block in this case) will give you is the
> so-called diamond problem. As an example let's say you've got something of
> the like:
>   class Nemajas_Block public gr::awesome_block, gr::coolness_block;
> with both awesome_block and coolness_block not being abstract classes (thus,
> you can create instances of awesome_block and coolness_block).
> As a matter of fact, an instance of Nemajas_Block will *contain* the data of
> an awesome_block and the coolness_block, and those two each contain an own
> gr::block object.*
> So there's two basic_block s that represent your instance of Nemajas_Block,
> of which only one will be connected... I haven't tried this, but I'd think
> this will lead to the GR runtime telling you to connect the unconnected
> parts.
>
> So long answer short: No, I don't think there is an example where a block is
> derived from two isolated working blocks, because that's not a good idea.
> There are, however, examples, where, using the virtual inheritance method, a
> block is derived from a base block and gr::block directly; take
> gr::analog::pwr_squelch_ff. Look closely where they use the virtual
> inheritance method!
>
> I'm not quite sure however, why, for your particular problem, you can't take
> either a) the gr::blocks::file_sink way (inherit from gr::block and from a
> non-block class) or b) just put your algorithmic implementation into
> subclasses of a common (non-block) deframer_algorithm_base_class, and have
> your block hold a pointer to an arbitrary one of those, calling that to
> deframe when needed.
>
> Hope that was helpful
> Marcus
>
> *unless inheritance was defined as ":(public|private|protected|) virtual
> superclass" all the inheritance chain down, but from looking at the source,
> I'd think this is not usually the case (especially not for sync_block).
>
> Am 11.09.2013 10:41, schrieb Nemanja Savic:
>
> Actually my question is: is there any example where some block is derived
> from two other blocks (for example from two sync blocks)?


Nemanja,

Yes, Marcus is right, this probably isn't what you want to do. We have
some blocks that have multiple parent classes, but there is only one
path from gr::block and the other parent class has completely
different responsibilities.

What you'll probably want to do is derive a new class from
gr::sync_block (or whatever) and then derive your actual block from
your new class, overloading the functions as needed in that new class.


-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13


> On Tue, Sep 10, 2013 at 12:45 PM, Nemanja Savic  wrote:
>>
>> Thank you Josh. At the moment I wanted to make this as simple as possible.
>> My idea was to make a new class(block type) and to make my impl class
>> inherit that class also. In that new class I would store message port
>> subscription and a method for sending message that deframer received valid
>> message. The problem is i can't really figure out how to make a the new
>> class that will be used only to be inheritted by my deframer block.
>> Something simillar is done with filter blocks in gnuradio, there are few
>> classes declared in fir_filter.h and other filters inherit that class.
>>
>> Cheers,
>> Nemanja
>>
>>
>> On Fri, Sep 6, 2013 at 1:07 AM, Josh Blum  wrote:
>>>
>>>
>>>
>>> On 09/05/2013 02:12 AM, Nemanja Savic wrote:
>>> > HI all guys,
>>> >
>>> > I have 3 different packet deframers, and now I would like them to be
>>> > able
>>> > to send a message to a certain block about correct packet reception. In
>>> > order to do that I want to make some "phantom" block that will have
>>> > message
>>> > out port.
>>>
>>> Are you looking to have a sort of control block that can apply
>>> configuration settings to these packet deframers? Either once at
>>> init-time or at runtime based on some conditions? If so, this also might
>>> make sense for you:
>>>
>>> In GRAS, your deframers would register calls for configuring packet
>>> reception:
>>> https://github.com/guruofquality/gras/wiki/Codeguide#method-registration
>>>
>>> In the top block, when you connect flows, you can also register the
>>> blocks into a tree. The control block could then find the deframers at
>>> runtime and apply new settings dynamically:
>>>
>>> https://github.com/guruofquality/gras/wiki/Codeguide#wiki-zero-configuration
>>>
>>>
>>> Its all GRC friendly and thread safe. You could do this with messages
>>> too, it really depends what works best or makes the most sense. Anyway,
>>> I have just been thinking about this kind of stuff and I wanted to share.
>>>
>>> -josh
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnura

Re: [Discuss-gnuradio] flowgraph with async messaging hangs on calling wait()

[Tom Rondeau]

On Thu, Aug 22, 2013 at 10:44 PM, Mark Cottrell
 wrote:
> Hello all,
>
> I have written a sync block that takes in samples and outputs messages
> (similar to tagged_stream_to_pdu), but when writing a test for the block I
> found that when I called top_block.run(), the test never finished, as it
> appears to be hanging on the call to top_block.wait().
>
> The flow graph for the test is as follows:
> non-repeating file source -> my block -> message_debug
>
> is hanging the expected behaviour?  I can work around it by counting the
> number of items written by the file source, but it would be nice to have it
> terminate of its own accord.
>
> Thanks,
> Mark


Mark,

No, that's not expected behavior. When the file sink finishes, it
should set the DONE stage in the scheduler that should indicated to
every down stream block that they are also done.

Make sure that there isn't something happening where your block isn't
getting stuck in 'work' at this point.

-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

Re: [Discuss-gnuradio] swig smart pointer inheritance issue

[Tom Rondeau]

On Tue, Sep 10, 2013 at 7:44 PM, Rick Spanbauer  wrote:
> I'm converting some old blocks I wrote for ~3.5 gnuradio APIs to 3.7.  I
> have a block that
> calculates the MER of an incoming signal - this block is a synchronous
> decimator, and
> the make function takes a constellation_sptr and decimation rate as input:
>
> mer::sptr
> mer::make(gr::digital::constellation_sptr mod_const, int decim_rate)
> {
>   return gnuradio::get_initial_sptr (new mer_impl(mod_const,
> decim_rate));
> }
>
> Note, I'm using gr_modtool to rough out all the details of building a module
> template & associated build system scaffolding.
>
> To test, I'm trying to pass in a constellation_rect_sptr, which is a
> subclass
> of the constellation class.  The relevant code snippet is this:
>
> def make_qam_constellation(pts):
> return gr_qam.qam_constellation(constellation_points=pts,
> differential=False)
>
>
> When I pass in the constellation_rect_sptr, like this:
>
> #!/usr/bin/python
> from myqam import *
> from qam_demod import mer
> import gnuradio
>
> c = make_qam_constellation(256)
> print "type(c) = ", type(c)
> print "type(c.base()) = ", type(c.base())
> m = mer(c.base(), 4096)
>
>
> the swig type checker is throwing out the c.base() input:
>
> type(c) =  
> type(c.base()) =  
> Traceback (most recent call last):
>   File "/home/rick/Z/test_mer.py", line 9, in 
> m = mer(c.base(), 4096)
>   File "/usr/local/lib/python2.7/dist-packages/qam_demod/qam_demod_swig.py",
> line 95, in make
> return _qam_demod_swig.mer_make(*args, **kwargs)
> TypeError: in method 'mer_make', argument 1 of type
> 'gr::digital::constellation_sptr'  <
>
> Just looking at the output from the two type() statements, the types seem
> proper, though
> the dotted notation vs '::' is interesting.
>
> I notice that Ben Reynwar posted a very similar issue back in 2010.  I had
> the same problem
> at the time, and resolved it via using the .base() method, apparently just
> as he did.  I suspect
> this issue, while similar, may have something to do with 3.7's use of
> namespaces, and some
> of the complexity of SWIG's processing of namespace.  I'm a definite SWIG
> neophyte, and
> perhaps I'm just missing something obvious, or at least I hope so.
>
> Has anyone run into this issue and found a resolution?  Looking at the .i
> files in the distribution
> didn't provide much in the way of inspiration as to how to solve the
> problem.
>
> Any pointers would be greatly appreciated.
>
> Rick Spanbauer


Hi Rick,

The problem isn't with 3.7 and the namespaces. You would have had to
use the '.base()' call on that block, even in the previous 3.6 way of
doing things. It's a larger issue of inheritance and managing classes
and shared pointers. But basically, when creating a constellation
class in Python and passing it as an argument to a
function/constructor, you need to return it as a shared pointer to the
parent class (gr::digital::constellation class in this case). If you
look at your constructor, you are asking for a 'constellation_sptr' as
the class of the input. But the qam_constellation will return
something derived from constellation (like constellation_rect_sptr).
Swig doesn't think these two are the same thing and won't let you do
it. So you recast the object as a consetllation_sptr and use that,
instead.

There could be a way around this in swig-land that we haven't really
looked into, though.

-- 
Tom
Visit us at GRCon13 Oct. 1 - 4
http://www.trondeau.com/grcon13

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

Re: [Discuss-gnuradio] Porting GR-AIS to GN3.7

[Nick Foster]

Hi all,

Just to update you all, I've updated gr-ais to the GR 3.7 API this morning.
I still have a mile's worth of updates to take care of, but it compiles and
runs OK. Be sure to use a 162MHz bandpass filter as in many places nearby
FM and broadcast TV RFI will saturate even the most linear front end.

Best,
--n


On Sun, Sep 8, 2013 at 3:04 PM, Marcus Müller  wrote:

>  Hi Fokko,
>
> you have a misconception of what flowgraphs are.
> You call connect twice, connecting all the blocks twice; this can't be
> done, since every block only has one set of input ports.
> Please consider flowgraphs as mathematical digraphs: Just a set of
> vertices (blocks) and directed edges; if you connect the two same blocks
> with the exact same connect(...) call, you end up with double edges and
> blocks that have more incoming edges than they can accept, since you try to
> add the same vertices and edges to a graph that it already has.
> You even made the mistake of overwriting self.filter with the second call
> to ais_rx - are you sure you know what you're coding here?
> Try with only one ais_rx; I don't see why that should not work. When you
> want to construct the second branch of your flowgraph, you need to
> duplicate all the vertices (blocks) first, so that they can function on
> their own.
>
>
> On 09/08/2013 11:47 PM, Driesprong, Fokko wrote:
>
>  Hello Marcus,
>
>  I am sorry for the scare information. Please let me elaborate.
>
>  The most recent version is pushed in my fork of the repository of gr-ais:
> https://github.com/Fokko/gr-ais/blob/master/apps/ais_rx.py
>
>  I have digged in the generated python swig code, but the type of the 
> osmosdr_source_c_impl
> and freq_xlating_fir_filter_ccf blocks seem the be gr_block, which should
> be accepted. It doesn't reach  the ais.demod block, it crashes right away.
>
>   Kind regards
> ,
> ing. Fokko Driesprong
>
>
> 2013/9/8 Marcus Müller 
>
>>  Hi Fokko,
>> The information you're offering is a little sparse.
>> Do you have the source code (at leas ais_rx.py in your current version)
>> somewhere?
>>
>>
>>
>> On 09/08/2013 09:25 PM, Driesprong, Fokko wrote:
>>
>>  He guys,
>>
>>  I have managed to fix all the swig error's, but now I have some issue's
>> with python. Maybe you guys have run into it earlier?
>>
>>  All the SWIG objects and Python classes are available. But something
>> might have changed in the connect method of the top_block.
>>
>>  Traceback (most recent call last):
>>   File "/usr/local/bin/ais_rx.py", line 216, in 
>> main()
>>   File "/usr/local/bin/ais_rx.py", line 169, in main
>> tb = my_top_block(options, queue)
>>   File "/usr/local/bin/ais_rx.py", line 79, in __init__
>> self.ais_rx(self.u, 161.975e6 - 162.0e6, "A", options, queue);
>>   File "/usr/local/bin/ais_rx.py", line 121, in ais_rx
>> self.connect(self.u, self.filter, self.demod, self.unstuff,
>> self.start_correlator, self.stop_correlator, self.parse)
>>File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line
>> 131, in connect
>> self._connect(points[i-1], points[i])
>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
>> line 143, in _connect
>> dst_block.to_basic_block(), dst_port)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
>> 4130, in primitive_connect
>>  return _runtime_swig.top_block_sptr_primitive_connect(self, *args)
>> NotImplementedError: Wrong number or type of arguments for overloaded
>> function 'top_block_sptr_primitive_connect'.
>>   Possible C/C++ prototypes are:
>> gr::hier_block2::connect(gr::basic_block_sptr)
>>
>> gr::hier_block2::connect(gr::basic_block_sptr,int,gr::basic_block_sptr,int)
>>
>>  Some blocks are getting chained by the connect method. It crashes on
>> the following blocks:
>>   -> > freq_xlating_fir_filter_ccf (1)>
>>  These two blocks should pass complex numbers.
>>
>>  Anyone any idea? I am confused because the osmosdr and freq_xlanting
>> objects shipped with osmosdr/gnuradio.
>>  
>> Kind regards,
>> ing. Fokko Driesprong
>>
>>
>> 2013/9/5 Martin Braun (CEL) 
>>
>>> On Thu, Sep 05, 2013 at 12:20:17AM +0200, Driesprong, Fokko wrote:
>>> > He Guys,
>>> >
>>> > Thank you for the prompt replies, in special Nick Foster for the
>>> reply, I am
>>> > very thankful for the gr-ais package! :)
>>> >
>>> > Currently I am working with the modtool. I didn't know it's existence.
>>> A very
>>> > helpful tool.
>>>
>>>  Fokko,
>>>
>>> You really should read the tutorials on how to work with out-of-tree
>>> modules if you want to work with out-of-tree modules:
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
>>>
>>> MB
>>>
>>> --
>>> Karlsruhe Institute of Technology (KIT)
>>> Communications Engineering Lab (CEL)
>>>
>>> Dipl.-Ing. Martin Braun
>>> Research Associate
>>>
>>> Kaiserstraße 12
>>> Building 05.01
>>> 76131 Karlsruhe
>>>
>>> Phone: +49 721 608-43790 <%2B49%20721%20608-43790>
>>>  Fax: +49 721 608-46071

Re: [Discuss-gnuradio] flowgraph with async messaging hangs on calling wait()

[Mark Cottrell]

Hi Tom,

I spent a while playing around with this, including adding a bunch of debug
output to tpb_thread_body::tpb_thread_body, and found that when a block is
done, the DONE state should propagate through the flow graph as
tpb_detail::notify_neighbours is called (as I'm sure you're aware).  The
problem is, tpb_detail::notify_neighbours only notifies blocks that that
have input or output buffers (which as far as I can tell, blocks with only
message inputs or outputs don't), so blocks like message_debug will block
on tpb_detail::input_cond forever (on line 110 of tpb_thread_body.cc) and
can never be notified (as it has no input buffers, so notify downstream
does nothing).

Johnathan contacted me r.e. this and I sent him a patch which fixed the
problem for me (attached to this message), but I don't think he has had
time to look at it yet.  The gist of it is that it uses pmt::PMT_EOF to
indicate that message blocks should transition to done and notify
neighbours.

Please feel free to correct me on any of what I said above, this was my
first foray into the scheduler so I could have it completely wrong.

Thanks,
Mark


On Thu, Sep 12, 2013 at 3:56 AM, Tom Rondeau  wrote:

> On Thu, Aug 22, 2013 at 10:44 PM, Mark Cottrell
>  wrote:
> > Hello all,
> >
> > I have written a sync block that takes in samples and outputs messages
> > (similar to tagged_stream_to_pdu), but when writing a test for the block
> I
> > found that when I called top_block.run(), the test never finished, as it
> > appears to be hanging on the call to top_block.wait().
> >
> > The flow graph for the test is as follows:
> > non-repeating file source -> my block -> message_debug
> >
> > is hanging the expected behaviour?  I can work around it by counting the
> > number of items written by the file source, but it would be nice to have
> it
> > terminate of its own accord.
> >
> > Thanks,
> > Mark
>
>
> Mark,
>
> No, that's not expected behavior. When the file sink finishes, it
> should set the DONE stage in the scheduler that should indicated to
> every down stream block that they are also done.
>
> Make sure that there isn't something happening where your block isn't
> getting stuck in 'work' at this point.
>
> --
> Tom
> Visit us at GRCon13 Oct. 1 - 4
> http://www.trondeau.com/grcon13
>

-- 

--
This email, including any attachments, is only for the intended recipient. 
It is subject to copyright, is confidential and may be the subject of legal 
or other privilege, none of which is waived or lost by reason of this 
transmission.
If you are not an intended recipient, you may not use, disseminate, 
distribute or reproduce such email, any attachments, or any part thereof. 
If you have received a message in error, please notify the sender 
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or 
corrupted during transmission nor can we guarantee that any email or any 
attachments are free from computer viruses or other conditions which may 
damage or interfere with recipient data, hardware or software. The 
recipient relies upon its own procedures and assumes all risk of use and of 
opening any attachments.
--


async_message_stopping3.patch
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Error Compiling Multimon

[John]

I am running gnuradio 3.7.0 and been using grc with good results. When I 
try to make Multimon (recent trunk) I get the following errors:


trunk # make
/usr/local/bin/grcc -d . multimode.grc
>>> Error: Block key "gr_complex_to_real" not found in Platform - 
grc(GNU Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform
>>> Error: Block key "gr_keep_one_in_n" not found in Platform - grc(GNU 
Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform
>>> Error: Block key "gr_feedforward_agc_cc" not found in Platform - 
grc(GNU Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform
>>> Error: Block key "gr_keep_one_in_n" not found in Platform - grc(GNU 
Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform
>>> Error: Block key "gr_keep_one_in_n" not found in Platform - grc(GNU 
Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform
>>> Error: Block key "gr_fft_filter_xxx" not found in Platform - 
grc(GNU Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform

[continuation of errors snipped]

Any ideas as to how to address?


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

Re: [Discuss-gnuradio] Error Compiling Multimon

[Marcus D. Leech]

On 09/11/2013 08:51 PM, John wrote:
I am running gnuradio 3.7.0 and been using grc with good results. When 
I try to make Multimon (recent trunk) I get the following errors:


trunk # make
/usr/local/bin/grcc -d . multimode.grc
>>> Error: Block key "gr_complex_to_real" not found in Platform - 
grc(GNU Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform
>>> Error: Block key "gr_keep_one_in_n" not found in Platform - 
grc(GNU Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform
>>> Error: Block key "gr_feedforward_agc_cc" not found in Platform - 
grc(GNU Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform
>>> Error: Block key "gr_keep_one_in_n" not found in Platform - 
grc(GNU Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform
>>> Error: Block key "gr_keep_one_in_n" not found in Platform - 
grc(GNU Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform
>>> Error: Block key "gr_fft_filter_xxx" not found in Platform - 
grc(GNU Radio Companion)

Traceback (most recent call last):
  File "/usr/local/bin/grcc", line 25, in 
from grc.python.Platform import Platform
ImportError: No module named grc.python.Platform

[continuation of errors snipped]

Any ideas as to how to address?


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


Multimode hasn't been converted to 3.7 yet.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

Re: [Discuss-gnuradio] Error Compiling Multimon

[John]

On 09/11/13 20:02, Marcus D. Leech wrote:


Multimode hasn't been converted to 3.7 yet.


Thanks!

I have heard good things about how it handles nbfm and wanted to compare 
it to what I have hacked together.  I have been reviewing examples of 
nbfm demodulation and would appreciate any pointers to "ideal" approach 
in this area.


John


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

Re: [Discuss-gnuradio] Error Compiling Multimon

[Marcus D. Leech]

On 09/11/2013 09:12 PM, John wrote:

On 09/11/13 20:02, Marcus D. Leech wrote:


Multimode hasn't been converted to 3.7 yet.


Thanks!

I have heard good things about how it handles nbfm and wanted to 
compare it to what I have hacked together.  I have been reviewing 
examples of nbfm demodulation and would appreciate any pointers to 
"ideal" approach in this area.


John


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
You can pull the .grc into gnuradio-companion, although that might not 
work out that well, since the block-names changed across 3.7.




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

Re: [Discuss-gnuradio] Error Compiling Multimon

[John]

On 09/11/13 20:14, Marcus D. Leech wrote:


You can pull the .grc into gnuradio-companion, although that might not
work out that well, since the block-names changed across 3.7.


When I do this a large percentage of blocks/connectors do mot render.

In a separate thread I can present what I have so far to get some input.



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