HI
I am using the nRF54L15. Is it possible to integrate BLE Mesh functionality into the periodic_adv_conn example? This would allow the device to both receive data reported from a periodic_sync_connnode and route data with other periodic_adv_connnodes for data relaying and uploading.
Thanks!
Hi CRM,
I don't see a problem having mesh and PaWR running at the same time. We do have example doing normal BLE and mesh (ble_peripheral_lbs_coex). I think you should be able to base on that sample add change normal BLE to PaWR.
The question here is what you want to do with the mesh network ? Do you need both PaWR and Mesh ?
If you already have Mesh network, you can broadcast message into the network similar way how PaWR advertiser doing it.
And vice versa, if they are all in the same range of the advertiser, you can transmit data via PaWR without the need or a mesh network.
I have a large number of tags distributed across different areas. Each tag sends one piece of data every hour, and each piece of data is approximately 60 bytes at the application layer.
I want to use PAwR combined with MESH nodes as routers, where PAwR receives and manages the data from the tags, and then forwards this data to a more distant PC end through MESH networking. Therefore, I need nodes that operate in this mode. For this kind of model, which is more suitable: PAwR + Bluetooth Mesh or PAwR + Zigbee?
Please correct me if I'm wrong, so it's 70bytes/scanner/hour, correct ? How many scanner each PAwR advertiser handles ?
That's essentially correct. However, the 70 bytes refer to the data generated at the application layer, not the data after Bluetooth protocol encapsulation. Upon receiving and parsing out these 70 bytes, the advertiser forwards them directly without any processing. Each advertiser has approximately 500 nodes
No as far as I know the advertiser will have to use the next periodic advertising packet to send the confirmation back.
Note that the connection v2 can be established when the PAwR advertiser continue to do periodic advertising (it's part of the PAwR specification). If you choose a connection interval matches with the subevent interval there will be less chance of scheduling conflict. With the rate of transmitting once per hour , I don't see a problem).
So, is it feasible to establish a connection as long as the response slot is set with an appropriate interval?
Hi,
joey said:So, is it feasible to establish a connection as long as the response slot is set with an appropriate interval
Yes, in that case it will not disturb the periodic advertising activity. I made a blog here a while ago, this could be useful for you:
Periodic Advertising with Responses (PAwR): A practical guide
Connection v2 is touched briefly at section 3.3
That's essentially correct. However, the 70 bytes refer to the data generated at the application layer, not the data after Bluetooth protocol encapsulation. Upon receiving and parsing out these 70 bytes, the advertiser forwards them directly without any processing. Each advertiser has approximately 500 nodes
Regarding the BLE+Zigbee solution, what are the evaluation conclusions?
Yes, in that case it will not disturb the periodic advertising activity. I made a blog here a while ago, this could be useful for you:
Periodic Advertising with Responses (PAwR): A practical guide
Connection v2 is touched briefly at section 3.3
Thanks, I'll try it.
Hi,
joey said:Regarding the BLE+Zigbee solution, what are the evaluation conclusions?
Could you explain what you meant ? It's at production level as far as I know. Most of our Matter samples have BLE + Thread (802.15.4) support.
Please give the exact number of byte to be transmitted from PAwR advertiser to PC and the interval so that we can calculate the throughput.
you mentioned earlier that you need my data reporting status to assess whether the Zigbee throughput is suitable for this type of application
Please give the exact number of byte to be transmitted from PAwR advertiser to PC and the interval so that we can calculate the throughput.
you mentioned earlier that you need my data reporting status to assess whether the Zigbee throughput is suitable for this type of application
Hi,
Yes but your throughput is really low as far as I understand.
You are talking about 70 bytes * 500 nodes / hours = 9.7 bytes/s It should be fine with both Bluetooth mesh and Zigbee.
Thanks, According to your calculations, what is the maximum throughput limit for Zigbee or BLE Mesh?
Hi,
The generic numbers (it depends a lot on how many nodes in the network, how large the data packet is) for Zigbee is 20kbps-120kbps. When for Bluetooth mesh it much lower, at around 3-4kbps with one hop.
