USB To Go Wireless 212
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.'"
Re:Wireless Digital Monitor (Score:4, Informative)
Re:Wireless Digital Monitor (Score:2, Informative)
Re:Wireless Digital Monitor (Score:3, Informative)
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?
Re:Wireless Digital Monitor (Score:5, Informative)
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)
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)
Re:FPS != Refresh rate (Score:2, Informative)