<?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>Mesh segmented message long roundtrip time</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/114412/mesh-segmented-message-long-roundtrip-time</link><description>Hi Nordic Team 
 I encounterd the following behaviour: 
 Segmented message took 8s for acknoledge state. 
 I did the following: 
 Setup: 2 Devices NRF52840DK, provisioned and configured one groupadress to write/listen on. 
 TTL = 4, acknoledged message</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 06 Sep 2024 14:10:50 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/114412/mesh-segmented-message-long-roundtrip-time" /><item><title>RE: Mesh segmented message long roundtrip time</title><link>https://devzone.nordicsemi.com/thread/501570?ContentTypeID=1</link><pubDate>Fri, 06 Sep 2024 14:10:50 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:54eaa1a2-d764-4aab-9339-528a4d74387c</guid><dc:creator>Simsim</dc:creator><description>&lt;p&gt;Hey Terje&lt;/p&gt;
&lt;p&gt;Thanks for pointing in the right direction. I had Gatt Advertising on 200ms what leads to the long roundtrip time, while going back to 2000ms the roundtrip time was going to 3.4s what is near to the point i was expecting.&lt;/p&gt;
&lt;p&gt;Thanks for the profound answer&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Regards&lt;/p&gt;
&lt;p&gt;Sim&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Mesh segmented message long roundtrip time</title><link>https://devzone.nordicsemi.com/thread/501038?ContentTypeID=1</link><pubDate>Tue, 03 Sep 2024 18:29:28 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1cbd59a6-817c-4a96-8728-1987dcf11114</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;Round trip time should be much less than 8 seconds, and the 2 seconds that you experience with the app sounds much more reasonable.&lt;/p&gt;
&lt;p&gt;There is a limitation (imposed by the Bluetooth Mesh stack) where a mesh device should not originate more than 100 packets within a sliding window of 10 seconds. This will in some instances reduce throughput and lead to long delays (typically delays a little shy of 10 seconds.&lt;/p&gt;
&lt;p&gt;Since the device is advertising, I would expect the radio to use the SoftDevice for BLE from time to time, which with the nRF5 SDK for Mesh solution means the device will have gaps in Bluetooth Mesh performance. (I assume this advertising is normal BLE which is happening concurrently with running the Bluetooth Mesh stack, can you confirm this?) In particular, when there is a collision between the normal BLE advertiser advertising, and the Bluetooth Mesh stack scanning, this may lead to the Bluetooth Mesh stack not receiving packets. Especially if retransmit intervals are a multiple of the BLE advertising interval, you may risk multiple collisions in a row, lwading to very long response times.&lt;/p&gt;
&lt;p&gt;In order to figure out what might be happening in this particular case, I am afraid I would need some more information. If you have any sniffer traces, or steps to reproduce the behavior, then I may be able to look into that. Also, confirmation (or correction) regarding what BLE advertising is ongoing (with full information about intervals etc.) and whether the BLE stack is also concurrently scanning, would be of great value, for assessing what might be the issue at hand.&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Terje&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>