<?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>Peripheral connection terminated with 0x08 (Connection Timeout) after ~163 ms although the initial supervision timeout is 720 ms</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/129232/peripheral-connection-terminated-with-0x08-connection-timeout-after-163-ms-although-the-initial-supervision-timeout-is-720-ms</link><description>Environment 
 
 
 nRF Connect SDK v3.3.1 
 
 
 SoC: nRF54LM20A 
 
 
 BLE peripheral using connectable legacy advertising 
 
 
 Central: smartphone 
 
 
 Problem 
 We occasionally see very short-lived BLE connections that are disconnected with reason 0x08</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 22 Sep 2026 10:13:23 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/129232/peripheral-connection-terminated-with-0x08-connection-timeout-after-163-ms-although-the-initial-supervision-timeout-is-720-ms" /><item><title>RE: Peripheral connection terminated with 0x08 (Connection Timeout) after ~163 ms although the initial supervision timeout is 720 ms</title><link>https://devzone.nordicsemi.com/thread/571422?ContentTypeID=1</link><pubDate>Tue, 22 Sep 2026 10:13:23 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:13bb2c43-d0fd-48e2-825a-0be13749009d</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;I see. Yes, please capture an over-the-air sniffer trace for us to see what is going on. From what I understand the peripheral could also time out after six events, if nothing is heard after the CONNECT_IND. Otherwise, the timeout should be after the full supervision timeout. What exact smartphone and OS (including versions for both) is the central device?&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><item><title>RE: Peripheral connection terminated with 0x08 (Connection Timeout) after ~163 ms although the initial supervision timeout is 720 ms</title><link>https://devzone.nordicsemi.com/thread/571407?ContentTypeID=1</link><pubDate>Tue, 22 Sep 2026 01:53:48 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:bf6435bc-19fe-4cb4-9ae1-89190e945835</guid><dc:creator>strongman</dc:creator><description>&lt;p&gt;Hi Terje,&lt;/p&gt;
&lt;p&gt;Thank you for the detailed explanation.&lt;/p&gt;
&lt;p&gt;Just to clarify the roles in our setup: the &lt;strong&gt;nRF54LM20A is the Peripheral&lt;/strong&gt;, and the &lt;strong&gt;smartphone is the Central&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;The log shown in my original post is from the nRF54LM20A itself. In other words, the &lt;code&gt;connected&lt;/code&gt; and &lt;code&gt;disconnected&lt;/code&gt; callbacks are executed on the Peripheral, and the &lt;code&gt;0x08&lt;/code&gt; disconnect is reported by the nRF54LM20A.&lt;/p&gt;
&lt;p&gt;So this does not seem to match the scenario you described, where the Peripheral does not receive the &lt;code&gt;CONNECT_IND&lt;/code&gt; and therefore never considers the connection to have been established. In our case, the Peripheral does report the connection as established first, and then about 162.7 ms later its &lt;code&gt;disconnected&lt;/code&gt; callback is triggered with reason &lt;code&gt;0x08&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;The issue is also intermittent &amp;mdash; most connections work normally, but occasionally we see this short-lived connection followed by the &lt;code&gt;0x08&lt;/code&gt; disconnect.&lt;/p&gt;
&lt;p&gt;Would the six-connection-event timeout you described also be possible from the Peripheral&amp;#39;s side in this situation, or could there be another mechanism in the SoftDevice Controller that causes the Peripheral to report &lt;code&gt;0x08&lt;/code&gt; this early?&lt;/p&gt;
&lt;p&gt;I will also try to capture an over-the-air trace with the nRF Sniffer to see what happens during these short-lived connections.&lt;/p&gt;
&lt;p&gt;Best regards,&lt;br /&gt;Strong man&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Peripheral connection terminated with 0x08 (Connection Timeout) after ~163 ms although the initial supervision timeout is 720 ms</title><link>https://devzone.nordicsemi.com/thread/571401?ContentTypeID=1</link><pubDate>Mon, 21 Sep 2026 15:51:52 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:da74bd42-41b8-4aa2-a2bd-c56842f5216a</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;I assume your device is acting as initiator / central.&lt;/p&gt;
&lt;p&gt;In that case, I suspect what you are experiencing is that the central sends a CONNECT_IND packet (to indicate it wants to initiate a connection), but that the peripheral for some reason doesn&amp;#39;t get that packet. In that situation, the central is considered connected, but the peripheral is not. The peripheral will not send any packets during the connection, as from the perspective of the peripheral there never was any connection to begin with. The central will then time out, as it never receives any packets from the peripheral within the connection events of the connection.&lt;/p&gt;
&lt;p&gt;The particular timeout is a special case of supervision timeout. At the beginning of a connection, the central is mandated to time out already after six connection events, if at that point it has not received any packets at all from the peripheral. This is a special case for ensuring rapid timeout in the exact situation of a would-be peripheral not receiving the CONNECT_IND packet. For reference, please see the Bluetooth Core Specification v6.3, Vol 6, Part B, section 4.5.2 Supervision timeout.&lt;/p&gt;
&lt;p&gt;In your case, with connection interval of 30 ms, the timeout should be expected after slightly more than 5 * 30 = 150 ms, and is consistent with the timing you see of 162.7 ms. (Five times the connetion interval, as the six connection event instances have a total of five gaps between them.)&lt;/p&gt;
&lt;p&gt;A sniffer trace, for instance using the &lt;a href="https://www.nordicsemi.com/Products/Development-tools/nRF-Sniffer-for-Bluetooth-LE"&gt;nRF Sniffer&lt;/a&gt;, will reveal what is actually going on over-the-air, and potentially further confirm that the above is what is happening. That is, the central aborting the connection after having sent packets at six consecutive connection events from the beginning of the connection, and the peripheral not sending any packets as part of the connection (but rather proceeding with its advertising as if nothing had happened.)&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>