OSTC over BLE experiences and questions

[Dirk Hohndel]

On Tue, Jul 11, 2017 at 02:02:23PM +0200, Jan Mulder wrote:
> 
> Time for an update (finally). Good news this time. I just successfully
> downloaded 118 dives from my OSTC3 over BLE.

Excellent.

> To be complete in my
> description, this download ended in a libdivecomputer parsing failure on
> dive 119, but at this point in time, I do not expect this to be a BLE
> related thing. Simply downloading a couple of new dives, just works without
> error at the end.

So both Linus and I have seen this happen when downloading a larger number
of dives, occasionally you get a failure. Maybe the BLE error correction
isn't as good as one would hope? Don't know. Kinda frustrating. But then
again, the main use case should always be "download the last few dives
that I did" which is more likely to succeed.

> I did the following to the Subsurface code (functionally, code details can
> be read from the commits I'm going to produce).
> 1) I undid the the aggressive "read until there is no more data coming" in
> the BLEObject::read(). Not only because it breaks non-OSTC usage, but simply
> because it is wrong.

Agreed :-)

> 2) As suggested by Anton, I implemented a more friendly read one level
> above. ble_serial_read() now reads not only one packet, but reads up to the
> requested size parameter. For example, the OSTC libdc parser code reads from
> individual bytes, up to 1K blocks for the larger data parts (profile data).
> I cannot test this adapted behavior of the serial ble read for other that
> OSTC, but I have good hopes that this will work for any serial over BLE
> libdb interface (assuming that these call this function with the proper size
> parameter).

I asked Linus to take a look at that commit, given that he understands
that code much better than I do.

> 3) Implemented "credit management". Despite a simple concept, and seemingly
> good documentation in the earlier mentioned TIO document, it is a tricky
> process. Asking for to much or to little credit will stall the download at
> some point, tripping a timeout. I spend (too) much time understanding why my
> download stopped in a deterministic way after correctly downloading 14 dives
> (and almost 13K 20-byte BLE packets).

That is an interesting concept... especially since it takes a bit for the
credits to be recorded. Are you comfortable that 32 is a reasonable lower
threshold? Would it be more reliable (with slightly more overhead) if we
moved that to 40? Or 64?

Not advocating to do this, just trying to understand how you picked 32.

Thanks for all the work on that. I keep hoping that with every flavor of
BLE that we add we will cover more of the "typical" cases and that the
next one to add will become easier.

I know that there's the Aeris 300CS (aka shaving mirror) that does BLE.
I'm sure that there already are more and that even more will be coming out
over the next year or two.

/D