What kind of parameters would that be? Most of the "value keeping" for
things like gain, frequency... are done purely inside the UHD host-side
driver, so notifying your GUI of whatever action your GNU Radio flow
graph does would probably do the trick just as well!
I'm including the discuss-gnuradio list here; I think the discussion is
going to go more into a GNU Radio-specific area; feel free to follow up
on whatever mailing list *you* deem more approporiate
Going through things in my head, there's two to three options:
1. The web service kind of thing: XMLRPC. I think there should be an
example within GNU Radio. Together with a function probe, this might
be totally sufficient for your use case. I remember Balint Seeber
has hacked together a quick restaurant pager highjacking GUI [1]
using XMLRPC
2. The most universal way of doing this is probably going through the
controlport RPC facility that GNU Radio has – you should be able to
add RPC variables for whatever you want to monitor. Downside: I
think this is not a python thing yet, so you'd have to meddle with
GNU Radio C++ source code. Out of the box, I think gr-uhd supports
sample rate (and not much else). Others on the discuss-gnuradio
mailing list might be better informed than me.
3. Notification based updating of the GUI: Make your GUI listen to
ZeroMQ packets. Whenever you change something on the USRP sink or
source, send a message to a ZeroMQ message sink – for examples, you
could implement your GUIs all as ZeroMQ subscriber sockets. All the
GUIs would then subscribe to one ZeroMQ PUB Message sink, getting
notified when your application sends a message to that. On the GUI's
side, use GNU Radio's PMT library (available in both C++ and Python,
but should be easily wrappable to C ABI, and hence, available pretty
much everywhere¹) to decode the messages.
Best regards,
Marcus
[1] https://www.youtube.com/watch?v=x3UUazj0tkg
¹ I'm not even sure why GR doesn't do that. The whole PMT tree feels
like it's old-school C style with its whole "pmt_t pmt_operation(pmt_t,
parameters);" API, but as far as I can tell, that is not exported as a C
API.
On 28.06.2016 16:40, Tihomir Mescic wrote:
> Thanks for the advice. Do you maybe have a link to an example of how
> would one create a server withing GNU radio?
>
> As for the use case, I want to create a service that would expose
> parameters of the the device during processing (something similar to
> SNMP) so that I can display them to the user during processing (GNU
> radio would be running headless in the background).
>
>
> *Tihomir Meščić
> *Senior Software Engineer
>
> Amphinicy Technologies
> Nothing is Impossible.®
>
> Zagreb Office
> Trg Nikole Subica Zrinskog 15 | HR-10000 Zagreb | Croatia
> T +385 1 6407 831 <callto:+385%201%206407%20831> | M +385 95 8745 900
> <callto:+385%2095%208745%20900> | F +385 1 485 2824
> <callto:+385%201%20485%202824>
> W amphinicy.com
>
>
> ------------------------------------------------------------------------
> *From: *"usrp-users" <usrp-us...@lists.ettus.com>
> *To: *"usrp-users" <usrp-us...@lists.ettus.com>
> *Sent: *Tuesday, June 28, 2016 4:28:40 PM
> *Subject: *Re: [USRP-users] Multiple parallel connections to x310
>
> Hello Tihomir,
>
> no, USRP access is inherently exclusive, because there's no safe way to
> concurrently access the ressources on the X310.
>
> What you can (probably should) do is write a minimal server that runs
> within the GNU Radio application and gives remote access to the USRP
> functionality you want.
>
> Could you elaborate on what you need to do while GNU Radio is streaming
> samples from/to the USRP?
>
>
> Best regards,
>
> Marcus
>
>
> On 28.06.2016 15:33, Tihomir Mescic via USRP-users wrote:
> > Hi everyone,
> >
> > I am using GNU radio to read and process data from the Ettus x310.
> What I would like to do now, is to be able to access the device (using
> the UHD C API) from another process *while* GNU radio is using it. I
> know that this is not possible out of the box, but I am interested is
> a workaround? What about using the second Ethernet port (I am
> currently only using the first Ethernet port)?
> >
> > Tihomir Mescic
> > Visit us on Toulouse Space Show 2016 at booth E35
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > usrp-us...@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> Visit Amphinicy Technologies on Toulouse Space show 2016 - booth E35
> Visit us on Toulouse Space Show 2016 – booth E35
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
