Sending up to 20 bytes of data during a notify event.

RE: Sending up to 20 bytes of data during a notify event.

kabiskac — Mon, 13 Sep 2021 10:07:54 GMT

I had a problem where there was garbage if I wrote less data than the full length. Setting attr_md.vlen to 1 fixed it.

RE: Sending up to 20 bytes of data during a notify event.

Carles — Wed, 25 Mar 2015 11:13:55 GMT

Any news on this?

RE: Sending up to 20 bytes of data during a notify event.

Carles — Thu, 19 Mar 2015 09:52:47 GMT

Well then what's gonna trigger the first call to on_ble_evt(TX_COMPLETE), which will call imu_data_send()? Are you sure you're executing imu_data_send() at all?

RE: Sending up to 20 bytes of data during a notify event.

bulbse — Wed, 18 Mar 2015 23:04:03 GMT

Nothing explicitly triggers TX_COMPLETE in my code.

static void imu_data_send(void)
{
	uint32_t        err_code;
	
	uint8_t Data[20] 		= {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20};
	uint16_t	data_len 	= sizeof(Data) / sizeof(Data[0]);
		
	while(true)
  {
		err_code = ble_aavs_on_imu_available(&m_aavs, Data, data_len);
		if (err_code == BLE_ERROR_NO_TX_BUFFERS ||
				err_code == NRF_ERROR_INVALID_STATE || 
				err_code == BLE_ERROR_GATTS_SYS_ATTR_MISSING)
				{
					break;
				}
				else if (err_code != NRF_SUCCESS) 
				{
					APP_ERROR_HANDLER(err_code);
				}
  }

}

wait for event:

static void on_ble_evt(ble_evt_t * p_ble_evt)
{
...

case BLE_EVT_TX_COMPLETE:
            imu_data_send(); 
            break;
...
}

RE: Sending up to 20 bytes of data during a notify event.

bulbse — Wed, 18 Mar 2015 22:56:11 GMT

I can look into that, will let you know soon.

RE: Sending up to 20 bytes of data during a notify event.

Carles — Wed, 18 Mar 2015 18:54:58 GMT

This garbage data might be read perhaps instead of notified? Have you tried with Master Control Panel PC (Windows) app instead? Maybe if you tried that it could shed some light, I don't know the mobile app well.

RE: Sending up to 20 bytes of data during a notify event.

Carles — Wed, 18 Mar 2015 18:53:18 GMT

I'm running out of ideas now but you say that you call hvx() when you get a TX_COMPLETE event. What triggers then the first notification? It's the first notification that will trigger that first TX_COMPLETE event.

RE: Sending up to 20 bytes of data during a notify event.

bulbse — Wed, 18 Mar 2015 18:33:51 GMT

Thanks Carles, Ive updated the code to reflect your changes. I agree the size of a pointer will never changes, that got passed me. I still see garbage data though. Not sure what could be causing it.

RE: Sending up to 20 bytes of data during a notify event.

Carles — Wed, 18 Mar 2015 17:11:25 GMT

This here:

uint16_t len = sizeof(p_imu_data)/sizeof(p_imu_data[0])

sizeof(ptr) will always give you 4 bytes, you cannot do that in C to obtain the length of the memory pointed to. You will have to pass imu_data_len as a parameter to ble_aavs_on_imu_available()

RE: Sending up to 20 bytes of data during a notify event.

bulbse — Wed, 18 Mar 2015 17:01:03 GMT

Thanks Stefan, I will let you know what I find.

RE: Sending up to 20 bytes of data during a notify event.

bulbse — Wed, 18 Mar 2015 16:59:53 GMT

In the service.c file I set the characteristic like so:

    static uint32_t imu_char_add(ble_aavs_t * p_aavs)
{
    ble_gatts_char_md_t char_md;
    ble_gatts_attr_md_t cccd_md;
    ble_gatts_attr_t    attr_char_value;
    ble_uuid_t          ble_uuid;
    ble_gatts_attr_md_t attr_md;

    memset(&cccd_md, 0, sizeof(cccd_md));

    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.read_perm);
    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.write_perm);
    cccd_md.vloc = BLE_GATTS_VLOC_STACK;
    
    memset(&char_md, 0, sizeof(char_md));
    
    char_md.char_props.read   = 1;
    char_md.char_props.notify = 1;
    char_md.p_char_user_desc  = NULL;
    char_md.p_char_pf         = NULL;
    char_md.p_user_desc_md    = NULL;
    char_md.p_cccd_md         = &cccd_md;
    char_md.p_sccd_md         = NULL;
    
    ble_uuid.type = p_aavs->uuid_type;
    ble_uuid.uuid = AAVS_UUID_IMU_CHAR;
    
    memset(&attr_md, 0, sizeof(attr_md));

    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.read_perm);
    BLE_GAP_CONN_SEC_MODE_SET_NO_ACCESS(&attr_md.write_perm);
    attr_md.vloc       = BLE_GATTS_VLOC_STACK;
    attr_md.rd_auth    = 0;
    attr_md.wr_auth    = 0;
    attr_md.vlen       = 0;
    
    memset(&attr_char_value, 0, sizeof(attr_char_value));

    attr_char_value.p_uuid       = &ble_uuid;
    attr_char_value.p_attr_md    = &attr_md;
    attr_char_value.init_len     = sizeof(uint8_t);
    attr_char_value.init_offs    = 0;
    attr_char_value.max_len      = 20;//sizeof(uint8_t);  // This sets the data length to be transmitted.
    attr_char_value.p_value      = NULL;
    
    return sd_ble_gatts_characteristic_add(p_aavs->service_handle, &char_md,
                                               &attr_char_value,
                                               &p_aavs->imu_char_handles);
}

I then later define a method which is supposed to transfer data over ble from the pointer I feed into it.

   uint32_t ble_aavs_on_imu_available(ble_aavs_t * p_aavs, uint8_t* p_imu_data, uint16_t imu_data_len)			
{
	 uint32_t err_code;
	
 if (p_aavs->conn_handle != BLE_CONN_HANDLE_INVALID)
{
ble_gatts_hvx_params_t params;

  
memset(&params, 0, sizeof(params));
params.handle 	= p_aavs->imu_char_handles.value_handle;
params.type 		= BLE_GATT_HVX_NOTIFICATION;
params.offset 	= 0;
params.p_len 	= &imu_data_len;
params.p_data 	= p_imu_data;
					    
err_code = sd_ble_gatts_hvx(p_aavs->conn_handle, &params);
					
	}
	else
	{
		err_code = NRF_ERROR_INVALID_STATE;
	}
	
		return err_code;

}

from within the application I have a method which calls the notification code under the condition it sees a BLE_EVT_TX_COMPLETE within the on_ble_evt method

RE: Sending up to 20 bytes of data during a notify event.

bulbse — Wed, 18 Mar 2015 16:56:05 GMT

See within answer.

RE: Sending up to 20 bytes of data during a notify event.

Carles — Wed, 18 Mar 2015 15:52:10 GMT

Can you post the characteristic population code along with the notification code? When you call sd_ble_gatts_characteristic_add(). Let's see if we can find out what's wrong.

RE: Sending up to 20 bytes of data during a notify event.

Stefan Birnir Sverrisson — Wed, 18 Mar 2015 09:34:09 GMT

ok, thats not it then. Take a look at this thread in order to look at what is needed to send multiple bytes in a single packet. Also, here is an example that transmits 20 bytes per packet, perhaps you can spot something missing in your code by comparing with that code.

RE: Sending up to 20 bytes of data during a notify event.

bulbse — Wed, 18 Mar 2015 00:49:20 GMT

Yes Carles, I've discovered the fact that the characteristic needed to be updated. I just dont know why im not sending the expected data.

RE: Sending up to 20 bytes of data during a notify event.

bulbse — Wed, 18 Mar 2015 00:48:09 GMT

making it static didn't change anything. I was under the impression that the ble_gatts_hvx_params_tlooks first to see if we populated the p_data method. It doesn't seem to be doing that in this case.

RE: Sending up to 20 bytes of data during a notify event.

Stefan Birnir Sverrisson — Tue, 17 Mar 2015 14:35:38 GMT

Try to define your variable as static, i.e.

static uint8_t data[20] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20}; // 20 bytes of data

RE: Sending up to 20 bytes of data during a notify event.

Carles — Tue, 17 Mar 2015 08:56:34 GMT

There's a bug s110 SD versions pre-8.0.0 where we would initialize the length of a variable length characteristic to max_len instead of init_len. See the 8.0.0 release notes for more info.

RE: Sending up to 20 bytes of data during a notify event.

Carles — Tue, 17 Mar 2015 08:54:54 GMT

Hi there,

Please see this answer here but effectively a notification or indication will always send the complete current size of the characteristic up to MTU bytes.

RE: Sending up to 20 bytes of data during a notify event.

Nguyen Hoan Hoang — Mon, 16 Mar 2015 07:55:56 GMT

Now I understand. The code looks good. I haven't used the MCP. I don't know how it behaves. It looks like you are sending custom data via a standard profile, HRS or battery or something like that. Could that be the problem ?

RE: Sending up to 20 bytes of data during a notify event.

bulbse — Mon, 16 Mar 2015 04:31:48 GMT

Yes, I understand sizeof(uint8_t) is one byte, I said i found that it fixed my 1 byte long value problem, I am now sending 20 bytes but they are garbage data. So I'm using the "nRF master control panel" as the central from an android device. Im using PCA10028 with S110. I have updated the question with a screen capture of what i am receiving.

RE: Sending up to 20 bytes of data during a notify event.

Nguyen Hoan Hoang — Sun, 15 Mar 2015 12:26:01 GMT

sizeof(uint8_t) gives the value 1 because type uint8_t is one byte long.
You still haven't said which platform you are working on, iOS, Android, HTLM, Windows, OS X, Linux,...? Which API... ? Can you post that section of the code and the results you are getting?

RE: Sending up to 20 bytes of data during a notify event.

bulbse — Sun, 15 Mar 2015 09:30:16 GMT

Thanks Nguyen for your efforts, I found a clue to my problem but i need directions. I found this code within my characteristic definition attr_char_value.max_len = sizeof(uint8_t); which makes sense why only 1 byte is being transmitted. I changed that to attr_char_value.max_len = 20; I see a string of 20 bytes however it is garbage. I expect to see the data stream defined above. any ideas what might be happening?

RE: Sending up to 20 bytes of data during a notify event.

Nguyen Hoan Hoang — Sat, 14 Mar 2015 22:08:59 GMT

What is the receiving end ? iOS, Android ? The value of 20 you receive, is it the data or the length ? If receiving is iOS. You can try my code on this blog site. There are many examples code with one to one nRF51 & iOS counterpart. embeddedsoftdev.blogspot.ca/.../ehal-nrf51.html

RE: Sending up to 20 bytes of data during a notify event.

bulbse — Sat, 14 Mar 2015 19:44:00 GMT

that was just an example. I'm saying that regardless of the data array i have it consistently transmits something unrelated.