Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

packet data duplication problem for using hvn_tx_queue

Hello.

I need to solve this problem urgently.

I have now created my own protocol and are testing.

At the point of this project is the guarantee of data transmission and the speed of communication.

So, Indication is quite slow, so I use the following to get a guarantee for the data to be sent to the Notification.

· hvn_tx_queue_size

However, the following unintended packets are transmitted.

Softdevice seems to have a problem.

Please let me know about this in detail.

※Explanation

I set the size of hvn_tx_queue_size to 10.

9 packets of 182 Bytes were transmitted as described below.


"Succ": sd_ble_gatts_hvx execution success.
"S_not": sd_ble_gatts_hvx Execution success count total.
"C_not": sum of hvn_tx_complete.count of CallBack Function (on_tx_complete)
"Q1": available_queue_element_count
"DT": The first 4 bytes of the transmission data.

Please concentrate on the packets received from the 6th and 10th packets beginning with 「0x48482c21」.

Do you see duplicate data?

This is the packet data transmitted from the nrf52 to the ninth last.

Please check why this packet is duplicated on the receiving side for the sixth time.

Is not it a problem with Softdevice?

■ nrf52 device - Send

<info> app: Succ S_not: 0, C_not: 0 Q1: 9 DT: 0x2
<info> app: Succ S_not: 1, C_not: 0 Q1: 8 DT: 0x400140C0
<info> app: Succ S_not: 2, C_not: 0 Q1: 7 DT: 0x76FF2F2F
<info> app: Succ S_not: 3, C_not: 0 Q1: 6 DT: 0x0
<info> app: Succ S_not: 4, C_not: 0 Q1: 5 DT: 0xC301C0FE
<info> app: Succ S_not: 5, C_not: 0 Q1: 4 DT: 0x4E483AFF
<info> app: Succ S_not: 6, C_not: 0 Q1: 3 DT: 0x0
<info> app: Succ S_not: 7, C_not: 0 Q1: 2 DT: 0x27E47DFE
<info> app: Succ S_not: 8, C_not: 0 Q1: 1 DT: 0x212C4848

syncopation...

<info> app: fatfs_file_read_subroutine_loop failed. 9 1  << - 「Q2」: sum of count for gatts_evt.params.hvn_tx_complete.count
<info> app: Next S_not: 9, C_not: 2 Q1: 3 Q2: 1 << - 「Q2」: gatts_evt.params.hvn_tx_complete.count
<info> app: fatfs_file_read_subroutine_loop failed. 9 2
<info> app: Next S_not: 9, C_not: 3 Q1: 4 Q2: 1
<info> app: fatfs_file_read_subroutine_loop failed. 9 3
<info> app: Next S_not: 9, C_not: 4 Q1: 5 Q2: 1
<info> app: fatfs_file_read_subroutine_loop failed. 9 4
<info> app: Next S_not: 9, C_not: 5 Q1: 6 Q2: 1
<info> app: fatfs_file_read_subroutine_loop failed. 9 5
<info> app: Next S_not: 9, C_not: 6 Q1: 7 Q2: 1
<info> app: fatfs_file_read_subroutine_loop failed. 9 6
<info> app: Next S_not: 9, C_not: 7 Q1: 8 Q2: 1
<info> app: fatfs_file_read_subroutine_loop failed. 9 7
<info> app: Next S_not: 9, C_not: 8 Q1: 9 Q2: 1
<info> app: fatfs_file_read_subroutine_loop failed. 9 8
<info> app: END Trans S_not: 9, C_not: 9 Q1: 10 Q2: 1 << - CallBack Function (on_tx_complete) : OK with 9

■LightBlue(iPhone X) - Receive

20:45:17.186 — Characteristic (92A10FC7-5236-4777-8AB3-4E3967C6F18C) wrote new value: <01523031 30313337 31>
20:45:17.222 — Characteristic (92A10FC7-5236-4777-8AB3-4E3967C6F18C) notified: <02000000 00000000 00030200 00000000 00a5301a 00000000 00000018 e5000003 02000000 00000000 00030200 447fff0b 06a330fb 52000000 00000019 e6010003 02000000 00000000 00030200 465fffad 54a930ee 52000000 00000019 e6020003 02000000 00000000 00030200 446fff90 54a730ec 52000000 0000007d e4030003 02000000 00000000 00030200 412fff9d 549830e6 52000000 0000006f e0040003 02000000 00000000 000302c0 3b8fff92 549930df 5200>
20:45:17.225 — Characteristic (92A10FC7-5236-4777-8AB3-4E3967C6F18C) notified: <c0400140 fef1e205 00030200 00000000 00000003 02c0359f ff8d54ab 30c25200 c0400140 fe19e606 00030200 00000000 00000003 02c0336f ff7d548d 30bc5200 c0400140 fee2e107 00030200 00000000 00000003 02c0367f ff8a548e 30c05200 c0400140 fec9e308 00030200 00000000 00000003 02c039bf ff885493 30be5200 c0400140 fe87e609 00030200 00000000 00000003 02c039af fe8c5493 30c75240 c04001c0 fea0e50a 00030200 00000000 00000003 02c0>
20:45:17.225 — Characteristic (92A10FC7-5236-4777-8AB3-4E3967C6F18C) notified: <2f2fff76 548e30a2 5240c040 01c0fef1 e20b0003 02000000 00000000 000302c0 fe7fff4b 54713036 5240c040 01c0fef1 e20c0003 02000000 00000000 000302c0 fe6fffc0 532630bf 5140c040 01c0fec9 e30d0003 02000000 00000000 000302c0 feafff85 531a30d0 5140c040 01c0fe19 e60e0003 02000000 00000000 000302c0 47cfffcd 531e30f7 51c0bf80 0180fee2 e10f0003 02000000 00000000 000302c0 618fff0d 542d3027 52c0bf80 0180fef1 e2100003 0200>
20:45:17.225 — Characteristic (92A10FC7-5236-4777-8AB3-4E3967C6F18C) notified: <00000000 00000003 02c07eaf ff1e541e 30d251c0 bf800180 fe16de11 00030200 00000000 00000003 02c0f7ef f1df5050 2e664ec0 bf800180 fee2e112 00030200 00000000 00000003 02c0a3ef ff244e6c 2d754cc0 bf800180 fe87e613 00030200 00000000 00000003 02c073bf ffbf4a89 2c954ac0 bf80fec0 01c9e314 00030200 00000000 00000003 02c07b3f ff0d485e 2c384ac0 bf80fec0 0118e515 00030200 00000000 00000003 02c07baf ff50484f 2c194ac0 bf80>
20:45:17.226 — Characteristic (92A10FC7-5236-4777-8AB3-4E3967C6F18C) notified: <fec001c3 e8160003 02000000 00000000 000302c0 775fff2f 48452c2e 4ac0bf80 fec0017d e4170003 02000000 00000000 000302c0 6ebfed3f 48562c33 4ac0bf80 fec001e2 e1180003 02000000 00000000 000302c0 665fff42 484a2c1e 4a40c000 00c0fe6f e0190003 02000000 00000000 000302c0 600fe43a 48592c24 4a40c000 00c0fe16 de1a0003 02000000 00000000 000302c0 570fff36 484f2c39 4a40c000 00c0fec9 e31b0003 02000000 00000000 000302c0 4f2f>
20:45:17.236 — Characteristic (92A10FC7-5236-4777-8AB3-4E3967C6F18C) notified: <48482c21 4ac0bf00 00c0fec3 e82d0003 02000000 00000000 000302c0 fef3ab38 484a2c34 4ac0bf00 00c0fea0 e52e0003 02000000 00000000 000302c0 fee3a033 483f2c35 4ac0bf00 00c0fec3 e82f0003 02000000 00000000 000302c0 ff43983c 48532c20 4ac0bf00 00c0fef1 e2300003 02000000 00000000 000302c0 fe93843e 48482c30 4ac0bf00 00c0fe19 e6310003>
20:45:17.237 — Characteristic (92A10FC7-5236-4777-8AB3-4E3967C6F18C) notified: <ff3a484e 2c264a40 c00000c0 fe16de1c 00030200 00000000 00000003 02c0438e d9254849 2c224a40 c00000c0 fee2e11d 00030200 00000000 00000003 02c03a3d 4c35484d 2c244a40 c0400000 fe16de1e 00030200 00000000 00000003 02c02feb ec3c4851 2c0f4a40 c0400000 fef1e21f 00030200 00000000 00000003 02c027ba c441483e 2c2a4a40 c0400000 fef1e220 00030200 00000000 00000003 02c02039 c035484d 2c1d4a40 c0400000 fec9e321 00030200 0000>
20:45:17.238 — Characteristic (92A10FC7-5236-4777-8AB3-4E3967C6F18C) notified: <00000000 000302c0 13b8e028 48442c26 4a40c040 0000fe87 e6220003 02000000 00000000 000302c0 0be7fd39 48462c16 4a00c000 0080fe7d e4230003 02000000 00000000 000302c0 05371b35 484a2c2c 4a00c000 0080fee2 e1240003 02000000 00000000 000302c0 feb65439 48482c15 4a00c000 0080feec e6250003 02000000 00000000 000302c0 feb5a82b 48432c2f 4a00c000 0080feec e6260003 02000000 00000000 000302c0 feb50530 48432c2d 4a00c000 0080>
20:45:17.239 — Characteristic (92A10FC7-5236-4777-8AB3-4E3967C6F18C) notified: <fe7de427 00030200 00000000 00000003 02c0fee4 9426483f 2c1a4a40 c0000040 fee2e128 00030200 00000000 00000003 02c0ff04 44324848 2c224a40 c0000040 fe87e629 00030200 00000000 00000003 02c0fec4 002b483c 2c354a40 c0000040 fe7de42a 00030200 00000000 00000003 02c0fed3 cf2f4859 2c2d4a40 c0000040 feece62b 00030200 00000000 00000003 02c0ff53 bc34484b 2c104a40 c0000040 fe19e62c 00030200 00000000 00000003 02c0ff23 ad33>
20:45:17.241 — Characteristic (92A10FC7-5236-4777-8AB3-4E3967C6F18C) notified: <48482c21 4ac0bf00 00c0fec3 e82d0003 02000000 00000000 000302c0 fef3ab38 484a2c34 4ac0bf00 00c0fea0 e52e0003 02000000 00000000 000302c0 fee3a033 483f2c35 4ac0bf00 00c0fec3 e82f0003 02000000 00000000 000302c0 ff43983c 48532c20 4ac0bf00 00c0fef1 e2300003 02000000 00000000 000302c0 fe93843e 48482c30 4ac0bf00 00c0fe19 e6310003>

★Test Infomation

※s132_nrf52_6.0.0_softdevice

※ SDK Version

     nRF5_SDK_15.0.0_a53641a

※ IC

     nRF52832

  • I have now created my own protocol and are testing.

    I am assuming that you still are using BLE protocol for communication, since you are talking about notifications and softdevice.

    There are so many use cases where customers have been transmitting large chunks of data of over and I did not see any kind of duplicate data being received. 

    I think the problem is on your transmit side, are you pretty sure that your transmitter is not transmitting in the same way? please print the log in the transmitter side also to see if this is the case.

    You can also use a BLE air sniffer to see if the packets in the air are different and the things received are different.

    In short, I highly doubt that this is a bug in the softdevice, but could be something in the application side of your code. Please provide me with the logs of how the transmitter is queueing and we can compare them with how the receiver is getting those packets and if some order is changed. We can then try to debug what the problem is.

Related