<?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>Connection fail in a noisy environment</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/34766/connection-fail-in-a-noisy-environment</link><description>Hi Team, 
 I am using nRF52832 to implement smart watch product and it is now close to PP stage. 
 Currently our product testing engineer found that in a relative noisy environment, say there are several tens of wear product which is typical place for</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 28 May 2018 13:29:14 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/34766/connection-fail-in-a-noisy-environment" /><item><title>RE: Connection fail in a noisy environment</title><link>https://devzone.nordicsemi.com/thread/133670?ContentTypeID=1</link><pubDate>Mon, 28 May 2018 13:29:14 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:4d5e8232-650e-47d7-8a97-9308b350e9db</guid><dc:creator>run_ar</dc:creator><description>[quote user="AmbystomaLabs"]I disagree with run_ar that this is an inherent weakness of BLE.[/quote]
&lt;p&gt;Please note that I was referring to the connection indication packet in this case. This is easily blocked by active scanners if they do not back of. BLE in general is quite robust, and I guess it is a bit unfair to call this a weakness as you can simply send another connection request if the first one fails. The good thing is that you can quite easily check if the connection request is lost using a sniffer: You will see the central sending packets (6&amp;nbsp; packets) without getting a reply from the peripheral, while the peripheral continues to advertise as if nothing have happened.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Connection fail in a noisy environment</title><link>https://devzone.nordicsemi.com/thread/133447?ContentTypeID=1</link><pubDate>Fri, 25 May 2018 13:57:08 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:8cdab3af-45b6-4f8c-aa3d-4984e6edde0b</guid><dc:creator>AmbystomaLabs</dc:creator><description>&lt;p&gt;I disagree with run_ar that this is an inherent weakness of BLE.&lt;/p&gt;
&lt;p&gt;While BLE does occupy the same band as WiFi, microwave ovens, cordless phones, etc. it does have many features to make it relatively immune to interference.&amp;nbsp; BLE employs a random back-off time to help with collisions, a narrow bandwidth to aid in placing it between occupied channels, carrier sense to allow it to avoid occupied channels, a simple GFSK modulation which requires very little S/N to decode and multiple advertising channels to make sure it is seen and comms get started.&lt;/p&gt;
&lt;p&gt;Plus BLE TX frames are really, really small.&amp;nbsp; So, unless you are trying to fully occupy channels there should be plenty of bandwidth to go around.&lt;/p&gt;
&lt;p&gt;I would guess your issue stems from low S/N from the start possibly from board related issues. Then a small number of interferes can push it over the edge.&lt;/p&gt;
&lt;p&gt;Another option is local spurious noise from your device. Non-random local noise sources, eg, clocks, can add constructively at the receiver and cause reception failures. In addition the high refresh rates of a device display, DC/DC switchers all can influence both the transmit and receive functions.&lt;/p&gt;
&lt;p&gt;You should start by measuring radiated local 2.4GHz band noise at your device during normal operation. Easiest way is RF shielded room and spectrum analyzer with a preamp and 2.4GHz antenna.&amp;nbsp; If you don&amp;#39;t have a shielded room do it in somewhere far from WiFi noise such as outside. At the same time you can also get a clear picture of what your radiated BLE signal looks like so you can look for abnormalities.&lt;/p&gt;
&lt;p&gt;Also you should in a similar manner measure local noise under 500MHz. You will need a special antenna and preamp to do this.&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Local noise can cause a receiver to fail and per other Nordic guidance their receiver uses an intermediate frequency of around 350MHz.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Connection fail in a noisy environment</title><link>https://devzone.nordicsemi.com/thread/133435?ContentTypeID=1</link><pubDate>Fri, 25 May 2018 13:01:22 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1e220d7a-169b-4e75-b5f5-5ff9488f7471</guid><dc:creator>run_ar</dc:creator><description>[quote user=""]From above process, what I saw is that there is only one&amp;nbsp;&lt;span&gt;&amp;nbsp;connection indication packet sent once. No resend or retry....What if this&amp;nbsp;&amp;nbsp;connection indication packet was broken due to the noisy environment?&amp;nbsp;&lt;/span&gt;[/quote]
&lt;p&gt;This is a weakness with the ble protocol. If this happens the phone will try to send 6 packets after the connection request before it times out and will have to try to connect again.&lt;/p&gt;
&lt;p&gt;How many advertisers are we talking about here? do you have multiple scanners as well? Usually having multiple active scanners in an area would be much worse than having a lot of advertisers. The scanners would pick up the same advertisement packet and sends scan requests to the peripheral at the same time as the connection request is sent to establish a connection (There is some backup routine, but not sure if it&amp;#39;s good enough). Passive scanners would be fine.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>