Connection fail in a noisy environment

[Cake Huang]

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 our testing,there is a much higher possibility that the phone could not connect to the target watch.

My question is that is this a drawback of BLE?

From my understanding regarding the connection set up process in the BT spec, the scanner which is the phone, would send the connection indication packet immediately after it sees the advertisement packet coming from the exact advertiser that the phone wants to connect. Once this is done, the phone would try to send first data packet within some time(like transmit window size plus window offset) to set the archor point. If the wear device responds with data PDU then the connection is set up correctly.

From above process, what I saw is that there is only one  connection indication packet sent once. No resend or retry....What if this  connection indication packet was broken due to the noisy environment? 

Hope to get more clarification on this.

Thanks.

[AmbystomaLabs]

I disagree with run_ar that this is an inherent weakness of BLE.

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.  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.

Plus BLE TX frames are really, really small.  So, unless you are trying to fully occupy channels there should be plenty of bandwidth to go around.

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.

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.

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.  If you don'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.

Also you should in a similar manner measure local noise under 500MHz. You will need a special antenna and preamp to do this. 

Local noise can cause a receiver to fail and per other Nordic guidance their receiver uses an intermediate frequency of around 350MHz.

[run_ar]

AmbystomaLabs said:

I disagree with run_ar that this is an inherent weakness of BLE.

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  packets) without getting a reply from the peripheral, while the peripheral continues to advertise as if nothing have happened.