For most applications, I would suggest building a python native GNU Radio message block to interact with a graph -- and *not* jumping to thrift or zmq without a reason -- bridging messages and streams over zmq IPC is doable but more work -- in this case PMT serialization and JSON are the most used message formats - valid reasons might be if gnu radio is secondary to your app and you want a large layer of separation, process separation, or remote message passing -Tim
On 12/27/2015 11:42 AM, Marcus Müller wrote: > 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 > descriptor. >> 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, > Marcus > > [1] http://gnuradio.org/doc/doxygen/page_msg_passing.html > [2] > https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Programming_Topics#53-Message-Passing > [3] http://gnuradio.org/doc/doxygen/page_ctrlport.html > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
