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
  • Not arguing about potential benefits of all your suggestions, just reminder that point number 2 is because of BT 4.0/4.1 certification which forbids non-connectable advertisement intervals below 100ms and point number 3 is not true, there are radio_notification events which gives application callback before and after every radio packet transmission (so if you are only doing advertisement it will tell you exactly when packet goes out), however it's not useful for dynamic advertisement implementation (you cannot start/stop/modify adv. interval easily in radio_notification handler). I'm also surprised by point number 1, that would be rather bug then feature because if you run any scanner - not central connection, that's different story! - then you should always get all adv. events. Are you sure you enable additional scanner once your central establishes connection?

Reply
  • Not arguing about potential benefits of all your suggestions, just reminder that point number 2 is because of BT 4.0/4.1 certification which forbids non-connectable advertisement intervals below 100ms and point number 3 is not true, there are radio_notification events which gives application callback before and after every radio packet transmission (so if you are only doing advertisement it will tell you exactly when packet goes out), however it's not useful for dynamic advertisement implementation (you cannot start/stop/modify adv. interval easily in radio_notification handler). I'm also surprised by point number 1, that would be rather bug then feature because if you run any scanner - not central connection, that's different story! - then you should always get all adv. events. Are you sure you enable additional scanner once your central establishes connection?

Children
No Data
Related