This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How do I make suggestions for improvement to the softdevice stack?

I have some improvement I would like to see in the stack. How can I get these implemented. Improvements include:

  1. Allow advertisement reporting events during connect scanning. Currently when a connect is in progress advertising packets are received and processed by the stack but they do not generate reports. There should be a option to enable such reporting.

  2. Non-connectable advertising packets are limited to 100ms (<10Hz in practice). Remove this limitation as it adds nothing to the abilities of the stack.

  3. Dynamic advertising cannot be implemented well in the current stack because the stack does not have a "transmitted advertising packet" callback (which seems like it would be trivial to add) and because of the 100ms limit above. When scanning, connecting and advertising at the same time there appears to be no way to determine that an advertising packet was sent so that a new one can be loaded.

  4. The 100ms limit also means that if you want to cycle through even 2 packets your net rate is 5Hz, if you have 10 packet the net rate would be 1Hz. There should be a way to instantly send advertising packet so that the "transmitted advertising packet" callback can send dynamic packets.

Parents
  • I do agree with point 4 in connection with point number 2: it's currently very hard to implement "multiple" advertisers on Nordic BLE stacks, even if you accept limitation of equal adv. intervals it leads to multiplying of 20ms (for connectable) or 100ms (for non-connectable) interval as lower limit which can be a problem for some applications. Also once there is another radio "role" active (= connection) then radio_notification events are not useful any more and application needs to use separate timers to juggle with adv. data to emulate multiple advertisers...

Reply
  • I do agree with point 4 in connection with point number 2: it's currently very hard to implement "multiple" advertisers on Nordic BLE stacks, even if you accept limitation of equal adv. intervals it leads to multiplying of 20ms (for connectable) or 100ms (for non-connectable) interval as lower limit which can be a problem for some applications. Also once there is another radio "role" active (= connection) then radio_notification events are not useful any more and application needs to use separate timers to juggle with adv. data to emulate multiple advertisers...

Children
No Data
Related