Creating a wireless mesh from scratch

"Don Y" <this@is.not.me.com> wrote in message 
news:m5t142$1kn$1@speranza.aioe.org...
> On 12/5/2014 12:10 PM, tim..... wrote:
>>
>> "Don Y" <this@is.not.me.com> wrote in message
>> news:m5of6m$6es$1@speranza.aioe.org...
>>> On 12/3/2014 3:36 PM, tim..... wrote:
>>>> Last week, I had a (telephone) interview with a company who said that 
>>>> (they
>>>> thought) their problem required a wireless mess solution but that the
>>>> environment that they worked in was too noisy for the 2.4 GHz band that
>>>> available solutions (such as Zigbee) operate in, and they wanted 
>>>> someone to
>>>> design (eventually, code and test) such a solution using a different 
>>>> wireless
>>>> band.
>>>
>>> "They thought"... what?  That they needed a wireless mesh network?  That
>>> the RF environment was too polluted (at least around 2.4G)?
>>>
>>> Did they rule out a *wired* network?
>>
>> that really is impossible, yes really!
>
> You didn't expound on the requirements in your initial post.  Just said:
>    "(they thought) their problem required a wireless mess solution"
> That suggests that there may have been other alternatives -- or, that
> it would be "wireless or impossible to produce".
>
> Over the years, I've found that folks who "think" they need something
> are just looking for an alternative to another option that they have
> decided (rightly or not) is "too hard" and are hoping that something they
> don't completely understand may, magically, save their asses.
>
> When they discover/decide that they can't have their wireless mesh
> solution (in the allotted time), they may "suddenly" decide that
> the "too hard" approach bears revisiting.  And, perhaps with this
> greater motivation, come up with a viable solution!
>
> [There are some interesting texts/research that suggest the quality
> of the solution (to any problem) rises to meet the constraints
> placed upon it.  I.e., people only tend to look for "difficult
> solutions" when they have been convinced they *must*]

well perhaps,

but I'm not convinced that there is any reward in being this messenger

tim


>

 

On 12/5/2014 1:08 PM, tim..... wrote:
>> When they discover/decide that they can't have their wireless mesh
>> solution (in the allotted time), they may "suddenly" decide that
>> the "too hard" approach bears revisiting.  And, perhaps with this
>> greater motivation, come up with a viable solution!
>>
>> [There are some interesting texts/research that suggest the quality
>> of the solution (to any problem) rises to meet the constraints
>> placed upon it.  I.e., people only tend to look for "difficult
>> solutions" when they have been convinced they *must*]
>
> well perhaps,
>
> but I'm not convinced that there is any reward in being this messenger

+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".

> They have their own specialist data collection (slave) modules which
> need to send that data back to a master wirelessly (and that need is
> absolute, a wired solution is impossible).

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: news@netfront.net ---

"David K. Bryant" <dbryant_94585@earthlink.net> wrote in message 
news:m5ti7l$g3s$1@adenine.netfront.net...

>
>
> 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.

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


 

"Paul E Bennett" <Paul_E.Bennett@topmail.co.uk> wrote in message 
news:ceaq4mFaj5sU1@mid.individual.net...
> David LaRue wrote:
>
>> Hello Tim,
>>
>> "tim....." <tims_new_home@yahoo.co.uk> wrote in
>> news:ce9hk4F1abpU1@mid.individual.net:
>>
>>> Last week, I had a (telephone) interview with a company who said that
>>> (they thought) their problem required a wireless mess solution but
>>> that the environment that they worked in was too noisy for the 2.4 GHz
>>> band that available solutions (such as Zigbee) operate in, and they
>>> wanted someone to design (eventually, code and test) such a solution
>>> using a different wireless band.
>>
>> It sounds like they don't have the requirements nailed down yet.  Any
>> single candidate won't be able to solve their issue in the time they
>> want.
>>
>> You could have inquired about the requirements for the project, what
>> issues they were having, and how you might go about solving their
>> problem ("get a solid communications network for their product").
>>
>>> Not having any experience at all of working on a mesh, I declined on
>>> the grounds of insufficient match for the job.
>>
>> That was a wise decision.  However if you have a good grounding in
>> communications applications you might be able to get up to speed on what
>> is needed.
>>
>> I've been in that situation too, and the time frame is what worried me
>> most about your call.  They were looking for a savior as well as someone
>> to solve a vague set of requirements.
>>
>> With enough communication background or interest in their product you
>> might have gone on to a second interview which might have led you to
>> people who could have told you what the facts really were about their
>> goals.
>>
>>> My gut feel for this task is that creating (the software for) a mesh
>>> network from scratch would be 5-10 (man) year's of effort and not the
>>> 9-12 months that the company would like it to be, and I would be on a
>>> hiding to nothing trying.
>>
>> Hopefully they'd build on an existing hardware/firmware/communications
>> stack and have you, or your team, solve the problem from there.  9-12
>> months isn't long for an outsider to make a great solution that would be
>> production worthy.  They might take that long to evaluate possible
>> communications technologies if they haven't already done so.
>>
>>> Does anybody have any experience of creating a, software, mesh
>>> solution from scratch who can confirm or refute my estimate of how
>>> long it might take - should the opportunity arise again :-)
>>
>> The length of time depends mostly on the complexity and richness of the
>> product.  Suppose you have radios and stacks that provide the ability to
>> monitor other stations in your area and a store/forward communication
>> protocol.  A simple application could take relatively short time.  A
>> more complex application would have more problems to solve to evolve a
>> solid solution.  Again, this presumes they really do need a mesh
>> network.
>
> A Mesh network requires having enough residual bandwidth for each node 
> that
> it can repeat frames intended for another node between two nodes not able 
> to
> link directly.
>
> Node 1 message meant for node 3 is received by node 2 then gets repeated 
> to
> node 3 by node 2.

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







 

Den fredag den 5. december 2014 20.08.37 UTC+1 skrev tim.....:
> "Les Cargill" <lcargill99@comcast.com> wrote in message 
> news:m5o8pf$qpm$1@dont-email.me...
> > tim..... wrote:
> >> Last week, I had a (telephone) interview with a company who said that
> >> (they thought) their problem required a wireless mess solution
> >
> >
> > They need to think again, then. Are they building to deploy MAN
> > networks? My understanding is that that market is oh so very dead.
> 
> what market is that?
> 
> They are not planning on making a generic network solution to sell on
> 
> They have their own specialist data collection (slave) modules which need to 
> send that data back to a master wirelessly (and that need is absolute, a 
> wired solution is impossible).  They have a (presumably patented) unique 
> product that they sell into specialist markets with little competition.
> 
> Currently they create a one to many, star network but that has a maximum 
> range of about 40 metres.
> 
> they want to extend that range (to several 100 metres) by creating a mesh 
> from the slaves
> 
> Personally, I would have suggested multiple masters connected together on a 
> point to point basis, but I guess that they have already thought of this.
> 
> 
> >
> >> but that
> >> the environment that they worked in was too noisy for the 2.4 GHz band
> >> that available solutions (such as Zigbee) operate in,
> >
> > Mesh over Zigbee sounds bloody painful.
> >
> >> and they wanted
> >> someone to design (eventually, code and test) such a solution using a
> >> different wireless band.
> >>
> >
> > These are available as COTS for next to nothing on 802.11g and such.
> > AliExpress has a node for $45.
> 
> I don't think the costs of the radio is significant, but the power 
> consumption almost certainly is

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

tim..... wrote:
>
> "Les Cargill" <lcargill99@comcast.com> wrote in message
> news:m5o8pf$qpm$1@dont-email.me...
>> tim..... wrote:
>>> Last week, I had a (telephone) interview with a company who said that
>>> (they thought) their problem required a wireless mess solution
>>
>>
>> They need to think again, then. Are they building to deploy MAN
>> networks? My understanding is that that market is oh so very dead.
>
> what market is that?
>

Municipal Area Networks.

> They are not planning on making a generic network solution to sell on
>
> They have their own specialist data collection (slave) modules which
> need to send that data back to a master wirelessly (and that need is
> absolute, a wired solution is impossible).  They have a (presumably
> patented) unique product that they sell into specialist markets with
> little competition.
>
> Currently they create a one to many, star network but that has a maximum
> range of about 40 metres.
>
> they want to extend that range (to several 100 metres) by creating a
> mesh from the slaves
>
> Personally, I would have suggested multiple masters connected together
> on a point to point basis, but I guess that they have already thought of
> this.
>
>

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.


>>
>>> but that
>>> the environment that they worked in was too noisy for the 2.4 GHz band
>>> that available solutions (such as Zigbee) operate in,
>>
>> Mesh over Zigbee sounds bloody painful.
>>
>>> and they wanted
>>> someone to design (eventually, code and test) such a solution using a
>>> different wireless band.
>>>
>>
>> These are available as COTS for next to nothing on 802.11g and such.
>> AliExpress has a node for $45.
>
> I don't think the costs of the radio is significant, but the power
> consumption almost certainly is
>
>
>
>

-- 
Les Cargill

On Fri, 5 Dec 2014 19:08:31 -0000, "tim....."
<tims_new_home@yahoo.co.uk> wrote:

>I don't think the costs of the radio is significant, but the power 
>consumption almost certainly is

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

On Sat, 6 Dec 2014 11:45:33 -0000, "tim....."
<tims_new_home@yahoo.co.uk> wrote:

>
>"Paul E Bennett" <Paul_E.Bennett@topmail.co.uk> wrote in message 
>news:ceaq4mFaj5sU1@mid.individual.net...
>> David LaRue wrote:
>>
>>> Hello Tim,
>>>
>>> "tim....." <tims_new_home@yahoo.co.uk> wrote in
>>> news:ce9hk4F1abpU1@mid.individual.net:
>>>
>>>> Last week, I had a (telephone) interview with a company who said that
>>>> (they thought) their problem required a wireless mess solution but
>>>> that the environment that they worked in was too noisy for the 2.4 GHz
>>>> band that available solutions (such as Zigbee) operate in, and they
>>>> wanted someone to design (eventually, code and test) such a solution
>>>> using a different wireless band.
>>>
>>> It sounds like they don't have the requirements nailed down yet.  Any
>>> single candidate won't be able to solve their issue in the time they
>>> want.
>>>
>>> You could have inquired about the requirements for the project, what
>>> issues they were having, and how you might go about solving their
>>> problem ("get a solid communications network for their product").
>>>
>>>> Not having any experience at all of working on a mesh, I declined on
>>>> the grounds of insufficient match for the job.
>>>
>>> That was a wise decision.  However if you have a good grounding in
>>> communications applications you might be able to get up to speed on what
>>> is needed.
>>>
>>> I've been in that situation too, and the time frame is what worried me
>>> most about your call.  They were looking for a savior as well as someone
>>> to solve a vague set of requirements.
>>>
>>> With enough communication background or interest in their product you
>>> might have gone on to a second interview which might have led you to
>>> people who could have told you what the facts really were about their
>>> goals.
>>>
>>>> My gut feel for this task is that creating (the software for) a mesh
>>>> network from scratch would be 5-10 (man) year's of effort and not the
>>>> 9-12 months that the company would like it to be, and I would be on a
>>>> hiding to nothing trying.
>>>
>>> Hopefully they'd build on an existing hardware/firmware/communications
>>> stack and have you, or your team, solve the problem from there.  9-12
>>> months isn't long for an outsider to make a great solution that would be
>>> production worthy.  They might take that long to evaluate possible
>>> communications technologies if they haven't already done so.
>>>
>>>> Does anybody have any experience of creating a, software, mesh
>>>> solution from scratch who can confirm or refute my estimate of how
>>>> long it might take - should the opportunity arise again :-)
>>>
>>> The length of time depends mostly on the complexity and richness of the
>>> product.  Suppose you have radios and stacks that provide the ability to
>>> monitor other stations in your area and a store/forward communication
>>> protocol.  A simple application could take relatively short time.  A
>>> more complex application would have more problems to solve to evolve a
>>> solid solution.  Again, this presumes they really do need a mesh
>>> network.
>>
>> A Mesh network requires having enough residual bandwidth for each node 
>> that
>> it can repeat frames intended for another node between two nodes not able 
>> to
>> link directly.
>>
>> Node 1 message meant for node 3 is received by node 2 then gets repeated 
>> to
>> node 3 by node 2.
>
>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

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.

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

On 12/6/14, 6:45 AM, tim..... wrote:
>
> "Paul E Bennett" <Paul_E.Bennett@topmail.co.uk> wrote in message
> news:ceaq4mFaj5sU1@mid.individual.net...
>>
>> A Mesh network requires having enough residual bandwidth for each node
>> that
>> it can repeat frames intended for another node between two nodes not
>> able to
>> link directly.
>>
>> Node 1 message meant for node 3 is received by node 2 then gets
>> repeated to
>> node 3 by node 2.
>
> 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
>

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).