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?
Hi Crm,
You will have to calculate the amount of data that you plan to transmit from the PAwR advertiser(s) to PC.
Mesh is not designed to transmit large amount of data.
Can you describe the mesh network you plan to establish ? How many PAwR advertiser nodes in the network ? What's the distance between nodes , PAwR, and the PC ?Are they all in range of each other ?
Do you plan to do any data processing on the PAwR advertiser before sending to PC ?
If you don't and the plan is simply sending the same data from the PAwR advertiser to PC via mesh isn't it unnecessary ? Is it possible to just send the data straight from the nodes to PC ?
If your mesh network doesnt change dynamically (for example a node may move from one location to another) then Zigbee could be a better option as it can provide higher throughput.
I want to build a network where the PAwR scanners are freely mobile, but the PAwR advertisers are in fixed positions. However, some advertisers might be located far from the PC (server). Therefore, I intend to enable the advertisers to form their own network.
After collecting data from the scanners, if an advertiser is far from the PC, it can route the uploaded data through other advertisers.
These advertisers do not need to process the data; they only need to cache the data and then report it. After installation, the network topology will not change. Each network will require approximately 5 to 10 PAwR advertisers.There will be approximately 2,000 PAwR scanners, which report data every hour or every two hours.,
Therefore, I would like to know whether BLE Mesh or Zigbee is more suitable.
Hi Crm,
You will need to do some tests especially on the throughput. What's the expected throughput from a PAwR advertiser to PC ?
Using Zigbee has an advantage of higher throughput but the draw back is that you will need to have 2 stacks , BLE + Zigbee on the device.
Having just BLE + BLE Mesh would make it more simplified.
How is those 5- 10 PAwR advertiser located ? Are they all in the range of each other or not? How far away from each other ? Could you describe more ?
In addition, do you send data from the PAwR to the scanner ? Or only receive data from the scanner to PAwR. I'm asking because we need to check if PAwR needed or simply advertising from the scanner to PAwR advertiser node is OK ?
You will need to do some tests especially on the throughput. What's the expected throughput from a PAwR advertiser to PC ?
From the PAWR broadcaster to the PC-side central node, when the PAWR scanner reports data every hour, there will be relatively concentrated data transmission. Normally, data transmission is sporadic or in small amounts. When the broadcaster receives data, it first caches it and then uploads it to the PC-side central node approximately every 500ms. The data payload is about 60 bytes. Each time the PC-side node receives the data, it replies with a payload of 10-15 bytes to the PAWR broadcaster.
Using Zigbee has an advantage of higher throughput but the draw back is that you will need to have 2 stacks , BLE + Zigbee on the device.
Having just BLE + BLE Mesh would make it more simplified.
If I want to test BLE + Zigbee, how can I integrate both protocol stacks together? What example should I use?
How is those 5- 10 PAwR advertiser located ? Are they all in the range of each other or not? How far away from each other ? Could you describe more ?
The distribution of PAWR broadcasters is not fixed, with distances of about 50-100 meters between them. The signals from the farthest few might not be covered by the PC-side node, requiring intermediate routing. It's also possible that the broadcasters are surrounding the PC-side node, and their signals can cover each other while also being covered by the PC-side node.
In addition, do you send data from the PAwR to the scanner ? Or only receive data from the scanner to PAwR. I'm asking because we need to check if PAwR needed or simply advertising from the scanner to PAwR advertiser node is OK ?
I'm also very concerned about this issue. I currently need the PAWR broadcaster to reply with a notification to the PAWR scanner after receiving the reported data, confirming that the data has been received. I'm looking for implementation methods for this, but haven't found good ideas yet.
joey said:From the PAWR broadcaster to the PC-side central node, when the PAWR scanner reports data every hour, there will be relatively concentrated data transmission. Normally, data transmission is sporadic or in small amounts. When the broadcaster receives data, it first caches it and then uploads it to the PC-side central node approximately every 500ms. The data payload is about 60 bytes. Each time the PC-side node receives the data, it replies with a payload of 10-15 bytes to the PAWR broadcaster.
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.
joey said:If I want to test BLE + Zigbee, how can I integrate both protocol stacks together? What example should I use?
You can take a look at this ticket:
Can Zigbee coordinator and Bluetooth host run together on nrf52840
joey said:The distribution of PAWR broadcasters is not fixed, with distances of about 50-100 meters between them. The signals from the farthest few might not be covered by the PC-side node, requiring intermediate routing. It's also possible that the broadcasters are surrounding the PC-side node, and their signals can cover each other while also being covered by the PC-side node.
I assume with distance 50-100m they are in light of sight with no obstruction, correct ?
joey said:I'm also very concerned about this issue. I currently need the PAWR broadcaster to reply with a notification to the PAWR scanner after receiving the reported data, confirming that the data has been received. I'm looking for implementation methods for this, but haven't found good ideas yet.
You can use the broadcast from the PAwR to send confirmation. Or you can also establish a connection to each and every scanner to send/receive data (Connection 2.0 with PAwR). It's also possible to do so with normal BLE connection, if the communication is only once in an hour, I don't see a problem establish a connection to transfer little amount of data and then disconnect again.
joey said:From the PAWR broadcaster to the PC-side central node, when the PAWR scanner reports data every hour, there will be relatively concentrated data transmission. Normally, data transmission is sporadic or in small amounts. When the broadcaster receives data, it first caches it and then uploads it to the PC-side central node approximately every 500ms. The data payload is about 60 bytes. Each time the PC-side node receives the data, it replies with a payload of 10-15 bytes to the PAWR broadcaster.
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.
joey said:If I want to test BLE + Zigbee, how can I integrate both protocol stacks together? What example should I use?
You can take a look at this ticket:
Can Zigbee coordinator and Bluetooth host run together on nrf52840
joey said:The distribution of PAWR broadcasters is not fixed, with distances of about 50-100 meters between them. The signals from the farthest few might not be covered by the PC-side node, requiring intermediate routing. It's also possible that the broadcasters are surrounding the PC-side node, and their signals can cover each other while also being covered by the PC-side node.
I assume with distance 50-100m they are in light of sight with no obstruction, correct ?
joey said:I'm also very concerned about this issue. I currently need the PAWR broadcaster to reply with a notification to the PAWR scanner after receiving the reported data, confirming that the data has been received. I'm looking for implementation methods for this, but haven't found good ideas yet.
You can use the broadcast from the PAwR to send confirmation. Or you can also establish a connection to each and every scanner to send/receive data (Connection 2.0 with PAwR). It's also possible to do so with normal BLE connection, if the communication is only once in an hour, I don't see a problem establish a connection to transfer little amount of data and then disconnect again.
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.
The transmission from the PAWR advertiser to the PC is primarily concentrated at the top of each hour (00:00, 01:00, ..., 11:00) in a cyclical pattern. This is because PAWR scanners report data to the PAWR advertiser at these fixed hourly intervals. The PAWR advertiser caches the received data and then, at the application layer, packages and forwards 70-byte data packets to the PC-side node every 300ms until all cached data is cleared. Outside of these hourly reporting windows, there might be occasional retransmissions from a small number of scanners that failed to report successfully during their scheduled hourly slots.
I assume with distance 50-100m they are in light of sight with no obstruction, correct ?
There are some indoor columns present, but overall the environment is predominantly open and unobstructed.
You can use the broadcast from the PAwR to send confirmation. Or you can also establish a connection to each and every scanner to send/receive data (Connection 2.0 with PAwR). It's also possible to do so with normal BLE connection, if the communication is only once in an hour, I don't see a problem establish a connection to transfer little amount of data and then disconnect again.
I'm currently using S8 coding which provides relatively slow data rates. If I establish a connection to send reply messages, would this interfere with the timing slots and also increase power consumption? Instead of establishing connections or using broadcast transmissions, is it feasible for the advertiser to directly reply to the scanner within the same time slot when the scanner is reporting its data?
Hi,
joey said:The transmission from the PAWR advertiser to the PC is primarily concentrated at the top of each hour (00:00, 01:00, ..., 11:00) in a cyclical pattern. This is because PAWR scanners report data to the PAWR advertiser at these fixed hourly intervals. The PAWR advertiser caches the received data and then, at the application layer, packages and forwards 70-byte data packets to the PC-side node every 300ms until all cached data is cleared. Outside of these hourly reporting windows, there might be occasional retransmissions from a small number of scanners that failed to report successfully during their scheduled hourly slots.
Please correct me if I'm wrong, so it's 70bytes/scanner/hour, correct ? How many scanner each PAwR advertiser handles ?
joey said:I'm currently using S8 coding which provides relatively slow data rates. If I establish a connection to send reply messages, would this interfere with the timing slots and also increase power consumption? Instead of establishing connections or using broadcast transmissions, is it feasible for the advertiser to directly reply to the scanner within the same time slot when the scanner is reporting its data?
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).
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.
