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

Heartbeat with response to understand both mobile device is connected

Hi,

I have a setup where mobile device(central) connect to nrf51dk (peripheral) and exchange data for a time. I want to detect unplanned disconnection of mobile device in 2-3 seconds. I tried to do this with supervision timeout but android forces its 20s supervision timeout. I am planning to implement a heartbeat that nrf51 sends and mobile phone receives, but i want to include give a response from the mobile phone to the heartbeat received from nrf51dk. So that i can understand mobile phone is connected. How can i do this? is there any notify with response gatt type? or any other suggestions?

SDK: 12.3.0

Soft Device : S130

Thanks 

Parents
  • Hello,

    I want to detect unplanned disconnection of mobile device in 2-3 seconds.

    By this, do you mean a termination of the link from either side, or that a device stops responding - such as if it is out of reach?

    I tried to do this with supervision timeout but android forces its 20s supervision timeout.

    This is correct, it is the central that determines the supervision timeout.

    I am planning to implement a heartbeat that nrf51 sends and mobile phone receives, but i want to include give a response from the mobile phone to the heartbeat received from nrf51dk.

    Well, strictly speaking, every connection event will be such a heartbeat - because a connection event starts with the central sending a packet, followed by the slave's response, acknowledging the masters initial packet.

    How can i do this? is there any notify with response gatt type? or any other suggestions?

    Every packet sent over BLE needs to be acknowledged by the other device. If a packet is not acknowledged, then it will be re-transmitted until it is acknowledged or the timeout supervision is up, and the link is terminated.
    I am not entirely sure what you would like to achieve here.
    I suppose you could implement a timer that keeps track of how long time has passed since the last received packet - but this would come in addition to the existing timeout supervision timer. Additionally, if you then were to send a link termination packet, it will not be acknowledged either, so the link will time out instead.
    Could you tell me more about what you intend for the peripheral to do, if it does not receive anything from the central for 2-3 seconds?

    Best regards,
    Karl

  • Hello, thanks for your answer. By unplanned disconnection I meant power off of mobile phone or disconnection because of distance. I want to detect this disconnection in 2-3 seconds and go back to advertising. Supervision timeout takes too long to go back to advertising state.

    What came to my mind is, sending heartbeat every 2-3 seconds from peripheral and on the mobile phone side, during the handling of this heartbeat notification, writing to a write characteristic provided by peripheral. And in peripheral side check if this write characteristic is triggered every 2-3 secs. If not go back to advertising state. 

  • Hello,

    Sorry for my late reply.

    Serhan said:
    thanks for your answer.

    No problem at all, I am happy to help!

    Serhan said:
    By unplanned disconnection I meant power off of mobile phone or disconnection because of distance. I want to detect this disconnection in 2-3 seconds and go back to advertising. Supervision timeout takes too long to go back to advertising state.

    I understand what you mean, thank you for clarifying.
    This is usually what the supervision timeout feature is used for, but I understand your issue with the Android central dictating a too long supervision timeout.

    Serhan said:
    What came to my mind is, sending heartbeat every 2-3 seconds from peripheral and on the mobile phone side, during the handling of this heartbeat notification, writing to a write characteristic provided by peripheral. And in peripheral side check if this write characteristic is triggered every 2-3 secs. If not go back to advertising state. 

    You could use the sd_ble_gap_disconnect function for this, as illustrated in this sequence diagram. You could have this function called following a timer timeout, and then refresh the timer with every received packet, or after a certain transfer has occurred. What do you think about this solution, could it work for your application?
    The disconnect is usually handled by going back to advertising, so this will require only small changes to your existing code - namely the addition of such a timer.

    Best regards,
    Karl

Reply
  • Hello,

    Sorry for my late reply.

    Serhan said:
    thanks for your answer.

    No problem at all, I am happy to help!

    Serhan said:
    By unplanned disconnection I meant power off of mobile phone or disconnection because of distance. I want to detect this disconnection in 2-3 seconds and go back to advertising. Supervision timeout takes too long to go back to advertising state.

    I understand what you mean, thank you for clarifying.
    This is usually what the supervision timeout feature is used for, but I understand your issue with the Android central dictating a too long supervision timeout.

    Serhan said:
    What came to my mind is, sending heartbeat every 2-3 seconds from peripheral and on the mobile phone side, during the handling of this heartbeat notification, writing to a write characteristic provided by peripheral. And in peripheral side check if this write characteristic is triggered every 2-3 secs. If not go back to advertising state. 

    You could use the sd_ble_gap_disconnect function for this, as illustrated in this sequence diagram. You could have this function called following a timer timeout, and then refresh the timer with every received packet, or after a certain transfer has occurred. What do you think about this solution, could it work for your application?
    The disconnect is usually handled by going back to advertising, so this will require only small changes to your existing code - namely the addition of such a timer.

    Best regards,
    Karl

Children
Related