<?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>OTA DFU packet characteristic - writeWithoutResponse</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/34594/ota-dfu-packet-characteristic---writewithoutresponse</link><description>Hi, 
 I&amp;#39;m writing a client which does the OTA DFU for the nRF52832 and I&amp;#39;m a bit confused why the packet characteristic has the writeWithoutResponse property ( https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk52.v0.9.2%2Fbledfu_transport_bleservice</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 23 May 2018 10:46:56 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/34594/ota-dfu-packet-characteristic---writewithoutresponse" /><item><title>RE: OTA DFU packet characteristic - writeWithoutResponse</title><link>https://devzone.nordicsemi.com/thread/132954?ContentTypeID=1</link><pubDate>Wed, 23 May 2018 10:46:56 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b52fd8c0-42c2-486c-8a34-d34ba8bb3649</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;This is not an issue we have seen before. Packets are in any case acknowledged on the link layer (and retransmitted if necessary), and the BLE device is not allowed to send packets out of order. Doing so is a violation of the BLE specification, so I would say that if this really happens, then it indicates a bug with the library you are using on the peer side.&lt;/p&gt;
&lt;p&gt;I discussed this with one of the developers of the DFU bootloader, and there are a few points worth noting:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;We do not recommend making changes in the DFU protocol (to not have the `write_wo_resp` property) as it will break compatibility with the protocol we have defined. However, you can do it if you want, provided you also change the UUID.&lt;/li&gt;
&lt;li&gt;The DFU implementation in the SDK has been rigorously tested and verified to behave as expected. No modification should be required.&lt;/li&gt;
&lt;li&gt;Another option could be to use the Packet Receipt Notification (PRN) mechanism of the DFU protocol as flow control. This is intended to be used on platforms that are too fast for the DFU target to keep up. You could for example try to set this to 12. In that case, you will send 12 packets, then wait for a notification before you can send another 12, and so on.&lt;/li&gt;
&lt;/ul&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>