Forgot your password?

USB To Go Wireless 212

Posted by Zonk
from the realizing-the-bluetooth-dream dept.
Troy Samuel writes "The WiMedia Alliance is planning to make the technology known as 'ultrawideband,' or UWB, work among a wide variety of consumer electronics devices. Various organizations, including the Bluetooth SIG, have chosen the WiMedia Alliance's version of UWB technology as the foundation for a next-generation short-range networking technology." From the article: "UWB technology can deliver data rates at up to 480 megabits per second at around 3 meters, with speeds dropping off as the range grows to a limit of about 10 meters. Real-world speeds will probably be a little slower, but this is as fast as the wired version of USB 2.0 and much faster than current Wi-Fi networks are capable of transmitting data. 'This stuff is plumbing,' Roger Kay, an analyst with Endpoint Technologies Associates, said of the newer-generation wireless technology. 'It's important that it be there, it's going to be handy for getting rid of cables hanging around your desk.'"
This discussion has been archived. No new comments can be posted.

USB To Go Wireless

Comments Filter:
  • by b-l4ke (997876) on Wednesday October 18, 2006 @05:28PM (#16492511) Homepage
    1600 x 1200 x 32bpp per pixel x 30 fps = 1.85 Gbps
  • by Name Anonymous (850635) on Wednesday October 18, 2006 @05:30PM (#16492531)
    Double that at least as computer displays run at 60+ fps
  • by Dunbal (464142) on Wednesday October 18, 2006 @05:30PM (#16492535)
    how much bandwidth is required to make a wireless monitor? Let's say its running at 1600x1200 with 24bit color.

          The answer is right there. 1600 x 1200 x 24 = 46,080,000 bits per frame (46Mb) - not including any overhead for packing/unpacking all this info. Now how many frames per second did you want?
  • by 56ker (566853) on Wednesday October 18, 2006 @05:30PM (#16492537) Homepage Journal
    24 bits = 3 bytes
    3 bytes * 1200 * 1600 = 5.76 Megabytes

    Assuming a refresh rate of 50fps that's 288 Megabyte/second or 2.25 Gigabits/second A monitor's a rather pointless one though as it requires a cable for the power.
  • Re:A good fit? (Score:5, Informative)

    by Animats (122034) on Wednesday October 18, 2006 @06:15PM (#16493143) Homepage

    symmetric peer-to-peer interfaces like that provided by Firewire.

    Firewire actually has rather strong master/slave relationships; there's a tree, and a tree root, and a master node. But there's a negotiation process during hot-plugging which establishes the master/slave relationships.

    One big problem with Firewire is that it doesn't have a notion of device ownership. You can plug two computers together with FireWire, and that will work if both machines support IP or Ethernet over FireWire. But plug a peripheral into the same bus, and there's no mechanism to allocate it to a unique host computer. You'll get a control clash.

    Underneath, FireWire isn't really a "bus". It's actually a local area network, and its controllers work more like Ethernet controllers, with packets and buffer chains, than bus adapters.

    The "bus" aspect is that there are defined packet formats for loading and storing 32-bit data items in a 64 bit address space. In practice, though, what usually happens is that at the host end, some code formats such a packet, saying "set bit 22 of register 0x2490 at node 3", and when that packet gets to node 3, some little CPU in the peripheral decodes the packet, acknowledges receipt of the packet, a switch statement decodes the "register" address, and code notes that bit 22 means "turn camera on". No status for this event comes back; the host has to send a packet to "read" some other device register to find out what happened.

    Giving FireWire a "device register" model turned out, in the end, to be kind of silly. Something more like SCSI, with function codes and statuses, would have made more sense. (And, in fact, there's SCSI over FireWire.) You'd get back better status info, and devices which don't implement some functions would have a simple way to report that. This makes it easier to implement generic drivers, reducing the temptation to have to have a special driver for every manufacturer's device. And we all know where that leads.

    So if you're designing something like this, don't go with a device register model. Anything smart enough to talk it will have a CPU, so use it.

  • Except... (Score:3, Informative)

    by Junta (36770) on Wednesday October 18, 2006 @06:41PM (#16493457)
    Copper pennies aren't made anymore, because, you guessed it, the amount of copper required to make a penny is worth more than 1c, so if they made copper pennies you'd be theoretically better off melting them down and selling the raw material...
  • by monsted (6709) on Thursday October 19, 2006 @06:21AM (#16498977)
    In the case of computer monitors with a variable input signal, it does actually show 60/85/whatever distinct pictures per second (although some may be the same if your app isn't fast enough to update the frame buffer).

Dreams are free, but you get soaked on the connect time.