<?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>Discrepancies in the Bluetooth profile between NRF Connect SDK and Zephyr Bluetooth</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/115618/discrepancies-in-the-bluetooth-profile-between-nrf-connect-sdk-and-zephyr-bluetooth</link><description>I&amp;#39;m currently porting the code from our released product built on NRF SDK with nrf52832. For the next version we want to have the option to go to the upcoming nrf54L* processors so we are trying to port and build an equivalent product. I&amp;#39;m currently developing</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 18 Oct 2024 16:17:34 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/115618/discrepancies-in-the-bluetooth-profile-between-nrf-connect-sdk-and-zephyr-bluetooth" /><item><title>RE: Discrepancies in the Bluetooth profile between NRF Connect SDK and Zephyr Bluetooth</title><link>https://devzone.nordicsemi.com/thread/506978?ContentTypeID=1</link><pubDate>Fri, 18 Oct 2024 16:17:34 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:14d30310-6791-4fe2-9052-32e794bc9829</guid><dc:creator>Anthony Ambuehl</dc:creator><description>&lt;p&gt;Thanks that is all helpful.&amp;nbsp; I found in our implementation the mobile app required the DIS to provide SW revision, which I had not configured.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Its a shame about secure DFU, switching to a new DFU service is just more work that my clients will need to pay for to be able to continue using Nordic&amp;#39;s products.&amp;nbsp; Nordic certainly isn&amp;#39;t making the transition easy for existing users of your products. I keep finding capabilities I used in NRF SDK that I&amp;#39;m now forced to replace or rewrite.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Discrepancies in the Bluetooth profile between NRF Connect SDK and Zephyr Bluetooth</title><link>https://devzone.nordicsemi.com/thread/506906?ContentTypeID=1</link><pubDate>Fri, 18 Oct 2024 12:11:53 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:3487b986-b771-4faf-80fb-d0d346804133</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
[quote user=""]1) I notice in the &amp;quot;Generic Access&amp;quot; service, the NRF5 SDK included an characteristic called &amp;quot;Central Address Resolution&amp;quot;&amp;nbsp; &amp;nbsp;which is absent in the Zephyr Bluetooth / NRF Connect SDK.&amp;nbsp; What is the purpose of this characteristic.&amp;nbsp; Does Zephyr have a kconfig to include it?&amp;nbsp;&amp;nbsp;[/quote]
&lt;p&gt;The Central Address Resolution characteristic is optional and is used to indicate if&amp;nbsp;Central Address Resolution is supported or not. You can read more about this in the Bluetoth specification (page 1437 or version 6.0). This will be automatically included when both central feature (CONFIG_BT_CENTRAL) and privacy (CONFIG_BT_PRIVACY) is enabled.&lt;/p&gt;
[quote user=""]&lt;p&gt;2) In the &amp;quot;Generic Attribute&amp;quot; service, our NRF5 SDK was empty, but in Zephyr/NRF Connect SDK it now has &amp;quot;Service Changed&amp;quot;, &amp;quot;Client Supported Features&amp;quot; and &amp;quot;Database Hash&amp;quot;&amp;nbsp;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;What are the purposes of these characteristics?&amp;nbsp; Does Zephyr have a kconfig option to remove them?&amp;nbsp; Is there a benefit to have having them?&lt;/p&gt;[/quote]
&lt;p&gt;Service changed is used to indicate to the peer (GATT client) that teh database has changed and it should perform a new service discovery. Typically this could happen after a DFU operation, or theoretically also in other situations when the device expose a different set of services. For Client suported features and database hash I recomend you rever to the BT spec, page 1602-1606 in version 6.0.&lt;/p&gt;
[quote user=""]3) The next major difference is our NRF5 SDK device has the &amp;quot;Secure DFU&amp;quot; service.&amp;nbsp; Is it still true that Nordic has not ported this service and has no plans to provide it?&amp;nbsp;&amp;nbsp;[/quote]
&lt;p&gt;Yes. DFU is handled differently in nRF Connect SDK, via SMP and implemented by MCUboot. I recommen you refer to the &lt;a href="https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/bootloaders_dfu/index.html"&gt;SDK documtation about that&lt;/a&gt;, as well as the DFU module in the &lt;a href="https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/"&gt;nRF Connect SDK Intermediate&lt;/a&gt;&amp;nbsp;course.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>