Re: [Discuss-gnuradio] GNU flow graph containing a UHD block - unable to detect USRP E310

[Marcus Müller]

Hi John,

I really hate to nitpick, but I also feel that I must clarify a few things:


>
> 1.  The E310 has to be placed into "network mode", which loads the
> E310 FPGA with appropriate code.  
No, network mode works with the default (and only) FPGA image – it's
just a software daemon inside UHD.
> This mode is not implemented by default when the E310 is booted up.
Yes, indeed, you need to start that daemon explicitly (because it grabs
the device, so other applications can't use it, so there's no way to
autostart it)
>
> 2.  The UHD driver version in both the E310 and the networked platform
> with GRC must be the same version.
exactly! Also note that with the most recent versions of UHD, network
mode doesn't exist anymore. The E310 image Release 4 still contains a
network-mode-capable version of UHD.
Dropping the network mode became technically inevitable with the
introduction of RFNoC. Of course, this is a regression to those who use
Network Mode in their daily work, but the benefits of actually being
able to use the FPGA with RFNoC on an embedded device whose CPU is
comparably weak are so high that we felt that eliminating the network
mode was worth it; it was never intended to be a full mode of operation,
just a diagnostic tool, and frankly, its bandwidth is pretty limited, in
turn limiting its usefulness.
>
> 3.  Ettus encourages the running of GRC on the E310 rather than an
> external computer.
Ah, I think I'd personally like to make a difference here: GRC, the GNU
Radio Companion, is a graphical tool to design flow graphs. Hence, run
it on your development PC (which has a screen), and let it generate
Python GNU Radio flow graph, deploy that to the E310, and run GNU Radio
(only the runtime, not the Companion design tool) there.
> That is understandable from a network load perspective.
The point mainly is that the Zynq's architecture really doesn't allow
for high rate UHD-tunneled-through-network streaming. The CPU is the
main limit, there.
> OTOH, if you have a dedicated test LAN, which may consist of just the
> E310 and the GRC computer, this shouldn't be an issue.  
Well, if about 1MS/s is enough for you.
> For programming test and debugging, I prefer having the network mode
> on my E310 since running an SDR application that outputs sound is
> easier to do on an external computer using its sound card and
> speakers.  Also the GUI of GRC seems to be more readable when GRC is
> running on the external computer as opposed to running an SSH -X
> session to the E310.
Exactly! The E310 is an embedded device; embedded design philosophy is
to develop on a proper workstation, and then deploy software to the
embedded device. It's really not usual (and hence, I'm somewhat critical
of that myself) that an embedded device's filesystem even contains
graphical applications that can be launched via SSH. It's a good thing
to get a quick look into how things work, but a lot (most?) of the E310
users deploy their devices on some utility pole, remote shed, dark
corner of their lab... without any graphical interaction, in the end.
> I also find that if an SDR application defined by the GRC flow
> graph/Python code is designed to output real time graphical info it
> seems to be less clunky when GRC is run external to the E310.  My .02
> worth. Sincerely,
That's certainly true; basically, a limitation of the X11 protocol,
designed somewhen in the mid-80s, for displaying GUIs with text and
rectangles that you can click on, not real-time visualization.

I often find myself recommending a hybrid approach: Make a flow graph
that reduces the data to the things I want to display (e.g. a vector of
128 floats every 1/20 s), and sends that using a ZMQ or UDP sink, and a
matching flow graph that does the GUI on the computer with the screen.

Best regards,
Marcus