Pinoccio Arduino Wireless Mesh

[jclark58]

Thanks Tom,
Yes. I could do with some collaboration even if its just to  get me going.
I seem to have become stuck in a a bit of "analysis paralysis", looking for ideal solutions that already out there.

Feel free to jump on this.... What I ideally envisage is a self powered wireless data logging node that I can place at a point of interest either as a sensor and/or actuator and that can be configured for its purpose simply eg via a text file as to what pins do or represent what and fairly easily integrates into the "network" without too much, if any, programming.  I can break this down further for you as to how I would see something like this working.

The attraction I saw with the pinoccio was that it seemed to provide a lot of that plus IP access to nodes and an infrastructure software solution for making information available on the internet.

I am conceptually aware that the moteino has essential limitations and so I am not essentially wedded to a mesh.

Tell me some more about what you have in mind.

John

[TomWS]

@jclark58, sorry it took so long to get back to you, but I've been traveling and didn't have the time to reply.  I did, however, have some time to think about this and have some 'observations':

First, since I'm only interested in Moteino implementation, rather than an 'academic' solution, I'm going to focus on that.

With this in mind, IMO Moteinos have some key attributes that make them ideal for widely dispersed, low power monitor/control units:

• They are capable of sleeping for a long duration at a power <= 25uA.
• They can run off low voltage (nominally 3.7V if you use on board regulator, 3.0V or less if you remove the regulator and drop the CPU clock to 8MHz)
• Even at reduced power, the radio performance is virtually the same.
• VERY long range with very little wireless expertise
• VERY reliable communication protocol for this type of device (ie, non-TCP or sophisticated comm protocol)
• VERY flexible addressing (1-254 node ids within 1-254 networks) + Broadcast and 'promiscuous' mode
• Encryption (which I view primarily as a means to improve comm robustness rather than any security advantage)
• Well known, documented, low cost programming environment
• And, if Felix isn't listening, very low cost for all this...

That they don't support TCP/IP to me is an advantage. Again, IMO, for a mote, a simple point to point comm protocol allows data collectors and remote controls to be implemented quickly and easily.  HOWEVER, this means that there MUST be a gateway to the 'real' (ie, IP) world.  As you may have seen throughout this forum, there are several of us working on our own concoctions for this.  A gateway keeps the Moteino traffic to a simple purpose oriented content rather than requiring a lot of protocol at the end points.

Without getting in the gateway design yet, let's turn the conversation back to the problem of dealing with a mote that can't 'see' the gateway.  ISTM that a mote shouldn't be burdened with dealing with this problem.  The problem should be addressed by placing a 'gateway' within sight of the mote.  And this is where a repeater could come into play.

To a mote, a repeater should 'appear' to be a gateway.  To a gateway, there might be advantage if it appears to be a repeater rather than a simple endpoint.  Ignoring that for the moment, I think it's safe to say that a repeater, at least to a mote, should be a gateway proxy.

This, of course, begs the very important question as to how the repeater will get powered.  Motes easily run off small batteries for years BECAUSE they can have an extremely low duty cycle.  Repeaters, on the other hand either have to be listening all the time or do something special to listen at just the 'right' time in order to pick up the seemingly random transmissions from all the motes within it's 'realm'.  In either case, the power consumption at the Repeater could potentially be an order of magnitude higher than any one mote.  This isn't so easily addressed.  And if the topology becomes more 'mesh' like, this problem will become that much more severe.  One possibility in this regard is if the communication from motes can be made synchronous, ie, the Repeater is capable of predicting when traffic will occur and is able to sleep the rest of the time.  In this case, it's conceivable to operate a Repeater on batteries.  For example, if your motes all have 10 minute broadcast intervals and you can control their timing to prevent overlap, but occur within a relatively narrow window (eg within 30 seconds of each other) then the Repeater duty cycle would only be 5% and most of that would be in receive mode.  Anything longer than this would be a challenge running on purely batteries.

I'll stop here.  Sorry for the 'dump'.  I had intended to organize this better, but that would have delayed the post...

Tom