nRF Bluetooth Mesh

RE: nRF Bluetooth Mesh

daviddedwin — Tue, 29 Dec 2020 04:13:57 GMT

Please accept the answers that you liked the most and upvote them. Thanks for choosing Nordic.

RE: nRF Bluetooth Mesh

vkadal — Mon, 28 Dec 2020 17:10:47 GMT

Thaks a lot for the inputs

RE: nRF Bluetooth Mesh

daviddedwin — Fri, 25 Dec 2020 17:01:39 GMT

If you like my replies please give them upvotes.

If you are going for the connection oriented solution:
You can go for the nRF52840 based module with external antenna and optionally PA/LNA. The Central will need a lot of RAM to manage the links and the nRF52840 has the maximum RAM and FLASH. You can also choose to use a module with the nRF52833 IC as that has more RAM as compared to the nRF52832. The nRF52832 will be the most affordable IC as it has been in production the longest in the nRF52 series. The peripheral does not need a lot of RAM and FLASH so the nRF52832 should be fine as well, but since the project is small it may be simpler to pick a single module an use it for both central and peripheral.

https://www.nordicsemi.com/Software-and-Tools/3rd-Party/3rd-party-modules#shortrange , the ones with u.FL refer to the external antenna connector. Raytac has good availability in your region and you can check for other modules as well locally. You send me a direct message for more information.

RE: nRF Bluetooth Mesh

vkadal — Fri, 25 Dec 2020 10:59:42 GMT

Thanks for the detailed reply. The data flow is bidirectional. I need to set some limits for the sensor parameters. Can you suggest suitable modules for end devices and the central node?

RE: nRF Bluetooth Mesh

daviddedwin — Thu, 24 Dec 2020 12:46:32 GMT

Simpler is better, absolutely. I think you can go for a connection oriented star or possibly a unidirectional or bi-directional connectionless star . In both cases go at least for a external antenna based module and optionally with a PA/LNA (as stated earlier the PA/LNA gives you some link budget and forgives bad placement decisions to some extent.

In a connection oriented star network:
The central point of the will be a Bluetooth central which connects to the Bluetooth peripheral sensors, the central will not be power efficient but the sensors on the edges can be battery operated. The connected Central can have upto 20 sensors that can be simultaneously connected, so you can choose to sample the sensors in a scheduled fashion or have a 3-4 Central nodes that will connect to the 70 odd sensors that you have. The links can be encrypted so data privacy is ensured.

Do a channel map management so the Centrals will get a different set of Channel maps each, additionally ensure that the channel maps do not collide with local WiFi.

In a connectionless star network:
The sensors are advertising as Bluetooth broadcasters and the gateway is a scanner. There is no data encryption so you need to implement an encryption scheme yourselves. It is simple for the sensors to be be battery operated and only broadcast (unidirectional), if you want to make the sensor bi-directional i.e. an advertiser and scanner role, you will have to work a bit more to do this in a battery friendly was but definitely possible (you will need to keep the scanner after the advertising and keep it as short as possible, if you dont control the scanner then it becomes the Bluetooth mesh role). In this case you will need only a single gateway to handle the connectionless advertising and scanning.

Make sure you have the link budget as at 300m you are at the limit of an external antenna solution, a PA/LNA will help here.

RE: nRF Bluetooth Mesh

vkadal — Thu, 24 Dec 2020 02:02:43 GMT

Thanks for the update. Even star network will suffice me . All the sensors need to send data to one location. So mesh may be an overkill as you say it is not power friendly. Is there any simpler solution?

RE: nRF Bluetooth Mesh

daviddedwin — Tue, 22 Dec 2020 19:54:04 GMT

I would suggest the nRF52832 or nRF52840, since the project volume is not very large you can pick a module. Pick a module with an external PA/LNA , the PA/LNA will give you some additional link budget, a ufl connector with an external antenna will give you a larger range as compared to a chip antenna or PCB antenna.
Look at https://www.nordicsemi.com/Software-and-Tools/3rd-Party/3rd-party-modules#shortrange for the list of modules available.

I assume these nodes will NOT be battery powered as Bluetooth mesh relay nodes are not power friendly.

An alternative to the Bluetooth mesh can be a connection oriented BLE mesh like https://github.com/mwaylabs/fruitymesh , which can provide more bandwidth but less complexity as compared to the Bluetooth mesh. (This is a 3rd party solution, but you can easily setup a similar solution or build on top of the github code), this can also be a bit more power efficient as compared to Bluetooth mesh. The packet size is also much larger so the bandwidth increase is substantial as well.

Development kits: nRF52832 DK or nRF52840 DK, go with the nRF52840 for the additional flash available during development , as suggested earlier use the DKs for the demo.

Bandwidth:
56 sensors, each sensor is read once in 30 seconds.
This would mean approximately 2 read messages per second.
Are you polling the sensor so you would get a read request and the response has the data ? or is the data from the sensor being sent asynchronously to the gateway ?

If you are reading the sensor and the sensor sends a response, it would make it 4 messages per second.

If you are using a vendor specific opcode for the mesh model, that will be 3 bytes of the 11 byte mesh payload, leaving you with 8 data bytes per packet. If you send data more than 8 bytes the packet will be segmented and performance will suffer quite a bit. Aim to keep the sensor reads within 8 databytes

RE: nRF Bluetooth Mesh

vkadal — Tue, 22 Dec 2020 15:18:23 GMT

These accelerometer will be fixed on rotating machines like motors. Nothing great will change even within 30 minutes. I have 56 sensors and if I take one reading per 30 seconds, it will not be much of data.

RE: nRF Bluetooth Mesh

daviddedwin — Tue, 22 Dec 2020 10:44:56 GMT

Since you are using accelerometers/tilt sensor, I presume this will be streamed over the wireless network and the analysis of the data will be at the PC. Is this correct ?
How often will you be sending data from the accelerometers to the PC, will this be on a specific event or will it be periodic (like once a second).
It will be easier to provide suggestions once I understand the bandwidth needs a bit more.

Please comment.

RE: nRF Bluetooth Mesh

vkadal — Tue, 22 Dec 2020 09:35:25 GMT

Yes, I agree with the point of view. Now I have checked the distance between sensors. Now I understand all the sensors will be within a range of 200-300 meters. So Bluetooth mesh seems to be a good solution.

I am planning to use ADXL series accelerometers. They have 3 analog outputs. So these tree inputs shall be measured and transmitted to a central location.

Can you suggest me the exact part number to achieve this solution? The data can be delivered locally through RS-232 to any local laptop / desktop

RE: nRF Bluetooth Mesh

daviddedwin — Tue, 22 Dec 2020 09:20:57 GMT

Yes, a wired multi drop bus is always a possibility but

1. wireless reduces installation costs when compared to a multidrop bus installation
2. adding a wired retrofit solution to a existing plant wiring is more complex and has more resistance in the plant management hierarchy, so a wireless retrofit is more amenable as it is seen as less disruptive
3. The value of a wireless solution is always perceived as more valuable, as the sales resistance to a wireless pilot project is less which results in more interested prospects

It does make sense to use wired and wireless as a mix and match, and a wireless component definitely adds more flexibility and value to the solution.

Some customers see wireless as a more reliable solution as opposed to a cable when cable wear and tear due to vibration, light or heat or movement etc is present.

Hope this helps

RE: nRF Bluetooth Mesh

vkadal — Tue, 22 Dec 2020 08:39:56 GMT

Increasing the number of nodes to cover a larger area will increase the cost and complication. Simpler option, for this use case, will be wired RS-485 . However thank you for the update

RE: nRF Bluetooth Mesh

daviddedwin — Mon, 21 Dec 2020 06:53:58 GMT

Thanks for asking this question. 3KM by 3KM is a pretty large area and would increase the number of hops in the mesh to beyond significant levels, by signification I mean a hop count of more than 10. I would strongly urge you create zones in the mesh and also plan for a backhaul between the zones.

Each zone should have 100-200 nodes typically, the nodes per zone can be increased if your bandwidth requirements are very low but I would start at the suggested typical and then move to larger zones. You should have a backhaul between the zones like LoRAWAN or just Ethernet.
Each zone will need a zone controller that sits on the backhaul.

Line of sight range where both end points are visible, obstructions are not present , outdoor and the antenna performance is good can be about 100m even on 0dbm, you can also get better range when you switch the RF side to the CODED PHY (as opposed to standard 1Mbit PHY in the mesh spec), range using the same constraints stated earlier can be about 900m to 1km.

Additionally evaluate a external PA/LNA for the mesh which will get you better performance as compared to using the mesh on CODED PHY

You must control the relay nodes that are used for hopping very strictly so that you get the bandwidth that you need.

RE: nRF Bluetooth Mesh

Joakim Jakobsen — Thu, 17 Dec 2020 09:05:12 GMT

Hi.

There shouldn't be an issue to cover an area of 3km x 3km, as long as you have a sufficient number of nodes and relay nodes in the network.

As long as the network is covered by relay nodes (Relay nodes: Nodes in the network that will relay messages through the network, increasing range and coverage) your message/command will be able to hop and reach the final destination.

Line of sight range of BLE / BLE Mesh nodes is very hard to say exactly. It will heavily depend on the environment, noise from other sources, obstacles, radio output power etc.

If you want to make a demo for your client, you could simply use a network of our development kits. If you don't have any specific requirements of memory, peripherals etc. you could take a look at the nRF52832.
We have working examples in our nRF5 SDK for Mesh that you can use as a starting point for your demo.

Please let me know if you have any further questions.

Br,
Joakim Jakobsen