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