NCS1.9.0 or NCS1.9.1 periodic_adv work error in nRF5340-DK

[yoyou]

Hello,

NCS1.9.0 or NCS1.9.1,  Windows10 X64,VS Code,periodic_adv.default codes

with nRF52840-DK work fine.

but nRF5340-DK got error,as folow logs

"Failed to create advertising set (err -5)"

*** Booting Zephyr OS build v2.7.99-ncs1  ***
Starting Periodic Advertising Demo
Failed to create advertising set (err -5)
[00:00:00.283,355] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.283,355] <inf> bt_hci_core: HW Variant: nRF53x (0x0003)
[00:00:00.283,386] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 14.50663 Build 1008232294
[00:00:00.286,712] <inf> bt_hci_core: Identity: C7:71:77:EB:8D:C1 (random)
[00:00:00.286,712] <inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0x22fe, manufacturer 0x0059
[00:00:00.286,712] <inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0x22fe
[00:00:00.289,093] <wrn> bt_hci_core: opcode 0x2036 status 0x01

  

thanks

Best Regards

[ovrebekk]

Hi

1) Possibly the issue is that the advertising interval is too slow, which means you will send the advertise packets at a very slow rate. 

To use the quickest possible advertising interval you can change the call to bt_le_per_adv_set_param(..) like this: 

err = bt_le_per_adv_set_param(adv, BT_LE_PER_ADV_PARAM(BT_GAP_PER_ADV_MIN_INTERVAL, BT_GAP_PER_ADV_MIN_INTERVAL, BT_LE_PER_ADV_OPT_NONE));
if (err) {
	printk("Failed to set periodic advertising parameters"
	       " (err %d)\n", err);
	return;
}

Could you try this and see if it helps?

2) A second suggestion is to not use the timeout feature, and simply run the bt_le_per_adv_set_data(..) function on a timer at regular intervals to update the data without stopping advertising. Then you will most likely have less gap between sending the old and new packets, and you should get more advertise packets through. 

Best regards
Torbjørn

[yoyou]

Hello,

i've  use bt_le_per_adv_set_param(...),

30ms-60ms send one time,it is enough to (2kByte/s);

The key is how to ensure that the packet is modified immediately after each sent.

Otherwise,periodic_sync will recv "123123123789"

it is repeat "123" and lost "456"  (audio data can't do that).

   

Best Regards

[ovrebekk]

Hi

In your screenshot you are not using the fastest possible advertising interval. To do that you should configure the periodic advertising parameters using the BT_GAP_PER_ADV_MIN_INTERVAL define, instead of the BT_GAP_PER_ADV_FAST_INT_MIN_1 define. 

I tried to get this working myself, and I am able to get a reliable transfer when I update the advertise data every 40ms:

sequence_test_per_adv.zip

The example I shared shows an example of implementing a sequence number, allowing me to identify retransmitted packets easily, and also detect when packets are lost. 

Packet loss is not great when transmitting audio, but any wireless application is susceptible to packet loss, and this is something you need to handle somehow in the application. 

Best regards
Torbjørn

[yoyou]

Hello,

thank you very much, good job,great!

If NCS can support each packet sending finished  will have a callback(without bt_le_ext_adv_stop and restart),

it is best to bt_le_per_adv_set_data().itcan reduce duplicate data.

     

your codes can send 20 valid data per second, send 100byte at a time will be reached 2kByte/s;

but now less than 30 bytes at a time.

i've add config to prj.conf

# Allow for large Bluetooth data packets.

CONFIG_BT_L2CAP_TX_MTU=252

CONFIG_BT_BUF_ACL_RX_SIZE=256

if set greater than 30, periodic_sync will can't recv data.

   

thanks

Best Regards

[ovrebekk]

Hi 

yoyou said:

If NCS can support each packet sending finished  will have a callback(without bt_le_ext_adv_stop and restart),

it is best to bt_le_per_adv_set_data().itcan reduce duplicate data.

What is most important to you? To avoid duplicate data or to avoid packet loss?

If you only send each packet once you will have much higher packet loss than if you send each packet multiple times, and this will surely have a negative impact on the user experience. 

I can try to figure out if there is an easier way to detect duplicate packets on the receive side, so you don't have to do this manually. 

yoyou said:

i've add config to prj.conf

# Allow for large Bluetooth data packets.

CONFIG_BT_L2CAP_TX_MTU=252

CONFIG_BT_BUF_ACL_RX_SIZE=256

if set greater than 30, periodic_sync will can't recv data.

If you increase the CONFIG_BT_CTLR_ADV_DATA_LEN_MAX parameter on the advertiser side you should be able to send longer advertise packets. I tested this myself by setting CONFIG_BT_CTLR_ADV_DATA_LEN_MAX=202, and was able to send 200 byte long packets (200 bytes of data + 2 bytes of manufacturer ID).

If you send a 200 byte payload every 50ms you should get 4 kByte/s easily. 

Best regards
Torbjørn