<?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>NRF54L15 DK channel sounding (RTT ONLY) improvements confusion?</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/120604/nrf54l15-dk-channel-sounding-rtt-only-improvements-confusion</link><description>SETUP: 
 2 x NRF54L15 DK initiator/reflector sample (as of 4/8/2025) Major RTT settings below - RTT (BT_CONN_LE_CS_MAIN_MODE_1) with 1M phy, 32 bit random RTT (will add settings and prj.conf below) 
 QUESTIONS: 
 1. 1phy data is OK but a lot of negative</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 11 Apr 2025 16:22:59 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/120604/nrf54l15-dk-channel-sounding-rtt-only-improvements-confusion" /><item><title>RE: NRF54L15 DK channel sounding (RTT ONLY) improvements confusion?</title><link>https://devzone.nordicsemi.com/thread/531565?ContentTypeID=1</link><pubDate>Fri, 11 Apr 2025 16:22:59 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:36154e8a-2b5a-4cca-9e78-43d7831af8e1</guid><dc:creator>JoeD7</dc:creator><description>&lt;p&gt;ok thanks! &lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: NRF54L15 DK channel sounding (RTT ONLY) improvements confusion?</title><link>https://devzone.nordicsemi.com/thread/531430?ContentTypeID=1</link><pubDate>Thu, 10 Apr 2025 18:19:48 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:88cf66f7-5e85-4475-a9cf-64ee2b1baee8</guid><dc:creator>Amanda Hsieh</dc:creator><description>&lt;p&gt;(updated)&lt;/p&gt;
&lt;p&gt;Hi,&amp;nbsp;&lt;/p&gt;
[quote user=""]&lt;p&gt;1. 1phy data is OK but a lot of negative TOF values which is confusing me. Is there an issue with the hex conversion of this data or something im missing as to why? (obfuscated in bt_ras_rreq_rd_subevent_data_parse &amp;quot;helper for parsing ranging data-formatted buffer&amp;quot;). I&amp;#39;m reminded of the 4-3 byte conversion from the early AOA days...&lt;/p&gt;
&lt;p&gt;2. the 2M phy data is consistent, but always shifted about -7m.Is this just the the current state of the parse helper not accounting for the 2m phy mode? ( changed the .cs_sync_phy &amp;amp; .phy to 2M and enabled 2M in the prj.conf of the initiator, then enabled 2M in prj.conf on refl)&lt;/p&gt;[/quote]
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Firstly, when using RTT-measurements, we highly recommend using 2M phy for syncing, which can be done by setting &lt;span&gt;bt_le_cs_create_config_params.cs_sync_phy = BT_CONN_LE_CS_SYNC_2M_PHY. We see better performance with this internally, which is probably also the reason they say that 2M phy is consistent.&lt;/span&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;When it comes to the -7m shift, it is a little trickier. We&amp;#39;ve experienced the differences between DKs in terms of internal delays, meaning that the time from the packet enters the antenna until it enters the radio varies. The time for each DK is consistent, but it varies between different DKs. Since RTT is very sensitive, small differences create big differences in the final result. The fact that the delays in the DKs vary sort of adds the need to do a &amp;quot;calibration-routine&amp;quot;, where you put the DKs next to each other and measure the default offset. We currently do not have any other good solutions to this..&amp;nbsp;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Also, a negative ToF value is not wrong in the sense that some conversion has gone wrong or something. It&amp;#39;s just because our measurements are not accurate enough.&lt;/span&gt;&lt;/p&gt;
&lt;ul&gt;&lt;/ul&gt;
[quote user=""]3. Any suggestions on more levers to pull to improve this setup? Not using channel switching or a subevent confused me in the setup quite a bit.[/quote]
&lt;p&gt;&lt;span&gt; I don&amp;#39;t understand the question. The devices will use channel switching and subevents when running the Channel Sounding procedures, but the order of the channels and when the subevents are run is not exposed to the user. The channels are shuffled with a common seed, and the subevents are scheduled according to other activities in the radio.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Amanda H.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: NRF54L15 DK channel sounding (RTT ONLY) improvements confusion?</title><link>https://devzone.nordicsemi.com/thread/531210?ContentTypeID=1</link><pubDate>Wed, 09 Apr 2025 14:34:52 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:355c8a5c-d91d-4b5b-bf6b-e7df0f690c2e</guid><dc:creator>JoeD7</dc:creator><description>&lt;p&gt;SDK 2.9.1&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>