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!
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.
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?
