Re: Python module: object as a reference (just as "Block ID" in "Function Probe" block)

[Lukas Haase]

Hi Marcus,

> Gesendet: Freitag, 21. Februar 2020 um 03:44 Uhr
> Von: "Müller, Marcus (CEL)" <address@hidden>
> An: "address@hidden" <address@hidden>, "address@hidden" <address@hidden>
> Betreff: Re: Python module: object as a reference (just as "Block ID" in 
> "Function Probe" block)
>
> Hi Lukas,
> 
> On Fri, 2020-02-21 at 00:24 +0100, Lukas Haase wrote:
> > These blocks support a message interface but unfortunately this is pretty 
> > useless except for the simplest applications (I need to control advanced 
> > tuning with timed commands, GPIO ports etc).
> 
> That's very much supported, far as I know: you send PMT dictionaries
> containing a time spec and the setting you want to do. 
> That is, if your USRP supports that, you can do it with GNU Radio.

I think that's another discussion, but, I don't think so.
I looked into the code of gr-uhd already it it's really just for "toy examples".

Example 1:

tune_request: Like a uhd::tune_request_t, but always uses POLICY_AUTO. This is 
a pair, composed of (target_frequency, lo_offset)

(see https://www.gnuradio.org/doc/doxygen/page_uhd.html)

Example 2: How do select integer-n mode?

tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))
tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer", 
"int_n_step=1000e3",]))

If this message interface should be useful at all, it needs to support all the 
functions that the API provides. Otherwise I start writing a nice architecture 
using messages and shortly after I realize I need to through everything away 
because the interface just doesn't expose the functions needed.

> > Hence I need to call the methods of these objects directly but I need a 
> > reference to them inside my custom block.
> 
> From a software architecture point of view: no, you don't :) 

Hmm, I can see why, yes.

> > Within my python block I cannot reference the parent blocks, hence I need 
> > to pass a reference to these two objects via the constructor (and 
> > parameters).
> > Basically I want to do the same as parameter "Block ID" from the block 
> > "Function Probe" does.
> > 
> > What is the best way to implement this?
> 
> Not implementing this at all, since the resulting flow graph makes
> assumptions on the order of initialization, and other things that you
> really shouldn't depend on, since they can't be assumed.

Well, at least I could check within my functions if the objects are properly 
initialized (as I expected).

> > Param - Usrp Source Block(usrp_source_block):
> >     Value "uhd_usrp_sink_0" cannot be evaluated:
> >     name 'uhd_usrp_sink_0' is not defined
> 
> Exactly this! 
> 
> So, really, if this is about setting the gain as a timed command, then
> follow [1] and use a "time" field.

No, see above. Either I don't see it or this interface has not been made for 
any more advanced application.

> For GPIO, you're right, there's no message handler for that. But as far
> as I'm concerned, you *really* don't want to set GPIO things without a
> message handler, as this could lead to undefined device states if
> another thread (here, the one running the work() of your
> uhd_usrp_source block, or a message handler) is manipulating device
> state. Generally, on classic gen<=3 USRPs, the command queue is head-
> blocked – and thus, you'll need to send in all commands in order.
> Therefore, a call to get something (e.g. the state of GPIOs) after a
> timed command call might then block, and things get logically
> complicated pretty quickly.

I am not sure if I understand exactly. So GPIO should only be used with 
messages or NOT with messages?
If with messages, why is there no way to send GPIO messages to the USRP blocks?

Let me briefly tell why these GPIOs are important: In order for them to make 
sense, I need to synchronize them precisely to my signal flow. For example, I 
want to switch something exactly at sample n=10000. Otherwise I could just use 
a random I/O board connected in parallel with the USRP. In fact, I just need to 
execute something like

self.uhd_usrp_x310.set_gpio_attr("FP0", "OUT", 1, 1 << 4)

as a timed command. Just as returning the LO.

> Now, how to solve your issue?
> 
> Honestly: At this point, I'd recommend just patching the
> uhd_block_impl.cc, probably. Look for `REGISTER_CMD_HANLDER` and
> imitate that line.

If this is really the only way, I teeth-gnashingly proceed with that.
This unfortunately results in an unmaintable code base that I wanted to avoid 
at all costs.
I use my project at various different machines, by various people, have the grc 
files in git. OOT modules make things already complicated but patching gnuradio 
or usrp itself is even more painful.

I am wondering if I am the first person in the world needing to access more 
than just basic functionality.
And this is my first project in gnuradio, so I am a beginner.

So either I am doing things wrong (in which case I am happy to discuss the 
right way, based on what I wrote above) or gnuradio/uhd/usrp-x310 is not 
powerful enough for my first gnuradio application (which is hard to believe).


In any regard thanks for your advice!

Best,
Luke