Messages lost from NRF52 to IOS

For clarification I use the nrf5_SDK_for_Mesh_v2.1.1. and the nrf52832.

For a product of ours we use multiple NRF52 as nodes in a mesh that sends data to an application. This system uses one node as gateway that is connected with use of a BLE GATT as a bridge to connect the app with the nodes. The issue that we observe is that one message gets lost with IOS when two nodes sends data at roughly the same time, but this doesn't seem to be an issue when we use android. From this forum I got the information that Apple scans for peers and that it does not scan continuously, and that I should transfer data at a given interval. But how can I get this given interval with a mesh of which the nodes get triggered on a user input?

So in short how can I solve this issue in which messages get lost in IOS when I use a BLE mesh of which several nodes individually can transmit a message at the same time?

Sincerely.

Mr sunshine. 

Parents
  • Hi,

    Is the gateway also using nRF52832 and a project based on nRF5 SDK for Mesh v2.1.1, using the GATT proxy feature?

    In any case, it doesn't sound plausible that messages should get lost on the gateway to iOS device GATT connection. However, different GATT connections would have different connection parameters, dictating how much time the gateway must spend for the GATT connection, and in turn how much time the gateway have left to listen for inocming packets. It is the smartphone device which decides on connection parameters, since it is the central of the GATT connection. The gateway (GATT proxy device) is peripheral.

    If the iOS connection results in short connection interval and/or long connection events, then the gateway may spend more time in a GATT connection, missing more of the network traffic. One way to figure out connection parameters (and also see the extent of GATT communication between gateway and the iOS device) is to do a sniffer trace.

    Regards,
    Terje

  • Is the gateway also using nRF52832 and a project based on nRF5 SDK for Mesh v2.1.1, using the GATT proxy feature?

    Yes, yes, and yes.

    It is the smartphone device which decides on connection parameters, since it is the central of the GATT connection.

    I discussed this with the app developer who uses Flutter with the flutter_reactive_ble library to design the app (if you find this relevant information), and he had found a solution to adjust the characteristics to without response which seems to work. So this issue seems solved for now.

    One way to figure out connection parameters (and also see the extent of GATT communication between gateway and the iOS device) is to do a sniffer trace.

    I didn't use a sniffer, but I did debug the system by looking the incoming messages from the nodes side and from the apps side. What is simply observe is that the iOS misses some of the messages when multiple messages are send to it. Does the sniffer trace show more data besides the transmitted data?

Reply
  • Is the gateway also using nRF52832 and a project based on nRF5 SDK for Mesh v2.1.1, using the GATT proxy feature?

    Yes, yes, and yes.

    It is the smartphone device which decides on connection parameters, since it is the central of the GATT connection.

    I discussed this with the app developer who uses Flutter with the flutter_reactive_ble library to design the app (if you find this relevant information), and he had found a solution to adjust the characteristics to without response which seems to work. So this issue seems solved for now.

    One way to figure out connection parameters (and also see the extent of GATT communication between gateway and the iOS device) is to do a sniffer trace.

    I didn't use a sniffer, but I did debug the system by looking the incoming messages from the nodes side and from the apps side. What is simply observe is that the iOS misses some of the messages when multiple messages are send to it. Does the sniffer trace show more data besides the transmitted data?

Children
  • Hi,

    The sniffer trace will show all packets sent, in both directions, with good resolution time stamps, as well as the contents of those packets. For BLE connections that includes the connection setup, when the connection parameters are decided (including connection interval.) It is also easy to see how many packets gets sent per connection interval, among other things. It is very useful for understanding what is going on in a connection. In order to truly understand what is going on, a sniffer trace is the best option.

    Regards,
    Terje

Related