Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Wireless Networking Hardware

Wireless at Firewire Speeds? 157

Posted by CmdrTaco from the I'll-believe-it-when-I-see-it dept.
MeCoward writes "EETimes reporting on working group that hopes to leapfrog 802.11 to create wireless 1394 links. Initially 100mbps but aiming for 400mbps." I don't expect to see this anytime soon, but it certainly makes things like wireless HDTV feasible. Sure would be cool. Of course Bluetooth is only now just catching on, so imagine how long it'll be before this becomes practical.
This discussion has been archived. No new comments can be posted.

Wireless at Firewire Speeds? More

Wireless at Firewire Speeds?

Comments Filter:

  • wireless HDTV? (Score:5, Informative)

    by Anonymous Coward on Wednesday May 07, 2003 @05:05PM (#5905654)
    I don't expect to see this anytime soon, but it certainly makes things like wireless HDTV feasible.

    Uh... maybe I'm just a dumbass or something, but wireless HDTV is already feasible. I watch it every day. It's called 8VSB.

    However you encode it, broadcast HDTV is only 19.3 Mbps. It's feasible over dual-like 802.11a, or 802.11g.

    • Re:wireless HDTV? (Score:2, Informative)

      by Anonymous Coward
      It certainly is feasible, see this [slashdot.org] article on recieving HDTV broadcasts using a radio tuner. It's a bit expensive, but pretty cool nonetheless.

    • Re:wireless HDTV? (Score:1, Informative)

      by Anonymous Coward
      Mbps != Mhz. Now you can encode 1 bit on every hert, but we've been past that for some time. Typical is about 12 bits on every hert with compression. Even then though, you have to worry about things like disconnects and signal strength. (Not worried about when you are using a closed cable system like with cable TV.)

  • Uhm (Score:5, Funny)

    by cscx ( 541332 ) on Wednesday May 07, 2003 @05:06PM (#5905664) Homepage
    but it certainly makes things like wireless HDTV feasible

    Because right now you can't pick up HDTV from over-the-air signals... right???? :P

  • Another wireless standard, yay. (Score:4, Funny)

    by poor_boi ( 548340 ) on Wednesday May 07, 2003 @05:09PM (#5905694)
    If 802.11g didn't make you want to stick your head in front of a Cantenna [turnpoint.net] to get a preview of brain tumors to come, this new standard certainly will.

  • small range (Score:5, Insightful)

    by afidel ( 530433 ) on Wednesday May 07, 2003 @05:10PM (#5905700)
    UWB only works if you severly limit the range (10m in the case of 802.15.3 networks). This might be fine for connecting you DVR to your TV, but it won't be usefull for connecting your DVR to the tv on the other side of the house or up a floor. This could be ultra cool for next generation MIDI though, the ability to connect all of your devices wirelessly and get both MIDI data and samples would rock. I can't imagine how much this would please all of the musicians who have had to do a road show with the spagheti nest that is MIDI setups.
    • Interesting. Though bluetooth should work well there no?
      • No, bluetooth could only handle the notation section like traditional MIDI, next generation MIDI also includes the ability to transfer sample data at high bitrates between devices, so your sampler could pull the output from your effects processor and loop it etc. Plus bluetooth doesn't have the level of QOS that firewire provides (though I'm not sure how well the QOS from firewire will work when layered on top of inherintly problematic transport like wireless UWB)
        • Bluetooth chipsets are currently not stable enough to guarantee sub 20ms delivery consistently. A jitter or latency that bad kind of sucks for interactive use, esp. for playing music.
          Moreover, the presence of other bluetooth or 802.11 devices could mess it up. As they become more commonplace, you have to consider whether you want to add latency sensitive devices to the mix until QoS is part of the protocol (or at least enforced in the driver).

    • Re:small range (Score:5, Insightful)

      by JesseL ( 107722 ) on Wednesday May 07, 2003 @05:24PM (#5905820) Homepage Journal
      Like every other form of radio communication, UWB requires a trade-off between data-bandwidth and range. To say "UWB only works if you severly limit the range" is grossly misleading. Any conventional carrier based radio communication that works at these data rates is going to be of similarly short range.
      • You are forgetting about interference, grasshopper. UWB works on bands that are occupied by other entities, and its range is LEGALLY limited to a few meters. Otherwise, it would interfere with everything.

        BTW, I doubt it would be acceptable for use in a critical environment like on-stage. You need reliability, and UWB won't provide it. Every nearby transmitter, microwave oven, or other source of interference would royally screw it up.

        • First, the range of UWB isn't limited by the FCC at all, the transmission power(It is limited to power levels so low that they may be below the normal noise floor), and certain spectra that may interfere with systems like GPS are restricted.

          Second, this application was never intended for "a critical environment like on-stage". From the article:

          "Backers hope the approach could leapfrog efforts on 802.11 to provide a route for consumer electronics companies to send high quality video signals over wireless

          • It is limited to power levels so low that they may be below the normal noise floor

            If the power level is below the noise floor, how do you tell signal from noise? That's probably supposed to mean that it causes interference, but not a whole lot of it. I am pretty sure the FCC limits both power and range (by prohibiting certain types of antennas with high gain).

            Second, this application was never intended for "a critical environment like on-stage". From the article:

            Read the parent post before starting
            • I suggest you read this article [eetimes.com]. I am not starting a "bitch session", my rely to the original post was only pointing out a particular fallacy that I didn't want to see spread, ie "UWB only works if you severly limit the range", I never intended to debate the merits of afidels idea of UWB wireless MIDI - I simply don't give a damn about that aspect of this threads original post.
              • Sure, it can work over any distance. If you have a 500MHz chunk of spectrum all to yourself, you aren't limited by anything except the power of your transmitter. You don't need UWB unless you are actually using someone else's frequencies. In that case, you DO have to limit yourself to short-range communications. Besides, you would need quite a bit of power to transmit a signal 500MHz wide for more than a few meters.

                Here's a quote from your linked article (which is mostly industry hype for potential in
    • Have you checked out this before?

      http://magic.gibson.com/index.html [gibson.com]

  • Range, bandwidth and security... (Score:5, Interesting)

    by WegianWarrior ( 649800 ) on Wednesday May 07, 2003 @05:12PM (#5905714) Journal

    Heberling is also working with the 802.15.3a committee attempting to set standards for an ultrawideband physical layer chip that could transmit at data rates of 100 Mbits/second initially but be upgraded to versions at 200 and 400 Mbits/s, albeit at ranges of 10 meters or less.

    So... I can have a massive bandwidth without any cabling - as long as I don't move the devices further apart than a cable can reach. Somehow, while fiddling with cables can be a hazzle now and then, I think I'll stick to cables. One reason for this is security - unless this technology relies on LOS (line Of Sight), which would make it even less an atractive replacement for cabling, people would likely be able to pick up the signals from a much further distance than the aforementioned ten meters...

    ...unless I decide to utilise some of that bandwidth - along with CPU-time - to encrypt my signal... which I wouldn't have that much reason to do with a piece of cabel in the first place.

    Still, early days and all that - we'll see just where and how this ends up in a few years time.

    • Encryption will almost always SAVE bandwidth because the first step to encryption is compression to eliminate repeating patterns in the input stream. It will cost you processing time (not necessarilly cpu, it can be done with an ASIC) and will slightly increase latency. Plus if I am sending next generation MIDI data or DV movies over it I really don't think I need to encrypt the signal.

      • Re:Range, bandwidth and security... (Score:4, Interesting)

        by the uNF cola ( 657200 ) on Wednesday May 07, 2003 @06:26PM (#5906294)
        The first step to encryption is NOT getting rid of duplicate data.

        All encryption is, is obfuscation of data. Usually, your goal is to have a 1-1 function that takes data in, some data to use as an encryption key (initialization vector, pk, something) and your result is new data, equal in size.

        Compression can be considered encryption, in that it obfuscates data. So is ROT-13. It's weak, fine, but the job is to prevent people from reading it unintentionally (like hidden answers).

        Btw, compressing will save data bandwidth, but not data processing bandwidth (CPU).

        • Actually, most serious encryption packages (as opposed to algorithms) compress the data before they encrypt it. This increases the entropy-per-bit of the data being encrypted, making it harder to break.

          It is true, though, that many encryption systems don't compress. This makes them weaker, though, and it's why PGP compresses the text (using gzip, I think) before encrypting it.

    • Whatever happened to trusting your neighbor?

      Its like walking against a river of stupidity. We might as well just be ludites.

  • High-speed PAN w/ copy protection? (Score:5, Interesting)

    by questionlp ( 58365 ) on Wednesday May 07, 2003 @05:14PM (#5905736) Homepage
    First, it seems that this would make record and studio execs happy since this is using IEEE 1394:
    The 1394 interface is a key interconnect for sending copy protected digital video between TVs, set-tops and other systems.
    So you have pretty good speed wireless connections plus some nice little bits to make sure that you may or may not be able to sniff the signal and redistribute it elsewhere.

    Anyway, this seems to be the next step up from Bluetooth (which is more of a wireless replacement of USB) for connecting wireless DVD players to a projector or TV, or play media files from a wireless 1394 hard drive or a computer sitting in your AV rack.

  • I agree that IEEE1394 technology could leverage off the existing WAP source focus point which translates into high-end yields in the fluctuation array.

    The transfer speeds could be augmented if we daisy-chained several EISA drives in a RAID 4 architecture (reflecting-mirror, where bit orders are reversed in drives 3, 7, and 11). That would allow the drives to sustain the increased write rates, although read rates may suffer during off-hours.

    This would also compensate for the electro-synergetic interferenc

  • Unbelieveable! (Score:5, Funny)

    by jspayne ( 98716 ) <jeff@payn[ ]lace.com ['esp' in gap]> on Wednesday May 07, 2003 @05:16PM (#5905749) Homepage
    To think, wireless HDTV! That would be like - like getting HDTV over the air! You would just need an antenna [antennaweb.org], maybe a fancy converter box [crutchfield.com]. Who could think it possible? Wouldn't it be cool if they could do multiple channels [titantv.com] at the same time? *sigh* Jeff

  • Well... (Score:5, Interesting)

    by MachineShedFred ( 621896 ) on Wednesday May 07, 2003 @05:17PM (#5905763) Journal
    "Bluetooth is only now just catching on, so imagine how long it'll be before this becomes practical. "

    Bluetooth is slow. If it was 100 time faster, it would catch on faster, becuase there would be more applications for it. With less-than-megabit speeds, the only thing you would EVER want to do is serial I/O (sync stuff, keyboards), and *maybe* a mono audio stream.

    The consumer electronics industry has been eyeballing FireWire (1394) for a while. It makes for one hell of an universal interconnect between all your digital devices, rather than having coax spaghetti and 20 IR or IF devices all over the place. Instead you have one FireWire hub, going to your receiver, your DVD player, your VCR, your CD changer, and your HDTV decoder, and one remote that tells one device what to tell the others...

    That's my kind of home automation and control.

    • Streaming mono cd quality sound over Bluetooth works great. But why bother with monoaureal sound when you have hip new technologies like, for example, mpeg1 layer3 encoding?

      If you don't believe me, check out these nice cans [openbrain.co.kr].

      With these cans, a Bluetooth pcmcia card and a mini-pci 802.11b card in my ultraslim laptop, I'm so wireless it hurts (my back, lugging around all the batteries).

    • Re:Well... (Score:2, Informative)

      by NomNet ( 542670 )
      Bluetooth is slow. If it was 100 time faster, it would catch on faster, becuase there would be more applications for it. With less-than-megabit speeds, the only thing you would EVER want to do is serial I/O (sync stuff, keyboards), and *maybe* a mono audio stream.

      Er, that's precisely what it's for ! What else would you want to use it for ?

      If you need a quick connection, then use 802.11x, together with the HUGE increase in component size and battery drain that it demands - the whole point of Bluetooth i

  • Will this new wireless firewire standard still suffer from the same driver patent issues that surround current firewire implementations? I can only assume so if it's based off the same basic technology. It would be nice if they (IEEE) would clean up their act in regards to royalty-based patents finding their way into standards. IMHO, of course.
    -A.M.
  • Apple posted a job for a wireless/firewire developer almost a year and a half ago.
  • 'Fess up? Who's the idiot that created the name HiperLAN 2? Next thing you know someone will start to write ciberkinetics and giroscopes !

  • Firewireless (Score:4, Informative)

    by Revvy ( 617529 ) on Wednesday May 07, 2003 @05:26PM (#5905833) Homepage
    Firewireless [google.com] has been around a while [theregister.co.uk]. It even has DRM [macworld.com].

    I don't expect to see this anytime soon...
    Why would you? We've only been waiting several years already.

    So much for being an 'early adopter'.

  • Wireless HDTV!?!? (Score:4, Funny)

    by anthony_dipierro ( 543308 ) on Wednesday May 07, 2003 @05:28PM (#5905852) Journal
    Wow, if they had wireless HDTV, they could put that in the UHF spectrum and free up the VHF spectrum for other uses!

  • Too much layering here (Score:5, Informative)

    by Animats ( 122034 ) on Wednesday May 07, 2003 @05:30PM (#5905864) Homepage
    Another layer underneath FireWire? Why?

    FireWire as an electrical interconnect is good. FireWire as a protocol sucks.

    Down at the bottom, FireWire is a LAN. You send packets with a source address and a destination address. It's a TDMA LAN, more like token ring than Ethernet, with assigned time slots.

    Video is sent as broadcast packets, on a rigid schedule, with no ACKs. That's quite straightforward.

    The ugly part is the layer which implements load/store emulation for 32-bit data items in a 64-bit address space. This was designed by people who think in terms of "device registers". Control functions are exercised by stores and loads from "device registers". Typically, these "registers" have no physical existence at either end; one end has a CPU issuing commands and the other end receives commands and executes switch statements. Register definitions are supposed to be standardized; in practice, the standards are more ambiguous than they should be. This results in FireWire devices coming with unnecessary "drivers". A command/response protocol like SCSI would have been far better. With the current system, generic drivers are hard.

    There's already Ethernet on top of FireWire, SCSI on top of FireWire, and raw IP on top of FireWire. This is too much layering of pure packet protocols.

    • I don't really see the problem with using a scheme like device registers. It makes it very easy to do a simple hardware implementation of the front of the protocol and it certainly does not make it difficult to do it in software.

      I also don't see what's wrong with layering protocols over one another if they work, especially if they're simple. It's somewhat offensive to have a lot of really complex protocols layered on one another because each of them is difficult to grasp the whole of. Firewire sounds pret

  • if yes, then it is a crime and must be banned!

  • Only in the US... (Score:1, Offtopic)

    by ischorr ( 657205 )
    "Of course Bluetooth is only now just catching on, so imagine how long it'll be before this becomes practical."

    Bluetooth "caught on" in Europe quite a while back. It's just us backwards Americans that are just now figuring out Bluetooth and GSM (and I don't think we'll EVER move metric..)

  • Call me paranoid. (Score:3, Interesting)

    by Nathan Ramella ( 629875 ) on Wednesday May 07, 2003 @05:43PM (#5905956) Homepage
    But, sometimes it bothers me to think that 200 years ago that the only radiowaves we were subjected to were ones from space.

    Does it really seem healthy to be constantly bombarded with gigabits of data?

    Any tinfoil hat people out there that do tailoring? -n

  • Good news, everyone! (Score:3, Funny)

    by jmoriarty ( 179788 ) on Wednesday May 07, 2003 @05:52PM (#5906010)
    I was worried I would have to wait years for WiFi and cell phones to give me brain cancer.

    This should move up my timetable considerably AND increase the number of locations in my home I can place the HDTV that I cannot yet afford. Bonus!
  • other than for laptops, at our company, (a small consulting firm, that helps other small buisnesses with their computing needs) we have found wireless to be awaste of money. issues with configurations, signal strength, security conserns, costs and lack of speed keeps everyone away. Our personal view is until can get gigabit wireless for the same price as wired, then wireless is mostly a gadget, reserved for the gotta have it croud, before you flame me for saying that, think about it. in a buisness environm
    • I would say that there is plenty of potential applications for wireless.

      Compare the cost of the wireless with paying to have a company come in and wire the building.

      Or how about for a point to point WAN with two buildings in the same city?

      Or for consultants so you can segment them off from the rest of your network?

      Or for a company that has most of its employees out where wires are out of the question (a landfill comes to mind)?

      How about in a warehouse where wireless scanners are the norm?

      How about a b

  • What shall we call it? (Score:5, Funny)

    by evilviper ( 135110 ) on Wednesday May 07, 2003 @06:57PM (#5906494) Journal
    Well, it's based on Firewire, but there's no wire... It travels through the air with no wire, kinda like a bird.

    I've got it, let's call it "FireBird"... I can't forsee any problems with using that name, and I've done months of research...
  • This will obviously be marketed by Apple as 'firewireless,' or maybe just 'fireless' until the mainstream public/press catches on, when the same wizards who brought you 'wireless fidelity' will start touting the cool features of 'fi-fi.'

    Shoot me now.

    never underestimate the powers of condescension - it knows not the bounds of time or space
  • The broadcast industry is already performing digital transmission of some television signals in some markets. By a certain date, all transmissions will have to be digital per FCC regulation. Whether or not a digital signal is HDTV or not depends on how many digital transmission channels a certain broadcaster want to utilize for a given broadcast. This means that digital TV signals come in several flavors depending on the content, and some carry HDTV feeds. Since these signals are broadcast they are, by
  • 100Mbps? 400Mbps? These are still too slow.

    1024*768*32*75=1887436800

    In other words, we need at least 1.75Gbps before I can play battlefield or raven shield with decent settings on a remote monitor. To play it at a better res (1600x1200), we'd need over twice that (4.29Gbps). Add the keyboard, mouse, etc. to the same link, and a few hundred Mbps for inter-computer communications, and I'd say that 5Gbps would be a good figure to look for before we can finally have completely wireless PCs.

    Well, excep

    • Re:Still too slow. (Score:3, Informative)

      by jandrese ( 485 ) *
      You may have heard of this nifty new technology called "compression" that allows you to get more effective data transfer out of a link. 10:1 compression on video is pretty trivial these days, which means you'd only need 175Mbps for that resolution (although you'd probably drop it down to 24 bit color).
      • 10:1 compression on video is pretty trivial these days, which means you'd only need 175Mbps for that resolution (although you'd probably drop it down to 24 bit color).

        I'm very interested in this. Please post a link to your 10:1 realtime effectively lossless video compression method, I'm sure the divx and xvid folks would be extremely excited over it.

        • Re:Still too slow. (Score:3, Informative)

          by Tyler Eaves ( 344284 )
          DivX is *VERY* high compression.

          Think for a sec.

          Let's use 640x480 as a sample res, 16 bit color, 30 fps.

          640*480*16*30 = 147,456,000. 147Mbit/sec. Without audio. Most DivX files are on the order of 0.5 - 1MB/sec. With Audio. That's 150:1 to 300:1 compression.
          • Yes, you're right. However, it's extremely lossy, and nowhere near fast enough to run in real time on even a high end computer at the same time as an intensive video game, which was the point I was trying to make. If you could do effectively lossless 10:1 compression in real time, I would be impressed. That's what I'd like to see a link to. (Even more impressed if you could do with little enough cpu to make it practical for the application we're talking about, which if you'll recall was wireless monitor
            • Two Words: Hardware implementation.

              Hell, for most screens (But not a game, probably) a simple run length encoding scheme would get you close to, if not over 10:1

          • Re:Still too slow. (Score:2, Informative)

            by vigata ( 608523 )
            DivX/XviD/MPEG are all lossy codecs for natural looking video images. The math above just does not apply if you are thinking of a remote monitor situation.
            You can already do a remote desktop with Remote Desktop Protocol on Windows XP at 802.11b speeds.
    • You know, blasphemy of blasphemies, it need not all be digital.

      Remember, the signal going to your monitor is in all likelihood just analogue data. All you really need is three analogue signals -- red, green, blue. Perhaps use the traditional "vertical blank interrupt" period to handshake with the monitor to keep it in synch.

    • Firewire is supposed to hit 3.2Gbps by 2005 or something. Look it up, I'm too lazy. I looked it up once already. They plan to do it with some funky connector with one piece of fiber and four electrical conductors, mostly for power I think. Hopefully they will drop power to two wires, or drop it entirely.

  • zzzzzzzz (Score:3, Informative)

    by ubiquitin ( 28396 ) * on Wednesday May 07, 2003 @08:08PM (#5906878) Homepage Journal
    Ever heard of 802.16 [80216news.com]? Seriously, the microwave folks have been doing point to point wireless to project mad bandwidth across serious distances for a LONG time.

  • A couple of facts (Score:5, Informative)

    by bryan1945 ( 301828 ) on Wednesday May 07, 2003 @08:12PM (#5906901) Journal
    I am a member of the IEEE Standards Association, and I've spent the last month writing a paper on WLANs.

    1)802.15.3 IS Ultra WideBand.
    2)The FCC has basically crippled the original version of this tech.
    3)Cellular providers & GPS want their freqs eliminated from this (UWB goes from 3-10 GHz)
    4)The original spec only went to 100 Mbps, and there is no official working group trying to expand this.
    5)The outermost range is 10 meters, while 802.11 can max out at 100 meters. Great leapfrog action!
    6)Only 4 companies can currently produce UWB devices- 3 for imaging systems and 1 for some kind of "toilet device". (seriously! but I couldn't find any more enough about this toilet thing)
    7)Thomson's 802.11a & HiperLan product has nothing to do with UWB, yet they quote 802.15.3 (see #1)
    8)TOTAL HORSESHIT STORY

    Happy day!

  • "Of course Bluetooth is only now just catching on, so imagine how long it'll be before this becomes practical."

    There is a big factor in the adoption of Bluetooth:

    No one wanted it. :)
  • I'm definitely going to buy it when it comes. Now I can hold LAN's between my friends without a high ping.

    However, I think some ISP's with game servers would want to have a good hard look at this technology. It could help keep the bandwith choke down in metro areas
  • i guess i have microwaves absorbing into my flesh at this very moment, and 100Mbps is very fast for wireless.

  • Nomenclature (Score:3, Funny)

    by alexburke ( 119254 ) * <.ac.ekrubxela. .ta. .todhsals+xela.> on Wednesday May 07, 2003 @10:26PM (#5907675)
    Instantly "Firewireless" popped into my mind, but that just doesn't have the same ring to it...

    And where the hell has the "Post Anonymously" box gone?!

  • mbps? (Score:1)

    by _Splat ( 22170 )
    mbps? Like 1 x 10^-3 bps? Thats some slow-assed connection.

  • So 802.11 is at 54mb, and they want to "leapfrog" it by going to 100 sometime, and 400 sometime later.

    Since 54mb devices are already common and faster 802.11 will undoubtedly follow, how do they plan to "leapfrog" it?
  • In the US, HD DTV terrestrial broadcasts are done with a MPEG-2 transport stream of maximum 19.39 Mbps using the ATSC standard. [atsc.org]

    In practice, most people will be receiving HD at slightly lower speeds to allow a multiplexed SD feed (2-4 Mbps) in the ATSC channel along with the HD feed (15-17 Mbps)

    I am under the impression that most DBS HD will also be in the 10-20 Mbps department. HDNet programming varies from 10 Mbps to 18 Mbps, while DBS HBO HD only goes up to 15 Mbps.

    Uncompressed HD is somewhere around
  • Initially 100mbps but aiming for 400mbps.

    802.11b supports speeds up to 11Mbps, and 802.11a supports up to 54Mbps. Rates of less than 1 bit per second don't sound like much of a "leapfrog over 802.11" to me.

Slashdot Top Deals

A fail-safe circuit will destroy others. -- Klipstein

Close