OSTC over BLE experiences and questions

Jan Mulder jlmulder at xs4all.nl
Tue Jul 11 06:44:44 PDT 2017


On 11-07-17 15:24, Dirk Hohndel wrote:

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

Yes, very good. Despite me changing it, I also do not fully understand 
why the code was as it was.

> 
>> 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?

In my testing I have not seen any cases of 32 being not enough. So, yes, 
comfortable with it. The 118 dives where a serious stress test.

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

It is coming from the Telit code samples :-) I just copied it, tested it 
with this value, and it just works.

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

Indeed. The step to OSTC was a pretty difficult one, with that weird 
credit thing, 4 characteristics to deal with, and a different parser 
concept than the "one-packet is fine" types as before.

And in the meantime, I tried Android, with Qt 5.9.1 but no success yet. 
Cannot open device (BLE that is, BT just works).

--jan



More information about the subsurface mailing list