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 in time, the client may receive a mashup of two or more different values, if access_cb returns a current value each time. For example, a 32-byte value might end up as 22 bytes from sample 0 plus 10 bytes from sample 1 -- a combination that does not decode to a valid reading. One way around this is to lock in a stable sample for each connection, but that becomes harder to keep track of with many concurrent connections.
I don't really have a solution yet, just complaining ;) Perhaps nimble holding on to the value for subsequent offset reads makes sense after all. I guess the difficulty there is knowing when to free it? Cheers, simon On Tue, Jul 25, 2017 at 12:19 PM, Andrzej Kaczmarek < [email protected]> wrote: > Hi, > > > On Tue, Jul 25, 2017 at 8:14 PM, Christopher Collins <[email protected]> > wrote: > > > On Tue, Jul 25, 2017 at 10:46:32AM -0700, Pritish Gandhi wrote: > > [...] > > > [...] > > > > > Is this true for notifications too? If I need to send notifications for > > > that long characteristic value, will my access callback be called > several > > > times based on the MTU of the connection? > > > > Unfortunately, Bluetooth restricts notifications to a single packet. If > > the characteristic value is longer than the MTU allows, the notification > > gets truncated. To get around this, the application needs to chunk the > > value into several notifications, and possibly use some protocol which > > indicates the total length, parts remaining, etc. > > > > Also client can just do long read in order to read remaining portion of > characteristic value > > - this is what ATT spec suggests. > It depends on actual use case, but this way client may be able to decide > whether it should read remaining portion of value or skip it, e.g. some > flags can be placed at the beginning of the characteristic value and they > will be always sent in notification. > > Best regards, > Andrzej >
