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
  • Regarding advertising reports while connecting: as I understand it, during the connection process there is first a scan phase, whose time depends on the peripheral, to find a suitable peripheral and then a connection phase which is quite short. During this scanning phase you cannot see the received advertising packets - at least I do not see them. Once connected I can turn on the scanning process and see advertising packets again. Perhaps I'm doing something wrong? The reason I do not like this design is that the peripheral and RF determine the performance of the central. I have gotten around this by setting a bunch of timers to make sure a misbehaving peripheral does not deny service to other peripherals, but I can only scan around 2/3 of the time, the remaining 1/3 of the time is devoted to initiating connections.

Reply
  • Regarding advertising reports while connecting: as I understand it, during the connection process there is first a scan phase, whose time depends on the peripheral, to find a suitable peripheral and then a connection phase which is quite short. During this scanning phase you cannot see the received advertising packets - at least I do not see them. Once connected I can turn on the scanning process and see advertising packets again. Perhaps I'm doing something wrong? The reason I do not like this design is that the peripheral and RF determine the performance of the central. I have gotten around this by setting a bunch of timers to make sure a misbehaving peripheral does not deny service to other peripherals, but I can only scan around 2/3 of the time, the remaining 1/3 of the time is devoted to initiating connections.

Children
No Data
Related