<?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>Designed behaviour of S110 when notifications(CCCD) are disabled with packets queued?</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/6242/designed-behaviour-of-s110-when-notifications-cccd-are-disabled-with-packets-queued</link><description>What is the designed (/actual/required due to the specification) behaviour of the Bluetooth stack S110 when notification packets are queued and the CCCD controlling the attribute has its notifications disabled before they are sent? 
 e.g. 
 
 I queue</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 27 Mar 2015 14:56:58 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/6242/designed-behaviour-of-s110-when-notifications-cccd-are-disabled-with-packets-queued" /><item><title>RE: Designed behaviour of S110 when notifications(CCCD) are disabled with packets queued?</title><link>https://devzone.nordicsemi.com/thread/21853?ContentTypeID=1</link><pubDate>Fri, 27 Mar 2015 14:56:58 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:48bfb169-3815-4558-a298-d904c04eaddf</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;@Peter: As far as I know, the stack will continue to send these 3 packets that already queued in the buffer. We don&amp;#39;t have a mechanism to stop and trash them.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>