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

[CEL]

Hi Lukas,
On Fri, 2020-02-21 at 16:17 +0100, Lukas Haase wrote:
> 
> 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.

Well, It's really not that I disagree! But: you do realize this is a
FOSS project mainly at the mercy of volunteers?
Sure, there's a company with interest in gr-uhd, but even they are
resource-limited and can't guess your use case. So, you're doing the
right thing here, discussing your use case and proposing change.

> > 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.

Good thing that you can modify the source code of GNU Radio :)

> I am not sure if I understand exactly. So GPIO should only be used with 
> messages or NOT with messages?

Only through message handlers.

> If with messages, why is there no way to send GPIO messages to the USRP 
> blocks?

Because nobody implemented it! That's why I recommended you do that :)

> 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.

Ah, that sounds even less like you'd want to call a function on the
block: That'd be totally unrelated to the signal flow, and might come
too early, or too late.

For the USRP sink, the right way to work here would be using a stream
tag (but again, you'd want to add a stream tag handler to the
usrp_sink's work() then); for the USRP source, yeah, send a message
with a timed command, and start the stream with a start time, so that
you know when, relative to the first received sample, things will
happen.

> > 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.

Sorry!

> This unfortunately results in an unmaintable code base that I wanted to avoid 
> at all costs.

?!
I don't see why – upstream that change, it's universally helpful, and
it appears in our releases pretty quickly.

> I am wondering if I am the first person in the world needing to
access more than just basic functionality.

Maybe!

> And this is my first project in gnuradio, so I am a beginner.

I can see how this is a bit bad :(

Let me think about this: Maybe we can circumvent the need for you to
modify GNU Radio.
I have never done so, but in principle, you can register message
handlers not only for yourself (if you're a GNU Radio block), but on
other blocks just as well.

So, we could try to:

1. Write a function that takes the arguments you need to properly call
things on the USRP block from a PMT and a USRP block
(say, gpio_at_time(block_handle, PMT))

2. add a new message port "special", i.e.
block_id->message_port_register_in(pmt::mp("special"));

3. register a new message handler on the USRP block, i.e.

block_handle->set_msg_handler(
                  pmt::mp("special"),
                  [block_handle](pmt::pmt_t msg)
                                { 
                                  gpio_at_time(block_handle, msg);
                                }
                  );

To explain:
3. generates a lambda that calls your setter function, but GNU Radio
makes sure that the function is only ever called when no other
functions in the GNU Radio block execution is trying to use the USRP.

Now, obviously, that doesn't get rid of the need to pass a block
handle, but it'd solve the threading issue here.

To solve the handle issue:

* Write a hier_block that *contains* the USRP block you want to use –
now you know what the block handle is in your hier block's constructor
* do 1.-3. in there
* use that hier block in your overall flow graph instead of the USRP
block itself.

I hope that sounds less crazy than trying to change the UHD blocks
themselves.

Personally, I'd of course prefer a good upstreamed solution, but I can
see how that might not be feasible at this point.


Best regards,
Marcus

smime.p7s
Description: S/MIME cryptographic signature