OSTC over BLE experiences and questions

[Jan Mulder]

On 05-07-17 20:01, Jan Mulder wrote:
> On 05-07-17 18:23, Linus Torvalds wrote:
>> On Wed, Jul 5, 2017 at 8:57 AM, Matthias Heinrichs
>> <matthias.heinrichs at heinrichsweikamp.com> wrote:
>>>
>>> Theoretically, this should happen through the flow control lines from 
>>> the
>>> Bluetooth Chipset to our applications processor. When using BLE (Due 
>>> to the
>>> much lower end-to-end baud rate), the flow control already is very 
>>> active
>>> and controlling the bytes from the OSTC to the Bluetooth chipset. When
>>> looking at the snoop file, it shouldn't hurt to reset this credit 
>>> counter
>>> from time to time to 255. Or try a higher number like 65536? 
>>> Specification
>>> says 255 but have you tried higher values?
>>
>> It says it's only a single byte, so 255 is the max..
>>
>>                   Linus
>>
> 
> I made some progress by sending new credits, but it seems a bit more 
> complex that just sending a new 255 credits from time to time, but I'm 
> sure it going to work. I already had about 800 packets incoming during 
> my testing, but things seems very fragile. So too much WIP to push 
> anything out.
> 
> This all said, I really appreciate that you (Matthias and Linus) give 
> input to this subject.

Time for an update (finally). Good news this time. I just successfully 
downloaded 118 dives from my OSTC3 over BLE. 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.

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.
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).
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).

--jan