Large Wireless networks?

With those requirements the master can spend only 100 ms with each slave. Assuming some timeouts and retransmissions, this is quite hard, even if the data rate is quite low.

In practice, you will need some kind of hierarchial systems, with data concentrators and thus different frequency channels (or CDMA sequences).

Since the slaves are not mobile, it would help a lot (in throughput and power consumption), if you could assign a frequency channel (and thus a concentrator) based on the approximate geographical location.

Paul

While I would probably be amused by that section. No, I am not applying for anything. However, you have omitted some critical information, such as communication rate over the network, and communication density. From your numbers addressing requires at least a 14 bit unsigned quantity. Polling 10k items in 15 minutes from a single point leaves an absolute max of 9000 / 10k ~= 1 sec per poll. That ignores any retransmissions needed. Sounds like the addresses have to be position dependant. These are just initial thoughts.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.


** Posted from http://www.teranews.com **

"Vladimir Vassilevsky" a écrit dans le message de news: EpSPj.236$ snipped-for-privacy@newssvr27.news.prodigy.net...

Hi Vladimir, We are right now developping a quite similar project. Constraints on our project were to get short data messages from up to 1000 moving nodes in "real time", meaning no longer than 20 seconds for the 1000 nodes, with low power consumption (around 1mA average). We quicly concluded that no standard protocol was applicable, and in particular not Zigbee due to the heavy dataflow and node count. We (unfortunatly) ended up with the design of a custom TDMA & FDMA protocol working in the 868MHz european ISM band, with a lot of cautions regarding regulatory frequency use constraints (duty cycle, etc). In order to reduce power the only reasonnable solution was however to allow the end node to initiate the communication. Design is still on going but that's a really interesting kind of project... Yours,

--
Robert Lacoste
ALCIOM - The mixed signal experts
www.alciom.com

You must have short seconds where you live, if you managed to get 9000 into 15 minutes :-).

In any half-duplex protocol, the Rx/Tx turnaround delay is critical in order to get a decent throughput. Any receiver with ordinary IF and a single PLL frequency synthesizer should be avoided, since the PLL would have to swing from the Rx local oscillator frequency to the transmit frequency, which can take a quite long time, before the transmission can begin. Using a zero-IF receiver or separate PLLs for Rx and Tx would be OK.

One way to reduce the effects of Rx/Tx delays would be to use a TDMA system, in which the master sends a common sync message and each slave has a time slot based on the node-ID in which it has to transmit. The distances in the OP's case are so small, that the two-way propagation delay is only a few microseconds, so you do not have to leave large guard bands into the slot or use some GSM style propagation delay compensation.

In TDMA or ordinary master/slave systems, in order to reduce the slave power consumption, the master should use a fixed poll cycle, thus the slave receiver could be turned of for most of the polling cycle and be activated just slightly prior to the expected poll to this slave (as in DVB-H).

Paul

Yeah, we specialize in deci-secs. :-)

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.


** Posted from http://www.teranews.com **

Vladimir Vassilevsky wrote: >

Consider trying

They may have an off-the-shelf answer. I don't work for them or represent them in any way. I am not overly familiar with their offerings.

I used one of their products to implement a custom solution years ago. Their product was solid and easy to use.

Cheers, Jody

Un bel giorno Vladimir Vassilevsky digitò:

Define "matter". :) If something near to 30 mW is acceptable, the easiest and ready-to-go solution is to use some RF chip with embedded packet handling, for example the Nordic chips (nRF24L01, or nRF24LU1 if costs requirements are tight and an 8051 MCU is enough).

Scalability doesn't look to be a problem, if you have a point-multipoint architecture (a single master). IIRC the entire send-acknowlesge sequence of nRF24L01's proprietary protocol needs something in the range 1-10 ms, depending on how many retransmissions you set.

--
emboliaschizoide.splinder.com

That, and considerable transmission strength even for individual hops.

10k nodes spread over several km^2 means you're looking at over 20 meters average node distance --- each node has several 100 m^2 to itself!

That's a bad idea, I think. It doubles the network's latency for no positive effect.

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:

Well, you'll need a good part of its bandwidth, more than its (reliable) distance, and way more than its capacity in terms of number of nodes in the net. In other words, you're trying to put to shame an entire industry that is putting a lot of time and money into out-performing each other on all these aspects. Good luck --- you'll need it

Un bel giorno dalai lamah digitò:

Ooops, I didn't notice the multiple hops thing. It's much easier if you can install a big and high antenna on the master station so that you can separately contact every client. "Several square kilometers" could mean a maximum distance of 2-3 km from the master station; I think that it's a lot easier to find a way to reach that range obeying the ITU/FCC/etc rules on tx power, rather than building a complex mesh network with 10k clients based on a trivial, lightweight protocol. Using the 868/900 MHz ISM band instead of the 2.4 GHz band could help.

--
emboliaschizoide.splinder.com

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

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

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

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.

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.

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.

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.

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.

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