Features
-
Automatic meshing and self-healing capabilities with The FruityMesh Algorithm
-
UART Terminal to execute commands with a list of arguments for either manual or automated communication with a MeshGateway (see Usage)
-
Debug Logger with support for filtering log tags (see Usage)
-
Modular structure with persistent module configurations (see Modules)
-
Encrypted mesh and Smartphone connections
-
AdvertisingModule for configuring custom broadcast messages such as EddyStone or iBeacon
-
StatusReporterModule for monitoring the nodes
-
EnrollmentModule for provisioning nodes (locally or over an existing mesh) and giving them access to a mesh
-
IoModule for signaling commands using leds or other pins
-
MeshAccessModule for handling connections from/to Smartphones and other devices
-
Time Synchronisation over the mesh (see Usage)
-
RecordStorage A record based filesystem for storing data in flash
-
Automatic packet splitting if packets are bigger than the connection MTU.
-
Automatic cycling of different advertising messages with the AdvertisingController.
Closed Source features
A number of modules of FruityMesh are not yet open source but can be used by our customers. Contact us if you are interested.
-
DfuModule firmware updates over the mesh, not limited to FruityMesh but also available for connected controllers.
-
AssetModule.adoc broadcasting of asset telemetry messages that can be located indoors by our infrastructure.
-
We have already implemented a number of Custom modules and customization of FruityMesh for many of our customers.
Feature Roadmap
Coming soon to GitHub: Our CherrySim - written in C++ - simulates the mesh using the FruityMesh code and allows us to implement unit and system tests.
Features in Detail
Sink Determination
During clustering, a new node will do a handshake with its partner node, where they exchange information about the network structure. This includes the cluster size and also the master bit that is used to determine which cluster must dissolve if a connection is lost. Also included in this handshake is the number of hops to the sink (MeshGateway). This information is also included in clusterInfoUpdate packets which notify all nodes about changes in the network.
If a sink is available through a connection, the number of hops to that sink will be sent with these packets. The sink itself has 0 hops to the sink. If there is no sink available, it is denoted with -1.
Watchdog with Safe Boot mode
The hardware watchdog is configured to restart a node after a certain time if it does not receive a keep alive packet from the gateway in the meantime. This is the last fallback to recover a node if there is some critical unknown issue. This issue will then be reported as a watchdog reboot using the error log of a node.
It is possible to configure the watchdog to use safe boot. In safe boot mode, the node will boot up without loading any persistant configuration. This will also mean that the node will not be enrolled in this mode, but it will reboot again in normal mode after the watchdog triggers again. This makes it possible to rescue a node that received a faulty persistent configuration.
Error Log and Live Error Reporting
Each node can store a number of errors in ram. The timestamp, error code and some extra information can be stored. This log can be queried every few minutes or hours. The errors have different significance and some information is logged using a counter that always increments. This statistical information can be used to determine the health of a live mesh and to monitor it. Storing the errors is necessary as they might be generated while a node is disconnected from the mesh. The error log will be cleared once the errors have been queried.
Additionally, live error logging can be used to send information about errors through the mesh instantly. This will of course only work if the node is part of the mesh.