This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How to implement timeslot observer based on ble_app_hrs?

Greetings,

I have a peripheral (S110) , when it is connecting to a central, it also need to scan another broadcaster (beacon) to obtain its RSSI and send to the central. So I tried to use the Nordic GitHub project Timeslot Oberver example on ble_app_hrs. So I copied the code from \nRF51-multi-role-conn-observer-advertiser-master\observer to \ble_app_hrs , and merged the two main() functions. But it didn't work. And I found if i commented advertising_start(), it can print advertising_report. And if i uncommented advertising_start(), it printed nothing. What's the problem and how can I do? Many thanks!

  • Hi,

    You can try the experimental_ble_app_multiactivity_beacon example in SDK v7.x where you can find a advertise and a scanner example that combine with hrs profile.

  • Thanks. I have tried this example. But after peripheral connected to central, the scanner stopped working. And then I changed the priority of earliest from NRF_RADIO_PRIORITY_NORMAL to NRF_RADIO_PRIORITY_HIGH, it works, but the connection between peripheral and central always broke. How can I do the scanning meanwhile maintaining the connection?

  • If the connection interval is too short, it will not timeslot for scan period to be able to catch the advertising packet. So if you can set the connection interval to longer, say 500ms, the scanner should work. In the example, the connection interval will be updated when the notification of the HRS service is enable (write 1 to the CCCDs).

  • Hi Hung, thanks for your suggestion. In my code, the MIN_CONN_INTERVAL is 500ms, MAX_CONN_INTERVAL is 1s, SLAVE_LATENCY is 0. But the problem is still there : after the connection between peripheral and central was established, once the scanner got a advertiser package, the peripheral disconnected to the central. It's so weird. Do you have any clue?

  • How do you handle the event when the advertising packet is caught ? Note that if you take too much time in the event handler you will have a hardfault.

    Could you run the firmware in debug mode and add a breakpoint in the assert handlers, such as in softdevice_assertion_handler() and find which line number, and file name caused the issue ?

    You can test by doing nothing but toggle a LED when receives the advertising packet to see if the issue remains. If it doesn't crash I would suggest you to use the scheduler, or set a flag when receive the advertising packet, instead of doing the processing inside the event handler.

Related