CC2652R7: Bluetooth Mesh based School bus seat occupancy and seat belt fastening detection system for kids.

Hi Piyush,

Thank you for reaching out and bringing such an interesting use case to our attention.

First of all, please make sure to review the basic concepts of Bluetooth Mesh here and the related labs (here).

The description you have provided here did not mention the existence of relay node, may I ask why? Relay nodes are actually the ones allowing to extend the mesh network size. Without relay nodes, you have a single hop mesh network (also called star network ;) )...
In addition, I am not sure the friend node you have mentioned could actually enable the behavior you want. The friend nodes, are supposed to aggregate the messages for the low power nodes. In other words, the message from the bus driver to the seats could be aggregated by friend nodes - but I don't think this is part of your use case. 

If I may, I would like to kindly suggest a slightly different approach for your use case.
Instead of leveraging a Bluetooth Mesh network, I think you could leverage Bluetooth LE, potentially with Long Range PHYs (S2 and S8). In that case, similarly to what you have described in "scenario 2", the nodes would long-range advertise only when a change in the status of the seat is detected. In that case, you would need only the driver's node to be line powered (because it would continuously scan). All the other nodes could be battery powered.
Transmitting at 5dBm (or even a bit higher) with coded PHYs, you should definitely manage to get the range needed, without using a Mesh network.

From a hardware point of view, I would recommend to have a look at the CC2651R3SIPA  wireless system-in-package module with integrated antenna for the seat-nodes. The cost optimized CC2340 (https://www.ti.com/cc2340) could also be a good fit for the seat-nodes.
For the driver, I would recommend the CC2652R7.

I hope this will help,

Best regards,

Hi Clement, 

Thank you for your quick reply. 

With respect to Bluetooth Mesh concept, Yes I have through the documentation.

Yes you are correct, since my communication is more likely to be unidirectional hence instead of Friend node I shall rather need a Relay Node. 

Bluetooth Mesh Approach:
               Scenario 2: Considering I am using normal Bluetooth LE(Without coded phy) device for my sensors and they are configured as LPN devices. So in order to me to relay my messages to the front Proxy node at Drivers Cabin I shall need to instal (mains powered)relay nodes at regular intervals am I correct?

Bluetooth LE Coded Phy (Long range Phys): 

As per your suggestion, you mean to say that I may be able to directly use the Bluetooth LE with Long range PHYs into the advertising mode and should be able to transmit the data directly at the Tablet in the driver cabin. Wherein the tablet in the driver cabin will be always kept in scanning mode and will extract the data from the advertising packet of each sensor node. Please let me know if my understanding is correct?

My concerns: 

1) In my application I am looking for a possible max line of sight distance of around 100m between the drivers Tablet and my end node. Please let me know if the Long range Coded Phy support these distances without any issues. 

2) I would also like to request you to consider that my each seat belt sensors and seat occupancy sensors will also be a battery powered device ? Do you think I shall able to have atleast a year kind of battery life using long range Codded Phys.

3) I would like to bring to your notice that Inside the bus I am assuming lots of RF intereference sicne most of the seats will be metallic and there will be lots of school kids constanly moving around in the bus. Also since my sensors are for the seat belt and seat occupancy hence I believe most of the time they will be placed onto the seats in idle mode. So do you think the Long range PHYs would still give us good range?

Worst Case Solution: 

Considering lots of RF intereference due to lots of metallic seats and objects inside the bus, if incase my signal is not able to reach till driver's cabin. Do you think its possible to have a relay node along with the Long rage codded Phys to extend the coverage area of the network?
If not relay then is there any other way to extend the network coverage area of my bluetooth signals?

Thanks. 

Piyush Saxena 

Hi,

Piyush Saxena45 said:

1) In my application I am looking for a possible max line of sight distance of around 100m between the drivers Tablet and my end node. Please let me know if the Long range Coded Phy support these distances without any issues. 

The achievable range depends on a lot of factors. I would recommend to reference a range estimator (https://www.ti.com/tool/RF-RANGE-ESTIMATOR or https://www.bluetooth.com/learn-about-bluetooth/key-attributes/range/).  

Piyush Saxena45 said:

2) I would also like to request you to consider that my each seat belt sensors and seat occupancy sensors will also be a battery powered device ? Do you think I shall able to have atleast a year kind of battery life using long range Codded Phys.

I believe so. You can run some power measurement on your own leveraging EnergyTrace or using our power calculator https://www.ti.com/tool/BT-POWER-CALC

Piyush Saxena45 said:

3) I would like to bring to your notice that Inside the bus I am assuming lots of RF intereference sicne most of the seats will be metallic and there will be lots of school kids constanly moving around in the bus. Also since my sensors are for the seat belt and seat occupancy hence I believe most of the time they will be placed onto the seats in idle mode. So do you think the Long range PHYs would still give us good range?

Please refer to the first question.

Piyush Saxena45 said:

Considering lots of RF intereference due to lots of metallic seats and objects inside the bus, if incase my signal is not able to reach till driver's cabin. Do you think its possible to have a relay node along with the Long rage codded Phys to extend the coverage area of the network?
If not relay then is there any other way to extend the network coverage area of my bluetooth signals?

This is not "standard" Bluetooth Mesh, but it should work. You could consider having an "advertisements collector" in the middle of the bus that is either repeating the advertisements, or transmitting only the data through a Bluetooth connection to the bus driver. Note that the "advertisements collector" should be line powered as it would require to remain scanning for long periods of time. However, in that case, the bus driver's device would require much less power and could then be battery powered.

I hope this will help,

Best regards,

Hi Clement, 

Thank you for your suggestions. 

Please find my questions below. 

1) Can we have all the BLE Mesh stack functionalities using the long range Coded Phy's chip such as  CC2652R7 IC?

2) Considering that all the long range coded Phy chip support BLE Mesh, then do you think I can first start with having all my sensor nodes configured as LPN devices with BLE advertisers and then having a IPAD running the BLE scanning option always and then displaying/processing all the scanned advertisement packets into corresponding sensor node status into my IPAD Application. 

3) In continuation to my point 2, suppose my sensor nodes advertisement packet are not able to reach until drivers cabin then do you think I shall be able to then add some relay devices at corresponding positions and thereby will be able to improve the BLE mesh network coverage area?

4) After some study regarding overall the BLE Mesh architecture, I have came to know that it works on managed flooding based packet transmission. Since my sensor node data is crucial information for me hence do you think BLE Mesh will work for my overall application. 

5) In order to have a compact form factor of the sensor node I will be using mostly the MIFA antenna or the CHIP antenna which comes already built into the BLE modules. Do you think I shall be able to have similar longe range coverage using these antenna with the Coded Phy''s based chip such as CC2652R7. 

6) Considering the Managed flooding mechanism, do you think I should rather keep advertising my sensor node status at regular intervals to increase the probability of data being received at drivers end. Or do you have think that even transmitting the data once at every change in the sensor node status should also give me good reliability in terms of data. 

7) In terms of cost, battery and packet reliability do you think BLE mesh or Thread will be the best solution for my application. 

Thanks  

Hi,

Piyush Saxena45 said:

1) Can we have all the BLE Mesh stack functionalities using the long range Coded Phy's chip such as  CC2652R7 IC?

Yes - but you will have to implement them on your own as these are not Bluetooth standard

Piyush Saxena45 said:

2) Considering that all the long range coded Phy chip support BLE Mesh, then do you think I can first start with having all my sensor nodes configured as LPN devices with BLE advertisers and then having a IPAD running the BLE scanning option always and then displaying/processing all the scanned advertisement packets into corresponding sensor node status into my IPAD Application. 

I-Pads do not support long range PHYs

Piyush Saxena45 said:

3) In continuation to my point 2, suppose my sensor nodes advertisement packet are not able to reach until drivers cabin then do you think I shall be able to then add some relay devices at corresponding positions and thereby will be able to improve the BLE mesh network coverage area?

Yes - Note that a BLE Mesh network without relay nodes does not make much sense

Piyush Saxena45 said:

4) After some study regarding overall the BLE Mesh architecture, I have came to know that it works on managed flooding based packet transmission. Since my sensor node data is crucial information for me hence do you think BLE Mesh will work for my overall application. 

I do not have all the details of your application. I'll let you assess this one on your own

Piyush Saxena45 said:

5) In order to have a compact form factor of the sensor node I will be using mostly the MIFA antenna or the CHIP antenna which comes already built into the BLE modules. Do you think I shall be able to have similar longe range coverage using these antenna with the Coded Phy''s based chip such as CC2652R7. 

Please refer to the antenna stated for each part

Piyush Saxena45 said:

6) Considering the Managed flooding mechanism, do you think I should rather keep advertising my sensor node status at regular intervals to increase the probability of data being received at drivers end. Or do you have think that even transmitting the data once at every change in the sensor node status should also give me good reliability in terms of data. 

I do not have all the details here.
It sounds like advertising the state every x minutes could be a good idea, but it would come at the price of additional power consumption. You'll have to assess the pros and cons.

Piyush Saxena45 said:

7) In terms of cost, battery and packet reliability do you think BLE mesh or Thread will be the best solution for my application. 

It depends on the application. You'll have to make this assessment on your own.

I hope this will help,

Best regards,

Hi Clement, 
Thank you for your feedback. 

My Application Details:

In my application there will be a pressure switch based occupancy sensor and a input contact based mechanism for seat belt fastening detection. These both sensor will be battery powered and will be there for each seat of a bus. There may be aroung 150 seats to 200 seats in a bus, so total number of device will be around 300 to 400 ble devices. Now Its important for me to know as well log the status of each sensor into a Mobile/Smart device which may be present at the cabin section of the bus driver. Since this whole application is for the school kids travelling through school bus hence the data from each sensor is quite important to be receveid onto the smart device present with the bus driver. 

All the seats and internal structure is made up of metallic material and I assume the total length of the bus would be around 80 to 100m. 

I hope this shall give you sufficient clarity about my application. Do let me know if you need any more information. 

Based on your comments, It will be great if you can share your expert opionins/suggestion on below mentioned points. 

1) Due to my inexperience working with the coded phy ic my point 1 and 2 of my previous post was not precise hence i would like to apologise. Now, trying to make my own mesh stack with coded phy would be my last option as I don't want to add more complication into the system. Considering all of my sensors node are designed using coded Phy ic's and are transmitting their status as advertisers at regular intervales may be around 2 sec. In order to fully utilize the long range feature of long range coded phy IC's, do you mean to say that my receiver should also have the same support of the Coded phy? What if I make a gateway with a line powered Coded phy receiver which will receive all the advertisement data from each sensor and on the other end there will be normal BLE 5 device with connectable advertisement to which driver shall be able to connect using hi Smart Device? Do you think this is possible, please let me know if you have any better solution for the above case. 

2) Also I was doing some research and it came to my knowledge that the latest smart phone such as Samsung 10+ and above. one plus 9 and above etc have support for coded Phy. Can you please let me know if this will still work with our long range codded phy based approach explained in point 1. 

3) The case scenario mentioned in the point 1 is valid assuming that all the advertisement data packet is being able to be recevied by the receiver present at the driver cabin. In case this is not the scenario, meaning some of the sensor data is not being able to be reached at the driver's cabing then what are possible solution? Here do i need to implement custom repeaters using codded phy Ic based device? how this device will be able to scan as well as transmit this information simultaneously ?

4) In order to compensate for the limitation of using Coded phy in point 2 since they do not have a BLE mesh stack support, Do you think it will be preferrable for me to implement the BLE mesh itself since anyways I may be forced to have a custom repeater in case scenario discussed in point 2. 

5) Considering the Managed flooding mechanism, do you think I should rather keep advertising my sensor node status at regular intervals to increase the probability of data being received at drivers end. Or do you have think that even transmitting the data once at every change in the sensor node status should also give me good reliability in terms of data. 

6) Now since you know my application do you think using Thread protocol will be much suited for my application as compared to bluetooth. 

7) Is implement BLE mesh much cheaper in terms of hardware cost as compared to Thread protocol?

Thanks

Hi,

Piyush Saxena45 said:

4) In order to compensate for the limitation of using Coded phy in point 2 since they do not have a BLE mesh stack support, Do you think it will be preferrable for me to implement the BLE mesh itself since anyways I may be forced to have a custom repeater in case scenario discussed in point 2. 

Probably

Piyush Saxena45 said:

5) Considering the Managed flooding mechanism, do you think I should rather keep advertising my sensor node status at regular intervals to increase the probability of data being received at drivers end. Or do you have think that even transmitting the data once at every change in the sensor node status should also give me good reliability in terms of data. 

It sounds like advertising the state every x minutes could be a good idea, but it would come at the price of additional power consumption. You'll have to assess the pros and cons.

Piyush Saxena45 said:

6) Now since you know my application do you think using Thread protocol will be much suited for my application as compared to bluetooth. 

As phones usually don't support Thread, Bluetooth should be a better choice.

Piyush Saxena45 said:

7) Is implement BLE mesh much cheaper in terms of hardware cost as compared to Thread protocol?

The same hardware should be usable (CC2651R3SIPA / CC2652R / CC2652R7) so I do not expect much differences at this level.

I hope this will help,

Regards,

Hi Clement, 
Greetings of the Day

I would like to request to share your thoughts about the point 1 and 2 of my earlier post.

Thanks 

Regards

Piyush Saxena 

Hi,

Piyush Saxena45 said:

1) Due to my inexperience working with the coded phy ic my point 1 and 2 of my previous post was not precise hence i would like to apologise. Now, trying to make my own mesh stack with coded phy would be my last option as I don't want to add more complication into the system. Considering all of my sensors node are designed using coded Phy ic's and are transmitting their status as advertisers at regular intervales may be around 2 sec. In order to fully utilize the long range feature of long range coded phy IC's, do you mean to say that my receiver should also have the same support of the Coded phy? What if I make a gateway with a line powered Coded phy receiver which will receive all the advertisement data from each sensor and on the other end there will be normal BLE 5 device with connectable advertisement to which driver shall be able to connect using hi Smart Device? Do you think this is possible, please let me know if you have any better solution for the above case. 

Piyush Saxena45 said:

2) Also I was doing some research and it came to my knowledge that the latest smart phone such as Samsung 10+ and above. one plus 9 and above etc have support for coded Phy. Can you please let me know if this will still work with our long range codded phy based approach explained in point 1. 

Communication is possible only if interoperability of the devices is ensured.
In other words, both the sender and the receiver should support Coded PHY if this is the mean you want to use for communication.

Note also that Coded PHY is a Bluetooth defined feature i.e. any device supporting this feature should be able to be used.

Regards,