search

bluerange-io / bluerange-mesh

BlueRange Mesh (formerly FruityMesh) - The first completely connection-based open source mesh on top of Bluetooth Low Energy (4.1/5.0 or higher)
https://bluerange.io/
Other
288 stars 109 forks source link

FruityMesh debug messages #188

Closed mabner1996 closed 2 years ago

mabner1996 commented 2 years ago

Hello last time I was asking for debug and ping modules in CherrySim

Using cherrysim, whenever I use debug for flood and ping, I will receive the result in terminal (for example, flood is 22 kb/s and ping sent with 3 seconds).

However, when I use the same command in UART Terminal in the actual hardware, I did not receive any message. For example, I inputted "action 0 debug flood 1 2 10". The UART recognizes the command but it does not print any message afterward.

Please note that my physical FruityMesh system was the January 2019 Version as I only have NRF51822 chips. However, I saw the same debug and ping command in the programming of this version and it should work the same as the current version that I simulate in CherrySim.

So I want to ask why I can't received the debug result for ping and flood in the physical simulation Does the statistics only shown in CherrySim? or is it because I am using the older version (2019).

Thank you for your time and consideration. Sincerely,

Michael

mabner1996 commented 2 years ago

So I tried to flood a node to get the throughput in kb/s On the left terminal (Node ID 9881), I entered command "action 11188 debug flood 9881 2 5" to ask for node 11188 to flood node 9881. However on the right terminal (Node ID 11188) keep giving a message that there is a message being queued thus the command never finished resolved.

Any idea/ solution on how to fix this? Thanks

Error
siretty commented 2 years ago

With a recent version of FruityMesh on nRF52 I get similar output as the simulator, here - as an example - the 'best-case' scenario with only two nodes side-by-side:

image

The lower one is sending the flooding packets to the upper. The value of 8 kb/s is as far as I'm aware pretty much the upper limit for such a limited setup, ~2 kb/s is realistic for more complicated ones - but this depends heavily on how big the mesh is and how 'branchy' it is.

The 'byte/s' output is missing in your physical tests as that was added much later down the line (from a quick glance, I think sometime in 2020). A lot has changed since the 2019 version.

As flooding is restricted to the DebugModule you might be able to backport the functionality from the current version to the 2019 version.

Kind regards Daniel

siretty commented 2 years ago

The command used to generate the flood packets was action this debug flood 1037 2 10000 30.

siretty commented 2 years ago

This issue is being closed after 21 days of inactivity. Please feel free to re-open it!