Hi Chris,
None of the example apps configure the scan response data (we should
change this). It is relatively simple to configure response data: call
ble_gap_adv_rsp_set_fields()
(http://mynewt.apache.org/develop/network/ble/ble_hs/ble_gap/functions/ble_gap_adv_rsp_set_fields/).
This function is more or less identical to ble_gap_adv_set_fields(),
except it configures response data rather than advertising data.
That was easy then, thanks. Sorry for missing something obvious now that
I see it. :(
PS: One other note with reference to the design guidelines from Apple:
many Apple devices are very specific about the timing requirements
(Section 3.5, 3.6, etc.) and devices that don't respect the limits may
not appear even if they are within the core specification limits. It
might be worth adding a section to the documentation on controlling the
key timing values (advertising interval, connection interval, etc.).
We're just looking into some of the details now that we have a basic app
running with DIS and Nordic UART, and I'm happy to contribute some
documentation in markdown as we track these details down, but it might
be worth considering having something easy to use in the core API to
control the various timing values in one central location.
Is there a particular API change that you are thinking of? You're right
about there being are a lot of timing settings, and anything that makes
the API simpler would be an improvement.
We'll finish this quick demo app and I'll let you know if there are any
specific suggestions, or we can push out a pull request if something
makes a lot of sense and other people on the dev list can review it an
comment.
I think having a really minimal nimble example with the following would
help people, though, but perhaps it's something we can contribute since
it's basically what we're working on locally:
- Match Apple's Bluetooth Low Energy timing restrictions (20ms
connection interval, etc.)
- Local Name and TX Power in the Scan Response (as per Apple's suggestion)
- Device Information Service (Strong recommended by Apple, but generally
just useful for tracking firmware revisions in mobile apps, etc.)
- Simple service example using notify or indicate (Nordic's BLE UART is
a good and useful example that's easy to understand)
That's probably going to be the baseline requirement of any real world
app in my opinion, and following Apple's recommendations works fine on
Android devices as well (where you have a small minimum connection
interval).
K.
