NRF_ERROR_DATA_SIZE when trying to configure/encode adv data in Codec PHY

[Victor Ruiz 26]

Hi,

I was trying to configure adv data such us UUID, major, minor and other data using codec PHY in BLE. I am able to send it correctly using 1M PHY, buy I am having many troubles using Codec.

My project is this one:  0167.ble_app_beacon_.zip and using 

SEGGER Embedded Studio for ARM
Release 7.32 Build 2023081802.53976
Windows x64.

With nRF5 SDK v17.1.0

First of all i have defined two compilation settings (needed for compiling, as i used defined variables on them in advertising_init):

I defined the variables in the first two profiles.

As it is shown in the Preprocessor options:

This project is an advertiser that sends BLE advertisements accord the compilation profile defined. And Tx power and PHY mode can be changed using switches 3 and 2 respectively. 

I have the following NRF_ERROR_DATA_SIZE error using the 1adv_seg compilation environment, please use only this one (in which the tx power change works properly):

The error is in this line:

This worked for me before because I had commented those lines, but when I scanned the adv in Codec mode I realised than it did not contain any advertisement data to obtain and analyze, so I uncommented the lines and the error arose.
I also tried to create a new ble_gap_adv_data_t m_adv_data, defining the len of the p_data defined by other buffer for extended advertisers, as is shown in the image:

Therefore, my issue is inside the ble_advdata_encode for extended advertisements using Codec, and I do not know where is the problem, please if you would help me.

Thanks for the support!

[Vidar Berg]

Hello,

You seem to be using the incorrect BLE_GAP_ADV_TYPE when starting advertising with the coded PHY. This PHY is only supported with extended advertising. Please implement the changes below and let me know if it works or not.

@@ -512,12 +511,12 @@ static void advertising_init(void)
         if(m_adv_scan_type_selected == SELECTION_CONNECTABLE)
         {
    //         NRF_LOG_INFO("Advertising type set to CONNECTABLE_SCANNABLE_UNDIRECTED ");
-            adv_params.properties.type = BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED;
+            adv_params.properties.type = BLE_GAP_ADV_TYPE_EXTENDED_CONNECTABLE_NONSCANNABLE_UNDIRECTED;
         }
         else if(m_adv_scan_type_selected == SELECTION_NON_CONNECTABLE)
         {
    //         NRF_LOG_INFO("Advertising type set to NONCONNECTABLE_SCANNABLE_UNDIRECTED ");
-            adv_params.properties.type = BLE_GAP_ADV_TYPE_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED;
+            adv_params.properties.type = BLE_GAP_ADV_TYPE_EXTENDED_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED;
         }
         
         ret = ble_advdata_encode(&adv_data, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
@@ -549,9 +548,10 @@ static void advertising_init(void)
         {
     //        NRF_LOG_INFO("Advertising type set to EXTENDED_NONCONNECTABLE_SCANNABLE_UNDIRECTED ");
             adv_params.properties.type = BLE_GAP_ADV_TYPE_EXTENDED_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED;
+            // Re-init '.len'paramater to default value in case it was updated by previous call to ble_advdata_encode()
+            m_adv_data_ext.adv_data.len = BLE_GAP_ADV_SET_DATA_SIZE_EXTENDED_MAX_SUPPORTED;
 
-
-            ret = ble_advdata_encode(&adv_data, m_adv_data_ext.scan_rsp_data.p_data, &m_adv_data_ext.scan_rsp_data.len);
+            ret = ble_advdata_encode(&adv_data, m_adv_data_ext.adv_data.p_data, &m_adv_data_ext.adv_data.len);
             APP_ERROR_CHECK(ret);
 
             ret = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data_ext, &adv_params);

Best regards,

Vidar

[Victor Ruiz 26]

Yes, the first block of code you posted is inside condition: if(m_adv_scan_phy_selected == SELECTION_1M_PHY). The block:

So I think that my initialization is correct in mode 1M.

The second block is referred to m_adv_scan_phy_selected as Codec PHY. And the m_adv_data_ext is another structure that i used for initialising the m_adv_handle for this mode. And I do not modify this structure anywhere 

Here is the question, should I use the same ble_gap_adv_data_t structure for both phy modes? If it is, I should define the ble_gap_adv_data_t->adv_data->p_data  m_enc_advdata array as BLE_GAP_ADV_SET_DATA_SIZE_EXTENDED_MAX_SUPPORTED, right? 

But by this way, I would send many unnecessary data when using 1M PHY mode...

So, which is the way to create these structures and changing each other as change the PHY mode?

Thanks.

[Vidar Berg]

Sorry, I was reviewing the code for the wrong if statement. However, I believe it should work if you ignore the first part and apply only the last part of my patch starting at line 549.

[Victor Ruiz 26]

Oh Sorry, It works now. The error occurred when the ble_adv_data_enconde function was called with the wrong m_adv_data_ext parameters (i was passing .scan_rsp_data.p_data, scan_rsp_data.len instead of .adv_data.p_data and adv_data.len).

Thank you so much for the support!

[Victor Ruiz 26]

Hi Vidar. 
Which is the utility of scan_rsp_data inside ble_gap_adv_data_t m_adv_data structure?

Are these data values that the BLE receives? Or are prefixed (or modificable at running time?) data that the advertiser returns to an adv_scan_req?

My question comes because i want to implement a system where the central receives advertisements from the peripheral and when i press a button in the central, for example, it sends an advertisement to which the peripheral would respond, all this without connecting the devices. I mean, all communication is using advertisements, I one case undirected (from peripheral to central) and in the other case (when button pressed, from central to peripheral), directed to that peripheral

I do not know ir this approach is correct, or i would implement connectable advertisements and ble_events.

Thanks in advance

[Vidar Berg]

Hi,

The advertisement type you have selected is 'non-scannable', which means you cannot send any scan response. Therefore, there is no need to provide a buffer for scan response data either.

Victor Ruiz 26 said:

My question comes because i want to implement a system where the central receives advertisements from the peripheral and when i press a button in the central, for example, it sends an advertisement to which the peripheral would respond, all this without connecting the devices. I mean, all communication is using advertisements, I one case undirected (from peripheral to central) and in the other case (when button pressed, from central to peripheral), directed to that peripheral

Is there a reason you don't want to make it connection-based? The setup you describe means that the devices will need to operate in both a GAP Observer role and a GAP Broadcaster role. It is not going to be very efficient in terms of power usage.

[Victor Ruiz 26]

Hi, 

At the moment we are trying to squeeze advertising mechanism and adv/scanner activation/deactivation  in order to modify the communication and sleep intervals.

In short: A central will send advertisements with a proprietary and known packet structure (for example, requesting a param value o other thing). Then, the peripherarl (that is in rx mode) receives the advertiser, parses the inside adv data fields and, in this case, it will response with the value, by changing to tx when rx cicle ends and sending the corresponding value inside an advertising.

When tx is done, the peripheral will return to rx mode (or sleep mode, is yet to be defined).

[Vidar Berg]

I understand the setup you're describing, where the devices will alternate between the observer and advertising roles, but I'm not clear on the motivation for this. Getting good synchronization between the scanner and advertiser is made difficult by the fact that the Bluetooth stack appends a random 1-10 ms delay before every advertising event. In other words, the advertiser does not broadcast at fixed intervals.

[Victor Ruiz 26]

Right now, we are working on an architecture where there is a central coordinator that communicates in a directional way to around 10 to 30 sensor devices. And we need long range BLE. That is why we are exploring point to point communication between coordinator (central) and sensor (peripherals).