This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF Bluetooth Mesh

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?

Parents
  • 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.

  • 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

  • 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

  • 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

Reply
  • 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

Children
  • 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.

  • 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.

  • 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

  • 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?

  • 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.

Related