Re: BLE_GATT_CHR_F_NOTIFY and pinkey
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
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
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
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