BLE without codec

[Kashyap23]

Hi,I am using NRF54L15 DK in which I need to transmit audio data over BLE where that data will be used for only plotting in application,I am using sampling rate of 16000 and 2 channels each of 16 bit i.e at 64 KBps .I am able to send data over BLE but only in one meter range ,if I increase the distance I could able to see loss in BLE  as I kept sequence number to check the loss.How can I solve this issue ,I didn't used any codec as BLE support at 2 Mbps which will be good enough as per my data ,what will be effecting BLE  if I maintain some more distance.

[Kenneth]

Hi,

I assume you are using isochronous channels?

If you are using isochronous channels you can add some forward error correction in each packet that for instance can allow the receiver to recover any potential lost packets, or you can choose to send the same packet more than once (adding redundancy in case packets are lost). 

Kenneth

[Kashyap23]

I couldn't able to get that .I am using i2s protocol for reading data from mics using 2 channel at 16k sampling rate ,I want to transmit that data over BLE ,If I am increasing devices distance I can see loss of packets but I am not getting any error codes everying it's getting only 0 if i check "bt_gatt_notify" ret code, so it seems like data is not updating into that ble unction proprly.I am using work queue to update data in ble for every 8 ms thread will execute  and I will get 250 samples into buffer of mic ,it will be filled in 7.8 ms as per calculation(125x(1/16000)) as per 2 channel for frame i will gt 2 samples so it wll be 125 frames to get 250 samples.And i kept sequence number in first 2 bytes ,i am getting loss of some sequence numbers but I am not getting any error codes.will i2s_buff_read will work differently?

#define SAMPLES_PER_BLOCK   250
int32_t Pcm_In[SAMPLES_PER_BLOCK];
int16_t Pcm_Out[SAMPLES_PER_BLOCK];

    ret = i2s_buf_read(i2s_dev_rx, &Pcm_In, &block_size);
	if (ret < 0) {
		printk("Failed to read data: %d\n", ret);
		break;
	}
	copyBuffer(Pcm_In,Pcm_Out,SAMPLES_PER_BLOCK);
	ret = i2s_buf_write(i2s_dev_tx, Pcm_Out, block_size);
	if (ret < 0) {
		printk("Failed to write data: %d\n", ret);
		break;
	}


static void copyBuffer(int32_t *Buff_In,int16_t *Buff_Out,uint16_t number_of_samples)
{

	Buff_Out[0] = (int16_t)(data_counter & 0xFFFF);
    Buff_Out[1] = (int16_t)((data_counter >> 16) & 0xFFFF);
	for(int i = 2; i < number_of_samples; i++) 
	{

		Buff_Out[i]=(Buff_In[i]>>16 );
		
	}
	data_counter++;

}	
	

static void send_data_work_handler(struct k_work *work)
{
    if (!current_conn || !atomic_get(&is_notification_enabled)) {
        goto reschedule;
    }
	

    memcpy(data, &Pcm_Out, sizeof(Pcm_Out));

    int err = bt_gatt_notify(current_conn, &custom_service.attrs[1],
                            data, sizeof(data));
    if (err!=0) {
        printk("Failed to send notification (err %d)\n", err);
    }

reschedule:
    k_work_schedule_for_queue(&app_work_q, &data_send_work, K_MSEC(8));
}

[Kenneth]

If you are using normal BLE connection, then all packets should be reliably sent yes, in the order they are written, I don't see any reason that should fail here. You can connect a nRF sniffer for BLE and check if that can give some clue as to what is happening.

Kenneth