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

Delay between characteristics changing and connected device getting notification of that change

Hi folks,

I have a system basically working with the following setup:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS)      
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS)       
#define SLAVE_LATENCY                   0      

I have a custom service with four characteristics that allow data to get from Nordic to PC (running Linux, not Windows or OSX) with handshaking in the following way:

PC Puts data in char1

Nordic gets new data and then:

Nordic writes value to char2 which tells the PC the Nordic has got the data and has enough space in its buffer for the PC to send more data. PC then pus updated version in char1 and so on...

The other two characteristics work for data being sent the other way.

Now, this works fine apart from the fact that there's a big old delay between data being put in a characteristic and the other end getting notification of that change. One problem is I don't know whether this is a delay between the Nordic picking up what the PC has changed or the PC picking up what the Nordic has changed.

I have put measurements at the PC end so I can tell that from a characteristic changed by the Nordic to tell the PC it is ready for more data it takes 140ms between updates. ie it is a round trip of 140ms, which is far too long!

Nordic writes to char2, PC updates char 1. Between the PC picking up that change in char2 and updating char1 there is less than a millisecond.

From the Nordic picking up the change in  char1 and putting a new value in char2 to twell the PC it can update char1 there is less than a millisecond.

So, there is either:

A delay in the soft device updating the characteristic after its API is called or:

A delay in the PC picking up the change in the characteristic or:

A delay in the PC from the application writing to the characteristic and it appearing "on air" or:

A delay in the soft device from picking up the change in char1 to sending it to my software running on the Nordic.

Or some combination of these. 

Are there any settings I have not tweaked that might be causing this? If so, what migt they be?

Can anyone think of anything I can do to track down exactly where the problem might be please? If I could toggle a pin on the PC when it picks up a change in char2 that might help I guess, but the days of parallel ports are long gone! ;)

Many thanks.

  • Hi,

    Nice, thank you for the sniffer log. I think it points us neatly towards what is the issue.

    1. The L2CAP fragmentation that you see is not a limitation of the sniffer. What we see is how the packets are actually being sent.

    2. Yes, the existence of longer packets shows that the sniffer is capable of receiving longer packets.

    3. Good questions. Is there any change of MTU size, or PDU, or other activity in-between there that can explain a change?

    4. There should be communication both ways, in order to ACK from the Slave, as you mention.

    Indeed, I think looking into the fragmentation will lead us towards a solution here...

    We have seen similar behavior before, in that some packets are split in two that one would expect not to have been fragmented at all. The reason has to do with L2CAP and Link Layer frames being stored in ring buffers sometimes wrap around and thus lie partly at the end and partly at the beginning of the ring buffer. Because of contiguous memory requirements this splits them into two, for all intents and purposes.

    While the previously seen issue may explain part of the fragmentation (the "final" division into two fragments), it does not explain why the MTU gets split into more than two fragments. For looking into that, we need more of the sniffer log, to see what MTU, PDU, etc. are negotiated.

    For the case related to the previously seen issue the data transfer went from Slave to Master and there were two-way communication in the Sniffer logs. If I am not mistaken, there should be two-way communication in your case as well, at least at some point, for the Slave to ACK. Is there any other BLE activity from Slave to Master in-between the filtered sniffer output?

    Full sniffer log would be really helpful. If you do not want to share it openly here in a public forum thread, let me know and I can change this into a private ticket.

    Regards,
    Terje

  • Hi again,

    It's taken a fair bit of time this morning to get this going. The sniffer and/or Wireshark is very flaky. I have to log out and back in again if I want to start a new sniff and the nrf dev board needs to be powered off and on.

    Anyway, here is a full log, but it's even weirder than before. The first transfer starts at packet 10, this is 27 bytes long. We then get a reply from the nrf which is bizarre. Wireshark thinks it's empty, but it's not, it has two bytes in its payload which is correct.

    We then get a whole massive series of 27 byte transfers. The file being transferred starts on packet 12 with FC 9F and ends with rhe 1E 01. The next bytes in the file being sent are 08 1A D5 etc exactly as is found in packet 14.

    The last part of the file is in packet 26592 ending in 10 C6 BA.

    Everything is clearly getting sent correctly as the new file is accepted, reprogrammed in the target and rebooted.

    I'm going to put the debugger on the nrf and double check what size packets it is reading. It certainly *used* to be 240 bytes, so I con't see why it should have changed.

    As far as I underatand, the master (Qt program) listens to the slave (nrf) and decides size of transfer on the size of the characteristic, so the Qt program shouldn't, AFAIK, decide to on;y sent 27 byte chunks.

    Will be back with a little more info on what the nrf receives shortly!

    small packet sizes.pcapng

  • I can confirm that when I get a read of the 240 byte characteristic, my printf in SES tells me that I receive 240 characters each and every time.

  • One further thing to report. If I use a different laptop which has a BT4.2 module it works really well, really fast data transfer as I'd expect. Do you know of any reason why there should be an issue with 4.2 and not 5.0?

  • And one final thing, FWIW. This is the pcap for the fast transfer.

    fast transfer.pcapng

1 2 3 4