<?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>nrf5340 continuous notity problem</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/103718/nrf5340-continuous-notity-problem</link><description>Hello！ 
 We currently have a project that requires using nrf5340 Bluetooth to upload 250hz EEG data in real time, sending a set of packets every 200ms or faster, and sending 206 bytes per notify packet. Set MTU to 252. 
 My question is that sending the</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 13 Sep 2023 09:25:57 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/103718/nrf5340-continuous-notity-problem" /><item><title>RE: nrf5340 continuous notity problem</title><link>https://devzone.nordicsemi.com/thread/445791?ContentTypeID=1</link><pubDate>Wed, 13 Sep 2023 09:25:57 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:c94f3fc5-5016-4c64-b4c6-f17d45d9ec7d</guid><dc:creator>PeterWu</dc:creator><description>&lt;p&gt;Thank you for your reply. It seems that the network core configuration has not met the requirements. I have preliminarily changed the configuration and it has improved, and I am still confirming it.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: nrf5340 continuous notity problem</title><link>https://devzone.nordicsemi.com/thread/445781?ContentTypeID=1</link><pubDate>Wed, 13 Sep 2023 08:57:45 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6405867e-7875-4417-aa9a-23bd150c7f02</guid><dc:creator>Kenneth</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;I think to understand what is actually happening here you should look into getting an on-air sniffer log (e.g. using nrf sniffer for BLE). It could be that data is fragmented or that you are experiencing much packet loss, so having a sniffer log would be helpful to see what may be influencing the data transmissions.&lt;/p&gt;
&lt;p&gt;If I understand the application correctly you are combining multiple sensor readings into a large packet that can be sent less frequently (e.g. every 200ms), I think this is a very good idea and should be the most efficient way of sending the data. However even if you only send data every 200ms, you should have a connection interval that is faster that can handle packet loss and retransmissions. So for instance I would recommend for instance a connection interval of 50ms and a slave slave latency of 3. In terms of power consumption this would give the same result as having a connection interval of 200ms, because in good condition with no packet loss data will only be sent every 200ms, however if there is packet loss the link will be able to send data between the 200ms periods to catch up.&lt;/p&gt;
&lt;p&gt;Kenneth&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>