Advertising init as nonconnectable but still shows as connectable?

RE: Advertising init as nonconnectable but still shows as connectable?

AllenS — Wed, 02 Mar 2022 17:49:29 GMT

Thank you for the information. All of it is working very well right now.

RE: Advertising init as nonconnectable but still shows as connectable?

Vidar Berg — Wed, 02 Mar 2022 11:30:55 GMT

Good to hear that it works now. Note that the 32 KHz crystal will give you a slightly lower average current if you have the option to choose.

[quote user="AllenS"]1. Is the internal DCDC regulator enabled by default?[/quote]

We use the LDO by default, but you can call sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE ) after ble_stack_init() to enable it. However, before you enabling it, please make sure you have the DCDC inductors included in your design:

Otherwise, you may risk bricking the device.

2. Idle and system ON is the same in this context. I.e. the device enters System ON when you call the idle function from your main loop.

[quote user="AllenS"]Does the profiler take into consideration the other passives on the board that allow the micro to function?[/quote]

Yes, the power profiler data is based on actual measurements.

3. sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_ADV , 0, <tx power>).

RE: Advertising init as nonconnectable but still shows as connectable?

AllenS — Tue, 01 Mar 2022 23:45:26 GMT

Adding static as you suggested fixed the beacon data issue. I found the NRF_SDH_CLOCK_LF_SRC symbol and changed it as you suggested and verified operation still worked after disabling the 32KHz crystal. So now, I am back on track again. So I have a few more questions if you do not mind.

1. Is the internal DCDC regulator enabled by default?

2. When I ran the online power profiler and plugged in the variables for my application, I liked the result that it came back with. Does the profiler take into consideration not really going into sleep (System On) but rather Idle as in the case of the beacon app example? Does the profiler take into consideration the other passives on the board that allow the micro to function?

3. Can you point me where I need to go to adjust the TX Power output of the beacon?

RE: Advertising init as nonconnectable but still shows as connectable?

Vidar Berg — Fri, 25 Feb 2022 09:11:59 GMT

I don't see why initializing the m_enc_advdata buffers would make any difference. Anyway, I see now that I had not placed the manuf_specific_data variable in static memory. So the p_manuf_specific_data ends up pointing to a stack variable.

Please try to define this variable as 'static' and see if fixes the problem:

 static ble_advdata_manuf_data_t manuf_specific_data;

[quote userid="111673" url="~/f/nordic-q-a/85044/advertising-init-as-nonconnectable-but-still-shows-as-connectable/354888#354888"]Would it not be better to take care of all the housekeeping in one event rather than multiple events firing asynchronously?[/quote]

In theory yes, but I doubt it will make a noticeable difference in practice. The time it takes to wake up to service an interrupt is only a few micro seconds. What's more important is how often you decide to read the voltage. It does not make sense to sample a battery voltage every 5 seconds if the battery is expected to last for several months.

[quote userid="111673" url="~/f/nordic-q-a/85044/advertising-init-as-nonconnectable-but-still-shows-as-connectable/354888#354888"]As for the 32KHz source, where do I go check to see if the external crystal is enabled or does it just default to the internal 32KHz source by default?[/quote]

You can see which clock source the Softdevice the will be configured with from the NRF_SDH_CLOCK_LF_SRC symbol in sdk_config.h. Our SDK BLE examples have the LF crystal selected by default.

RE: Advertising init as nonconnectable but still shows as connectable?

AllenS — Fri, 25 Feb 2022 00:51:16 GMT

UPDATE: I started investigating what could have caused a difference between the advertising_init and the subsequent update routine. The only thing I could come up with had to do with initializing both encode buffers in the advertising_init routine. That did take care of the ERROR 12 issue. However, when you go look at the nRF Connect app to see the beacon data, something somewhere is becoming corrupted and not pointing to the correct data. Below is the code snippet for the advertising_init:

 uint32_t      err_code;

 NRF_LOG_INFO("advertising_init");

// ble_advdata_t advdata;  // moved to a global position

 // flags must be this for beacon to work properly
 uint8_t       flags = BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED;

 // Changing to this flag causes an ERROR 7 to occur if m_adv_params.duration = 0
 //   Even if you change the duration to 5 you still see nothing on nRF Connect App
 //uint8_t       flags = BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE;

 ble_advdata_manuf_data_t manuf_specific_data;

 manuf_specific_data.company_identifier = APP_COMPANY_IDENTIFIER;

 manuf_specific_data.data.p_data = (uint8_t *) m_beacon_info;
 manuf_specific_data.data.size   = APP_BEACON_INFO_LENGTH;

 // Build and set advertising data.
 memset(&advdata, 0, sizeof(advdata));

 advdata.name_type             = BLE_ADVDATA_NO_NAME;
// advdata.name_type             = BLE_ADVDATA_FULL_NAME;
 advdata.flags                 = flags;
 advdata.p_manuf_specific_data = &manuf_specific_data;

 // Initialize advertising parameters (used when starting advertising).
 memset(&m_adv_params, 0, sizeof(m_adv_params));

 m_adv_params.properties.type = BLE_GAP_ADV_TYPE_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED;
 m_adv_params.p_peer_addr     = NULL;    // Undirected advertisement.
 m_adv_params.filter_policy   = BLE_GAP_ADV_FP_ANY;
 m_adv_params.interval        = NON_CONNECTABLE_ADV_INTERVAL;
 m_adv_params.duration        = 0;  // Never time out.  Must be zero for beacon to work properly

 m_adv_data.adv_data.p_data = &m_enc_advdata[1][0];

 NRF_LOG_INFO("adv_init enc buf 1");

 err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len); 
 APP_ERROR_CHECK(err_code);

 NRF_LOG_HEXDUMP_INFO(m_adv_data.adv_data.p_data, m_adv_data.adv_data.len);

 NRF_LOG_INFO("adv_init enc buf 0");

 m_adv_data.adv_data.p_data = &m_enc_advdata[0][0];

 err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
 APP_ERROR_CHECK(err_code);

 NRF_LOG_HEXDUMP_INFO(m_adv_data.adv_data.p_data, m_adv_data.adv_data.len);

 err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data, &m_adv_params);
 APP_ERROR_CHECK(err_code);

Below is the updated code for the update routine:

   uint32_t err_code;
   uint8_t loc_index = BATT_VAL_OFFSET_IN_BEACON_INFO;

   NRF_LOG_INFO("Adv data update started.");

   /* This is an [in][out] variable used by the encode function */
   m_adv_data.adv_data.len = BLE_GAP_ADV_SET_DATA_SIZE_MAX;

   m_beacon_info[loc_index] = app_Batt_PCnt; // Batt percent value

   /* Swap adv data buffer - from API doc: "In order to update advertising
      data while advertising,new advertising buffers must be provided" */

   if (f_enc_idx & 1)
     {
      m_adv_data.adv_data.p_data = &m_enc_advdata[0][0];
     }
   else
     {
      m_adv_data.adv_data.p_data = &m_enc_advdata[1][0];
     }

   ++f_enc_idx;

   /* Go encode the updated beacon data for the buffer that was selected */
   err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
   APP_ERROR_CHECK(err_code);

//   NRF_LOG_HEXDUMP_INFO(m_adv_data.adv_data.p_data, m_adv_data.adv_data.len);

   err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data, NULL);
   APP_ERROR_CHECK(err_code);

   NRF_LOG_INFO("Advertising payload updated.");

This is what I see when I capture on the debug terminal:

<info> app_timer: RTC: initialized.

<info> app: advertising_init

<info> app: adv_init enc buf 1

<info> app:  02 01 04 1A FF 59 00 02|.....Y..

<info> app:  15 01 12 23 34 45 56 67|...#4EVg

<info> app:  78 89 9A AB BC CD DE EF|x.......

<info> app:  F0 00 00 80 C3 50      |.....P  

<info> app: adv_init enc buf 0

<info> app:  02 01 04 1A FF 59 00 02|.....Y..

<info> app:  15 01 12 23 34 45 56 67|...#4EVg

<info> app:  78 89 9A AB BC CD DE EF|x.......

<info> app:  F0 00 00 80 C3 50      |.....P  

<info> app: Beacon example started.

<info> app: advertising_start

04:04:12.910: <info> app: Adv data update started.

<info> app: Advertising payload updated.

04:04:17.976: <info> app: Adv data update started.

<info> app: Advertising payload updated.

04:04:22.901: <info> app: Adv data update started.

<info> app: Advertising payload updated.

04:04:27.961: <info> app: Adv data update started.

<info> app: Advertising payload updated.

04:04:32.990: <info> app: Adv data update started.

<info> app: Advertising payload updated.

On the nRF Connect app the raw data I see is:

0x02010403FF0000

If I back out the update routine, everything seems to work fine with no updates. Any ideas?

RE: Advertising init as nonconnectable but still shows as connectable?

AllenS — Thu, 24 Feb 2022 22:52:50 GMT

I implemented the async timed advertise update function and have run into two issues.

1. On the first update attempt the nRF Log dumps out and ERROR 12

<info> app_timer: RTC: initialized.

<info> app: advertising_init

<info> app: Beacon example started.

<info> app: advertising_start

<info> app: Adv data update started.

<error> app: ERROR 12 [NRF_ERROR_DATA_SIZE]

on this line of code:

err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);

The only things that changed were the one uint8_t data in the beacon that represents the battery percentage and further in the code which encode buffer to point to when the encode function is called. Below is the code from the handler:

   uint32_t err_code;
   uint8_t loc_index = BATT_VAL_OFFSET_IN_BEACON_INFO;

   NRF_LOG_INFO("Adv data update started.");

   /* This is an [in][out] variable used by the encode function */
   m_adv_data.adv_data.len = BLE_GAP_ADV_SET_DATA_SIZE_MAX;

   m_beacon_info[loc_index] = app_Batt_PCnt; // Batt percent value

   /* Swap adv data buffer - from API doc: "In order to update advertising
      data while advertising,new advertising buffers must be provided" */

   if (f_enc_idx & 1)
     {
      m_adv_data.adv_data.p_data = &m_enc_advdata[0][0];
     }
   else
     {
      m_adv_data.adv_data.p_data = &m_enc_advdata[1][0];
     }

   ++f_enc_idx;

   /* Go encode the updated beacon data for the buffer that was selected */
   err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
   APP_ERROR_CHECK(err_code);

   err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data, NULL);
   APP_ERROR_CHECK(err_code);

   NRF_LOG_INFO("Advertising payload updated.");

The advertising_init code initializes the structures and calls the same encode function and does not seem to have a problem with the data sizes. See the code snippet below:

// ble_advdata_t advdata;  // moved to a global position

 // flags must be this for beacon to work properly
 uint8_t       flags = BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED;

 // Changing to this flag causes an ERROR 7 to occur if m_adv_params.duration = 0
 //   Even if you change the duration to 5 you still see nothing on nRF Connect App
 //uint8_t       flags = BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE;

 ble_advdata_manuf_data_t manuf_specific_data;

 manuf_specific_data.company_identifier = APP_COMPANY_IDENTIFIER;

 manuf_specific_data.data.p_data = (uint8_t *) m_beacon_info;
 manuf_specific_data.data.size   = APP_BEACON_INFO_LENGTH;

 // Build and set advertising data.
 memset(&advdata, 0, sizeof(advdata));

 advdata.name_type             = BLE_ADVDATA_NO_NAME;
// advdata.name_type             = BLE_ADVDATA_FULL_NAME;
 advdata.flags                 = flags;
 advdata.p_manuf_specific_data = &manuf_specific_data;

 // Initialize advertising parameters (used when starting advertising).
 memset(&m_adv_params, 0, sizeof(m_adv_params));

 m_adv_params.properties.type = BLE_GAP_ADV_TYPE_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED;
 m_adv_params.p_peer_addr     = NULL;    // Undirected advertisement.
 m_adv_params.filter_policy   = BLE_GAP_ADV_FP_ANY;
 m_adv_params.interval        = NON_CONNECTABLE_ADV_INTERVAL;
 m_adv_params.duration        = 0;  // Never time out.  Must be zero for beacon to work properly

 err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
 APP_ERROR_CHECK(err_code);

 err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data, &m_adv_params);
 APP_ERROR_CHECK(err_code);

2. When trying to actually debug the code I run into this error:

<info> app_timer: RTC: initialized.

<info> app: advertising_init

<info> app: Beacon example started.

<info> app: advertising_start

<info> app: Adv data update started.

<error> app: SOFTDEVICE: ASSERTION FAILED

It just so happens inside of the advertising update function on line:

err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);

Any ideas on how to get past both these issues?

RE: Advertising init as nonconnectable but still shows as connectable?

AllenS — Thu, 24 Feb 2022 20:15:31 GMT

It is not important to have the data updated exactly before the advertisement event. It just needs to be updated at some point in time. My thoughts were if I am going to be active then be active for all things before going back to idle for a long period of time. Otherwise, I may be active for the beacon advertise and then later become active for an A2D sample. Would it not be better to take care of all the housekeeping in one event rather than multiple events firing asynchronously?

As for the 32KHz source, where do I go check to see if the external crystal is enabled or does it just default to the internal 32KHz source by default?

RE: Advertising init as nonconnectable but still shows as connectable?

Vidar Berg — Thu, 24 Feb 2022 18:48:42 GMT

1. It uses the 32 KHz source. Unlike the 32 MHz, this clock is always active while the Softdevice is enabled, so it does not affect the power consumption.

2. The app_timer uses RTC1 which has a run current of only ~0.1 uA.

3. You could configure the app timer instance run in APP_TIMER_MODE_SINGLE_SHOT mode, then start it every time you get the nACTIVE signal from the Softdevice. But how important is it to have the data updated exactly before the advertisment event? Observers will not usually be able to receive all advertisement packets anyway.

RE: Advertising init as nonconnectable but still shows as connectable?

AllenS — Thu, 24 Feb 2022 18:18:20 GMT

I noticed in your advertise-battery-level-in-beacon-advertising-packet link above you provide an attachment zip example. I do see in that example you generate an asynchronous timer for updating the beacon data. That leads me to a few questions regarding this.

1. Is the async timer based on the 32 MHz crystal input or the 32 KHz clock?

2. Regardless of which clock source the async timer is running on, how can I determine through the online power profiler if additional current consumption is being used by this timer since it would be asynchronous?

3. How would you go about syncing to the advertisement start?

RE: Advertising init as nonconnectable but still shows as connectable?

Vidar Berg — Thu, 24 Feb 2022 09:06:56 GMT

I would expect there to be enough time to perform a single A2D reading and processing between the ACTIVE signal and the advertising start event. I think it mainly depends on how long time the A2D sampling takes as there isn't much CPU processing involved in updating the payload.

Otherwise, you will have to use a timer instance like in my example and try to synchronize it to the advertisement start.

RE: Advertising init as nonconnectable but still shows as connectable?

AllenS — Wed, 23 Feb 2022 23:02:38 GMT

I am finding out that using the beacon app example is providing me the closest solution to the project I am working on. As you stated before, the advertising.c is really for connectable advertising and working directly with the soft device is better for the non-connectable solution. So I have shelved the advertising.c for now and have been looking at the link you sent and have been experimenting with some of the things presented in there. I do think the Radio Notification Signals is a good approach to a pre-transmission event. Do you think there would be enough time to take a single A2D reading, process it, update a single byte in the advertising beacon data and then go into a Sleep/Idle mode for power conservation until the next time the advertising is set to occur?

RE: Advertising init as nonconnectable but still shows as connectable?

Vidar Berg — Wed, 23 Feb 2022 17:59:02 GMT

Sorry, I did not notice that you were using the advertising module and just assumed you were working directly with the Softdevice APIs like how it's done in the original beacon example. As you have noticed, the problem with the advertising module is expose any options to select non-connectable advertising.

I made a small demo showing how you can update the beacon data a while ago which I posted here: https://devzone.nordicsemi.com/f/nordic-q-a/78948/advertise-battery-level-in-beacon-advertising-packet/326766#326766. Is that something you can use? I used a timer interrupt to update the adv. payload in that example, but you can also use Radio Notification signals for the same if you want the update to be synchronized to the adv. events.

RE: Advertising init as nonconnectable but still shows as connectable?

AllenS — Wed, 23 Feb 2022 16:17:58 GMT

Hello Vidar,

I am able to do the same of what you are describing. However, that is not my issue. My issue is about using the ble_advertising_init function and not being able to create an advertising beacon that is non-connectable. After looking at the structures that are available using this function, I have noticed there is no ble_gap_adv_params_t structure that is being initialized that allows for the setting of properties.type = BLE_GAP_ADV_TYPE_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED;

The example of ble_beacon_app does allow for this property type to be set. Therefore, when the example is run you get an advertising beacon with the data that is specified in p_manuf_specific_data.

So, with that in mind, how would one go about updating a few bytes of the p_manuf_specific_data in the advertising beacon prior to the advertising beacon being transmitted? I have not found a way to specify an event handler to perform an update such as this in a non-connectable example.

RE: Advertising init as nonconnectable but still shows as connectable?

Vidar Berg — Wed, 23 Feb 2022 13:37:25 GMT

Hello,

I was able to reproduce the same when I did the following:

1. Flashed some FW that did connectable advertising

2. Started scanning in the nRF connect app and saw that the device was shown as connectable.

3. Re-programmed the board with the beacon example

4. Observed that the device was still displayed as connectable.

But the connect button disappeared after I pressed the "Refresh" button indicating that it's a caching issue, either in the app or in the Android BT stack. Does the same work for you?

Refresh button:

Best regards,

Vidar