[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] asynchronous messaging frameworks

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] asynchronous messaging frameworks
Date: Sun, 27 Dec 2015 17:42:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

Hi Daniel,

On 12/27/2015 03:10 PM, Daniel Pocock wrote:
> Is there any generic documentation about the use of GNU Radio with
> asynchronous messaging and integration frameworks or would it be useful
> to build up a wiki page about the topic?
There's internal asynq messaging in GR (the "light grey" connections
between blocks); message passing is relatively well-documented in the
doxygen [1], and there's a bit on it in the guided tutorials[2].
As everything, it could be better documented :) Documentation patches
for the doxygen are always as welcome as wiki extensions.
For the RPC beneath the controlport interface[3] we use Apache Thrift.
There's also the XMLRPC, but I'm not experienced with that. I hear you
can develop web-style applications with it easily.

For network and IPC, we basically support zeroMQ, UDP, and of course
simple Unix mechanisms like FIFOs and everything that can get a file
> I came across some pages referring to ZeroMQ support[1], I was also
> curious about support for Qpid Proton[2] and other AMQP[3] systems.

> There were some comments elsewhere about people using OpenMAMA[4]
> (designed for low-latency financial messaging) to transport radar data,
> among other things.
> Another possibility that comes to mind is D-Bus[5] support, either at a
> low-level (other desktop applications controlling the radio or receiving
> data from the radio) or high level (e.g. a Telepathy Connection
> Manager[6] implementing one of the various digital messaging
> solutions[7] or even Morse code)
I personally don't know of any implementation of adapters for any of
these; however, writing e.g. a dbus to message passing adapter won't be
too hard. In fact, it should be but a couple of lines of python, unless
things get overly involved with business logic etc.

For your App-to-GNU Radio adaption, ZeroMQ pretty much sounds like a
perfect match. It's leightweight, multi-language, easy to learn.
> This could be a good way to further empower people familiar with other
> systems, e.g. there was some question a while ago about how gpredict
> could integrate with GNU Radio for real-time doppler shift
> correction[8].  Doing such things over an asynchronous message bus leads
> to looser coupling, so it is easier to swap components for
> test/simulation or add more components to the architecture.
I really cannot stress enough how right you are: GNU Radio definitely
needs to get as "usable" from an application developer's perspective.
Easy solutions for sending information to and from applications are most
of the times sufficient; ZeroMQ definitely has become my tool of choice
for that. However, at some level of complexity, you start to implement
remote procedure calling.
RPC, however, isn't easy. You might really want to stick with
controlport, which is deeply integrated in GNU Radio, and its thrift
foundation, if you have the choice.

Best regards,

[1] http://gnuradio.org/doc/doxygen/page_msg_passing.html
[3] http://gnuradio.org/doc/doxygen/page_ctrlport.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]