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:
- 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
- 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.
- 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
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 | M +385 95 8745 900 | F +385 1 485 2824
W amphinicy.com
From: "usrp-users" <address@hidden>
To: "usrp-users" <address@hidden>
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
> address@hidden
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
address@hidden
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Visit us on Toulouse Space Show 2016 – booth E35