Hello,
I am currently working on a project to make a Bluetooth Mesh network that consists of devices that read and transmit data from on-body sensors. The goal is to have every node in the mesh network transmitting their individual data to reach a smartphone or tablet that can then display the received data in a graph. The graph will be updated live with new information from each node every so often. The data will be sampled from each node once per second, so each node will transmit a new data packet at 1 Hz.
I should mention now that I am using SDK and toolchain versions v2.4.2, and the device is the nRF5340. I don't believe this matters, but I am using WSL in VSCode.
As these devices will be on-body sensors, they will be moving around a lot. No single device will always be the device in range of the smartphone. Since smartphones cannot be added as a node to mesh networks, we have two options: 1. we make every node on the network a proxy node, or 2. we have a dedicated proxy node.
I've done some pro/con analysis between these two options, and the most efficient and robust method sounds like having the dedicated proxy node. One of the main reasons for this is the limited pairing needed by the smartphone with the dedicated proxy node. If every node was a proxy node, then we'd have to somehow manage having the smartphone switch (disconnect and connect to new) devices based on whether it was in range to read data. When the smartphone would go out of range of one device, it would be expected to automatically connect to the nearest device to pull data from that new device. This also means that every single device would have to be capable of transmitting data of the entire network over BLE, which adds strain to the device.
There is a lot involved in this system. One extra use-case I should mention is when a single user wants to see his data on a smartphone. We will likely have supported functionality to be able to connect to the device via BLE from an app to be able to read only that single device's data. In this case, the device would need to be a proxy node anyways since it would have to support BLE connectivity.
The two grand use-cases of this device will be: 1. having the data be read via a Bluetooth mesh network, and 2. have the data be read via a BLE pairing peer-to-peer connection.
I believe it would be easier to have a dedicated proxy node because the dedicated proxy node would be a node in the mesh network, meaning it could more easily get data from the network without having to worry about pairing based on signal strength or readability. It could also serve to bridge the network if the network splits: if the smartphone user is standing between two halves of one large network, if he is utilizing a dedicated proxy node that's connected to his smartphone (or is very close to it), then he can bridge the network and read data from both halves easily.
This was a bit of a ramble of thoughts, so I'll give a (barely) more concise list of most of my questions:
1. What are your thoughts on creating a mesh network implementation like this? Is there anything that I haven't listed here that I should consider while making this implementation?
2. What sounds better to you? The dedicated proxy node dongle or having every node act as a proxy that can be connected to at any time (although, this does not sound reliable to me, and from a networking standpoint, sounds like a nightmare!)?
3. How would I go about provisioning nodes on a network if they weren't all proxy nodes? I mentioned that we'll likely leave the proxy setting active due to the desired additional functionality to connect to and read data over BLE from a single device, but if we were to find a way around that and we wanted to disable the proxy node functionality, how would we provision the network via the proxy node dongle?
4. Side question that I've been asked about -- we want to minimize congestion in our network, as we plan to have many (30+) mesh nodes in the network. For segmented and unsegmented Bluetooth mesh packets, I know that the size restraints are 15 bytes and 12 bytes, respectively. I also know that those numbers include the opcode sizes and the MIC sizes. Opcodes can be either 1, 2, or 3 bytes, and the MIC can be either 4 or 8 bytes. However, as far as I'm aware, the opcode size variations are a bit misleading because 1-byte opcodes seem to be dedicated to background essential functionality in Bluetooth mesh, meaning I can't use them (I tried and my Bluetooth mesh simply did not initiate, and gave me an error telling me that my opcode was invalid). 2-byte opcodes seem to be consumed by all of the samples. I am making a vendor model, so I was recommended to use a 3-byte opcode. However, is it possible to use a 2-byte opcode somehow? Can I jerry rig a 2-byte opcode so that I can have an extra byte in my payload? For segmented packets, 12 bytes - 4-byte MIC - 3-byte opcode = 5 bytes of data per fragment. However, if I can get this to 6-bytes, then that may enable us to not have to fragment as much. We're attempting to use a 16-byte packet, and with 5 bytes of payload per fragment, that would require 4 fragments, but with 6 bytes per fragment, we could get away with 3 fragments, which would imply a 33% improvement to the network congestion as we'd be transmitting 3 fragments per second (since we're reading and transmitting data once per second) instead of 4. Also, what are your thoughts on this? Does this matter? Are we underestimating the hardware capabilities of the 5340? Will 3 fragments vs 4 fragments make a noticeable difference in reliability?
5. If we use dedicated proxy node dongles, where each dedicated proxy node will have its own respective mesh network, will it matter if we made all of those networks on one smartphone? To give an example, let's say we have 80 devices total, and we split it into 4 networks of 20 devices each. If we added a node to each of those networks (to total to 21 devices per network), and that node was a dedicated proxy node, would it break the system if all 4 of those networks were provisioned and put into groups on one smartphone? Our plan is to have one smartphone per dongle, and each of those networks of 20 devices would be managed by that one person with that one smartphone and dongle, so there'd be 4 people involved. By managed, I mean that one person would read data from the 20 devices in the network and plot it on a graph on their smartphone app. If they wanted to exchange dongles to exchange networks, would they be able to connect to their respectively new proxy node dongle and have it stream the data packets over BLE to the new smartphone to get data from all 20 devices in the new network?
6. Additional question related to the above question: if we had 80 devices on one large network, and 4 additional devices that acted as proxy node dongles with one smartphone paired per dongle, does that mean that each smartphone/dongle pair would be able to receive data from the large network of 80 (+4) devices?
I've tried to refrain from requesting to "see" large networks from new smartphones since I don't really need to see their mesh network topology from an NRF-mesh-like app, I just need to be able to read data from each device.
This was a very long post, and may not be coherent in some areas (apologies, my thoughts were a bit jumbled as I was writing), so let me know if there are any questions.
Thanks!
