nRF51 wrong sequence in received packets

RE: nRF51 wrong sequence in received packets

Rami AM — Mon, 01 Mar 2021 02:37:01 GMT

[quote userid="6207" url="~/f/nordic-q-a/71965/nrf51-wrong-sequence-in-received-packets/296444#296444"]I think what you are seeing is a conflict or race condition in your code, which is a general programming issue that you need to debug. I am quite confident that this is not related to the Nordic solution[/quote]

yes Susheel Nuguru it's exactly as yo said, it's a race condition between the ADC module, and BLE module, especially when I send the packet inside the main function's forever loop, after putting send function inside the ADC event handler, the problem almost didn't appear as much as before.

RE: nRF51 wrong sequence in received packets

Susheel Nuguru — Fri, 26 Feb 2021 11:57:00 GMT

[quote user="rami_am"]Is it possible that the problem exists in the central side?, because by using nRFconnect for pc the problem didn't appear. [/quote]

It is possible, please take a look at how it is unpacking data, like the code you showed me here.

I am quite confident that the BLE side does not have a problem since i have not heard of this issue within BLE before

RE: nRF51 wrong sequence in received packets

Rami AM — Fri, 26 Feb 2021 09:37:38 GMT

Is this p_data word aligned?

yes it's an array of 20 bytes

What is the value of MY_DATA_LENGTH?

20 bytes

is hr_buffer memory being accessed both by ADC and BLE notification modules?

when ADC fills out the array, it'll set a flag "ble_packet_ready_to_send", so the array will be available for the BLE notification module, otherwise there's no any other possibility for BLE module to get access to it. anyway, I'll re-check if there's any conflict or race-condition there.

Are you using ble_samples_cntr anywhere else apart from the code you showed?

no, only inside adc_event_handler, it's a static variable inside the handler, and it might affect the bytes order into the array, but I don't have such a case.

Is it possible that the problem exists in the central side?, because by using nRFconnect for pc the problem didn't appear.

RE: nRF51 wrong sequence in received packets

Susheel Nuguru — Fri, 26 Feb 2021 08:49:20 GMT

There are few things that are of concern.

hvx_params.p_data = (uint8_t*) p_data;

Is this p_data word aligned?

What is the value of MY_DATA_LENGTH?

The code below

if(sawtooth_cntr<100)
	sawtooth_cntr++;
else
	sawtooth_cntr=0;
	
if(ble_samples_cntr <10)
{	
	hr_buffer[ble_samples_cntr *2] = (uint8_t)(sawtooth_cntr>>8);
	hr_buffer[ble_samples_cntr *2 + 1] = (uint8_t)(sawtooth_cntr);
	ble_samples_cntr++;
}
if(ble_samples_cntr>=10)
{
	ble_samples_cntr=0;
	ble_packet_ready_to_send = true;
}

is hr_buffer memory being accessed both by ADC and BLE notification modules? if yes, then you need to have it under critical section

Are you using ble_samples_cntr anywhere else apart from the code you showed?

I think what you are seeing is a conflict or race condition in your code, which is a general programming issue that you need to debug. I am quite confident that this is not related to the Nordic solution. But if you can provide me a stripped version of this code that is ready to compile and flash, i can attempt to debug this a bit and try to see where you might have a race condition.

RE: nRF51 wrong sequence in received packets

Rami AM — Fri, 26 Feb 2021 02:29:07 GMT

for central side:

1-When using Bluetooth Low Energy on nRfconnect for pc, there were no problems, I can send my data over BLE @200hz, and get them as correct as I sent.

2- When using nRFconnect for mobile phone (android), there was no wrong sequence order in data packets, but when my phone had no enough RAM (i.e. there are other APPs are working together at the same time), in this case there was missed BLE packets, when I checked the log file, I've found that packet is missed there too

where P1 and P2 are the received packets, but there must be another packet between them because the mcu is generating a sequence of numbers between 0 and 100.

RE: nRF51 wrong sequence in received packets

Rami AM — Fri, 26 Feb 2021 01:56:46 GMT

this code is to generate the signal, it's done inside the adc_event_handler:

if(sawtooth_cntr<100)
	sawtooth_cntr++;
else
	sawtooth_cntr=0;
	
if(ble_samples_cntr <10)
{	
	hr_buffer[ble_samples_cntr *2] = (uint8_t)(sawtooth_cntr>>8);
	hr_buffer[ble_samples_cntr *2 + 1] = (uint8_t)(sawtooth_cntr);
	ble_samples_cntr++;
}
if(ble_samples_cntr>=10)
{
	ble_samples_cntr=0;
	ble_packet_ready_to_send = true;
}

this is where to send the packet:

for( ;;)
{
	.
	.
	.	
	
	if(hr_packet_ready_to_send && m_nlrs.is_notification_enabled )
	{
		if(my_data_tx_complete)
		{
			my_ble_characteristic_update(&m_nlrs,hr_buffer);
			ble_packet_ready_to_send = false;
			my_data_tx_complete = false;
		}
		
	}
}

this is how to update the characteristic value:

uint32_t my_ble_characteristic_update(ble_nlhrs_t * p_nlrhrs, uint8_t * p_data)
{
    uint32_t err_code;
    if((p_nlrhrs->conn_handle != BLE_CONN_HANDLE_INVALID) || (!m_nlrhrs->is_notification_enabled))            //ensure that ther's a connection, otherwise softdevice will result in error
    {
        uint16_t                    len = MY_DATA_LENGTH;
        ble_gatts_hvx_params_t      hvx_params;		//20 bytes
        memset(&hvx_params,0,sizeof(hvx_params));
        
        hvx_params.handle   = p_nlrhrs->char_handles.value_handle;
        hvx_params.type     = BLE_GATT_HVX_NOTIFICATION;
        hvx_params.offset   = 0;
        hvx_params.p_len    = &len;
        hvx_params.p_data   = (uint8_t*) p_data;
        err_code = sd_ble_gatts_hvx(p_nlrhrs->conn_handle,&hvx_params);       
    }
    else
        err_code = NRF_ERROR_NOT_FOUND;
		
    return err_code;       
}

and this is how I implemented tx_complete:

bool my_data_tx_complete=true;
static void on_tx_complete(ble_nlhrs_t * p_nlhrs, ble_evt_t * p_ble_evt)
{
    my_data_tx_complete=true;
    if(m_send_complete_para.callback) {
        m_send_complete_para.callback(m_send_complete_para.context,m_send_complete_para.task_type);
    }
}

RE: nRF51 wrong sequence in received packets

Susheel Nuguru — Thu, 25 Feb 2021 07:36:15 GMT

[quote user=""]example, when I send 3 packets of data, I send them as follow:
[Packet_1][Packet_2][Packet_3]...
but when when I receive them, sometimes, I receive them as follow:
[Packet_1][Packet_3][Packet_2]...[/quote]

I think this should not be possible to receive the swapped packets since BLE in its core have sequence numbers for packets so that the receiving controller layer will not accept a packet in wrong sequence order. It seems that there is something wrong in the way you are interpreting the data.

It would help us if you show us some code snippets on how you are sending data on the TX side and how you are pulling data on the receiver side.