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

_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Reply via email to