Sign in

username:

password:



Not a member?

Search Comp.Arch.Embedded



Search tips

embedded by Keywords

68HC11 | 68HC12 | 8051 | 8052 | ARM | ARM7 | Asic | AT91 | AT91RM9200 | Atmel | AVR | AVRStudio | Bootloader | CFP | CompactFlash | Cygnal | Cypress | Dataflash | DSP | eCos | EEPROM | Embedded Linux | Emulator | Endian | Ethernet | Firewire | FPGA | Freescale | GCC | GNUARM | GSM | H8 | HDLC | I2C | Infineon | Interrupts | Java | JTAG | LCD | LED | LPC2000 | MCU | Microchip | MMC | MPLAB | MSP430 | PC104 | PCB | PCI | PCMCIA | PowerPC | Rabbit | RS232 | RS485 | RTOS | SBC | SDRAM | Sensor | SPI | STK500 | UART | UML | USART | USB | Verilog | VHDL | VxWorks | Xilinx

Ads

Discussion Groups

Discussion Groups | Comp.Arch.Embedded | Large Wireless networks?

There are 15 messages in this thread.

You are currently looking at messages 10 to 15.

Re: Large Wireless networks? - Paul Keinanen - 02:30 25-04-08

On Thu, 24 Apr 2008 22:55:48 +0200, Hans-Bernhard Bröker
<H...@t-online.de> wrote:

>Vladimir Vassilevsky wrote:
>
>>  The task is to create a large (up to 10k nodes) ad-hoc wireless 
>> network   covering the area of several sq. km, so there is a need for 
>> many retransmission hops. 
>

>> The master needs to collect the  information (~100 
>> bytes) from the each node once in a while, however it is desired that 
>> the whole network could be polled in the time of 15 minutes.

Thus you have to allocate 900 s/10000 = 90 ms for each node.

Since each node needs to send 100 bytes in 90 ms, that is about 1.1
kbit/s

>So the master needs 1 Mbyte/s of bandwidth --- so will the individual 
>nodes, because any of them may have to be able to bridge large parts of 
>the master's throughput.  That runs seriously afoul of this requirement:
>
>> Power consumption does matter; that rules out the 802.11x.

Only a few kilobits/secon would be required by the master.

However, if a mesh network is used, with say 100 hops on average, the
total data transfer requirement is several hundred kilobits/s in the
area, translating to hundreds of kHz of frequency space. Hills and
other obstacles may shadow other areas, so the same frequency may be
reused on both sides of the obstacle, as long as the transmitted power
is kept sufficiently low. Of course a different frequency is needed to
route traffic around the obstacle.

In order to keep the total frequency requirement to a minimum, the
data should be delivered to the final destination with a low number of
hops, so in practice, some degree of node hierarchy is required.

Paul




Re: Large Wireless networks? - Rene Tschaggelar - 08:46 25-04-08

Vladimir Vassilevsky wrote:

> 
>  The task is to create a large (up to 10k nodes) ad-hoc wireless 
> network   covering the area of several sq. km, so there is a need for 
> many retransmission hops. The nodes are not moving; however the network 
> should be able to reconfigure itself once a node is added or deleted. 
> The communication in the network is always initiated by a single 
> dedicated master. The master needs to collect the  information (~100 
> bytes) from the each node once in a while, however it is desired that 
> the whole network could be polled in the time of 15 minutes. Power 
> consumption does matter; that rules out the 802.11x.
> 
> I am looking for the module level solution which would allow to 
> implement this network with the minimum hassle. Designing the networking 
> protocols is something that I would really like to avoid.
> 
> The candidate technology could be ZigBee; however I have big doubts 
> about the scalability to 10k nodes. There are some proprietary and 
> semi-proprietary solutions on the market; however it looks like they 
> never tested it with more then 20...30 nodes.
> 
> Can you suggest a more or less proven solution for that type of 
> application?

Proven solution... I worked with similar stuff
powerline based. I doubt there is a proven solution.
That kind of application requires some thinking
and a protocol of your own. You won't be able to
make it with a single master as the time slot for
each slave is too short. Drop some meshing-intelligence
into each node such that the data can be transmitted
through the mesh by the mesh.
I'd favour Zigbee for the simple connection logic
if the frequency range is acceptable. Otherwise grab
some modules in the 433 or 866MHz range. The number
of nodes in a single net hint for greater production
series, meaning there is some money around. It wouldn't
happen to be the container industry ?

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

Re: Large Wireless networks? - =?ISO-8859-1?Q?Hans-Bernhard_Br=F6ker?= - 15:20 25-04-08

Paul Keinanen wrote:
> On Thu, 24 Apr 2008 22:55:48 +0200, Hans-Bernhard Bröker
> <H...@t-online.de> wrote:
> 
>> Vladimir Vassilevsky wrote:
>>
>>>  The task is to create a large (up to 10k nodes) ad-hoc wireless 
>>> network   covering the area of several sq. km, so there is a need for 
>>> many retransmission hops. 
> 
>>> The master needs to collect the  information (~100 
>>> bytes) from the each node once in a while, however it is desired that 
>>> the whole network could be polled in the time of 15 minutes.
> 
> Thus you have to allocate 900 s/10000 = 90 ms for each node.
> 
> Since each node needs to send 100 bytes in 90 ms, that is about 1.1
> kbit/s

Turn's out we're _both_ wrong.  I by 3 orders of magnitude, you by one.

It's actually 1.1 k_Bytes_ per second, which makes for 10 kbit/s, not one.

Re: Large Wireless networks? - Tom - 23:01 27-04-08

In article <EpSPj.236$5...@newssvr27.news.prodigy.net>, Vladimir Vassilevsky
<a...@hotmail.com> wrote:
>
>  The task is to create a large (up to 10k nodes) ad-hoc wireless 
>network   covering the area of several sq. km, so there is a need for 
>many retransmission hops. The nodes are not moving; however the network 
>should be able to reconfigure itself once a node is added or deleted. 
>The communication in the network is always initiated by a single 
>dedicated master. The master needs to collect the  information (~100 
>bytes) from the each node once in a while, however it is desired that 
>the whole network could be polled in the time of 15 minutes. Power 
>consumption does matter; that rules out the 802.11x.
>
>I am looking for the module level solution which would allow to 
>implement this network with the minimum hassle. Designing the networking 
>protocols is something that I would really like to avoid.
>
>The candidate technology could be ZigBee; however I have big doubts 
>about the scalability to 10k nodes. There are some proprietary and 
>semi-proprietary solutions on the market; however it looks like they 
>never tested it with more then 20...30 nodes.
>
>Can you suggest a more or less proven solution for that type of application?

I could have suggested one about 14 years ago, the company that I used to work 
for was doing exactly the same thing. The transceivers were custom designed, 
and so was the protocol. There was extensive research and modeling done on 
various geography, terrain, device spacing and clustering etc. There was no 
off-the-shelf solution at that time that would be effective for those kinds of 
numbers and data rates. Here are a few points about the network that I do 
remember (the company itself is long gone).

- Forget trying to do this with unlicensed ISM bands. There is too much 
potential interference (especially in residential environments) and your 
network could end up fragmented. Pay the $70 per year to get your own 5 kHz 
UHF channel just like local couriers and flower delivery guys do. This also 
allows you to use much more transmit power.

- The entire network was based on a fairly straightforward TDMA scheme,  
synchrnonized by the master. Each new node would start by listening for quiet 
timeslots, and then attempt to claim one of those slots until it got an 
acknowledgement from the master. Once it found a good slot it would keep it 
until the master stopped acknowledging. This worked out surprisingly well; 
nodes that were the furthest apart would end up claiming the same timeslots.

- Because the data payload itself was small compared to protocol overhead, 
each node could act as an aggregator that would collect upto three reports 
from adjacent nodes and then send them off to the master. It was common for 
the master to receive several copies of the same report from the same device.

- When the system was deployed over very hilly terrain, it was common to place 
one or two dummy nodes on top of the hill that just acted as aggregators.

--Tom.

Re: Large Wireless networks? - Paul Keinanen - 01:02 28-04-08

On Mon, 28 Apr 2008 03:01:28 GMT, t...@nospam.com (Tom) wrote:


>- Forget trying to do this with unlicensed ISM bands. There is too much 
>potential interference (especially in residential environments) and your 
>network could end up fragmented. 

That is a good advice. At least in Europe, there can be strong (1 W -
to 10 kW EiRP) amateur radio signals in the 433 MHz ISM band. Even if
the interfering signal is not at exactly the same frequency as your
network, the bad front end selectivity and bad large signal handling
(especially with receivers with low power consumption) may block a
simple receiver. 

Many car keys operate in the 433 MHz band and if there is an active
amateur radio transmitter nearby, you may have to move your keys close
to the windscreen to get the doors opened :-), while normally the keys
work fine from a distance of several meters.
  
>Pay the $70 per year to get your own 5 kHz 
>UHF channel just like local couriers and flower delivery guys do. This also 
>allows you to use much more transmit power.

The OP would need quite a lot larger bandwidth, since the net
throughput would be 10 kbit/s and using anything past QPSK would
require more transmitted power and complexity, which usually also
increases the power consumption. Doing aggregation or even a complete
mesh network would increase the need for frequencies many times.

>- The entire network was based on a fairly straightforward TDMA scheme,  
>synchrnonized by the master. Each new node would start by listening for quiet 
>timeslots, and then attempt to claim one of those slots until it got an 
>acknowledgement from the master. Once it found a good slot it would keep it 
>until the master stopped acknowledging. This worked out surprisingly well; 
>nodes that were the furthest apart would end up claiming the same timeslots.

This is the well known "hidden transmitter" problem. One way around
would be to assign some fixed time slots for just monitoring for new
devices and a new station would claim access in one of these slots
either based of the last digit in the serial number, the hash of the
serial number or try different slots randomly in each poll. The master
would upon receiving a clean request assign an ordinary slot to that
node. 

>- Because the data payload itself was small compared to protocol overhead, 
>each node could act as an aggregator that would collect upto three reports 
>from adjacent nodes and then send them off to the master. It was common for 
>the master to receive several copies of the same report from the same device.

This will increase the need for the total bandwidth, but if this is
not an issue, the uplink to the master could be on a different
frequency and use very low power to collect data from the neighboring
nodes on some other frequency.

Paul


previous | 1 | 2