discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Speaking in Favor of Firewire


From: Eugen Leitl
Subject: Re: [Discuss-gnuradio] Speaking in Favor of Firewire
Date: Sat, 11 Jan 2003 14:35:49 +0100 (CET)

On Sat, 11 Jan 2003, Jeff Rush wrote:

> I'd like to speak in favor of using Firewire versus USB 2.0.  My 

What's wrong with FastEthernet (there are now embeddeds with FastEthernet 
on-chip), GBit Ethernet (whether optical or Cu)?

> background is systems software with some digital electronics engineering 
> -- complete novice where RF is concerned.  I have not yet built a 
> Firewire board, so my claims are based on tech lit, not experience.  I 
> plan to do so, when I am gainfully employed again... ;-(
> 
> Firewire is cool because:
> 
> [*] current speed is 400 megabits per second, with standards for up to
>      3.2 gigabits per second when switching from wire to fiberoptic,

Current GBit Ethernet is 1000 MBit/s, and 10 GBit/s is coming.
 
> [*] supports bandwidth allocation and isochronous streaming, with a
>      transmission frequency of down to 125 usec per block of 1KB.

Once it streams you're golden, but it can take ms to start streaming, or 
even longer, in worst case. You can get ~30 us pingpong latency over 
current FastEthernet from userland code.
 
> [*] can be daisy-chained, so multiple radios could be strung together
>      say for a phased-antenna setup or just protocol/freq conversion,

Ethernet and (since recently) GBit Ethernet have cheap few-port switches 
and scale to hundreds and thousands ports, if needed.
 
> [*] data stream doesn't have to go thru the PC but can be picked up
>      by other Firewire devices on the same cable; the PC then becomes
>      a symphony conductor directing data streams among radio units,

So does Ethernet.
 
> [*] multiple listeners, so that a raw data stream from a receiver
>      can be processed/filtered by multiple CPU devices, to extract
>      features/frequency bands,

You can broadcast at switch level, and a switch supports any topology, 
being a true crossbar.
 
> [*] both power (8 to 40 volts, 1.5 A max) and data go over same cable,

Have seen this for Ethernet, too (a weatherproofed 802.11b AP/bridge).
 
> [*] supports fiberoptic cabling, which may be useful in noise reduction
>      and placing the conversion electronics close to antenna fixtures
>      (although you lose the power option when using fiberoptics),

So does Ethernet.
 
> [*] the leading chipsets are available on the web from TI in cheap
>      ($5-15), small quantities for home/hobbyists via a relationship
>      btw TI and Digikey,

You can get complete embedded PCs with Linux(BIOS) and FastEthernet 
onboard.
 
> [*] single chip solutions are available from TI; used to be you had to
>      use a PHY chip and a LINK chip but not anymore,

First single-chip embeddeds with FastEthernet onchip has been reported.
 
> [*] on the PC side, drivers come with Windows, MacOS and Linux, so
>      everyone can play,

Even more true for Ethernet.
 
> [*] has a simple, memory-mapped read-write register architecture (up
>      to 256 terabytes per device), for controlling devices (tuning,
>      filtering, etc.); no need to invent another protocol or packet
>      format,

Use GAMMA, or TCP/IP.
 
> [*] self-configuring addresses, no need for switches or IP assignment,

Switches are an advantage, if cheap, since being crossbars. Plug and play 
with DHCP (and Apple's new discovery) is even simpler with Ethernet.
 
> Note: The standard firewire cable is good for 400 Mbps over 4.5 meters
>        using 28 AWG wire.  Cables with 24 AWG can run up to 14 meters
>        and several companies (NEC, Sony) have announced plastic optical
>        fiber solutions that allow for lengths of up 100 meters.

Uh, you just can't beat a LAN with WAN ambitions, as far as distance is 
concerned.
 
> Re protocol stacks on the -device- side; many of the chips I've seen 
> don't require a lot of protocol work as they do much of it internally; 
> you just shove bits thru.  However some kind of CPU will be required but 
> if chosen carefully, can be something uLinux-based, meaning the protocol 
> stack is free and accessible, which is part of the charter of GNU Radio.

Have you checked out LinuxBIOS?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]