<?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>sniffer detects LL infinite loop</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/17797/sniffer-detects-ll-infinite-loop</link><description>tr4x_87dB_0xc7_1024_7．5ms_おかしい.psd We are using a transmission scheme where we tag each of our packets with a block number and fire them off using write without acknowledgement. The receiving side looks for &amp;quot;holes&amp;quot; (missing block numbers) and requests</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 18 Nov 2016 08:47:08 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/17797/sniffer-detects-ll-infinite-loop" /><item><title>RE: sniffer detects LL infinite loop</title><link>https://devzone.nordicsemi.com/thread/68599?ContentTypeID=1</link><pubDate>Fri, 18 Nov 2016 08:47:08 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:f15ea613-d086-4dad-8e05-601cc050cb33</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Karel,&lt;/p&gt;
&lt;p&gt;It&amp;#39;s on the link layer not the ATT layer, so it&amp;#39;s doesn&amp;#39;t matter if it&amp;#39;s notification or write command, if the packet is not ACKed on link layer, it will be re-transmit until it&amp;#39;s ACKed or until the connection timeout.&lt;/p&gt;
&lt;p&gt;From your trace, it seems that the Slave tried to NACK the packet because it&amp;#39;s not possible to take more data (buffer full). It&amp;#39;s maybe that the application didn&amp;#39;t read the events out of the softdevice as it should and the event buffer is full. Or if you do authorization but failed to approve the write you will also get bufferfull.&lt;/p&gt;
&lt;p&gt;Which firmware do you use on the Slave side ?&lt;/p&gt;
&lt;p&gt;If you test using our SDK&amp;#39;s examples, would you have the same issue ?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: sniffer detects LL infinite loop</title><link>https://devzone.nordicsemi.com/thread/68598?ContentTypeID=1</link><pubDate>Fri, 18 Nov 2016 00:19:47 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:28a61513-1035-4e3d-8e72-8bd48ab39d6f</guid><dc:creator>Karel_TandD</dc:creator><description>&lt;p&gt;Hi Hung,&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;I was not fully aware that the protocol did not have a max retry count at the lower layers, is this true also for notifications as well as write-without-ack?&lt;/li&gt;
&lt;li&gt;Added the trace file (TI sniffer) to the top of the question.&lt;/li&gt;
&lt;li&gt;Don&amp;#39;t know the exact chip used, but another one from the same batch has markings&lt;br /&gt;
N51822 / QFACA1  /  1620AM
The chip on the Nordic Dongle (MasterEmulator side) has markings
N51442  /  QFACA1  /  1503AD&lt;/li&gt;
&lt;/ol&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: sniffer detects LL infinite loop</title><link>https://devzone.nordicsemi.com/thread/68597?ContentTypeID=1</link><pubDate>Thu, 17 Nov 2016 10:15:36 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:e04001bf-329b-4ea2-a18f-3c474dfc2fbb</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Karen,&lt;/p&gt;
&lt;p&gt;Could you send a full trace ?
If possible, please use Nordic Sniffer, we prefer to analyze data capture from that.&lt;/p&gt;
&lt;p&gt;From the trace what I can see is that the packet from Slave is often missing and it sent strange NESN. Please make sure  you put the sniffer close to the master and slave.&lt;/p&gt;
&lt;p&gt;I&amp;#39;m not sure what &lt;em&gt;&amp;quot;The receiving side looks for &amp;quot;holes&amp;quot; (missing block numbers) and requests the re-transmission of those missing blocks.&amp;quot;&lt;/em&gt; for. BLE is a reliable protocol,there will be no packet missing, packet is always retransmited until it&amp;#39;s ACKed.&lt;/p&gt;
&lt;p&gt;It&amp;#39;s by default that if a packet is not ACKed after a &amp;quot;connection supervision timeout&amp;quot; the connection will be terminated.&lt;/p&gt;
&lt;p&gt;How often do you see the issue ?  Which nRF51 chip are you testing with (please read the laser marking and compare to the revision overview &lt;a href="http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf51/dita/nrf51/pdflinks/nrf51_comp_matrix.html?cp=3_0"&gt;here&lt;/a&gt; )&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>