Also, would it make sense to have more consistent UUIDs, such as:
- 8D530001-1DB7-4CD3-868B-8A527460AA84
- 8D530002-1DB7-4CD3-868B-8A527460AA84
- 8D530003-1DB7-4CD3-868B-8A527460AA84 (potentially?)
We could perhaps even settle on a single base 128-bit UUID throughout
Mynewt, adjusting the 16 bit range at the start?
This is a minor detail and might be a nuisance to change, and more of a
cosmetic issue, but I figured it was worth tossing out there.
On 06/10/16 02:00, Kevin Townsend wrote:
I'm working with newtmgr over BLE based on the newtmgr lib in the
master branch of apache-mynewt-core, which currently has the following
structure:
Service UUID: 8D53DC1D-1DB7-4CD3-868B-8A527460AA84
Characteristic UUID: DA2E7828-FBCE-4E01-AE9E-261174997C48
The source code has this explanatory comment on the service:
> The "newtmgr" service consists of one write no-rsp characteristic for
> newtmgr requests: a single-byte characteristic that can only accepts
> write-without-response commands. The contents of each write command
> contains an NMP request. NMP responses are sent back in the form of
> unsolicited notifications from the same characteristic.
I remember some discussions previously about unsolicited notifies and
whether this was or wasn't supported in the BLE spec (I believe
between Carles Cufi from Nordic and I believe Will and/or Chris at
Runtime?), but given the uncertainty around this I wonder if it
wouldn't be better to adjust the newtmgr service definition to have
two characteristics similar to the way 'nus' (Nordic UART Service) works:
- One TXD or 'Request' characteristic to write commands to, which can
reuse the existing characteristic as-is
- A new RXD or 'Response' characteristic with notify enabled, which
would also allow you to send multiple data chunks since each packet
will cause a new notify event on the Central, making it relatively
easy to manage rebuilding packets.
I've been doing some initial tests with the netmgr service as is and
many apps don't seem to like the unsolicited notifications even if
they can be made to work. Two separate characteristics would probably
ensure everything is handled unambiguously on any platform, but I'm
curious to hear other people's thoughts?
Kevin
