We are upgrading some of our custom blocks for 3.7 and have run into a
snag. Our 3.6 era blocks included one that PTTed an external amplifier
based on stream tags. The IO was generated from the extra GPIO
available
on the WBX. One of the inputs to the block was a reference to the USRP
sink downstream in the FG. The block then calls the necessary methods
to
enable and disable the GPIO. Everything worked nicely, but when we
ported
our blocks to 3.87, there seemed to be a problem with this. I did not
personally do the testing, so I don’t have the exact error, but I can
probably re-create it given some time.
I started the porting of the blocks myself and did notice that getting
the
pointer to a USRP object had changed. But the blocks built without
error
when updated appropriately.
Is there anything in principle that would prevent this from working in
3.7?
Or, is there a better approach to controlling the WBX GPIO based on
stream
tags that we should consider?
I apologize for the vagueness on the actual error. I’ll try to
reproduce
it myself in the meantime.
I can probably post the code for the PTT-controlling block if that would
be
any help.
Very Respectfully,
Dan CaJacob
On Sat, Dec 21, 2013 at 6:29 PM, Dan CaJacob [email protected]
wrote:
I started the porting of the blocks myself and did notice that getting the
I can probably post the code for the PTT-controlling block if that would be
any help.
Very Respectfully,
Dan CaJacob
Hi Dan,
Sorry for the silence. Partly due to the holidays, partly due to me
not having a good answer for you. Most likely, your problem is related
in some way to the public/private implementations that we are
enforcing in 3.7 now. If you have more information or have figured
this out, let us know and we can see where we need to go from here.
Tom
Thanks Tom,
No problem. I hope you and the rest of the community had relaxing
holidays! I hope to have some better info for you by tomorrow, if not
before.
Another way to look at this is: does it make sense to keep doing things
this way? Is there a better way to reference the downstream USRP and
toggle the IO? I could imagine an async message stream or specific
stream-tags, but both would probably require changes to the actual UHD
sinks. I’m not sure our use case is generic enough to warrant that.
Very Respectfully,
Dan CaJacob
Hey Tom,
Here’s some more detail into our problem.
When running the flowgraph, we get the following error:
File “/usr/local/lib/python2.7/dist-packages/sq/sq_swig.py”, line 679,
in
make
return _sq_swig.usrp_pa_control_make(*args, **kwargs)
TypeError: in method ‘usrp_pa_control_make’, argument 1 of type
‘gr::uhd::usrp_sink::sptr’
When setting up a FG, the pa-control block accepts a reference to the
downstream UHD sink.
I have attached the specific block source.
Thanks!
Very Respectfully,
Dan CaJacob
On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob [email protected]
wrote:
‘gr::uhd::usrp_sink::sptr’
Dan CaJacob
It’s probably the difference between a gr::uhd::usrp_sink and a
gr::uhd::usrp_sink_impl.
A safer way to handle this might be to use the new(ish) block_registry
that we implemented to handle the message passing infrastructure. You
can get a basic_block_sptr from global_block_registry.block_lookup;
you should then be able to cast this to a usrp_sink_sptr. You’ll pass
it a PMT symbol containing the alias name of the UHD sink itself.
Take a look at basic_block.cc for a look at how the
global_block_registry is used. I’ve not done exactly this before, so
it might not go completely smoothly, and I’d be interested in your
experience.
In general, this sounds like something more appropriately implemented
as a message, though, but that would mean changing the gr-uhd code.
Having a message handler for the GPIO stuff would probably be useful
if done generically enough.
Tom
Hey Tom,
We’ve been working on this, but we ran into a snag. We couldn’t seem to
look up the usrp sink block’s key. Other blocks could be looked up with
the keys we expected, just not the uhd sink. I just un-commented a
print
statement in block_registry.cc so that we could see how each block
actually
gets registered, built it and ran a simple flowgraph.
The flowgraph is just a signal source -> throttle -> uhd sink. Here’s
the
output:
register_symbolic_name: top_block0
register_symbolic_name: gr uhd usrp sink0
register_symbolic_name: throttle0
register_symbolic_name: sig_source_c0
The UHD sink block gets an unexpected “gr” pre-pended and the
underscores
are replaced with spaces.
We are going to attempt our OOT blocks with this in mind, but I thought
I’d
give you a heads up on this behavior.
Thanks!
Very Respectfully,
Dan CaJacob
On Tue, Jan 14, 2014 at 9:09 PM, Dan CaJacob [email protected]
wrote:
Hey Tom,
The block worked fine with the right symblic name passed! The amp is
getting PTTed now in 3.7 Thanks for your help with this!
Great!
It still seems weird that the USRP Sink symbolic name was formatted
differently, though.
Hm, yes, that is odd. Would you open a ticket about it? Low priority
and a change in behavior that might have to wait for 3.8.
Also, would it be possible to automatically register symbolic name aliases
that are based on the block names created in GRC/python? That would make
the lookup a little more obvious.
Which names, exactly? Are you talking about the variable name itself?
For that, there’s no way for the block to know that information. On
the other hand, you can actually set the block alias yourself so you
don’t have to ask/guess/know what it is in advance using the
set_block_alias(string) function.
Tom
On Fri, Jan 17, 2014 at 5:40 PM, Tom R. [email protected] wrote:
It still seems weird that the USRP Sink symbolic name was formatted
differently, though.
Hm, yes, that is odd. Would you open a ticket about it? Low priority
and a change in behavior that might have to wait for 3.8.
Will do!
Also, would it be possible to automatically register symbolic name
aliases
that are based on the block names created in GRC/python? That would make
the lookup a little more obvious.
Which names, exactly? Are you talking about the variable name itself?
I’m not sure what the nomenclature is, but I am talking about the name
that
is auto-generated by GRC when a block is placed, but which can be
modified
by the user. This name becomes the blocks object name in the python
file.
For that, there’s no way for the block to know that information. On
the other hand, you can actually set the block alias yourself so you
don’t have to ask/guess/know what it is in advance using the
set_block_alias(string) function.
I am aware of the alias function. The question is - can we use that
somewhere so that the block automatically gets aliased as the name the
block instance is given in GRC? Probably, this needs to live in GRC
itself, specifically in the code that generates a python file from the
FG.
Does that make sense? I assume the alias function is a method of the
block objects in python.
Thanks for your help with this, Tom! I’m really excited about 3.7! I’m
already using it on one of my flatsat setups.
Hey Tom,
The block worked fine with the right symblic name passed! The amp is
getting PTTed now in 3.7 Thanks for your help with this!
It still seems weird that the USRP Sink symbolic name was formatted
differently, though.
Also, would it be possible to automatically register symbolic name
aliases
that are based on the block names created in GRC/python? That would
make
the lookup a little more obvious.
Thanks!
Very Respectfully,
Dan CaJacob