We just received our brand new E310 and we are wondering what is the
“right” approach for developing applications to be run on it.
In fact we are a bit used to working with a B220 but that operating
condition was a different: C(++) code and/or GNURadio (with the its
graphical Companion) was developed on the PC and the application was run
on the B220. Now the PC is in the E310 itself: so the question in the
subject comes natural (for us).
What seems clear is that the code has to be cross-compiled for that
on-board ARM processor (it is not clear where to download the
corresponding SDK from the Ettus site but that is a different issue).
But then it is not clear how to deal with GR (especially if you want to
use GRC!) and how to deal with the output. For instance, suppose you
just want to start with the FM receiver which is a sort of “Hello
world!” of SDR, at least for us.
Any suggestion is more than welcome. Maybe a helpful discussion might
come out from our doubts which is useful also for others.
Anyway TIA!
BR,
Maurizio.
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione
derivante dalla conoscenza di queste informazioni sono rigorosamente
vietate. Qualora abbiate ricevuto questo documento per errore siete
cortesemente pregati di darne immediata comunicazione al mittente e di
provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain
privileged information intended for the addressee(s) only.
Dissemination, copying, printing or use by anybody else is unauthorised.
If you are not the intended recipient, please delete this message and
any attachments and advise the sender by return e-mail, Thanks.
[rispetta l’ambiente]Rispetta l’ambiente. Non stampare questa mail se
non ? necessario.
glad to see you ask these questions! For those who read this later but
aren’t involved in Maurizio’s/mine email exchange: you get the SDK under
[1] in its current version, installation instructions under[2].
So, you’re right. With the E310, you’ll need to use a cross-compiler to
generate binaries for the E310; you can also do “small” compilations on
the device itself, but we generally try to encourage people not to do
that – building something as big as whole GNU Radio would take overly
long on the embedded processor of the E310.
So, two aspects:
If your flow graph doesn’t use graphical sinks (ie. it works in the “no
gui” build option), and only uses the blocks that GNU Radio comes with,
you can just copy over the resulting python file to your E310 (e.g. via
SCP), and run it there, unmodified. Especially if you already have
experience with the B210, this is handy: Anything that works with the
B210, and for which the E310’s CPU is fast enough, should also work on
the E310 (with very little restrictions). So you can design and test
your flow graphs on your PC with the B210, and if they work and are
fairly optimized, just copy them over to the E310.
Now, if you need custom GNU Radio modules, and you need to build C++ GNU
Radio blocks, you’ll actually need to cross compile. [2] has a paragraph
on building GNU Radio; do that, and also do the same (adjusting the path
to the platform cmake file) with your OOTs, and you should be fine.
And what about the new RFNoC and GRC to be run on an E310?
these are two different aspects:
GRC is a flowgraph /design/ tool. You wouldn’t run it on the E310
(especially as it is a graphical tool).
It can generate headless flow graphs set up by python programs that you
can copy over to the E310 – that’s the usage of GRC I’d recommend in
this case.
You can use gr-ettus to design flow graphs even if the PC you use for
design doesn’t have access to a USRP at all – the USRP/RFNoC is needed
at run time only.
The only way out I can think of is to
rely on data saved to file to be analysed in a post-processing step.
To be honest, yes, that is the problem with embedded devices. They are
limited in the ways you can interact with them and with the computation
happening on them.
A very software design driven approach would be to design good unit
tests, that you would first verify with simulated signals on your host
computer, and use them to understand the workings of your USRP.
If you limit yourself to low rates (go for < 1MS/s for a start), you
might also be able to build a flow graph that uses e.g. a ZMQ sink to
send the processed data to your host PC, where another flow graph takes
care of visualization.
And what about the new RFNoC and GRC to be run on an E310?
From Ettus site we are told that “RFNoC has been integrated into UHD for
our
third generation USRP SDRs (X300-series, E300-series, and future
devices)”.
Furthermore Ettus site shows some examples where RFNoC blocks are used
under
GRC, which is a GUI environment (but they are run on an X series HW…).
So the new question is: what is the right methodology to make designs
under
GRC to be run under an E310? What about initial testing steps
(especially if
you want to use RFNoc)?
About RFNoC I could imagine a step-wise approache where I prepare the
Python
with GRC (where the RFNoC OOT modules are installed) and then I run it
on
the E310 (where the RFNoC non-default FPGA configuration is installed).
But
what about testing such design? “If your flow graph doesn’t use
graphical
sinks” how can you test your design? The only way out I can think of is
to
rely on data saved to file to be analysed in a post-processing step.