nRF52 - Irregular delay between data packets

[Pjay]

Hi there,

In my application I use a hardware timer to capture and transmit sensor data with a sample time of 10ms (after corresponding notification is enabled). The connection interval is set up to 7.5ms. 

As the TX queue is filled with slower rate than the data is (or should) be transmitted, I would expect that there are "empty" (or no) packets between the sensor data packets, but not that multiple data packets are transmitted during one connection interval. However, that seems to be the case: I use a nRF DK52 board in combination with nRF Connect using a PC to enable notification of the bluetooth characteristic which should send packets with sensor data every 7.5ms. However, examining the timestamps of the incoming packets,

1) the delay times between the packets seem to vary and are never 7.5ms (s. Screenshot)
2) it seems as if during some connection intervals multiple packets are received

The data packets contain an index which is incremented by the sensor application with every new data set. Apparently, no packets seem to miss. Only the time in between the incoming packets is what troubles me (as for the real application the sensor data is transmitted to a second device which performs real time processing of the data, where the time difference of the packets is of importance). 

I am using an nRF52832 with SD s132 5.0.0 and have activated DLE.

The log file gained by nRF Connect is attached.

Thanks in advance for any help!

[Sigurd]

Hi,

The latest sniffer log also has event counter increments of more than 1, and that happens when the device starts to send notifications. But you are not losing any packets (as the SN, NESN are in sync). So, it seems like the master is deliberately skipping connection events.

How did the setup look like when you captured the sniffer log ?Could you explain this some more ? How many devices, 2 or 3? 1 DK used for nRF Connect BLE app(acting as central master) that you connect to this relay device(acting as peripheral in this case) ? Is the relay device connected to anything else, I assume it can connect to another peripheral? Is the relay scanning for other peripherals?

Pjay said:

some packets get lost

How are you detecting this ?

[Pjay]

Hi,

altogether 3 devices are used: two self-developed boards with an NRF52, and one NRF52DK board.  One of the self-developed boards acts as relay, and at the beginning scans for the advertising message of the other board (“slave”). The relay connects to the slave but does not yet activate notification of the slave characteristic. The connection interval is 7.5ms. As long as the relay is only connected to the slave, it simultaneously sends out its own advertising message. The DK board is used as central master and scans for the advertising message of the relay. It automatically connects to the relay based on the UUID and then it activates notification of the relay service/characteristic. In that case, the relay activates notification of the corresponding characteristic of the slave. After that, none of the devices advertises or scans anymore.
The slave sends its data to the relay, the relay send preprocessed data to the central master. The master transmits the data via NRF_LOG-commands either by UART or RTT to the PC (NRF connect app is not involved!).
Each notification message contains a Message ID, which is incremented in every call to BLE-update. BLE-Update is called based on a timer interrupt event every 10ms. The relay sends its own message ID and the Message ID received by the slave to the central. In this way, it can be controlled if any packet was not received between slave and relay, and/or relay and central (by looking at the difference between the message IDs of two adjacent packets). When I speak of lost packets, I mean the case when the difference between two adjacent packets is larger than 1 because that indicates that the corresponding message was not received.

However, I think I found out why in wireshark the difference of the packet index between adjacent  packets is always 1 (i.e. no packet is lost), but the difference of “my” message ID is not always 1 between two adjacent packets: the reason is, that the call to BLE update function was not always successful. It occasionally returned NRF_ERROR_RESOURCES, that means that the message was not sent. In these cases, the (application) message ID was still incremented, so that ID differences > 1 occurred. Now, I have changed the code to repeat the call to BLE Update function in case of return value NRF_ERROR_RESOURCES and it seems that the problem is solved.

What exactly is meant with “resources”? Does it mean that there is not enough time left in the current connection interval? Or does it have anything to do with the transmit buffer size?

If the BLE update is called periodically in a fixed timing interval, does the timing between the call to BLE update function and the next connection event matter? What happens for example, if the function is called when the connection event has already started?

[Sigurd]

Pjay said:

What exactly is meant with “resources”? Does it mean that there is not enough time left in the current connection interval? Or does it have anything to do with the transmit buffer size?

NRF_ERROR_RESOURCES means that too many notifications are queued, and the internal buffers in the SoftDevice are full. If that happens, you can not queue any more notifications until the BLE_GATTS_EVT_HVN_TX_COMPLETE event occurs. You have 2 options, either call your update function in a loop until the function returns NRF_SUCCESS, or wait for the BLE_GATTS_EVT_HVN_TX_COMPLETE and then send the packet. (e.g. in ble_app_uart example we are just waiting in a loop).

Pjay said:

If the BLE update is called periodically in a fixed timing interval, does the timing between the call to BLE update function and the next connection event matter? What happens for example, if the function is called when the connection event has already started?

At the start of the connection event the peripheral will start to send all the data(notifications) in the internal buffer as fast as possible to the central. When the peripheral don't have any more data to send, the connection event ends, and the peripheral need to wait until the next connection event occurs before it can send data again. If the application is queuing up data to the softdevice fast enough, i.e. faster than the data is being sent over BLE(this is typically not the case), the whole connection event could possibly be used to send data. The internal buffer size is configured indirectly by setting the NRF_SDH_BLE_GAP_EVENT_LENGTH in sdk_config.h, so if you are having issues with NRF_ERROR_RESOURCES, I suggest increasing that value in the peripheral project.

[Pjay]

Hi Sigurd,

thanks a lot for the support so far. I think your last reply answers my original question, as it explains why it can happen that the timing of the received packets varies and sometimes multiple packets are send during one connection interval (I'm going to check the timing in my application between adjacent calls to BLE-update function, maybe a variation of the processing time causes the queue to be filled unequally).

My last questions (promised ;-)) related to this topic:

1. If the available packet data size is 247 (or 244 without header) due to data length extension, does it have influence on timing how many bytes are really used (as long as the number of bytes is <244)?
2. The value in NRF_SDH_BLE_GAP_EVENT_LENGTH (in ms) should be smaller than the connection interval in order to provide correct timing behavior, right?
    
3. Should I avoid using connection length extension as my relay device has to handle two connections?
   
   
4. I made the following test to evaluate timing: I connected the peripheral (slave) directly over NRF connect using an NRF52 DK, set the connection interval to 7.5ms and activated notification. In the firmware, I set a GPIO-pin to high whenever BLE-update is called, and set it to low when the event BLE_GATTS_EVT_HVN_TX_COMPLETE is called. I analyzed the resulting signal during notification using an oscilloscope. The signal is usually high for a duration of about 11.9ms. Even in worst case regarding the time difference between the call to BLE-update (filling the queue) and the next connection interval event, I would expect the time difference to be less than 7.5ms. How can that be?
   Additional information: NRF_SDH_BLE_GAP_EVENT_LENGTH is 6 (which should equal 7.5ms), connection length extension is deactivated, and no errors with NRF_ERROR_RESOURCES are returned.

[Pjay]

Hi Sigurd,

could you please answer my last questions? I know this thread has exceeded the usual extent, but the last questions are still related to my original question and are very important for our project.