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!

[Pjay]

Hi,

Sigurd said:

The link gets encrypted, and the sniffer is therefore unable to see the packet content.

I thought that sniffing is possible, as long as the encryption is initiated after starting of the sniffing, as it was during my procedure (s. here https://devzone.nordicsemi.com/f/nordic-q-a/14035/is-nrf-sniffer-doing-decryption). Is bonding mandatory for that? Or are the devices using encryption information which was exchanged during first connection?

Sigurd said:

I don't see any issues in the log. The connection interval is 15 ms (Delta time (µs start to start) for master + slave). For each connection event, the master sends a packet, and the slave responds. Then after 15 ms the next connection event starts. The slave is always just sending 1 packet per connection event.

Isn't the delta time just the time spend during a connection interval, defined by NRF_SDH_BLE_GAP_EVENT_LENGTH? That would be "the time set aside for this connection on every connection interval". But what I am interested in is the time difference between two adjacent connection intervals.
By the way: the min- and max-values for the connection intervals are set to 7.5ms in the software for all devices. The value for NRF_SDH_BLE_GAP_EVENT_LENGTH is set to 5, which should result in 6.25 ms.

And: what does the flag "More Data" (TRUE/FALSE) represent? I wasn't able to find this information in the user guide. The flag is TRUE for some of the packets send from the slave to the master...

[Sigurd]

Hi,

Pjay said:

what does the flag "More Data" (TRUE/FALSE) represent?

It means that the peripheral has more data to send. From the Bluetooth spec(BLUETOOTH SPECIFICATION Version 5.0 | Vol 6, Part B page 2642):

The MD bit of the Header of the Data Channel PDU is used to indicate that the device has more data to send. If neither device has set the MD bit in their packets, the packet from the slave closes the connection event. If either or both of the devices have set the MD bit, the master may continue the connection event by sending another packet, and the slave should listen after sending its packet. If a packet is not received from the slave by the master, the master will close the connection event. If a packet is not received from the master by the slave, the slave will close the connection event.

Pjay said:

Isn't the delta time just the time spend during a connection interval, defined by NRF_SDH_BLE_GAP_EVENT_LENGTH?

No. Delta is the time since previously recieved packet.

Looking at the event counter field, it seems like every other connection event is missed by the sniffer(maybe due to the encryption), OR since this is a multlink central, the connection events are being skipped so that it can scan for other devices.

1) Is the central doing scanning when it's connected to 1 peripheral?

2) if the central is not scanning, could you provide a sniffer-log where you are not encrypting the link ?

[Pjay]

Hi Sigurd,

Sigurd said:

1) Is the central doing scanning when it's connected to 1 peripheral?

No, the central device stops scanning after connecting to the Master (Relay).

Sigurd said:

2) if the central is not scanning, could you provide a sniffer-log where you are not encrypting the link ?

Please find the log file attached to this post. I disabled encryption by declining pairing using
sd_ble_gap_sec_params_reply(conn_handle,BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, NULL, NULL);
I hope this is correct.

Wireshark_NoEncryption.pcapng

[Pjay]

Hi Sigurd,

the log files I have uploaded so far were related to the communication between the slave and the master/relay. As the master has to communicate with both the slave and the central, I think the log file of the master to central communication could be interesting as well (see attachment). I think that one cause of timing problems could be, that I have activated the connection length extension for the master. As the master has to handle two connections, this might be a problem. I also tested the communication with deactivated connection extension, and the result is very bad (many missing packets, see log file).

What is your opinion? Could this be the reason for sporadic timing problems?

WithConnExtension.pcapngWithoutConnExtension.pcapng

[Pjay]

Hi,

another question: as already stated I have activated data length extension and set MTU Size to 247. In my recent software, I have increased the transmitted data bytes from 64 to 82 bytes (sent from master/relay to central). Now, regularly some packets get lost (before all packets were received). If the available packet data size is 247 (or 244 without header), why does it matter if I transmit 64 or 82 bytes? Shouldn't the time needed for the 247 byte packet be the same?