A number of questions

[mariusheil]

I got these questions via E-Mail and I thought I will put them here for everybody:

1. Imagine there are 5 nodes in a Mesh network that are moving around in a specific region, Do they align among themselves? I understand with Automeshing it is yes! But is there specific reason based on dbm or distance approximation based?

2. In the enrollment module, it is given that "FruityMesh enables provisioning through mobile apps or Gateways, such as the SIG mesh. In addition to that, provisioning over the mesh is also possible. ", With Auto meshing, is it not that all the nodes are already provisioned or added to the network?

3. From the Docu, I understand that we need to use Mesh Access module to connect to a smartphone, Is there any particular App or something to use this? Relution/fruitymesh - IS this the API documentation in MeshAccessConnection.cpp? According to this documentation, Do you mean the nrfApp of mobile acts as a central and the firmware that we build acts as peripheral? can you explain?

4. I am using Nrf52 device, In a mesh, I am connecting a single node to the PC and other 2 through an external source(Power bank). The node connected to the PC has different behavior compared to others.

I understand LED2 blink indicates the no of input connections. But LD5 near the PCA chip flashes more often in devices connected externally and device connected to PC has a solid LED bink. Does it indicate something?

5. Can you suggest a way with which I can use any Application to view the messages communicated through the Mesh? Like CANoe in a CAN network where we can analyze the trace? I tried using Wireshark and the nrf sniffer as mentioned But the procedure isn't clear. Can you suggest something on this?

6. Where can I find the procedure to run the fruity mesh? I am not able to find the cherrySimTest.exe (as given in the image) I just want this for understanding purposes. Should that be generated? It did not get generated with the build

7. Is there a way that we can use the flash device over mesh ( proprietary modules? I am interested in dfu module )

[mariusheil]

Hi, hopefully, I got the questions right: 1) FruityMesh expects most nodes be be static to provide a stable mesh, however we have the concept of leaf nodes that will not relay data, but can move around within a static mesh. Even if you make them static, the FruityMesh algorithm will reconnect connections if they should be dropped. (I do not understand what you mean by: align themselves). 2) You can either preflash all your nodes to be in the same network, then they will all connect to each other. However you might not want this. You can also flash them with network id 0. Then they will not try to connect to each other ynd you have to provision or enroll them first using e.g. an app. 3) Sadly, we currently do not have an app that you can use without our platform, we plan to do this but it is not yet ready. You can also use a node connected via UART to a computer / gateway / ... as a provisioner by sending the enrollmen tcommands to this node over UART. The app will act as a central and the node will act as a peripheral. (I did not get the other parts of the quesiton, sorry again) 4) LED5 shows the debugger / USB connection and has nothing to do with the nrf chipset. It is located close to the SEGGER debugger chip. Only LEDs 1-4 are controlled by Fruitymesh. 5) You can enter "debug all" in the terminal of the node connected to the PC to get an overview of all messages passing through this node. As the communication over the mesh happens through connections and is encrypted, it is not easily possible to view the whole mesh communication at once. You can however try out our simulator (CherrySim). i am currently extending the documentation a bit more for that, but there is already documentaiton available. 6) For using the simulator, read CherrySim and BuildingWithCMake. But we are currently improving this section with better instructions. 7) You can build propriotory modules with the open source solution under the given licence terms. We also offer DFU update functionality but not as part of the open source solution at this point. If you are interested, you can contact us directly via e-mail.

[viveknath93]

Hi,

I have one question regarding the enrollment module.

By default, the nodes are flashed with networkid = 11. Suppose if i have 5 nodes, By auto meshing, it forms a 5 device network. I need a way in which a single node can be removed from being part of the network temporarily.

Using the Unenroll function: or by action nodeid enroll remove But this is to unenroll other nodes via the mesh. Can it also self unenroll itself? When I try to unenroll by default the device is going back to the default network id - hence reboots and Joins the network again.

Which parameter can help (when tweaked on un enrollment procedure ) to cease from participating from the mesh unless a reset is done? Basically want to unenroll and enroll based on sensor input without using the app / UART terminal.

Is it like unenrolling works only when the devices are flashed with network ID 0 - Manually add 4 devices to a particular network ID say -5. When you unenroll it again, it defaults back to whatever the option that we specified ( i.e using setFeaturesetConfiguration_github_nrf52 ) while flashing.

Thanks in Advance!

[mariusheil]

Hi,

I would guess that the basic ideas should be explained in our documentation here: https://bluerange.io/docs/fruitymesh/EnrollmentModule.html

Did you already read that?

The default in the Github featureset is just hard coded to give people a quick start. Maybe we should add a comment to make that more clear. You should remove that part. and should enroll each node in the beginning to let them form a network. Make sure to also take a look at the UICR section in the documentation as this is important.

Marius

Viveknath thulasi notifications@github.com schrieb am So., 23. Aug. 2020, 21:40:

Hi,

I have one question regarding the enrollment module.

By default, the nodes are flashed with networkid = 11. Suppose if i have 5 nodes, By auto meshing, it forms a 5 device network. I need a way in which a single node can be removed from being part of the network temporarily.

Using the Unenroll function: or by action nodeid enroll remove But this is to unenroll other nodes via the mesh. Can it also self unenroll itself? When I try to unenroll by default the device is going back to the default network id - hence reboots and Joins the network again.

Which parameter can help (when tweaked on un enrollment procedure ) to cease from participating from the mesh unless a reset is done? Basically want to unenroll and enroll based on sensor input without using the app / UART terminal.

Is it like unenrolling works only when the devices are flashed with network ID 0 - Manually add 4 devices to a particular network ID say -5. When you unenroll it again, it defaults back to whatever the option that we specified ( i.e using setFeaturesetConfiguration_github_nrf52 ) while flashing.

Thanks in Advance!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mwaylabs/fruitymesh/issues/134#issuecomment-678815675, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABM62NETP2LZSQKODUGSFRDSCFWDLANCNFSM4MP6KY6Q .

[viveknath93]

Hi,

Yes. I am following the link that you mentioned. I just misunderstood that 2 modules based on my analysis using terminal command handler capabilities of each module - Enrollment module and MeshAccessModule both are independent of each other.

So, To my understanding : When a new node/device is released as a final product, it is always left unenrolled ( networkID = 0 ). You always need a Gateway or Smartphone to enroll the device in a particular network. Also, In order to enroll, The 3 main parameters needed are networkID, network Key, and Unique nodeID which is provided by Gateway device /smartphone.

1. The first step is to Make a mesh access connection using a gateway or smartphone to create a handshaking mechanism - AES encryption -Get connected All being inherent to mesh Access connection/gateways. Unencrypted Enrollment - this initial handshaking process can be skipped when the unenrolled node uses a key FM_KEY_ID_ZERO.

2. Then send enrollment message - as given in Enrollment module docu from the Gateway/smartphone.

I am able to understand the 4 enrollment scenarios mentioned. so only a gateway or a smartphone can enroll/unenroll a device by sending a broadcast message through the mesh. If it has to form a new network, it connects to each node and adds to the network one by one. It is not like any node can unenroll any other node in the network.

Also with UICR, an organization/product series can be pre-programmed to have the network attributes as default so that they are already forming a mesh when they are powered on. And this can be used especially in tracking scenarios.

Extremely sorry If I am taking time to understand from Document. Please let me know if my understanding is correct.

[mariusheil]

Hello,

Sounds correct :-) It is of course possible to just preflash nodes with an enrollment, but this is not suitable for most production scenarios as that would mean that the nodes have to be prepared for each customer. So the usual workflow is to enroll all nodes using an app or a gateway. A Gateway can use a node with meshconnections that is connected via uart. An app has to use a MeshAccessConnection as it does not implement the FruityMesh algorithm. Nodes are able to use Mesh Access connections to enroll nodes that are too far away from the gateway or the app. They will automatically do this if the enrollment is addressed to a specific node or to the broadcast address 0, also the node key has to be given so that the node can build the MeshAccessConnection.

The zero key still means that the encryption handshake has to be done, but using the known key of 0000...0000.

Marius

Marius

[viveknath93]

Hi,

Thanks a lot for your inputs.

I have a couple of generic questions probably more related to Nordic specific or Bluetooth itself.

1. Can the range of fruity mesh be extended? Using the feature LONG RANGE in Bluetooth 5.1Specifications.

Also, In fruityHALNrf.cpp , there is a way to extend the range of coverage using the function : sd_ble_gap_phy_update But I observe that this part of code is not called at all: BLE_GAP_EVT_PHY_UPDATE_REQUEST

So is there a way if I implement this and use nrf52 device that supports Long Range? with BLE_GAP_PHY_CODED ( Currently it is commented as not supported)

2. How can I change the SDK that is currently in use?

I understand softdevice is based on the device that Is used. Hence, I see that s132 is being used because I am using nrf52832. Is it necessary that we should the latest SDK? What would be the difference? How can I configure it in the fruity mesh?

3. The fruity mesh currently uses default transmit power of +4dbm. Is this the maximum value? Does reducing the transmit power affect the functioning of the mesh or the transmit distances?

[mariusheil]

Hi,

1) Yes, that can be done, but it is not currently implemented. We had it implemented for testing the 2Mbit Phy in order to optimize the throughput, but we got really bad results in testing and decided not to invest more time into it for now. Implementing Long Range is probably not complicated but requires some thought if both Long Range and standard nodes should be connectable.

2) You will have to copy the latest SDK into the sdk folder, then update all the Cmake files and update the implementation of the HAL to support a different SDK. You do not have to use the latest SDK if you do not need any of the features. we did not update it for some time as we were completely fine with the current features in the SDk that we use. Depending on the changes in the SDK it might be trivial or a very complex task. We have not yet looked into the latest SDK versions.

3) For the nRF52832, this is the maximum value, the nRF52840 can do +8 I think. If you lower this, you will reduce power consumption but will have less usable range between the nodes.

Marius

[viveknath93]

Hi,

Thanks a lot :)

Viveknath