Feasibility of the VERY low power wireless network?

There is a network of ~100 wireless sensors, communicating to a single host. All sensors are located within ~50..100m from the host in the typical urban environment. Ideally, it would be desirable to poll each sensor at least 10 times/sec. When polling the sensors, we have to get just several bits of the status information from each sensor.

Problem: as sensors are battery powered, the average power consumption of the entire communication part of a sensor is limited to ~ 10mW max.

Is there a wireless technology/modules on the market that would allow such power budget?

Would it be possible to develop such technology using existing transceiver ICs or modules?

(Cost, operating band, compliance, acceptance, etc. are outside of consideration at this point).

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky
Loading thread data ...

Zigbee?

Reply to
Mostafa Kassem

Anything but low power.

Reply to
linnix

What is the real time requirement ?

TinyOS maybe what your looking for.

A google search for "wireless sensor networks" found this:

formatting link

as well as almost 1 million others.

hamilton

Reply to
hamilton

OP said 10Hz data.

not addressing the real problem.

Powering the transmitter constantly will drain any kind of OS/battery.

Reply to
linnix

Idiot

Reply to
Vladimir Vassilevsky

this:

formatting link

Some of the links above do target the power issue.

My real time question was for data integrity not data speed.

If each node sends 10 samples every second, rather than one sample 10 times a second, would that suffice.

formatting link

This would help with the overall power, as each node only has to talk with the next node not the remote host.

I had the opportunity to work with a water utility manufacture. The remote devices ( water meters ) needed to last 5-8 years in the ground. It used a single 3Volt lithium C-cell. They transmitted a low power signal once every 3 seconds for 100 uSec. This chirp would tell a roving receiver that it was within range. The roving receiver would then ask that meter to dump its entire data (a months worth).

The rest of the time it powered down to

Reply to
hamilton

e
h
t
n
.

yep, only some kinda high-powered RFID/'toll-tag' approach where the sensor is powered by the interrogating signal or solar powered/backed- up sensors ????

and 'sorting'/ID'ing the responses could get tricky i suppose.

Maybe use cellphone or other radio technology (ultrasonic burst?) to 'wake'/enable the sensors in an 'area', then shut them off and move on?

Reply to
1 Lucky Texan

100 sensors at 10Hz means 1,000 samples per second. If they occupy the same bandwith, each sensor has to power up, sync, and transmit in 1mSec. If it is really a polled network, you have to subtract from the millisecond, the time for the polling signal.

At 3.3V, that's only 3.3mA. That seems hardly enough to keep a receiver running all the time and to transmit occasionally at 10 to 50mA.

Are there any time-division systems where the host sends a broadcast polling command and each sensor transmits at a defined time slot offset from the polling? That means that after the polling command is received, both transmitter and receiver could shut down until time to send, then wake up the receiver until just before the next polling signal.

Does the system really respond to the sensors in 100mSec? If not, would it be possible to poll each sensor every 10 seconds and have it return 100 readings? With a lower transmit duty cycle, you might meet the power constraints. The host could then assemble a continuous record with 10 seconds of delay.

Mark Borgerson

Reply to
Mark Borgerson

Presumably, you want ~100ms latency and not just "10Hz rate" (i.e., you can't pack/compress data in the mote and then deliver it "less often")

Do the sensors *have* to talk to that single host? What constraints are there on the actual topography of "mote deployment"? E.g., are they evenly distributed in a "50-100m" radius? Or, are they clumped in (arbitrary) areas? (e.g., could you use a mesh to reduce the range each device has to handle)

What if a device fails to answer its poll? Is there some system cost to this?

Instead of an "interactive" poll, consider synchronizing (short term) all of the nodes and assigning timeslots to each mote. Instead of polling each *individual* mote, the host can be seen as "polling the network". If you can tolerate *not* getting a response from a mote, then this can be exploited in the mote: "don't power up the transmitter if you don't have anything interesting to say" (since you know how the host will interpret your silence). Couple this with a periodic "are you still there" polling beacon (which "requires" acknowledgement)

You can include this coupled with a mechanism to specifically talk to a *particular* mote. This gives you a way of listening to the "field" and still interacting with specific parts of it in more "directed" ways.

Can you migrate "parts of the application" into the mote to reduce it's need for communication with the "host"? I.e., what if the mote *doesn't* get a chance to upload its observation(s) to the host... does it just discard them or can it act on them?

What is the cost to replace the battery (i.e., can you increase the power budget or are there other factors driving that figure)?

I'm using bits of "all of the above" to drive my Pd down (though most of my motes don't *have* to look at data at

10Hz/24/7). Note that some of these issues also improve reliability of the "network" and, thus, "system".
Reply to
D Yuniskis

I agree here - the aim should be to keep the receiver powered-down most of the time. If you can keep the receiver active time to under 10% duty cycle, that gives you 33 mA when active, which should be plenty. Transmission costs should be low using short, high-speed bursts of data.

This is definitely the way to do it, if that suits the application. For short messages, it is the protocol and message overhead that is the real power-drain - wake-up, synchronisation, preambles, acknowledge messages, etc., are all much power power-consuming than the actual few bytes of sensor data.

Reply to
David Brown

Le 06/01/2011 04:09, Vladimir Vassilevsky a écrit :

Assuming wireless sensors wake up from "idle-state" (few hundred nA) to "run state" (20-30mA) ten times per seconds, you have to compute the total time of run-state during 1s to achieve 10mW.

i.e : ---- idle for 90ms ---- run for 10ms ---- idle for 90ms ---- run for 10ms --- ....

BTW i'm not sure that nowadays wireless transceivers can reach such time budget, especially i think 10ms is too short to exit from the idle state to run-state (clocks time stabilisation ...etc.)

Is that correct Vlad ?

Reply to
h.bouazizviallet

What does several bits mean ? 10 ? 100 ? or what amount of bits.

With 100 sensors, the receiver bandwidth would have to be several kHz i.e. in the same order of magnitude as two way handheld radios, which require at least -120 dBm for reliable reception in quiet areas.

The free space loss is inversely proportional to the square of distance, so with omnidirectional antennas at 433 MHz, the path loss is about 65 dB at 100 m, thus a peak transmitter power of -55 dBm would be sufficient.

However, in real world urban environment, the signal drop is more like inversely proportional of the fourth power of distance, thus the signal drops about 12 dB with each doubling of distance.

Thus, using multiple receiving antennas on the master at different locations in order to halving the RF path from each sensor, will drop the Tx power requirement well below 1/10 compared to a single antenna..

Keeping the sensor receiver active only during the expected synchronization time will also help in saving power.

Reply to
upsidedown

Why do they need to be battery powered?

Although I'm not a friend of it, technology exists to transmit enough power over this distance.

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz

e
h
t
n
.

it of course depends on how you use it but if zigbee isn't low power what is then?

-Lasse

Reply to
langwadt

gle

ach

get

ion

ax.

ow

ZigBee takes around 50mW to 100mW, so it won't be low power by itself. If OP can limit RF duty to less than 10%, then it might be possible.

Reply to
linnix

Why does anyone respond to this guy? When others ask questions rather than give even the least answer or any encouragement he derides them. When he asks questions and others respond, if he doesn't like the response, he derides them rather than thanking them and moving on or even just ignoring them.

Why does anyone think this guy deserves any sort of response when he is asking for help?

Rick

Reply to
rickman

le

ch

et

on

x.

w

Actually, even though the OP is a bit surly, his point-of-view and statements are often very valuable to me. Secondarily, I also thought the "1 million google responses" thing was small-brained since the post started out looking for very low power wireless and not wireless in general.

Reply to
Chris_99

The ATmega128RFA1 (ZigBee + 128kB Flash AVR) uses about 26 mW during transmission and a little bit lower during reception.

--
Best Regards
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

gle

ach

get

ion

ax.

ow

Atmega128RF runs at 8MHz with 30mW and 16MHz with 50mW. EM351 (128K ARM M3) runs at 24MHz with 50mW.

But Atmega128RF is not available on Digikey yet.

Reply to
linnix

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.