Features

Mesh Features

Additional Features

  • Mesh simulation and fast development using CherrySim

  • UART Terminal to execute commands with a list of arguments for manual or automated communication with a MeshGateway (cf. Basic Usage)

  • Modular structure with persistent module configurations (cf. Modules)

  • RecordStorage, a record based file system for storing data in flash that is always reliable

  • Automatic cycling of different advertising messages with the AdvertisingController

  • Multiplexing of different ScanJobs using the ScanController

  • Runtime Board Configurations so that the same firmware can run on multiple boards

  • Using Featuresets, you can easily compile different firmware configurations from the same source code

  • Predefined UICR structure that allows easy production of nodes with different serial numbers and settings

  • Small and highly optimized firmware size. It is modular and can be easily configured through the featureset

  • Abstraction from the BLE stack using our FruityHal

  • Lots of source code comments and easily understandable method and variable names (see source code ;-))

Reliability & Debugging

Module Features

This is only an extract of the different features of the Modules. Make sure to take a look at the Modules documentation and at the documentation of the different modules themselves.

  • BeaconingModule for configuring custom broadcast messages such as EddyStone or iBeacon

  • DebugModule to send test packets, flood the network, ping nodes, …​

  • EnrollmentModule for provisioning nodes (locally or over an existing mesh) and giving them access to a mesh

  • IoModule for signalling commands using LEDs or other pins

  • StatusReporterModule for monitoring the nodes

Closed Source Features

A number of modules of FruityMesh are not yet open source but can be used by customers. Contact us if you are interested.

  • DfuModule firmware updates over the mesh. Not limited to FruityMesh, but also available for connected 3rd party controllers

  • AssetModule: Broadcasting of asset telemetry messages that can be located indoors by our infrastructure

  • A number of custom modules and customization of FruityMesh have already been implemented for many customers.

  • A number of drivers, customized to work with FruityMesh

Upcoming Features

  • Flow Control & Quality of Service (QoS)

    • As an enhancement to our connections, we are planning to add Flow Control and QoS to better deal with throughput peaks and manage packet priorities

Features in Detail

CherrySim

  • Compilation of FruityMesh for x86 together with a simulator that abstracts the hardware and can simulate hundreds of nodes at the same time.

  • Integrated testing suite to write tests against a mesh of multiple nodes that can all run with different featuresets.

  • Provides the ability to Mock 3rd Party hardware.

  • Supports stdio and TCP sockets

  • Find the simulator documentation on the CherrySim page.

  • cherrysim

Time Synchronisation

FruityMesh has inbuilt time synchronization. A gateway or smartphone can act as a synchronisation device to send a unix timestamp to one node in the mesh. This node will then take care that this timestamp is synchronized to all other nodes in the mesh. If any number of nodes are rebooted, the time will be synchronized again if there is at least one node that still has the current time. By using a counter value, we make sure that the latest timestamp will be synchronized and that the time can be corrected in both directions. The time is always synchronized between two partners in a kind of handshake where first the time is sent to the other node and next, an offset is sent to account for the delay in sending that message. Further documentation can be found here.

Packet Splitting

Depending on the configuration of the nodes in a network, the connection MTU (Maximum Transmission Unit) might only allow for a packet size of 20 bytes payload. As you will probably need to send bigger packets from time to time, we implemented automatic packet splitting. A packet can be queued with a size of up to 200 bytes and is then split automatically before it is sent to the next node at which point it is automatically reassembled. This process also makes sure that a packet uses the maximum possible MTU available.

Sink Determination

Once we attach a Gateway to the Mesh, we might want to send messages on a direct route to that Gateway. Or maybe, we simply want to know if a Gateway is currently available in the mesh. Sink determination determines the number of hops to the Gateway on each node. During clustering, a new node performs a handshake with its partner node and exchanges 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. This handshake also includes the number of hops to the sink (MeshGateway). This information is also included in the clusterInfoUpdate packets that notify all nodes about changes in the network.

If a sink is available through a connection, the number of hops to this 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.

Connection Reestablishment

FruityMesh relies an standard BLE GAP connections which have a configurable interval and timeout. These can be chosen depending on the use-case for either high throughput or low power consumption. If a small timeout is chosen and the environment has high radio interference, it can happen that these GAP connections are disconnected. In these cases, there is an extended timeout in which FruityMesh will try to reestablish the GAP connection multiple times until it succeeds. Packets will stay in the queue and will be sent after the connection was reestablished. This means, that aside from a higher latency, no packet loss will occur.

Watchdog With Safe Boot Mode

The hardware watchdog is configured to restart a node after a certain time if it doesn’t 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. It is also possible to configure the Watchdog to work without a Gateway, it will then monitor the behaviour of the node itself.

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 also means that the node will not be enrolled in this mode, but it will reboot in normal mode after the watchdog triggers again. This makes it possible to rescue a node that received a faulty persistent configuration.