diff options
author | Jan Mulder <jlmulder@xs4all.nl> | 2017-07-04 09:03:30 +0200 |
---|---|---|
committer | Dirk Hohndel <dirk@hohndel.org> | 2017-07-04 23:46:07 +0900 |
commit | 709c1df2af4b871c5f38c2eb432ea00a8c449922 (patch) | |
tree | 5d89c0ef49fe919c6e07a2f24c179358c0e6701b /core/qt-ble.h | |
parent | d6b17fef08a6597582c4ea980ed3c7fcba410e43 (diff) | |
download | subsurface-709c1df2af4b871c5f38c2eb432ea00a8c449922.tar.gz |
BLE: read until no more data in coming in
The current BLE read reads just one 20 bype packet. That packet size is set
in ble_serial_ops, so, without being able to test on anything other than
a OSTC3, I assume that this holds for other BLE DCs too. So, I think is
is weird that those interfaces work with the current read() of just one
packet at the time.
As we need a blocking read (at least for the OSTC parser), just read all
data that is available on the input. And when we think we are done, give
the QtEventloop control to see if there is more, and process that incoming
data as well. All this basically implements a blocking read.
CAVEAT 1: This might break the reading from the currently working BLE devices.
CAVEAT 2: With this, I still cannot read the OSTC3 completely. For
developers familiar with the HW transfer protocol: it just stops while
reading the first full dive (header + profile) command 0x66, despite
correctly reading about 5Kb of data before. For some
reason, I do not believe that this is related to this commit.
CAVEAT 3: All above tested on Linux Desktop with bluez stack, and
confirmed NOT to work on Android 7.1.2, build with Qt 5.9.0, And
yes, I know 5.9.1 recommended.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Diffstat (limited to 'core/qt-ble.h')
0 files changed, 0 insertions, 0 deletions