<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Understanding BLE connection and intervals</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/75185/understanding-ble-connection-and-intervals</link><description>I started working with BLE and I have some trouble understanding few things. The connection interval happens every X ms, that is set by master, usually the default is lowest it can handle. In one interval X packets can be sent master-slave, slave-master</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 21 May 2021 14:32:36 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/75185/understanding-ble-connection-and-intervals" /><item><title>RE: Understanding BLE connection and intervals</title><link>https://devzone.nordicsemi.com/thread/311099?ContentTypeID=1</link><pubDate>Fri, 21 May 2021 14:32:36 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:23d507f0-d7f9-4c1e-a026-fd7b09edbab1</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;The connection parameters are decided, as you write, by the central. In your case the Android phone. What connection interval you end up with, as well as the event length (how many packets back and forth every connection event), is therefore decided by the smartphone.&lt;/p&gt;
&lt;p&gt;Also, as you write, packets should get queued up (as long as there is buffer space) and sent at next available connection event.&lt;/p&gt;
&lt;p&gt;What type of packets are you sending? Are you writing, reading, notifying, or indicating? I&amp;#39;m thinking if your choice of data transfer needs an ack on some level before sending the next packet, then if the peer for some reason delays the ack until the next connection event then that might explain a lot. Other explanations might be that the peer device does fewer packets per connection event than what you would need, or that packets gets lost due to interference on the 2.4 GHz band.&lt;/p&gt;
&lt;p&gt;Note that there might also be other processes going on in parallel with the packets that you send. In particular at the beginning of the connection. E.g. database discovery, connection parameter update, change of mtu size, other characteristics sending/receiving data, etc. In order to figure out what exactly goes on over the air, the best tool is a sniffer trace. If you post the traces here we would be able to look further into what is going on.&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Terje&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>