<?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>Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/65364/coded-phy-and-cte-are-mutually-exclusive</link><description>According to BLE 5.1 Core Specification Coded PHY and CTE are mutually exclusive. But losing 4xRange to implement Direction Finding is a big loss if, for instance, you need working in a very noisy environment or it happens that you want to implement direction</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Sun, 06 Sep 2020 16:36:05 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/65364/coded-phy-and-cte-are-mutually-exclusive" /><item><title>RE: Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/thread/268157?ContentTypeID=1</link><pubDate>Sun, 06 Sep 2020 16:36:05 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ac1129a7-7546-4d35-aded-3e6a4a093884</guid><dc:creator>p143</dc:creator><description>&lt;p&gt;Thanks Susheel&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/thread/267961?ContentTypeID=1</link><pubDate>Fri, 04 Sep 2020 07:27:58 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:918f39eb-61f9-4f96-8596-a23199592964</guid><dc:creator>Susheel Nuguru</dc:creator><description>&lt;p&gt;Awesome discussion, very very informative.&lt;/p&gt;
&lt;p&gt;Regarding the future compatibility of CTE and Coded PHY, Nordic cannot comment on it, but I think the usecase in general has been a discussion point. So let&amp;#39;s hope for a positive update in the future.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/thread/267903?ContentTypeID=1</link><pubDate>Thu, 03 Sep 2020 15:55:08 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:46429843-6ed6-43ef-b36d-3b55ebdb92fb</guid><dc:creator>Dmitry</dc:creator><description>&lt;p&gt;Unfortunately I&amp;#39;m not a member of Bluetooth SIG group &lt;span class="emoticon" data-url="https://devzone.nordicsemi.com/cfs-file/__key/system/emoji/1f642.svg" title="Slight smile"&gt;&amp;#x1f642;&lt;/span&gt;&amp;nbsp; Maybe there are some technical difficulties, maybe just an architecture decision. At least, 5.2 specification has the same limitations.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/thread/267865?ContentTypeID=1</link><pubDate>Thu, 03 Sep 2020 13:27:40 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:50e2d9bd-3dc6-47d2-af89-2ebf3ad117b4</guid><dc:creator>p143</dc:creator><description>&lt;p&gt;I understand now because if you read BLE literature, it clearly seems that Coded LE can not be used with direction-finding: See for instance what Digikey says:&lt;/p&gt;
&lt;p&gt;Asset Tracking Using Bluetooth 5.1: Part 2 | DigiKey&lt;/p&gt;
&lt;p&gt;&amp;quot;When selecting a transceiver, it is important to note that the CTE can&amp;rsquo;t be sent over a&lt;br /&gt;Bluetooth LE Coded PHY (the radio used to implement Bluetooth 5 technology&amp;rsquo;s long-range feature); rather the PHY must be of the uncoded type.&amp;quot;&lt;/p&gt;
&lt;p&gt;or&amp;nbsp;&lt;span&gt;Rohde &amp;amp; Schwarz inthis White Paper dated 05-2019:&amp;nbsp;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;(&lt;img alt=" " src="https://devzone.nordicsemi.com/resized-image/__size/1040x795/__key/communityserver-discussions-components-files/4/Coded-LE-and-CTE-uncompatibility_5F00_Rohde-_2600_-Schwarz.jpg" /&gt;&lt;br /&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;a href="https://www.rohde-schwarz.com/fi/applications/from-cable-replacement-to-the-iot-bluetooth-5.1-white-paper_230854-15851.html"&gt;www.rohde-schwarz.com/.../from-cable-replacement-to-the-iot-bluetooth-5.1-white-paper_230854-15851.html&lt;/a&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;In page 24, Paragraph 4.6.1, Table 4-1&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;That is why in my first query&amp;nbsp; I was asking if there is a physical or intrinsic reason behind this incompatibility or it was a way to circumvent it somehow.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Reading all your comments it seems that the way BLE Core Specification is defined, this incompatibility can not be avoided at de present in a BLE-compatible project. But it could maybe in the future, since I don&amp;#39;t see any &amp;quot;intrinsic&amp;quot; reason to prevent it, providing it would be enough user cases to justify&amp;nbsp;a change on the Specification.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;What do you think?&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;Thanks&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/thread/267826?ContentTypeID=1</link><pubDate>Thu, 03 Sep 2020 12:02:04 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1d4cabe7-e464-4591-b098-31c74bd51e97</guid><dc:creator>Dmitry</dc:creator><description>&lt;p&gt;I&amp;#39;ve used 1M PHY with software FEC and some tricks for reliable detection of sync word, but that was not BLE-compatible project.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/thread/267816?ContentTypeID=1</link><pubDate>Thu, 03 Sep 2020 11:45:24 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b7e662dd-6ec2-41a8-b546-02bde46e33b7</guid><dc:creator>p143</dc:creator><description>&lt;p&gt;Hi Dmitri.&lt;/p&gt;
&lt;p&gt;Thanks again for your comments.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Let me ask you. About these experiments you mention, which modulation were you using? Coded or uncoded?&lt;/p&gt;
&lt;p&gt;Regards&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/thread/267705?ContentTypeID=1</link><pubDate>Wed, 02 Sep 2020 21:23:33 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b564110e-24cb-4275-ac64-89de9474bf13</guid><dc:creator>Dmitry</dc:creator><description>&lt;p&gt;Hmm, there&amp;#39;s no simple answer... the range can be measured for data packets with some modulation, bitrate, coding scheme in some distinct environment - as the maximum distance where bit error rate is not higher than a defined threshold (0.1% for BLE). As CTE is just a sine wave, error rate is inapplicable to it, you can only measure signal-to-noise ratio at some distance. Of course, SNR will affect accuracy of measurement, and it&amp;#39;s hard to say whether an accuracy at the edge of 1M range will be sufficient - it depends on many factors, including array design, implemented algorithm, length of CTE, number of samples averaged, eventually an allowable error for your project...&lt;/p&gt;
&lt;p&gt;From my experiments, with a simple two-antenna array and straightforward algorithm like the one described in BLE spec, 5-degree accuracy is achievable at much shorter distances than 1M range limit, but efficient algorithm like MUSIC with well-designed array could improve distance significally.&lt;/p&gt;
&lt;p&gt;Looking from other side - to start reception, the radio has to catch the sync word, and coded scheme allows to do this more reliably at higher distances. For custom protocol using AoA, this challenge can be solved in different ways, but staying within BLE5.1 spec, to tune into CTE sequence, you have to receive SyncInfo message - the one should be sent at the same phy as subsequent CTE frames. That&amp;#39;s why the range of direction finding will be smaller than long-range advertising.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/thread/267704?ContentTypeID=1</link><pubDate>Wed, 02 Sep 2020 19:48:32 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6009a855-824c-4daf-8af2-2abc971cb155</guid><dc:creator>p143</dc:creator><description>&lt;p&gt;Hi Dmitri.&lt;/p&gt;
&lt;p&gt;Thanks for clarifying. The purpose of my project is being able to find transmitting asset using a portable receiver&amp;nbsp;including 5.1 AoA direction-finding and Coded modulation to have a range as big as possible.&lt;/p&gt;
&lt;p&gt;For this reason, I initially thought that not only the advertising packets but also the CTE tone had both to be coded to&amp;nbsp;take advantage of the 4xRange feature in both signals and not only in the advertising one.&lt;/p&gt;
&lt;p&gt;I had to read your comments to remember that in fact, the 4xRange feature is only a Forward Error Correction protocol (a mathematical trick) based in redundant bits in the payload, but not in any additional power on the transmitted signal compared to the non-coded modulation&amp;nbsp;variants.&lt;/p&gt;
&lt;p&gt;So being CTE a raw radio signal from which some information must still be sampled&amp;nbsp;(IQ amplitude and phase pairs) and a signal which&amp;nbsp; is added to the data&amp;nbsp;standard packets (in connected applications) and to advertising packets in connectionless applications,&lt;/p&gt;
&lt;p&gt;my question now is:&lt;/p&gt;
&lt;p&gt;Assuming we are&amp;nbsp;implementing AoA BT5.1,&amp;nbsp; Coded Modulation, and only advertising data, will in any case, the range of the CTE signal (I mean the direction-finding feature) be smaller than the one of the coded advertising feature (that is 4xRange)?&lt;/p&gt;
&lt;p&gt;Thanks for your comments.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/thread/267349?ContentTypeID=1</link><pubDate>Tue, 01 Sep 2020 07:20:44 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:2ca19742-ec50-4923-a87c-a06178e38a71</guid><dc:creator>Dmitry</dc:creator><description>&lt;p&gt;I don&amp;rsquo;t think using Coded PHY for AoA would make any sense. Let&amp;rsquo;s say, we have a central module with antenna array and some mobile devices, working in a very noisy environment. Coded PHY allows you to receive payload more reliably, but it wouldn&amp;rsquo;t improve reliability or accuracy of AoA measurement because direction finding operates with raw radio signal &amp;ndash; it would just add significant overhead to payload transmission time (the one actually we don&amp;#39;t need at all in CTE packet). If there are many devices working as AoA targets, an accuracy with Coded PHY will be even worse because of higher probability of interference from other devices.&lt;/p&gt;
&lt;p&gt;The only thing I consider wrong is the requirement to have AUX_ADV_IND and AUX_SYNC_IND to be at the same PHY. If AUX_ADV_IND could be sent at 128K, we could reliably receive SyncInfo message, then, knowing time parameters and hopping sequence, listen for short (two-byte) access address at 1M &amp;ndash; just to launch DFE (if SNR is so low that receiver can&amp;rsquo;t sync even on two-byte AA, I don&amp;rsquo;t think we will take any meaningful angle measurements).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/thread/267290?ContentTypeID=1</link><pubDate>Mon, 31 Aug 2020 15:31:58 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a0da036c-9499-414b-80be-a1e95abc66f0</guid><dc:creator>p143</dc:creator><description>&lt;p&gt;Thanks Dmitry. But if your Project must have a footprint and consumption very limited as is in my case,&amp;nbsp; using a PA is out of consideration. What I specifically would need is transmitting CTE and advertising data from the mobile asset and both Coded PHY, that is, using AoA and in connectionless mode. Would this be possible&amp;nbsp;with the actual BT5.1 Core Specification? Thanks&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Coded PHY and CTE are mutually exclusive</title><link>https://devzone.nordicsemi.com/thread/267081?ContentTypeID=1</link><pubDate>Sun, 30 Aug 2020 07:15:11 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:77ac0911-8df3-4246-880e-3c633285ca79</guid><dc:creator>Dmitry</dc:creator><description>&lt;p&gt;This requirement doesn&amp;#39;t mean that you cannot use&amp;nbsp;both&amp;nbsp;features together. BLE specification allows to send extended advertisements and establish a connection at CODED PHY, but send AUX_ADV_IND (or&amp;nbsp;LL_PERIODIC_SYNC_IND in connected state) pointing to periodic sync sequence containing CTE&amp;nbsp;info at 1M PHY.&amp;nbsp; Also, in AoD case you can build an asymmetric (1M/CODED) channel - good antenna array with PA will give even better distance than&amp;nbsp;long-range channel from mobile device. There&amp;#39;s only one problem - almost no support for these features from manufacturers...&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>