We are using nrf52832 with S132.
In our application, we have 1 device as central and it will connect to 4 peripheral devices.
Central device needs to send 128 bytes of data to each of 4 device at interval of 30 msec.
We have extended the data length to send 128 bytes in 1 packet.
Currently we are sending these packets at interval of 100 msec and still packets are getting dropped.
Connection interval is set to 7.5msec.
So how can we increase throughput to achieve our requirements?
Hi Haresh
A reoccurring 0x3E disconnect reason (connection failed to be established), is typically due to interference (for example other 2.4GHz devices such as the other devices you have connected if the connection parameters are set too small to handle multiple connection at the same time). It could also be interference on the nRF52832 board itself like oor antenna tuning, serial interfaces active close to the antenna, etc.
My guess is that the connection parameters aren't optimal for connecting to 4 devices at the same time, so try tweaking these to see if you can remedy these disconnects. Also, what device are you using as a central in this setup?
Best regards,
Simon
Hi Simonr
We are using custom boards as central and peripheral devices.
While testing there are nearly 50 devices in the surrounding using BLE. Central and Peripheral devices are placed 50ft apart.
It could also be interference on the nRF52832 board itself like oor antenna tuning, serial interfaces active close to the antenna, etc.
Can you provide any reference to the procedure to tune the antenna?
We are using UART for debugging purposes. Should we disable this for testing?
Hi,
Please find attached sniffer file.
Central Device Mac: E4:32:EF:F1:0E:13
Peripheral Devices Mac:
E0:7E:F4:D8:0F:E6
DA:82:EA:A8:A6:2D
CA:5E:61:30:05:B7
I have set the Key to Follow LE address and key to E4:32:EF:F1:0E:13 public in wireshark
Hi Haresh,
It seems that the sniffer didn't sniff into the connection attempt. That's likely because you track the central device, and not the peripheral device.
Could you get another trace, following the peripheral device instead?
I also see that your central device is advertising as well. That will be even more things needed to be scheduled on the SoftDevice...
On other note, have you tried lowering the scan window to see if it helps the later connections at all? There are some values recommended in the Bluetooth Core Spec, Vol 3, Part C, Appendix A. (as of spec v5.3). I think 30ms is a good place to start with.
Please understand if our responses are delayed for the next ~1.5 weeks due to a holiday here.
Hieu
Hi,
I attached the trace file following the peripheral device.
Central Device Mac: E4:32:EF:F1:0E:13
Peripheral Devices Mac: E0:7E:F4:D8:0F:E6
I also see that your central device is advertising as well. That will be even more things needed to be scheduled on the SoftDevice...
Should I disable the advertising when trying for a connection in the central device?
On other note, have you tried lowering the scan window to see if it helps the later connections at all?
I will try that and update if anything improves.
Haresh
Hi Haresh,
I am back, but I am still progressing through my backlog and could not get to your question yet. Please know that I am still around and will try to look into it within the next two working days.
I am sorry for the inconvenience.
Best regards,
Hieu
Hi Haresh,
If I understand correctly, in the latest sniffer trace, you include one connection attempt which failed, and another which succeeded. Is that right?
No. Time Source Destination Length RSSI Info 2832 19.275786 e0:7e:f4:d8:0f:e6 Broadcast 56 -32 dBm ADV_IND 2833 19.276256 e4:32:ef:f1:0e:13 e0:7e:f4:d8:0f:e6 60 -57 dBm CONNECT_IND 2834 19.277873 Master_0x38b7cf1f Slave_0x38b7cf1f 26 -62 dBm Empty PDU 2835 19.292875 Master_0x38b7cf1f Slave_0x38b7cf1f 26 -59 dBm Empty PDU 2836 19.307875 Master_0x38b7cf1f Slave_0x38b7cf1f 26 -53 dBm Empty PDU 2837 19.337878 Master_0x38b7cf1f Slave_0x38b7cf1f 26 -50 dBm Empty PDU 2838 19.352881 Master_0x38b7cf1f Slave_0x38b7cf1f 26 -69 dBm Empty PDU 2839 24.355563 e0:7e:f4:d8:0f:e6 e2:35:9c:59:59:81 38 -33 dBm SCAN_REQ
In the failed connection attempt around t = 19.2s, we can see after sending CONNECT_IND, the Central (Master) attempts to send some Empty PDU. The idea is that if the connection is established successfully, the Peripheral (Slave) should response.
However, we see that the response is absence. It is likely that the Peripheral has missed the CONNECT_IND.
Note that the absence of ADV_IND after CONNECT_IND does not show that the peripheral is not advertising anymore. After detecting CONNECT_IND, the sniffer would focus on tracing the connection, so it does not go back to tracing advertising activities for a bit.
You can see that in the successful connection attempt around t = 44.15s, the above issue does not happen.
Depends on the situation, this failure to establish a connection might or might not be normal.
I would like to ask a few questions to check on that:
Best regards,
Hieu
Hi Haresh,
If I understand correctly, in the latest sniffer trace, you include one connection attempt which failed, and another which succeeded. Is that right?
No. Time Source Destination Length RSSI Info 2832 19.275786 e0:7e:f4:d8:0f:e6 Broadcast 56 -32 dBm ADV_IND 2833 19.276256 e4:32:ef:f1:0e:13 e0:7e:f4:d8:0f:e6 60 -57 dBm CONNECT_IND 2834 19.277873 Master_0x38b7cf1f Slave_0x38b7cf1f 26 -62 dBm Empty PDU 2835 19.292875 Master_0x38b7cf1f Slave_0x38b7cf1f 26 -59 dBm Empty PDU 2836 19.307875 Master_0x38b7cf1f Slave_0x38b7cf1f 26 -53 dBm Empty PDU 2837 19.337878 Master_0x38b7cf1f Slave_0x38b7cf1f 26 -50 dBm Empty PDU 2838 19.352881 Master_0x38b7cf1f Slave_0x38b7cf1f 26 -69 dBm Empty PDU 2839 24.355563 e0:7e:f4:d8:0f:e6 e2:35:9c:59:59:81 38 -33 dBm SCAN_REQ
In the failed connection attempt around t = 19.2s, we can see after sending CONNECT_IND, the Central (Master) attempts to send some Empty PDU. The idea is that if the connection is established successfully, the Peripheral (Slave) should response.
However, we see that the response is absence. It is likely that the Peripheral has missed the CONNECT_IND.
Note that the absence of ADV_IND after CONNECT_IND does not show that the peripheral is not advertising anymore. After detecting CONNECT_IND, the sniffer would focus on tracing the connection, so it does not go back to tracing advertising activities for a bit.
You can see that in the successful connection attempt around t = 44.15s, the above issue does not happen.
Depends on the situation, this failure to establish a connection might or might not be normal.
I would like to ask a few questions to check on that:
Best regards,
Hieu
-> How consistent and how often (X fails every Y establishment attempt) does this happen in your test?
I am seeing this issue almost every time when I try to establish a connection(fails 3-4 times with reason 0x3E before making the proper connection)
->Does this happen when the Peripheral is advertising and scanning at the same time?
I have not checked with scanning disabled. Advertising and scanning are both enabled in Peripheral and Central devices as well.
->You noted that the Advertising Interval is 100ms. What are the scan parameters on these devices?
The scan Interval is 100msec and the Scan window is 80msec.
I have also tried with a scanning interval set to 160msec but the result is the same.
->Is the physical environment you are testing electromagnetically noisy?
Yes. We have nearly 50 devices in a closed environment
-> Are the devices far apart? What is the RSSI that they see from the other?
When devices are set 40ft apart, I see RSSI around 75-80.
Haresh05 said:Yes. We have nearly 50 devices in a closed environment
Are all of these devices running the same firmware?
Even if not, are many of these devices are performing Active Scanning?
Something we did not account notice with the sniffer traces is that there are a lot of SCAN_REQ from Active Scanners.
SCAN_REQ will be sent, received, and acted upon right after the Peripheral send an ADV_SCAN_IND.
It's at the same time as when CONNECT_IND should be sent.
On top of that, both SCAN_REQ and CONNECT_IND will be sent on the three BLE advertising channels.
Therefore, if there are multiple Active Scanner in range, the CONNECT_IND packet will have a lot of competitions, and the Peripheral would easily miss it.
Besides, if the other devices are advertising, they will also bring potential collisions to the advertising channels.
Haresh05 said:When devices are set 40ft apart, I see RSSI around 75-80.
This is also a little hard on the connection. At this range and RSSI, you will start to see some losses. This adds to the interference issue we have above.
To help improve RSSI, usually you can try to increase the TX Power of the devices. However, doing so will worsen the interference issue, so I wouldn't recommend it this time.
Given this situation, the difficulty to establish the connection is likely normal to be expected.
In this particular environment, I recommend you:
