Which is the best way of sending the data read from a sensor?

[Adrian1504]

Hi,

I need to read the data from an acceleration sensor. I tried with a custom program of mine to simulate some data, but it is delaying too much.

I tried reducing the notification interval, but sometimes it just jumps numbers so to say, it should show 1,2,3. But now it shows 1,3,5.

Am I missing something?

Thank you!

[Karl Ylvisaker]

Hello,

I need to read the data from an acceleration sensor. I tried with a custom program of mine to simulate some data, but it is delaying too much.

Could you elaborate on what you are doing here, and which delay you are referring to here?
Are you reading out the sensor data over I2C for instance, and then sending it over BLE, where the mentioned delay applies to the BLE communication?


If you are just starting out with the nRF Connect SDK then I highly recommend taking a look through the nRF Connect SDK Fundemental course to quickly familiarize with the SDK! :) 


Best regards,
Karl

[Adrian1504]

Hi Karl, 

I am still not reading any sensor, for now it is just dummy values, and supposedly they should be increasing in 1 unit each time the loop comes. But sometimes it is being increased in more than one unit. 
I think maybe sending each time the sensor is being "read" is not the best. Is it possible to send maybe an array? Or which is the best way to send the most amount of the "read" sensor?

Thank you!

[Karl Ylvisaker]

Hello Adrian Lopez,

Adrian1504 said:

When I connect my device it prints this notifications in the nrf Connect app: 

• PHY updated (TX: LE 2M, RX: LE 2M)
• Connection parameters updated (interval: 11.25ms, latency: 0, timeout: 10000ms)

And in the terminal I am getting this messages:

• MTU exchange successful, new MTU: 244 bytes
• Data length updated. Length 251/27 bytes, time 2120/2120 us

So I think that the central is accepting the changes successfully and is setting the same parameters as in the link you provided me. 

Thank you for clarifying - it is good to have it confirmed that you are using a 11.25 ms connection interval.

It seems that you have successfully changed your connection parameters, and so that should not be what is causing the issue with the throughput either. Could you detail how you are generating and queueing the data for sending again? It would be great to see the relevant code as well, if possible.

If the throughput is still an issue we will need to capture a sniffer trace of the communication between the devices. Are you familiar with the nRF Sniffer tool?

Best regards,
Karl

[Adrian1504]

Hi Karl,

A small update, I changed some things in my code and was able to achieve now .9 Mbps, so I guess the way I am queueing the data and sending it is still not correct. I would be happy to be able to get it up to 1.2. Of course, I will leave some of my functions here:

static void simulate_dataX(void)
{
	sensor_valueX++;
	if (sensor_valueX == 9) {
		sensor_valueX = 0;
	}
}

static void simulate_data(void){
	simulate_dataX();
	simulate_dataY();
	simulate_dataZ();
}

int my_lbs_send_sensor_notify(void)
{
	if (!notify_sensor_enabled) {
		return -EACCES;
	}

	return bt_gatt_notify(NULL, &accelerometer_svc.attrs[1], 
			      &buffer,
			      sizeof(buffer));
}

static void pack_data(uint8_t x, uint8_t y, uint8_t z){
	buffer[buffer_index].x = x;
    buffer[buffer_index].y = y;
    buffer[buffer_index].z = z;
    buffer_index++;

	if (buffer_index == BUFFER_SIZE){
		int err = my_lbs_send_sensor_notify();
		if (err) {
			LOG_ERR("Notification failed:  %d", err);
		}
		buffer_index = 0;
	}

}

void send_data_thread(void)
{
	while(1){
		if(notify_sensor_enabled){ //Without this if I was only achieveing .02 Mbps
			simulate_data();
			pack_data(sensor_valueX,sensor_valueY,sensor_valueZ);
		}

	}
		
}

K_THREAD_DEFINE(send_data_thread_id, STACKSIZE, send_data_thread, NULL, NULL,
		NULL, PRIORITY, 0, 0);

Here is the prj:

# nothing here
CONFIG_LOG=y

CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="BLE Device"
CONFIG_BT_DEVICE_APPEARANCE=0
#CONFIG_BT_BAS=y

CONFIG_BT_GATT_CLIENT=y

CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_DEBUG_THREAD_INFO=y
CONFIG_FPU=y

CONFIG_BT_PERIPHERAL_PREF_MIN_INT=30
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=40
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0
CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=1000
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y

CONFIG_BT_USER_PHY_UPDATE=y

CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_L2CAP_TX_MTU=247

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
CONFIG_MAIN_STACK_SIZE=2048
CONFIG_BT_RX_STACK_SIZE=2048

If you need any other part of the code, let me know. Also, I am not familiar to this tool, but I will have a look at it! Thank you!

Best regards, 

Adrian Lopez Vudoyra

[Karl Ylvisaker]

Hello Adrian.

Thank you for clarifying - I am glad to hear that you are having progress on the throughput!

The next step in figuring out where the bottleneck in the communication is would be to gather a sniffer trace, so that we can verify that the application always have data ready to send, and whether there is anything hampering the data from being sent.
It could for instance here be that the application is not supplying the data fast enough due to other tasks taking time away from the data generation.
Have you had a look at my suggestion for sniffer in my previous comment?

Best regards,
Karl

[Adrian1504]

Hello Karl,

Sorry for the late response. I have been trying to install it, but I ran into this problem:
"The term 'nrf_sniffer_ble.bat' is not recognized as
the name of a cmdlet, function, script file, or operable program."

I have already checked and I have python installed. Do you know what is the problem?

[Karl Ylvisaker]

Hello again, Adrian

Thank you for your patience with this - I have been out of office due to the public easter holiday last week, but now I am back.

Please make sure that you have followed all the steps in the Installing the sniffer guide - especially the part on Installing the sniffer capture tool. Please do this, and let me know if the issue persists!

Best regards,
Karl

[Adrian1504]

Hi Karl,

I am really sorry for the delay. I had to focus also on the reading of the sensor, the app for displaying the data and got stuck for a really long time. Now I had the chance to return and have a look at this issue again. 

I see that now I am obtaining again .02 MB/s. I tried making 2 different threads, one that reads the values from the sensor ands stacks them in an array, and other one that sends the data. It is also not working.

Having a look at the sniffer tool that you mentioned, I receive some things which I don't know if it is helpful to know, or how to interpret them. I see for example, that the updates in parameters to 2M and data length are being made. 

But when I subscribe to the notifications, I see that the master is also taking quite some time to send something and it is empty, is this normal?

Also, I don't see any warnings or errors.

I attach some screenshots of the wireshark. If there is a better way to share the logs, please let me know.

This first image is before any connection event

This second image is when the connection happened

This third image is before I subscribe

This fourth image is during the subscription

If there is any other information that might be useful, please let me know.

Best regards, 

Adrian Lopez

[Adrian1504]

Now I figured out what to send, an apology.
sniffer1.zip

Best regards,

Adrian Lopez