Hi Simon,
On Thu, Mar 8, 2018 at 9:18 AM, Simon Ratner wrote:
> Old thread, but I just bumped into this myself so want to resurrect it.
>
> Current api makes it very difficult to implement a long characteristic that
> changes frequently (e.g. time- or sensor-based reading, or
Hi Simon,
On Thu, Mar 08, 2018 at 12:18:41AM -0800, Simon Ratner wrote:
> Old thread, but I just bumped into this myself so want to resurrect it.
>
> Current api makes it very difficult to implement a long characteristic that
> changes frequently (e.g. time- or sensor-based reading, or including
Old thread, but I just bumped into this myself so want to resurrect it.
Current api makes it very difficult to implement a long characteristic that
changes frequently (e.g. time- or sensor-based reading, or including a
random component). In the case where mtu exchange fails or does not
complete
On Tue, Jul 25, 2017 at 10:46:32AM -0700, Pritish Gandhi wrote:
[...]
> Ah I see! I was assuming a call to access_cb() on a read to completely read
> the value of a characteristic so I was using that to trigger an event which
> would change the value of that characteristic again. I guess that
>
Hi Pritish,
On Mon, Jul 24, 2017 at 04:25:30PM -0700, Pritish Gandhi wrote:
> Hi All,
> So I'm trying to understand who is responsible for handling chunking the
> characteristic value in case the MTU of the connection is smaller than the
> characters ic value size.
>
> So for example, if I have
Hi All,
So I'm trying to understand who is responsible for handling chunking the
characteristic value in case the MTU of the connection is smaller than the
characters ic value size.
So for example, if I have a characteristic value of size 100B. When an iOS
App connects to my device and reads the