FireWire Gets Ready to Go Wireless 215
mindless4210 writes "The 1394 Trade Association has approved a specification for the development of wireless FireWire applications, which will let 1394-enabled devices, both wired and unwired, to connect with each other. The new spec will enable communication between a variety of devices, such as set-top boxes, HDTVs, tuners, and DVD players, all of which will be able to interoperate in home networks. Officials speculated that in the future there could be plug-in cards for set-top boxes enabling wireless connection to DVD players and hard-disk drives. The trade association also said it will work with the WiMedia Alliance to jointly develop collaborative products."
Like I said... (Score:2, Informative)
Re:WiFi? (Score:5, Informative)
Firewire, for instance, has error-checking and error-correction built into its spec (it'd be smarter about errors than, say, WIFI). You can build in the same with other protocols but you take a bigger performance and output hit and firewire might end up as more fundamentally reliable regardless. Some protocols do better with broadcast mediums as well.
Someday perhaps we'll standardize on one wireless protocol when we've enough over-the-air bandwidth and processing power as to make tradeoffs trivial, but that day has not yet come.
RD
802.15.3 = UWB (Score:5, Informative)
Team targets 802.15.3 for wireless video networks [theregister.co.uk]
Re:Because cell phones aren't bad enough (Score:5, Informative)
Re:Wireless (fill in the blank) (Score:5, Informative)
In short, basing on an existing wired standard means all the wireless standard needs to do is to define a radio link that emulates a wired link. Only the radio bridges need to be aware that wireless is being used, the other end of the bridge can just claim to be a typical powered or unpowered hub. There'd likely be some sort of way to issue an "Are you wireless?" query to hubs so that appications that can't tolerate the small delay wireless creates can scream about not having a good enough connection, and things like that... but most of the heavy lift operations can just lean on the wired standard.
Re:Because cell phones aren't bad enough (Score:2, Informative)
Re:Can't they all just get along? (Score:5, Informative)
Simple. The two busses have little in common.
Firewire:
- peer-to-peer design (all devices are created equal)
- low CPU overhead due to an intelligent controller with DMA
- requires smarter hardware due to peer-to-peer design
- heavily standardized protocols for storage, audio, video.
USB:- host-device design - devices can only talk to host, not each other
- higher CPU overhead since the host controller is relatively dumb
- really inexpensive hardware (both host and device), ideal for low-cost devices
- standardized protocols for pretty much everything, but particularly human interface devices
Firewire is well-suited to audio/video applications and storage, since those applications require heavy throughput, which would severely tax the CPU when using USB.USB is well-suited to low-speed devices like keyboards, mice, and inexpensive still cameras, scanners, and other consumer devices, since cost is the primary factor in their design.
Just my $0.02.
Re:WiFi? (Score:3, Informative)
The problem with 802.11 is it's lack of Quality of Service, i.e. it has no way to guarantee a chunk of bandwidth to a particular stream. 802.11 is just wireless ethernet with all of it's advantages and disadvantages. If you were streaming video form a DVD player to a TV and at the same time decided to transfer a large file between two computers sharing that same network, the video signal would get trashed.
Firewire, on the other hand, has the ability for devices to reserve a portion of the bandwidth. Other devices can use the remaining bandwidth, but the video still will still have all the bandwidth it needs. Basically, you get to setup a fixed sized pipe for each service.
QoS can be achieved on 802.11 using higher layers of the protocol stack, but you're still using a networking protocol to implement communications between entertainment center devices. So, instead of a rats-nest of wires, you would have to give each device an IP address or implement DHCP in each device and set up NAT, etc. Major pain.
Re:A future without cables and wires (Score:5, Informative)
Distance really hurts. Say you want to draw 20 amps through such a bus (240 watts - not really that much) and that your 12V equipment starts to get flaky at 11V (meaning you need one volt of drop or less). One volt loss with 20 amps means you need a round-trip resistance of less than .05 ohms. Say you need to run this 50 feet, or 100 feet round trip. You'd need wire with less than .5 ohms per 1000 feet. Googling for "copper wire table" reveals that you'd need 6-gauge wire!
If you ran 120V, not only would your devices be designed to draw 1/10th the current, but they would have greater tolerances to voltage drops - 119V is absolutely within specifications.
Instead of devices having wall warts and PC PSU's, you could just tap the stable 12v and GND lines and use a smaller chip that could convert it to 5v or whatever.
A modern switching power supply will be about as small and efficient whether it was designed to draw from 120VAC or 12VDC.
What might be more interesting for local power distribution would be higher-frequency AC, say 100kHz. Transformer-based power supplies would then shrink to the size of switching power supplies.
Firewire's up to 1600 now (Score:3, Informative)
But firewire perhiperals are typically going to be more expensive than usb - unless somehow firewire gains the inertia that makes 802.11 stuff cheaper than bluetooth.