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 11:37 Uhr
> Von: "Müller, Marcus (CEL)" <address@hidden>
> An: "address@hidden" <address@hidden>
> Cc: "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 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.

I understand, thanks for emphasizing 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.
> 
> 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.


Here is where I am unsure of WHY only over message handlers? I can also control 
GPIO via timed commands, right?

So my idea would have been to use timed commands to switch the GPIO ports via 
timed commands exactly at a specified sample time in future...



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

This was a great response, thanks again!

While I had some good experience with code in open source projects (e.g. xpra) 
I had some frustrating experiences where it was pretty hard to get code into 
mainstream.
Fair enough, in this case the value for the common good is fairly obvious.
(Also I can understand why it is often not so easy to get code integrated 
because it has to be tested appropriately etc)

So, I will take your suggestion of adding/modifying the message handlers in 
gr-uhd and try to get my changes integrated.

Best,
Luke