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?
Yes it's possible. But may I ask why you would want that when you have the awesome range of RFM69?
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.
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
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.
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.
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?
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?
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.
Yes, I don't think people stop to think about it much, or about the redundant traffic it produces.
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.
@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
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
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.
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
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
@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