We are currently looking for an Embedded / nRF Developer in Stuttgart that will help us to further develop FruityMesh (https://github.com/mwaylabs/fruitymesh) and our commercial Product BlueRange (https://bluerange.io/).
C++ knowledge is mandatory and Java knowledge would be a bonus. We have multiple projects at the moment with different requirements.
Please contact email@example.com and mention the nRF Devzone in your E-Mail.
Yes, low power is indeed one of the advantages and if the SIG mesh is combined with fruitymesh it is either only used at specific times or in use-cases where we do not rely on nodes having a low power consumption.
Is "non-power-hungry" one of the advantages that "the current mesh standard cannot yet offer"? If so, then this advantage goes down the drain once the fruity is meshed with the meshy (at least for those relaying nodes) ???
It should be possible to combine fruitymesh with BTLE mesh as the BTLE mesh runs on the TimeSlot API and source code is available for the BTLE mesh. This will allow you to leverage the long range or high data rate connection oriented links using fruitymesh.
Yes, you are right. It does however provide some advantages that the current mesh standard can not yet offer. But we are also planning to combine a SIG compatible mesh with fruitymesh in the future which could be helpful depending on the use-case.
I assume fruity is not too compatible with the BLE mesh standard released back in July?