You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Stephane D'Alu <sd...@sdalu.com> on 2016/06/02 12:25:33 UTC

BLE_GATT_CHR_F_NOTIFY and pinkey

I was trying to add a simple service with notification:

So I added to gatt_svr_svcs
     {
         /*** Service: Battery */
         .type = BLE_GATT_SVC_TYPE_PRIMARY,
         .uuid128 = BLE_UUID16(GATT_SVR_SVC_BATTERY),
         .characteristics = (struct ble_gatt_chr_def[]) { {
             .uuid128 = BLE_UUID16(GATT_SVR_CHR_BATTERY_LEVEL),
             .access_cb = gatt_svr_chr_access_battery,
             .flags = BLE_GATT_CHR_F_READ | BLE_GATT_CHR_F_NOTIFY,
         }, {
             0, /* No more characteristics in this service. */
         } },
     },

Adding the "| BLE_GATT_CHR_F_NOTIFY" result in an error when setting 
advertisement, which seems to be: pinkey missing.

105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6
111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0 
ocf=0x0 status=5

I'm using bleprph (0.9-dev) as template, which is already using 
BLE_GATT_CHR_F_NOTIFY for it's Alert service, and I haven't seen such 
pinkey requirement. Any idea on what is wrong?

Sincerly

-- 
Stephane D'Alu

Re: BLE_GATT_CHR_F_NOTIFY and pinkey

Posted by Christopher Collins <cc...@apache.org>.
On Thu, Jun 02, 2016 at 06:30:20PM +0200, Stephane D'Alu wrote:
> I also have some difficulties to size max_attrs and max_services.
> 
> Can I propose c)  Having a web-page for nimble stack 
> configuration/tuning, and a set of macro that describe the formula used 
> to compute the various configuration parameters according to the number 
> of services/characteristics/notifications-indications/....

I think that's a great idea.

Thanks,
Chris

Re: BLE_GATT_CHR_F_NOTIFY and pinkey

Posted by Stephane D'Alu <sd...@sdalu.com>.
On 06/02/2016 05:53 PM, Christopher Collins wrote:
> On Thu, Jun 02, 2016 at 02:25:33PM +0200, Stephane D'Alu wrote:
>> Adding the "| BLE_GATT_CHR_F_NOTIFY" result in an error when setting
>> advertisement, which seems to be: pinkey missing.
>>
>> 105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6
>> 111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0
>> ocf=0x0 status=5
>>
>> I'm using bleprph (0.9-dev) as template, which is already using
>> BLE_GATT_CHR_F_NOTIFY for it's Alert service, and I haven't seen such
>> pinkey requirement. Any idea on what is wrong?
>
> Hi Stephane,
>
> Unfortunately, it appears you are the victim of a few red herrings :).
> I will attempt to explain what is going on below.  First, the solution
> is to increase the max_client_configs setting by at least two, e.g.,
>
>      cfg.max_client_configs = 8;
>
> I believe this change will make the problem go away.

Bingo!

> > [...]
>
> Finally, your email sparked a few thoughts.  These are just some musings
> that need some more thought, but it will help me to write them down, so
> I hope you'll humor me and allow me to do so :).
>
> 1. We need better diagnostics.  It would be great if a message was
> printed to the debug log indicating exactly what failed when you
> attempted to advertise.
>
> 2. It is too difficult to get all the configuration settings correct.
> I'm wondering if we should have the application pass its service table
> to ble_hs_init().  That way, the correct values for max_services,
> max_attrs, and max_client_configs can all be derived from the table.
> One complication here is that the application is currently allowed to
> register its services in several steps (multiple calls to
> ble_gatts_register_svcs(), each time passing a different table).  I
> suppose the options are to either a) remove support for multistage
> registration, or b) maintain the current configuration behavior, and
> make the new service table method optional.
>

I also have some difficulties to size max_attrs and max_services.

Can I propose c)  Having a web-page for nimble stack 
configuration/tuning, and a set of macro that describe the formula used 
to compute the various configuration parameters according to the number 
of services/characteristics/notifications-indications/....


Thanks

-- 
Stephane D'Alu

Re: BLE_GATT_CHR_F_NOTIFY and pinkey

Posted by Wayne Keenan <wa...@gmail.com>.
Hi,


>
> 2. It is too difficult to get all the configuration settings correct.
> I'm wondering if we should have the application pass its service table
> to ble_hs_init().  That way, the correct values for max_services,
> max_attrs, and max_client_configs can all be derived from the table.
> One complication here is that the application is currently allowed to
> register its services in several steps (multiple calls to
> ble_gatts_register_svcs(), each time passing a different table).  I
> suppose the options are to either a) remove support for multistage
> registration, or b) maintain the current configuration behavior, and
> make the new service table method optional.
>
>
Please don't remove the multistage registration feature, it's very useful
for dynamically creating services from a scripting language.

Thanks
Wayne

Re: BLE_GATT_CHR_F_NOTIFY and pinkey

Posted by Christopher Collins <cc...@apache.org>.
On Thu, Jun 02, 2016 at 02:25:33PM +0200, Stephane D'Alu wrote:
> Adding the "| BLE_GATT_CHR_F_NOTIFY" result in an error when setting 
> advertisement, which seems to be: pinkey missing.
> 
> 105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6
> 111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0 
> ocf=0x0 status=5
> 
> I'm using bleprph (0.9-dev) as template, which is already using 
> BLE_GATT_CHR_F_NOTIFY for it's Alert service, and I haven't seen such 
> pinkey requirement. Any idea on what is wrong?

Hi Stephane,

Unfortunately, it appears you are the victim of a few red herrings :).
I will attempt to explain what is going on below.  First, the solution
is to increase the max_client_configs setting by at least two, e.g.,

    cfg.max_client_configs = 8;

I believe this change will make the problem go away.

As for the cause of the errors:

> 105:[ts=102480ssb, mod=64 level=3] error enabling advertisement; rc=6

The nimble host uses its own set of error codes, separate from the HCI
error codes.  Your confusion is understandable, as we haven't documented
the host error codes anywhere!  This is something we'll need to get on
right away.  The host error codes are defined in
net/nimble/host/include/host/ble_hs.h.  An error code of 6 indicates
memory exhaustion.  In this case, the host did not pre-allocate enough
client characteistic configuration descriptors (CCCDs) for a single
connection, so it prevented the application from performing a
connectable advertisement.

You need to increase max_client_configs by 2 (rather than 1) because the
host maintains a cache of CCCDs that aren't tied to any connection.  The
formula is:

    subscribable-charactericteristics * (max-connections + 1)

Where "subscribable-characteristics" is the number of characteristics
supporting notifications or indications.

The other error:

> 111:[ts=108336ssb, mod=4 level=0] Command Complete: cmd_pkts=1 ogf=0x0 ocf=0x0 status=5

This is caused by a bug in the hci debug output code.  The event being
logged here is the no-op that the controller sends on startup.  The
no-op is the only event which does not have a status field.  The debug
code assumes all events have statuses, and it prints a bogus value here.
This should be an easy fix, and I'll look at it shortly.

Finally, your email sparked a few thoughts.  These are just some musings
that need some more thought, but it will help me to write them down, so
I hope you'll humor me and allow me to do so :).

1. We need better diagnostics.  It would be great if a message was
printed to the debug log indicating exactly what failed when you
attempted to advertise.

2. It is too difficult to get all the configuration settings correct.
I'm wondering if we should have the application pass its service table
to ble_hs_init().  That way, the correct values for max_services,
max_attrs, and max_client_configs can all be derived from the table.
One complication here is that the application is currently allowed to
register its services in several steps (multiple calls to
ble_gatts_register_svcs(), each time passing a different table).  I
suppose the options are to either a) remove support for multistage
registration, or b) maintain the current configuration behavior, and
make the new service table method optional.

Thanks,
Chris