nRF Bluetooth Mesh

[vkadal]

I have a requirement to collect data over a plant, say a power plant whose size may be 3 KM by 3KM. I am planning to  have a Bluetooth mesh and collect data and control equipments.  The collected data shall be given to the SCADA installed in their plant.

Can message / command hop and reach the final destination in a Bluetooth mesh?

What is the line of site range of Bluetooth devices?

Kindly suggest required development boards and Bluetooth devices so that I can arrange a demo to my client?

[daviddedwin]

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.

[vkadal]

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

[daviddedwin]

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

[vkadal]

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

[daviddedwin]

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.

[vkadal]

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.

[daviddedwin]

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