Hi Dialog,
I'm trying to send sensor data at 50Hz to 100Hz with the DA14580. I've come upon problem whereby using the ble_app_peripheral if I change the APP_PERIPHERAL_CTRL_TIMER_DELAY in user_peripheral.h to a low number so I can get a fast sample rate then the device does not detect when the master device goes out of range and disconnects which I think leads to the memory overflowing as messages will continue to be sent with ke_msg_send(req); I have tried to put a flag into user_custs1_accl_ntf_cfm_handler to control the flow but this doesn't seem to have helped.
If I lower the sample rate by say increasing APP_PERIPHERAL_CTRL_TIMER_DELAY to 10 for 10Hz then everything seems to work OK. Is there somewhere else in the code I should hook into to make sure I detect the disconnect and stop the update timer?
Thank you for your time,
Best wishes,
Thomas
Hi thomasburton,
Is you device going into a reset ? This is the way to make a congestion control and fix that specific issue with notifications, are you sure that the implementation (wait for a GATTC_CMP_EVT event before sending the next notification) is properly implemented by your code ? The indication for the disconnection is the only available indication to your application in order to get the disconnection event.
Thanks MT_dialog
Hi MT_dialog,
Thanks for your quick reply, I added a call to user_custs1_accl_ntf_cfm_handler in user_periperhal.c under user_catch_rest_hndl and use that to trigger a flag to control ke_msg_send(req); in user_cust1_impl.c. However, this still doesn't seem to stop the device from not detecting when the phone has gone out of range. I've tried to hook straight into the GATTC_CMP_EVT in gattc_cmp_evt_handler in cust1_task.c but still nothing when the update timer delay goes below 10. I've tried this with the bare peripheral example only sending 2 bytes of data and get the same problem. I have a workaround by buffering the data and sending it less often but if there is a proper way to do it that would be preferable.
Thanks!
Thomas
Hi thomasburton,
You can try to reduce the supervision timeout in order not to wait that long before the stack sends a disconnection to the application.
Thanks MT_dialog
Hi Dialog,
That seems to have fixed it! Thank you very much for your help.
Best wishes,
Thomas