Creating a wireless mesh from scratch

+42

Few clients want to be told what is painfully obvious to others from the outside. Esp as the folks making those decisions have the most to lose from the decision being exposed as "bad" (or, "not good").

One of the toughest lessons for contractors to learn is "walking away".

OK, let me step in and contribute some thoughts:

Background... a few years back AT&T got really active, going around my neighborhood stuffing equipment into their curb-side telephone boxes in preparation for their big push for Uverse. About that time I noticed that four WiFi APs appeared with no SSID and consecutive MAC addresses. I was without an explanation that didn't fall apart with the least little examination.

Not very long after, PG&E came around and installed their SmartMeters.

Then one day this summer I was reading the Wikipedia article on Mesh Networks when it hit me!! SmartMeters ---> stealth APs

en.wikipedia.org/wiki/Mesh_network (very much worth the read; lots of good links)

The meter on one house passes it's readings to meter on the next house who passes it down the street in the direction of the AP. TaDa!, no more meter readers.

So, this sounds similar to what your client is trying to do. Gain distance via mesh networking.

FYI: The SmartMeters (or the radio components) are made by

Silver Spring Networks FCC ID: OWS-NIC507 IC: 5975A-NIC507

en.wikipedia.org/wiki/Silver_Spring_Networks

I'll assume you know how to look up the FCC info.

--- news://freenews.netfront.net/ - complaints: snipped-for-privacy@netfront.net ---

AIUI Smart metes communicate using a zigbee mesh.

The client claims that their environment is too "noisy" for that to work

I cannot evaluate that claim as I have no idea what this "noise" is, but I think it reasonable to assume that they would embark on a million dollar spend on something new, if they hadn't done some proper benchmarking on the available off the shelf systems (BICBW)

tim

I don't know much about how these systems work, but I assumed:

1) that N3s would send their data to more than one N2 in order to be sure that it reaches N1 2) N2s would be sending their data to other N2s lest their link to N1 is broken.

And that N1 then has to determine if it gets the same data from N3 (or even worse older data later than newer data, via different routes) and arbitrate all of these conflicts.

And as, to get to the length required, the number of hops escalates up to

10, or even 20, the number of routes from N20, via multiple N19, multiple N18s etc becomes virtually unmanageable if you don't architect your solution correctly

And as I only had 30 seconds to think about this ..... I said no

tim

There's a device called "diims" is its a bike/boat/car etc. tracking device using Zigbee, they claim 2years on a coin cell and 200 meter range

It talks to master devices mounted on cars from the postal service

so every time a device is with in range of a postal service car you get a GPS location

-Lasse

Municipal Area Networks.

There's not enough info in play to tell what might or might not work. Much available COTS gear should do a few 100 meters with no great difficulty. 1 KM will be much more challenging.

--
Les Cargill

Those slaves nodes close to the gateway station will have a lot of traffic to pass and hence also a higher power consumption.

You could have a Time To Live (TTL) counter field in each message. Each time the message gets repeated, the counter is decremented by one. Thus the message will finally die out, when TTL reaches zero, hopefully by then, the message has reached the target, so setting up the initial TTL value is critical.

That would be very inefficient. You would need to keep track of every message you have seen recently and ignore them if you hear them again or your network would fill with the echos of the very first message.

More likely you would build a routing protocol where each node tells the nodes near it who it knows how to reach and how "far" away they are, and if you can't directly reach your target destination, you send it to the node "closest" to the destination, who will then forward it on. (Not unlike how Internet routing works).

Exactly. That's how I designed my (wired) mesh, here though the mesh is used to enhance the reliability of datagram delivery in the presence of short-term overloads -- not as a necessary prequisite for packet routing. (i.e., any node *can* talk to any other node... but I don't want unconstrained traffic)

NOt sure that's a reasonable assumption. I spent much of my career facilitating projects in trouble. More often than not, the engineer didn't need help with a roadblock in his approach...he needed a new approach.

When you hit a snag three levels deep in tunnel vision, sometimes you need to reexamine the whole thing from the top. Unfortunately, the guy at the top would rather blame the guys at the bottom instead of taking another look at his decisions. You can be forgiven for being late. Admitting you are wrong is not acceptable.