Please Clarify the mesh network

[Ameer.Sheik]

Hello All

Could please tell me how mesh network is working. as per my understanding Bluetooth connectivity is point to point communication or one to one .(if i am wrong please correct me ) in this cash how mesh network happen

please clarify me doubt and could you please suggest me any reference guide for mesh network

Thanks Ameer

[endnode]

You are right, Bluetooth is normally (and that is similar for classic BR/EDR parotocols as well as LE) only peer-to-peer communication. However you can build mesh network on top of it as application. One approach would be to use directly LL or L2CAP layers (and that's also supported by Nordic stacks today - as well as many other vendors - so you can find such solutions over the internet), another is to build it on top of Advertising data (so you use spare space of ADV_IND packets to broadcast data to the air and other nodes can scan and re-broadcast further so data keep going) and another can be connection based where you take advantage of possible concurrent connections on each node and APP layer handles "mesh" protocol itself. All of these things can be found as examples, just use search function on this forum, blog zone and google (here are first two hits as example 1 2)

Recently BT SIG themselves released Bluetooth Mesh specification which again introduces kind of separate protocol which can co-exist with already existing standards like BLE. You can get basics from Nordic's description of their alpha implementation of that here.

[Roger Clark]

@endnote

Do you know if this runs on nRF51822QFAA 16k hardware ?

I looked in the blog post, but it just says "Recommended >= 32kB RAM"

Which doesn't rule out 16k, but perhaps they really mean "Required >= 32kB RAM"

[Thomas Stenersen]

Hi Roger,

The mesh stack should be possible to squeeze down a lot on RAM usage, but the Bluetooth Mesh itself is ultimately RAM hungry because of the amount of keys, addresses, etc. that needs to be maintained. Limiting RAM also limits cache sizes and packet queues, which in turn limits the mesh performance.

Also, there is the question of DFU/bootloader. The mesh stack has its own Mesh DFU that also imposes requirements on RAM and flash. Is there a particular reason for using the nRF51822QFAA and not the nRF52810?

Best,
Thomas

[Roger Clark]

Thanks Thomas

I already have a load of spare "smart beacons" which have the nRF51822QFAA, so I wondered if they could be re-purposed as a mesh demo.

BTW. I think someone else did their own mesh implementation quite some time ago and published on github (I don't remember the URL), and it required 32k RAM.

I was just hoping perhaps I could get perhaps a 10 mesh demo working with these beacons I already have

[Thomas Stenersen]

I see. I did some quick testing and it looks like it should be possible to run it on 51822xxAA :) In mesh/api/nrf_mesh_config_core.h set NRF_MESH_LOG_ENABLE 0 and reduce the PACKET_MGR_MEMORY_POOL_SIZE to, e.g., 512. Furthermore, reduce the __HEAP_SIZE to, e.g., 256 in toolchain/gcc/gcc_startup_nrf51.S (if building with GCC). The linker file should also be updated to match the RAM specification for the 51822xxAA. I just changed the toolchain/s130_nrf51422xxAC.ld file to RAM (rwx) : ORIGIN = 0x200022D8, LENGTH = 0x1d28. I also built with the -DCMAKE_BUILD_TYPE=RelWithDebInfo and -DPERSISTENT_STORAGE=OFF CMake configuration and GCC ARM embedded 6.3.1. With this I was able to build for the reduced size RAM 51_light_control_server target successfully.

Best,
Thomas

[Roger Clark]

Hi Thomas

Thanks for going to the trouble of getting it to work on the 16k device.

I will be building with gcc, and I'm familiar with changing the linker file, as its needed to make some of the SDK examples work on the QFAA device

I'm not going to have time to try this today, but I will try later in the week.

Thanks again

Roger