Hi Marcus,
> Gesendet: Freitag, 21. Februar 2020 um 11:37 Uhr
> Von: "Müller, Marcus (CEL)" <muel...@kit.edu>
> An: "lukasha...@gmx.at" <lukasha...@gmx.at>
> Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
> 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
