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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
