BLE UART connection status

[Robin]

Hello Nordic Pro's,

We are developing a product based on the BLE UART peripheral.  We communicate heavily via NUS.  There are extended processes that continually send status messages over BLE via a central based device.  These processes need to continue if the system disconnects, but the messages need to resume once reconnected.  So, we need to be able to detect the connection status and not send any messages when not connected, then resume the message once connected.  I have read through most if not all of the related cases, but cannot decipher a straightforward answer.  How can I determine from within a peripheral app whether it is connected to a central device? Has anyone successfully done this? 

Thanks again,

Robin@TL

[Simonr]

Hi Robin

I'm having some trouble understanding what exactly you want.  Do you mean like a return value when the peripheral connects/disconnects to a central? Because this can be seen if connecting it to a terminal or something similar. You should also be able to implement an LED to turn on when connected and off when disconnected if that is what you are after.

If I have misunderstood what you want to achieve, please try to explain it again.

NOTE: Creating a public case would let the community come with suggestions as well, which increases the chance of someone providing I.E. a working example of what you want. We can also set this case to public mode if you'd like. Just give me the word.

Best regards,

Simon

[Robin]

Hello again Simon,

I was premature in my assessment below that I had this working.  It only holds up for a couple minutes after the central disconnects.  If continually connect/disconnect, all seems fine, but if it stays disconnected for any length of time the peripheral crashes and needs to be powered down to restart correctly. 

To attempt to clarify what we are attempting, please consider the following rewording of the problem:

We are using a Nordic USB dongle as a ble_uart_central to communicate commands and responses over bluetooth between our board (which is based on the ble_uart_peripheral) and a host computer/terminal emulator.  Our board has code for performing long time duration (up to 24 hours) stabilization testing.  During this test, status updates are sent back to the host every 10 seconds or so.  The test must remain in effect if the central disconnect for any reason, with the intention of reconnecting later to resume and interpret the messaging.  So, the code snippet below shows how we understood this could be done, from our reading of similar posts.  However, as mentioned, it only holds up for a couple minutes of disconnect time and then the board crashes.  So long as we stay connected, the code runs to completion.

Anything you can offer on how this might be resolved is greatly appreciated.

Thank you in advance,

Robin@TL

[awneil]

If you've been disconnected for a "long" time, there will be a "lot" of waiting data to be sent

Your posted code doesn't check the return code from ble_nus_string_send() - it just keeps flinging data at it.

At some point, it is going to get overwhelmed - that point is, presumably, your "couple of minutes".

The error code NRF_ERROR_RESOURCES indicates that it is "full" - so you need to hold-off sending for a while...

[Robin]

Hello awneil,

I think my code sends nothing if not connected.  There is a if (connected) qualifier in the loop.  Since the last post I did add a while loop looking for a NRF_SUCCESS, but it did not help.  Am I missing something else here?

static void send_str(const char * str)
{
  if (connected)  // This should preclude any sending if disconnected..
  {
    uint8_t i = 0;
    while ((str[i] != 0x0A) && (str[i] != 0x00) && (i < BLE_NUS_MAX_DATA_LEN)) 
    {
      i+=1;
    }
    if (str[i] == 0x00)
      i-=1;   
    // wait until errors clear...
    while (ble_nus_string_send(&m_nus, (uint8_t*)str, i+1) != NRF_SUCCESS)
      ble_nus_string_send(&m_nus, (uint8_t*)str, i+1);
  }
}

[awneil]

Robin said:

I think my code sends nothing if not connected

But, in that case, you are saving up the data to be sent when you are next connected - yes?

So, the longer you are disconnected, the more data is going to be waiting to be sent when it reconnects.

The logic of your loop is not correct: you keep calling ble_nus_string_send() within the loop without checking its return while the call in the control clause returns other than success!

Take a look at how Nordic do it in the example ...

[Robin]

Hello,

I have no need to save the data for later transmission so I bypass the ble_nus_string_send() if disconnected.

Which specific example are you referring to, please?

Thanks

Robin