<?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>How does the BLE link layer keep the connection by using 32.768K in power saving mode ?</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/12704/how-does-the-ble-link-layer-keep-the-connection-by-using-32-768k-in-power-saving-mode</link><description>Hi, 
 I am curious about how the connection is keep while using the 32.768K in BLE link layer in power saving mode.
I know that the connection interval is based on multiple of 1.25ms. But the 1.25ms is not an integer multiple of 32.768K.
How did it</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 29 Mar 2016 14:12:01 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/12704/how-does-the-ble-link-layer-keep-the-connection-by-using-32-768k-in-power-saving-mode" /><item><title>RE: How does the BLE link layer keep the connection by using 32.768K in power saving mode ?</title><link>https://devzone.nordicsemi.com/thread/48250?ContentTypeID=1</link><pubDate>Tue, 29 Mar 2016 14:12:01 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:77856139-7282-4d8a-ad55-3e9fbfd95395</guid><dc:creator>Stefan Birnir Sverrisson</dc:creator><description>&lt;p&gt;Hi&lt;/p&gt;
&lt;p&gt;The 32 kHz clock does have limited accuracy. For BLE connection, both connected devices need to know when to transmit or receive packets. The central sends a packet in a connection event and the peripheral needs to enabled the receiver at the same time in order to receive the packet sent by the central. The perhiperhal does however need to enable the receiver a little sooner than expected to compensate for inaccuracy of the 32kHz clock of both the central and peripheral, and perhaps to compensate as well for the 1/32.768=30 microsecond worst case delay from timer tick until expected connection event instant.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>