The Chinese Solar Machine Layer by Layer Fire in the Library The Mystery Behind Anesthesia
Mesh together: This prototype relay node, developed by NIST, features an LED that automatically changes from green to red whenever a new node needs to be set down.
NIST
Ad-hoc wireless networks may soon tell emergency workers how to deploy transmitters.
Building an on-the-fly wireless communications networks is a vital part of firefighting, handling hostage situations, and dealing with other emergencies. But it is difficult to build such networks quickly and reliably.
Soon these emergency wireless networks could help build themselves. The National Institute of Standards and Technology (NIST) recently presented details of two experimental networks that tell emergency workers when to set down wireless transmitters to ensure a good signal.
Ad hoc wireless networks relay messages between transmitters, or nodes, without requiring any central control. But as things stand, emergency workers simply follow suggested guidelines for building such a wireless network--placing each node 15 or 30 meters apart and at key points, like the corners of a building. Or they periodically check back with the command center to make sure they're still in touch. Neither method is terribly efficient in an emergency, however. The process can also be costly if a large number of nodes are used.
The NIST prototypes, which have been under development for more than three years, use algorithms to monitor the signal-to-noise ratio of transmissions and automatically warn when a new node should be set down.
"We didn't want to have fixed rules, because there can be a lot of metal in walls or cinder block," meaning signal strength varies building to building, says Nader Moayeri, a senior technical advisor in NIST's Advanced Network Technologies Division. "Plus, you don't want to deploy too many, because of the cost factor as well as potential for communication delays."
Moayeri says that NIST considered having nodes ping each other with short messages to see how many packets of data were lost in transit. The problem with this approach is that the person deploying the network would not detect a weak connection immediately and might have to backtrack. Having an algorithm measure the signal-to-noise ratio instead avoids this problem and provides a clearer picture of connection strength.
NIST built two prototype networks using off-the-shelf hardware. One operates at 900 megahertz and uses Crossbow MICA2 Motes to transmit radio signals. The other, a Wi-Fi network operating at 2.4 gigahertz , uses Linux-based Gumstix transmitters. But Moayeri says that the NIST algorithm should work with any wireless hardware and on any available spectrum.
In the Crossbow system, each node has an LED that automatically changes color, from green to red, when a new node needs to be set down. The Gumstix system issues alerts via a handheld or tablet computer connected to the same wireless network.
Manufacturing in the United States is in trouble. That's bad news not just for the country's economy but for the future of innovation.
This document is part of the “How-To Guide for Most Common Measurements” centralized resource portal. This tutorial provides a detailed guide for measurement and device considerations to take temperature measurements using thermocouples. Get an introduction to thermocouples, which are inexpensive sensing devices widely used with PC-based data acquisition systems. Also review some specific thermocouple examples and learn how thermocouples work and ways to integrate them into a data acquisition measurement system.
View full PDF >Our list of the 50 most innovative companies, including the following:
ms
190 Comments
35 kbps is plenty for voice
35 kbps should be quite sufficient for voice communication. The standard rate for landline-quality voice is 64kbps uncompressed, which reduces to around 7kbps when compressed by standard methods.
Reply
riparian
2 Comments
Re: 35 kbps is plenty for voice
I asked Nader Moayeri to take a look at this and respond. He sent me a response instead, which I am posting below. Michael Fitzgerald
Moayeri's comment:
this is a good question. However, this person is thinking point-to-point communications. If you have a single transmitter sending information to a single receiver, then a tranmission rate of 35 Kbps would certainly be adequate for sending voice. In fact, there are voice coders that code voice at 4 Kbps.
However, when you do VOIP (Voice Over IP), which is what's happening in our network, there is a good bit of overhead (packet headers, possibly retransmissions as a result of transmission errors, etc). Not only we are using VOIP, but this is also an ad hoc network. There is a lot of overhead associated with establishing multihop routes and maintaining them, because routes do break. That's why having voice communications over our the mote network we built is not possible even if we had used a 4 Kbps voice coder. (Right now we are using a 28 Kbps voice coder.)
Reply