Pinoccio Arduino Wireless Mesh

Started by jclark58, January 07, 2015, 10:05:07 AM

jclark58

At https://pinocc.io/ there is an open source system called pinoccio which is a wireless web system for arduino boards similar to the Moteino.  It includes an online web based system for managing the mesh which appears to be installable on local servers.

Of real interest is that the arduino software AFAIKS implements a mesh network with self discovery and store and forward message passing

The board consists of an ATmega256RFr2 microprocessor, a USB interface, a temperature sensor, an RGB LED, and a LiPo battery. The mesh radio built into the chip is a 2.4 GHz transceiver supposedly capable of ZigBee and IEEE 802.15.4 transmission.

I am wondering if it might be  possible  for this mesh network to be implemented for the moteino?

Felix

Yes it's possible. But may I ask why you would want that when you have the awesome range of RFM69?

ColinR

Friend of a friend is on that project. They had startup $ and did some cool work. Hobby market didn't support it so they're going after industrial apps. Cool stuff but very expensive. Nice UI.
CuPID Controls :: Open Source browser-based sensor and device control
Interfaceinnovations.org/cupidcontrols.html
cupidcontrols.com

Felix

I like how all the new wireless technologies are meshed otherwise they aren't cool, and have a smart phone RGB LED color dial control web interface. Like bacon, RGB LED smart phone wireless meshed control makes everything better in our lives :D

ColinR

yeah that stuff is pretty funny. I run into it on boats where they run all the lights RGB because it's such a great feature, but realistically just set it and forget it.
CuPID Controls :: Open Source browser-based sensor and device control
Interfaceinnovations.org/cupidcontrols.html
cupidcontrols.com

jclark58

Quote from: Felix on January 07, 2015, 10:08:15 AM
Yes it's possible. But may I ask why you would want that when you have the awesome range of RFM69?

Im not suggesting that we ditch the RFM69 but that the Pinoccio software be adapted to utilise the moteino and the RFM69 rather than the other way round. As I understand it there is no mesh network available for the moteino, all the frilly colorful stuff is a plus but I need a way to mesh the moteinos and pass data reliably.

Felix

Moteino has been meshed before and I have the means although closed source at this point. But may I ask why you would want that when you have the awesome range of RFM69?

kobuki

I'm not speaking for OP, but I can tell at least a couple of reasons for mesh: error resilience (for RF-noisy environments and in general); even greater coverage. Or the mix of both. OTOH, the RFM69 range is pretty good in itself, it's absolutely true. But more use cases and technologies are a plus, IMO.

Felix, are you allowed to tell us why your customer asked for the mesh code?

Felix

Coverage is the only main reason, in this case entire acres of farm land. The complexities introduced by a mesh far oughweigh the benefits in my opinion. Meshing sounds like a magic word that everyone is fascinated with. But nobody seems to realize how difficult that is to implement properly. I know a lot of these new wireless kickstarters rave about meshing/autodiscovery/autohealing and sleep/ultralow power. All nice and dandy but you can't have all of those combined. It's a huge tradeoff between complexity and range gain and loss of throughput.

ColinR

Yes, I don't think people stop to think about it much, or about the redundant traffic it produces.
CuPID Controls :: Open Source browser-based sensor and device control
Interfaceinnovations.org/cupidcontrols.html
cupidcontrols.com

jclark58

Yes Felix you hit my problem on the head. I want to use the incredible range of the RFM69 and the low cost and elegance of the moteino.

I have acres of property that is off the electricity grid that I want to cover and manage for energy and operational purposes with gullies and high spots, water flows for irrigation and micro hydro, gates, temps, rpms humidity, state and locations of machinery and possibly even livestock.  As it stands I am looking at a big design and implementation with lots of potential dead ends and delays to even get something basic going.  If there is an existing system I can leverage off then the old pragmatic retired software engineer in me says why reinvent the wheel?

I'd like a generic base system that I could install and configure, with some small programming tasks for application specific logic, that provides an infrastructure and access via IP.  New nodes should be plugin and auto join even if its just as a relay.

Seems to me that the moteino with a system such as pinoccio would provide such an infrastructure with business and technical benefits to both.  My question related to the perceived technical difficulty of potentially porting pinoccio software to the moteino. Based on your technical knowledge of both systems, are there architectural diffs between the moteino/RFM69 and the ATmega256RFR2 that would make this impossible or difficult or could it likely be a fairly straightforward process?

Other questions as to whether is should be done or not or whether its got anything to do with RGB leds are irrelevant to me.

TomWS

@jclark, what makes you think that a mesh will address a problem when range can't?

Do you think that nodes will 'see' nodes but gateways won't? 

Further, in your many acres is there power available to all nodes or are the nodes running off batteries?

If running off batteries, what is their duty cycle (on receiving/transmitting vs off sleeping)?

I think, if you dig into the discontinuities in any network, the solution requires an always-on radio within line of radio 'sight' of every node and this can be addressed by any 'standard' moteino gateway - ie, the nodes don't have to have message forwarding responsibilities.  The bulk of the battery operated nodes I have in my network have a duty cycle of approximately 0.03%.  They won't provide the kind of networking support required by a mesh.

In the 'Internet Of Things', if all nodes are installed in wall switches, toasters, refrigerators, etc, then, with virtually unlimited power, a mesh is not only practical, but might be a necessity (due to physical rf barriers).  With acres of battery operated devices, I'll put gateways in tree tops before I'd consider asking my nodes to deal with other nodes' traffic.

I'm not trying to throw stones here, I'm just trying to provide some perspective on how Motes are used...

Tom

TomWS

Quote from: TomWS on January 09, 2015, 08:34:29 PM
@jclark, what makes you think that a mesh will address a problem when range can't?

Do you think that nodes will 'see' nodes but gateways won't? 

Further, in your many acres is there power available to all nodes or are the nodes running off batteries?

If running off batteries, what is their duty cycle (on receiving/transmitting vs off sleeping)?

I think, if you dig into the discontinuities in any network, the solution requires an always-on radio within line of radio 'sight' of every node and this can be addressed by any 'standard' moteino gateway - ie, the nodes don't have to have message forwarding responsibilities.  The bulk of the battery operated nodes I have in my network have a duty cycle of approximately 0.03%.  They won't provide the kind of networking support required by a mesh.

In the 'Internet Of Things', if all nodes are installed in wall switches, toasters, refrigerators, etc, then, with virtually unlimited power, a mesh is not only practical, but might be a necessity (due to physical rf barriers).  With acres of battery operated devices, I'll put gateways in tree tops before I'd consider asking my nodes to deal with other nodes' traffic.

I'm not trying to throw stones here, I'm just trying to provide some perspective on how Motes are used...

Tom
@jclark, after thinking about this post I realized that it was a bit heavy-handed and for that I apologize.

Also, after thinking about my glib comment about 'gateways in tree tops' I realized that 'gateways in tree tops' could be repeaters and, while not creating a true mesh, could be used to build a Zigbee-esque distributed star network, not only to extend range, but, as you pointed out, 'nodes in gulleys', or in my case, 'nodes contained within Irrigation Valve boxes'.  On the node side, the repeater looks like a gateway, but on the gateway side there could be either a terminal gateway or another repeater. 

Thinking about my own implementation, this kind of repeater could be implemented fairly easily, but, as I said, would require a good power source at the repeater. 

The downside, of course, would be the increase in traffic with +1X for every hop and that is only if the routing is fixed.  If 'self-healing' then the amount of traffic snowballs and the complexity rises significantly.

Again, I apologize for my previous response,
Tom

jclark58

Tom, 

Thank you for your responses. 

I am more than willing to have my perception corrected, but I must admit I was a bit taken aback by some of the responses to my post. 
One of the issues of text based communication.
It did cool my enthusiasm somewhat.

Again thank you for your latest response.


TomWS

Quote from: jclark58 on January 22, 2015, 09:52:26 PM
Tom, 

Thank you for your responses. 

I am more than willing to have my perception corrected, but I must admit I was a bit taken aback by some of the responses to my post. 
One of the issues of text based communication.
It did cool my enthusiasm somewhat.

Again thank you for your latest response.
I think it would be worthwhile exploring a distributed star network using Moteinos.  It sounds like you've got the need and the environment.  Are you interested?

Tom