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

[Marcus Müller]

Hi John,

On 09/30/2016 03:55 AM, John B. Wood wrote:
> Hello, Marcus.  All I can say is that when the E310 is commanded to go
> into network mode a string of messages is issued that indicates the
> FPGA is being loaded to support the network mode. So my conclusion was
> that for network mode the FPGA is loaded with code other than that
> used when booting up.
Ah, I haven't thought about these strings! Nevertheless, underneath, we
only have one FPGA image.
>
>>
>>> 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.
> These days that's peanuts on a wired LAN, IMHO.  Again, I use a
> dedicated LAN with my E310 so YMMV.
The point is not network congestion - the CPU on the E310 is simply too
slow to press through more than maybe 2MS/s on an especially sunny day...
>
> So my recommendations for those who develop SDR apps for the E310:
>
> 1.  Compile GRC with network mode enabled on the target platform.
network mode is a UHD, not a GNU Radio feature, but other than that,
yes, it will often be necessary to recompile GNU Radio to link against
your specific version of UHD.
>
> 2.  Connect the target platform to the E310 via a wired LAN that is
> shared with few or no other users.
Well, as you've already pointed out, since the (in my experience) 1MS/s
maximum sustainable network-mode sampling rate really doesn't put any
significant load on a 1GBit/s network, that's not as important. (Btw,
it's essentially 16bit I + 16bit Q = 32bit/complex sample -> 32Mbit/s
for 1MS/s
Any graphical sluggishness really is an effect of the X protocol not
being meant for real-time visualizations (everything needs to be ack'ed
by either end, so X11 is inherently sluggish over network, and it gets
worse when the client machine is busy with DSP), and of course CPU
limitation.
>
> 3.  Use GRC on the target platform for flow graph programming and
> automatic Python code generation.
>
> 4.  Following debugging, transfer the .py file(s) for the app to the
> E310 and from that point on you don't need the GRC GUI environment
> (unless more changes are required and you don't want to do Python file
> editing directly either on the target platform or while logged on to
> the E310).
Yep, that's a nice workflow. I also often, if I don't do RFNoC or rely
on any special features of the E310, simply use a B210 to do dev, and
then copy over.
>
> 5.  Keep in mind that if your E310 apps output real-time graph info
> and/or an audio stream, those things will put noticeable load on your
> network.
can't really agree – it's pretty hard to fully load a 1Gb/s network
connection using the Zynq CPU doing any DSP.
>
> At the risk of previously stating the obvious and sincerely,
>

Thanks for discussing this! I think it's pretty important to exchange
about development process and such; there logically can't be a single
golden way, since different applications and different developers have
different needs, and it's pretty much impossible to tell for us what the
best approach for a new user is going to be. Discussions like this one
help people understand the option they have with "real-world use cases".

Best regards,
Marcus