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