regrading sniffer trace and data transfering

[manikandan]

hello,

 i have used and got the daudio_csv_09-02-2023.xlsxaudio_file.pcapngata using sniffer.. trying to send 486 kb in 2035 packets total time taking is 190 seconds

in that data 

time taken for each read and time is 56ms ( average)

waiting time before the next write happens is 33 ms (average)

that 56 ms average is connection interval right?the one we are setting with slave latency..

in code that value is 7.5 to 12 ms then why it is taking 56ms for every packet?

while transmitting master sends write command for every transmission is there any way to send data continuosly because right now time taking for one packet is 80ms we want to reduce this as low as possible..

note: attaching excel where we calculated intervals and wireshark file kindly check and get back to me

thanks and regards

manikandan v

[Einar Thorsrud]

Hi,

that 56 ms average is connection interval right?the one we are setting with slave latency..

No. The initial connection interval is 45 ms, but that is changed to 11.25 ms in packet 4142.

in code that value is 7.5 to 12 ms then why it is taking 56ms for every packet?

If you look at the trace, for instance from 20476 to 20494 you will see that is one GATT packet, which is fragmented over many GAP packets. So you need many packets, which sent at an intreval of 11.25 ms to send this. If you want to increase the throughput you should use data length extension so that you can send longer packets.

while transmitting master sends write command for every transmission is there any way to send data continuosly because right now time taking for one packet is 80ms we want to reduce this as low as possible..

• Use notifications or write commands
• Use long packets, both at GAP and GATT level, so that the GAP packet has maximum length (251 bytes), and then can fit a GATT MTU of 247 bytes.
• Make sure the event length is as long as the connection interval, so that multiple packets can be sent per connection event.
• Consider using a longer connection interval (this is only good for throughput if the event length is adjusted accordingly). This is a two edged sword though, as a re-transmission always happens in the next connection event. So in bad RF conditions, shorter intervals may be better. And in good RF conditions, longer intervals may be better.

[manikandan]

thanks for your reply Torbjorn  helping me with this so i am closing this ticket