# On the "right" approach for developing applications to be run on an E310 **URL:** \ **Category:** GNU Radio\ **Created:** [September 2, 2015, 11:48pm UTC](https://www.ruby-forum.com/t/on-the-right-approach-for-developing-applications-to-be-run-on-an-e310/243230 "2015-09-02T23:48:15Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\ **Post date:** [September 2, 2015, 11:48pm UTC](https://www.ruby-forum.com/t/on-the-right-approach-for-developing-applications-to-be-run-on-an-e310/243230/1 "2015-09-02T23:48:15Z")
Hi! 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. ---
**Author:** ![Crozzoli\_Maurizio](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e9c0ed/32.png) [@Crozzoli\_Maurizio](https://www.ruby-forum.com/u/Crozzoli_Maurizio)\ **Post date:** [September 2, 2015, 11:59pm UTC](https://www.ruby-forum.com/t/on-the-right-approach-for-developing-applications-to-be-run-on-an-e310/243230/2 "2015-09-02T23:59:56Z")
Hi Maurizio, 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. Best regards, Marcus [1] [files.ettus.com:/e3xx\_images/e3xx-release-3/](http://files.ettus.com/e3xx_images/e3xx-release-3/) [2] [http://files.ettus.com/manual/page\_usrp\_e3x0.html#e3x0\_sdk](http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_sdk) ---
**Author:** ![Crozzoli\_Maurizio](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e9c0ed/32.png) [@Crozzoli\_Maurizio](https://www.ruby-forum.com/u/Crozzoli_Maurizio)\ **Post date:** [September 9, 2015, 12:10pm UTC](https://www.ruby-forum.com/t/on-the-right-approach-for-developing-applications-to-be-run-on-an-e310/243230/3 "2015-09-09T12:10:59Z")
Hi Maurizio, > 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. Greetings, Marcus ---
**Author:** ![Crozzoli\_Maurizio](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e9c0ed/32.png) [@Crozzoli\_Maurizio](https://www.ruby-forum.com/u/Crozzoli_Maurizio)\ **Post date:** [September 9, 2015, 12:03pm UTC](https://www.ruby-forum.com/t/on-the-right-approach-for-developing-applications-to-be-run-on-an-e310/243230/4 "2015-09-09T12:03:58Z")
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. Needless to say that comments are welcome… TIA! BR, Maurizio. – View this message in context: [http://gnuradio.4.n7.nabble.com/On-the-right-approach-for-developing-applications-to-be-run-on-an-E310-tp55779p55905.html](http://gnuradio.4.n7.nabble.com/On-the-right-approach-for-developing-applications-to-be-run-on-an-E310-tp55779p55905.html) Sent from the GnuRadio mailing list archive at [Nabble.com](http://Nabble.com).