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,
The ~50 devices on the 2.4GHz bandwidth will likely make an impact on the throughput you're able to get, but you should still be able to connect and keep a connection alive just fine.
Can you provide any pointer to check for the connection issue as in our case it is taking too long to establish the connection?
Hi Haresh05,
Simon is out of office, and I will support you in his absence.
Could you please give me the details I list above?
It could be that the radio is too busy maintaining existing connections that it cannot serve the establishment of a new connection.
Finally, I hope you can excuse some delays in our responses. My team is facing high loading due to some unavailability, and I am also partially out of office this week.
Hieu
Hi Hieu,
How long is it taking to establish the connection?
It takes 10-12 minutes to connect to all 4 peripherals.
Does it happen from the first connection, or does it only happen with the 3rd/4th connection?
Yes. Disconnection with error 0x3E happens from 1st connection
Connection parameter
Connection Interval:- MIN - 12.5msec
MAX - 18.75msec
Link Layer Data Length - 158
Supervision Timeout - 4 Sec
Peripheral Latency - 0
- Haresh
Hi Haresh,
Haresh05 said:Yes. Disconnection with error 0x3E happens from 1st connection
Disconnection error 0x3E is Connection Failed to be Established.
When this issue happen, does it happen right at the connection attempt or after a connection is formed and some TX/RX happens?
What is your scanning parameter?
Haresh05 said:Connection Interval:- MIN - 12.5msec
MAX - 18.75msec
Link Layer Data Length - 158
Supervision Timeout - 4 Sec
Peripheral Latency - 0
Are those your SDK configurations or are they the actual final connection parameters that you retrieved from SoftDevice event?
Your connection interval is very low and data length is quite long. Each connection interval, I expect the SoftDevice to be quite occupied with serving the connection events. That would explain the difficulty in making the 2nd/3rd/4th connections.
However, nothing really explains why the first connection is hard to establish. Do you think you can get a sniffer trace of when this problem happens with the first connection?
Hieu
Hi,
When this issue happen, does it happen right at the connection attempt or after a connection is formed and some TX/RX happens?
It happens right at the connection attempt.
What is your scanning parameter?
Scan Interval - 100 msec
Scan Window - 80 msec
Are those your SDK configurations or are they the actual final connection parameters that you retrieved from SoftDevice event?
These are SDK Configurations. I have not checked the parameters on softdevice event. Still, as I am setting the same parameter in Central and peripheral devices and I think it should be the same after a connection is established.
Your connection interval is very low and data length is quite long
It is done to increase the throughput. I can increase those if I am getting the throughput we require for our application.
On Peripheral Advertising Interval is set to 100 msec
Haresh
Hi,
When this issue happen, does it happen right at the connection attempt or after a connection is formed and some TX/RX happens?
It happens right at the connection attempt.
What is your scanning parameter?
Scan Interval - 100 msec
Scan Window - 80 msec
Are those your SDK configurations or are they the actual final connection parameters that you retrieved from SoftDevice event?
These are SDK Configurations. I have not checked the parameters on softdevice event. Still, as I am setting the same parameter in Central and peripheral devices and I think it should be the same after a connection is established.
Your connection interval is very low and data length is quite long
It is done to increase the throughput. I can increase those if I am getting the throughput we require for our application.
On Peripheral Advertising Interval is set to 100 msec
Haresh
Hi Haresh,
Haresh05 said:Scan Interval - 100 msec
Scan Window - 80 msec
You can see that this means the scan windows needs to take 80% of the radio time to work as expected.
When you start having connections, it might get difficult to schedule that much time for the scan window. What could then happen is scanning takes a long time to successfully find the peripheral. That somewhat multiplies with the difficulty to schedule the connection establishment, causing issue with the later connections.
However, I still cannot see a clue for why you have problem since the 1st connection. I think we will need a sniffer trace to figure that out. Do you think you can get one?
It would be best if you can get a pair of device log and sniffer trace of the whole process, including the advertising, scanning, and connection establishment which failed with error 0x3E.
If you need instruction to make a sniffer trace, you can refer to Lesson 6 of Nordic's Bluetooth Low Energy Fundamental online course.
Hieu
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
