Infinite, slow adversiting?

[Emil]

I am trying to make my NRF 51 advertise forever till someone connects. I have based myself on the ble_uart example where it uses fast advertising with 40 ms intervals for 180 seconds.

Now, I changed to slow advertising with 2000 ms intervals, but BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED (0) seems to have no effect. Then it simply doesn't advertise.

And what kind of advertising would be the most low power one? What is the max interval I can advertise on etc? And I guess you have to advertise in order to even connect to it? Is what I am doing a good practice at all? Or are most cases based on the fact that you have to push reset / reactivate advertisement before connecting?

Thanks :-)

Code:

  uint32_t      err_code;
   ble_advdata_t advdata;
   ble_advdata_t scanrsp;

   // Build advertising data struct to pass into @ref ble_advertising_init.
   memset(&advdata, 0, sizeof(advdata));
   advdata.name_type          = BLE_ADVDATA_FULL_NAME;
   advdata.include_appearance = false;
   advdata.flags              = BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE;
  
   memset(&scanrsp, 0, sizeof(scanrsp));
   scanrsp.uuids_complete.uuid_cnt = sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]);
   scanrsp.uuids_complete.p_uuids  = m_adv_uuids;
  
   ble_adv_modes_config_t options = {0};
   /*options.ble_adv_fast_enabled  = BLE_ADV_FAST_ENABLED;
   options.ble_adv_fast_interval = APP_ADV_INTERVAL;
   options.ble_adv_fast_timeout  = APP_ADV_TIMEOUT_IN_SECONDS;*/
        
  options.ble_adv_slow_enabled = BLE_ADV_SLOW_ENABLED;
  options.ble_adv_slow_interval = 3200;
  options.ble_adv_slow_timeout = BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED;
  
   err_code = ble_advertising_init(&advdata, &scanrsp, &options, on_adv_evt, NULL);
   APP_ERROR_CHECK(err_code);

[MartinBL]

Hi! There was a discussion about this topic yesterday with some great suggestions.

[Emil]

Cool That answered my first part of the question!

About restarting advertising in the handler? Yeah if BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED is not really doing what it claims to do (out from the name).

So, to the 2nd point, I guess disabling fast, and enabling slow, setting it to 2000 ms intervals would lower the power consumption a lot right? And is it a good practice doing this from a temp sensor that would last as long as possible sending data to a PC or a central having an USB dongle?

Thanks!

Also, is this a good practice in general to have something like a temp sensor doing this?

[RK]

I'll say one more time (then I'll shut up about it )

if (m_adv_modes_config.ble_adv_fast_interval == 0 || m_adv_modes_config.ble_adv_fast_timeout == 0)
     m_adv_modes_config.ble_adv_fast_enabled = false;

.. and the same for slow advertising too.

I get if the interval is zero then the mode should be disabled. I don't understand why setting the advertising timeout to zero should disable the mode when 0 is BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED.

I will now shut up about this

[Emil]

Also here it doesn't use the const, but rather a literal '0'. I guess BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED is wrongly named...

[RK]

No the constant is correct - it's what you put in the ble_gap_adv_params_t structure you pass to advertising start, zero means forever and it's documented there somewhere. The wrapper library just copies whatever is in the fast_timeout or slow_timeout to the structure when it starts advertising so you'd expect that constant to work the same way with the library. However zero is disallowed and turns advertising off completely for that mode.