Using GNU Radio Framework in my application

GNU Radio
1

Dear All:

I need to have a RF link between two E310.
My application is written is C++/ using Qt framework.
I already made the GRC diagram, but grc generates python codes.
Is there any source to help me integrate that code to my application.

Thanks,
jmod

2

Hi Jalil,

unless you install Qt on it and attach a screen to it, it will be hard
to use a Qt application on your E310.
Basically, the E310 is just a linux computer on an embedded device,
which means you can do the same as on your fully fledged Linux PC – the
question is if you should: The E310 is an embedded device with a
energy-efficient ARM CPU, that is in no way optimal for graphical front
ends, so visualizing some data on the E310 might be more stressful to
the CPU of the E310 than it is for the CPU of your PC; that together
with the fact that the USRP’s CPU is much slower might make your
application unusable; it really depends.

You say

I already made the GRC diagram, but grc generates python codes.
So, yes, that is how GRC works.
There’s multiple options on how you can integrate the resulting flow
graph into your application:

  • You could re-implement that flow graph in C++ instead of python. The
    functions are all the same (top_block.connect etc); then you could use
    the message_sink / _source to get information in and out of GNU Radio
    via queues.
  • You could use different sinks and sources to get your data in and out
    of your flow graph: For example, you can use the file sink and source
    with a Unix FIFO instead of a normal file, and write/read that FIFO from
    within your application. You can use ZeroMQ sinks and sources with
    “ipc://” URLs, so your Qt Application and your GNU Radio flowgraph would
    run in different processes, but still be able to communicate.
  • You could write a GNU Radio C++ block that wraps your application;
    that would be about as elegant as the message_sink/_source approach, but
    I’d ask you to realize that it’s very important to make the Qt
    Application work in the python/GRC-provided QtApplication instance, and
    pass the data from GNU Radio to your application in a
    multithreading-safe manner (ie. the block has to be able to run
    asynchronously to your GUI threads)
  • You could run your Qt Application on a PC that already has a screen,
    and use network sinks and sources (TCP, UDP, or, I consider this to be
    superior, the ZeroMQ blocks), to transport the things you want to get
    into your application over network. Notice that it will be very hard to
    get high rates out of the USRP, but visualizing data at these high rates
    will probably be even harder to do on the E310.

Best regards,
Marcus

Best regards,
Marcus

3

Hi Jalil,
please always make sure to reply to the mailing list rather than to
individual persons :slight_smile:

The application is not GUI based, it just utilizes the Signal/Slot
architecture of Qt framework.
That can be quite handy, but still requires Qt to be on the target
platform. Maybe Philip can comment on the support of Qt in the different
images we have for the E310.

I intend to make a QThread object, to run the GR scheduler in separate
thread.
The GR scheduler itself is very multithreaded :slight_smile:
every block runs in its own thread.
Your approach of starting the flowgraph in its own QThread seems sound.
For now, I just need to send/receive some one-byte commands, so I
think the message sink/source would be good for this stage.
Yes, since you are in the same process, that should work.
What type of modulation/demodulation is recommended for this environment?
That’s a question hard to answer without knowing a lot more. Generally,
go for something simple, robust, for a start.
However, I don’t know your drone system. Maybe they move very fast
relative to each other, so you need to build receivers that are very
resistant to Doppler; maybe you don’t. Doppler depends (aside from
relative speed) on carrier frequency, so what works on 75MHz doesn’t
have to work on 5GHz. What carrier frequency you use depends on what
antennas you want to use, which depends on the mechanical/aeronautical
aspects of your design.
Maybe you have something with large metal rotors; that can look very
disturbing in the spectrum (doppler due to reflection on fast moving
blades + choppy transmissions if the blades are somewhere in the signal
path). Maybe your drones are a few meters away from each other, allowing
you to use the 2.4/5GHz ISM band, maybe they are miles apart, calling
for lower frequencies due to lower attenuation.
I’d still try with one of the PSK modulators in GNU Radio, and maybe a
simple preamble correlation after that to allow commands to be detected.
But what you’re asking is basically one of the central questions of
digital communications, and it’s not universally answered.

Best regards,
Marcus