Ethernet SDR Interfacing

[Patirck Strasser]

schrieb wb4jfi am 2010-09-13 21:43:
> On 9/13/2010 4:57 AM, Patrick Strasser OE6PSE wrote:
>> wb4jfi wrote on 2010-09-11 22:16:

>> What do you mean with restrictive? Driver support, data rate,
>> flexibility, line length?
>>
>> For datarate, USB has gross bandwith of 480MiBit/sec, which boils down
>> to a sustainable net datarate of 32MiByte/sec or even a bit more.
 >
> The Digilent NIC PMOD (I do own one) only does ethernet at 10Mb, and
> uses serial SPI for communicating. Not nearly fast enough to handle the
> high-speed IQ data from an SDR. For 192k sampling, the data samples
> alone will be at over 6Mb/s. At 384k, they are 12.3Mb/s, and 480k over
> 15.3Mb/s. This does not account for ANY overhead or separate
> command/status data. (192k samples per second of separate I and Q 16-bit
> data samples = 6,144,000 bits per second). So, I wasted a few dollars on
> the Digilent NIC PMOD (at least for SDR usage).

Regarding speed it's not that big difference between USB and Ethernet 
100MBit.

> You hit it right, my main concern with USB is the drivers for whatever
> hardware chip is used. I believe the Cypress FX2 drivers for Vista and
> Win7 are now finally OK, but that fiasco pointed out how susceptible we
> are to having Microsoft change something and having hardware
> manufacturers lag behind on getting "approved" or signed drivers for
> their older products. An even worse example is what any Flex user has
> had to put up with when using their 5000 or 3000 with Vista or Win7. Hit
> F8 at boot, and ignore the unsigned driver warning. Every time.

Sounds very painful.
 From the SDR widget people, which try to stay with the USB audio 
system, I heard that there are lot of pitfalls and obstacles on Windows 
with USB. I did not know that Windows has so much problems with the 
EZ-FX2 drivers, though.
I'm using Linux for most things, there you have different problems.

> The most ubiquitous interface out there (next to USB) seems to be
> ethernet, so that's what I'm looking at. No more hardware-specific
> drivers AT ALL!! If it connects, it just runs. And, UDP seems reliable
> enough over a hard wire, so no fancy-schmancy protocol handshaking or
> different modes like USB. In addition, ethernet is made for distributed
> processing, so one computer can do some processing, then hand off the
> data to others. 100base-t is fast enough to handle present SDR data
> rates, and gig-e gives much higher speeds (with different hardware).
> Yes, ethernet wires can be much longer than USB as well. (I have a USB
> extender that uses ethernet wiring between the devices, but that costs
> another $30-$100).

OK, I understand now. With bad driver situation, Ethernet is the logical 
alternative.

> One major issue is that most computers have only one ethernet
> connection. So, if you want to use the e'net connection for both the SDR
> and Internet, a small switch must be used. Or, wireless can be used for
> the Internet (on a laptop).

You're very flexible with Ethernet. If you need galvanic isolation, you 
can even take an optical link, and bridge very long distances.

> I'm not worried about USB speeds or interface issues right now. The
> existing Charleston board works fine, even at 480k, on a fast enough
> computer. So, I'm more looking into the future. I see James Ahlstrom's
> work, new openHPSDR designs, and SDR-IP all going to ethernet.

Both USB and Ethernet have some attractive properties:
* Easy available. Every PC you can buy nowadays has at least one of both.
* Easy deployable. One standard cable available in every eletronics shop 
will do it for both, and you can not do very much wrong nin cabeling USB 
or Ethernet.
* High bandwith. 10, 100 and 1000Mbit for Ethernet, 12, 480 (and more 
with 3.0) for USB.

The drawback for USB is the limited cable length, master-slave 
architecture, driver dependence and complexity of architecture.

> Thanks for your response Patrick. I may be totally wrong in my thinking.
> I'm just getting worried about where Windows is going, and want to avoid
> any future problems, if possible. It seems like ethernet would do that.

I think your reasons are quite sane. I just wanted to put in my 2 cents 
and wanted to know your reasons.

For UDP:
I think that is the obvious choice. You can send samples in best case 
with a nearly static header. It has no big handshake or control, which 
reduces implementation problems. And you don't even need more.

For bandwidth, sharing connections and retransmitting processed samples:
That's all no problem if you do not try to satturate an Ethernet 
connection. It has collision detection/collision avoidance, which tends 
to congest in saturation of lines. But I guess that's no problem with 
the Charleston SDR. Generaly it's something you have to keep in mind 
when designing Ethernet SDR applications.

For costs:
Compared to ready-built SDR systems, the Charleston SDR is incredible 
cheap, even if you put another 100$ to the bill for good connectivity.

Patrick
-- 
Engineers motto: cheap, good, fast: choose any two
QTH: JN77rb
Patrick Strasser OE6PSE <oe6pse at wirklich priv at>