<?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>Nordic Uart Service TX delay while Service Discovery</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/63017/nordic-uart-service-tx-delay-while-service-discovery</link><description>Hi, 
 currently we are developing a firmware for 52840 based on the nRF5 v.16 SDK with Softdevice 7.0.1 on a custom board. We are able to connect and bond up to 5 devices ( with nrf Connect App for Android ) via BLE and send/receive Data. 
 When we connect</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 01 Jul 2020 07:38:02 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/63017/nordic-uart-service-tx-delay-while-service-discovery" /><item><title>RE: Nordic Uart Service TX delay while Service Discovery</title><link>https://devzone.nordicsemi.com/thread/257721?ContentTypeID=1</link><pubDate>Wed, 01 Jul 2020 07:38:02 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1a3c6ab0-3213-4343-89fc-33d7cd7a1698</guid><dc:creator>MichaelMe</dc:creator><description>&lt;p&gt;We can&amp;#39;t be sure the connection is always terminated by the phone ( e.g. when it is out of range or something).&lt;/p&gt;
&lt;p&gt;So i think we have to send one message repeatedly until we get an answer, or wait a few seconds.&lt;/p&gt;
&lt;p&gt;Thank you anyway for the support.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Nordic Uart Service TX delay while Service Discovery</title><link>https://devzone.nordicsemi.com/thread/257087?ContentTypeID=1</link><pubDate>Fri, 26 Jun 2020 10:08:09 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:af285b6a-f013-42e5-8f1f-52212b414fc2</guid><dc:creator>Susheel Nuguru</dc:creator><description>&lt;p&gt;I guess until we have the&lt;a href="https://www.bluetooth.com/wp-content/uploads/2019/03/1901_Feature_Overview_Brief_FINAL.pdf"&gt; GATT Caching&amp;nbsp;&lt;/a&gt;this is a known problem.&lt;/p&gt;
&lt;p&gt;If your device is the one that initiates the disconnect, then you can disable the TX notification flag just before disconnecting (haven&amp;#39;t tried it myself). That way the peer when they do the service discovery, have to re-enable the TX notification flag.which could be a signal to your application?&lt;/p&gt;
&lt;p&gt;In BLE5.1, when we support Gatt Caching, this problem will be solved, but until then we need to find some workaround like the one I mentioned above.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>