Hello Kevin,
Thank you for going through this.
I agree with what Chris mentioned. When I wrote the newtmgr protocol(NMP) in
swift for Nordic’s Toolbox app, I had enabled this bit for the newtmgr
characteristic. The port is still WIP and hence the incompleteness. I have
spoken to Chris about
I think you're right about that - a CCCD should not be set to one unless
the peer writes to it. What I'm not so sure about is whether it is
prohibited to send a notification to an unsubscribed peer. I didn't see
any language in the spec indicating that this is illegal. The ability
to send
On Wed, Oct 05, 2016 at 05:07:00PM -0700, Mike Ryan wrote:
> On Thu, Oct 06, 2016 at 02:00:25AM +0200, Kevin Townsend wrote:
> > I remember some discussions previously about unsolicited notifies
> > and whether this was or wasn't supported in the BLE spec
>
> My reading of the spec suggests that
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
On Thu, Oct 06, 2016 at 02:00:25AM +0200, Kevin Townsend wrote:
> I remember some discussions previously about unsolicited notifies
> and whether this was or wasn't supported in the BLE spec
My reading of the spec suggests that it is not legal. Referring to
Client Characteristic Configuration on
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
