<?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>RFCOMM vs. NUS</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/65733/rfcomm-vs-nus</link><description>Can anyone tell or give a pointer to info about RFCOMM vs. NUS (or any other vendor specific UART emulation service)? 
 Why are there vendor specific UART emulation services? Why/when should one choose vendor specific service instead of RFCOMM?</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Wed, 09 Sep 2020 08:44:13 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/65733/rfcomm-vs-nus" /><item><title>RE: RFCOMM vs. NUS</title><link>https://devzone.nordicsemi.com/thread/268668?ContentTypeID=1</link><pubDate>Wed, 09 Sep 2020 08:44:13 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:40652930-fd8a-4919-9fa1-414a7ecd4b16</guid><dc:creator>awneil</dc:creator><description>&lt;p&gt;&lt;a href="https://devzone.nordicsemi.com/members/crfosse"&gt;Carl Richard&lt;/a&gt; gave the answers regarding RFCOMM.&lt;/p&gt;
&lt;p&gt;NUS is defined here:&amp;nbsp;&lt;a href="https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.0/ble_sdk_app_nus_eval.html"&gt;https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.0/ble_sdk_app_nus_eval.html&lt;/a&gt;&lt;/p&gt;
[quote userid="93197" url="~/community/f/wireless-forum/65733/rfcomm-vs-nus"]Why are there vendor specific UART emulation services?[/quote]
&lt;p&gt;Because the Bluetooth SIG, in their wisdom &lt;em&gt;(sic?)&lt;/em&gt;, decided &lt;strong&gt;not&lt;/strong&gt; to define a standard one!&lt;/p&gt;
&lt;p&gt;Why on earth they would make such a glaring omission is anyone&amp;#39;s guess. My guess would be that they wanted people to user properly defined Services - not just send arbitrary, unstructured data over a UART emulation?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: RFCOMM vs. NUS</title><link>https://devzone.nordicsemi.com/thread/268665?ContentTypeID=1</link><pubDate>Wed, 09 Sep 2020 08:37:51 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:4749ed21-f1ad-4932-a64e-1b34015e1bf6</guid><dc:creator>Carl Richard</dc:creator><description>&lt;p&gt;Hello, turboscrew.&lt;br /&gt;&lt;br /&gt;RFCOMM is a Bluetooth Classic protocol and&amp;nbsp;is not supported in Bluetooth Low Energy. Hence, it&amp;#39;s not possible to use RFCOMM for BLE communication.&amp;nbsp;&lt;br /&gt;&lt;br /&gt;You can read more about this&amp;nbsp;&lt;a href="https://stackoverflow.com/questions/50503701/reading-data-from-a-bluetooth-device-low-energy-rfcomm-python3"&gt;here&lt;/a&gt;&amp;nbsp;and&amp;nbsp;&lt;a href="https://devzone.nordicsemi.com/f/nordic-q-a/10567/what-is-nus-nordic-uart-service"&gt;here&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;Best regards,&lt;br /&gt;Carl Richard&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>