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!

[Adrian1504]

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

Best regards,

Adrian Lopez

[Einar Thorsrud]

Hi Adrian,

I will look into this and get back to you tomorrow.

Br,

Einar

[Einar Thorsrud]

Hi Adrian,

From what I understand you want to maximize throughput. Generally, to maximize thourhput with BLE from a GATT server to a client this is important:

1. 2 Mbps PHY
2. Use data length extension to send as long link laye rpackets as possible
3. Use along event length (equal to the connection interval).
4. If using an event length equal to the connection inteval and the link has little packet loss, increasing the connection interval can then increase the thorughput due to overhead when changing connection interval.
5. Make sure various buffers are large enough and always provide data to the stack so that it has data to send.

Looking at the sniffer trace, 1 and 2 from the above list is good. The connection inteval is 15 ms which is perhaps a bit low. But at the same time, I also see that ther more data field is often not set, which is also a potential problem.

So I suggest that you start with adjusting buffer sizes and event length as shown in the prj.conf from the throughput sample and perhaps also adjust the connection interval. Do you get better throhgput then? If not, make sure you attempt to send data fast enough.

[Adrian1504]

Hi Einar,

Thank you so much for your reply.

Here, what do you mean?

Einar Thorsrud said:

I also see that ther more data field is often not set, which is also a potential problem

I adjusted the buffer sizes and also the event length.

I tried changing the connection interval to 30ms, and it still does not work. Maybe the way I am setting my BLE connection is not right?

For the prj:

CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_RX_SIZE=502
CONFIG_BT_BUF_ACL_TX_SIZE=502
CONFIG_BT_L2CAP_TX_MTU=498

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
CONFIG_MAIN_STACK_SIZE=2048
CONFIG_BT_RX_STACK_SIZE=2048

And in the main, I see that in the sample you attaches, they are using bt_le_conn_param, I am using this, Should I change this?:

static struct bt_le_adv_param *adv_param = BT_LE_ADV_PARAM(
	(BT_LE_ADV_OPT_CONNECTABLE |
	 BT_LE_ADV_OPT_USE_IDENTITY), /* Connectable advertising and use identity address */
	BT_GAP_ADV_FAST_INT_MIN_2, /* 0x30 units, 48 units, 30ms */
	BT_GAP_ADV_FAST_INT_MAX_2, /* 0x60 units, 96 units, 60ms */
	NULL);
	
	

I attach my code in case it is more useful.

BLESPIZip.zip

Thank you so much

Adrian Lopez

[Einar Thorsrud]

Hi Adrian,

Adrian1504 said:

Here, what do you mean?

I was refering to the more data field in the packets in the sniffer trace. When that is not set, that indicate that the nRF does not have more data to send, and the connection event will be closed. So it seems you are not providing data to the BLE stack fast enoug (for higher throughput).

Looking at your code I see you send data in your ble_notify_thread() and this waits for a semaphore buffer_sem given in simulate_data. What throuhgput do you get if you skip this part and just send the same dummy data over and over (no acellerometer data and no semaphore)? The way the code looks now I cannot see if the limiting factor here is getting the accelerometer data or sending the data over BLE.

[Adrian1504]

Hi Einar,

Thank you for your answer.

I tried what you suggested, and yes, now I receive more. So I am receiving 25920 int 32 which I think makes it .8 Mbps. Since I think now the problem is the reading of the accelerometer data, I changed my program to read the FIFO, instead of reading register each time it was accessed. I am now getting .5 Mbps, which is good, but I'd like to increase it to .8 that was amazing. Would you know of any way I could make this better?

Maybe making 2 buffers and sending one and then the other? Increasing the frequency of SPI?

I will try them, but if you have any advice, I would be really interested in reading it.

Best regards,
Adrian Lopez.

[Einar Thorsrud]

Hi Adrian,

I am not familiar with the adxl355, but how fast can you read data from it? There is probably a maximum sampling rate etc. That should be specified in the data sheet. I would suggest that you first look into what you can actually achieve theoretically. And then start testing without bluetooth this time, just logging (not very often) how much data you have recieved, and ignore the data.