I am now using 52832 to do a project, need to send a BLE broadcast package first, and then start scan, what examples can I refer to?
Attachment is my TX/RX process,and I need to implement the device B
I am now using 52832 to do a project, need to send a BLE broadcast package first, and then start scan, what examples can I refer to?
Attachment is my TX/RX process,and I need to implement the device B
The exact timing doesn't make much sense and you might get some troubles catching exactly 2ms delay but it should be possible after some fight with the code and testing. When it comes to dual roles you just need to implement both GAP Peripheral and Observer/Central. There are dual BLE role examples in the SDK, you might like BLE relay but in the end you will probably arrive to your own FW code just slightly inspired by these...
The exact timing doesn't make much sense and you might get some troubles catching exactly 2ms delay but it should be possible after some fight with the code and testing. When it comes to dual roles you just need to implement both GAP Peripheral and Observer/Central. There are dual BLE role examples in the SDK, you might like BLE relay but in the end you will probably arrive to your own FW code just slightly inspired by these...
Thank you, my project is a similar beacon application, the difference is that after the device sends a beacon, it needs to receive a reply (to execute some commands).
I do understand it but why exactly 2ms? All BT stacks I've seen can multiplex Tx/Rx much faster so letting it on them and just run both roles in parallel should do the job.
Are both the Device A and Device B nRF52832 devices ?
I don't think Android or iOS gives you access to the low level of the BLE hardware which would allow you to do this.
No,only device B is a nRF52832 device. device A is a locator that is designed by other Company.
Still what is the meaning of these arbitrary delays? There is nothing like this defined in BT SIG Core spec so why you need them? And if Device B simply follows the spec and logical implementation of BLE functions why just don't use it (meaning it will "listen" sooner then that 1ms after Tx window - whatever that Tx window is - and it might be listening longer)?