Hi Kevin, On Fri, Jul 15, 2016 at 04:50:14PM +0200, Kevin Townsend wrote: > My apologies if I'm missing something in the documentation, but putting > an example together here we are almost done with a barebones app > implementing Nordic's UART service to reuse the apps we've published for > iOS, Android, OS X, Python, etc., which use Nordic UART as an easy > lowest common denominator. > > We had a couple questions though:
These are both very good questions. Even if the functionality were supported, it could just be documented poorly, so asking on the list is always helpful for Mynewt! > 1. How would we subscribe to CCCD changes on the peripheral side? You're right - this is completely missing! This was in a list of changes that were needed for the host API, but somehow it slipped through the cracks. I will take a look at this today, but I imagine this would be naturally implemented via a GATT access callback. > The use case here is to know when the Central enables or disables the > notify/indicate bits (or really any changes) in the CCCD since we > probably want to keep sensor(s) powered off until they are actually > needed, i.e. when the Central starts subscribing to data from them. This > is an important power consideration in my opinion and the CCCD changes > to be easy to capture. Is this handled internally (which I would propose > reconsidering if true), or can the CCCD updates be easily captured? It is handled entirely internally at the moment, but I agree that the application needs to know when a peer changes a CCCD value. > 2. How is a failed 'indicate' message handled? > > Indicate generates an ACK, but are there any examples or documentation > around how to properly check for the response message to know if the > message arrived? This is currently hidden from the application. If any GATT procedure times out, the host terminates the connection. So, if the connection stays up, that implies the indicate acknowledgement has been received. The above explanation is a bit too weasely for my liking :). I think it would be good for the host to explicitly notify the application when an indicate response is received. Again, I think the right place for this to happen is in a GATT access callback. > Again, sorry if this is clearly documented or obvious in an example, but > I didn't spot anything looking around. I can read a characteristic > descriptor, but I think we we really need is a callback rather than > having to poll ... which may already be possible, though??? Not directly related to your question, but I don't think polling would work because each peer gets its own copy of the CCCD set. The host will report a read error if you attempt a local read of a CCCD. Thanks for asking about this; it is very helpful. I will try to implement both of these missing features today, and I'll send a message to the dev list indicating the API changes. In the meantime, if you (or anyone) have any thoughts on how the API should look, please feel free to chime in! Chris
