Hi Jan,
Am 04.07.2017 um 14:02 schrieb Jan Mulder:
So, far so good. All this data is correctly received and processed on
the Subsurface/libdc side.
- 0x66: send one dive including profile, for index 0x86
This results in correct reception of the header (256 bytes), followed by
some samples (in total 624 bytes) so a very small fraction of the
selected approx 1 hour dive, that results in approx 20kb).
And then is just stops, until a timeout is hit. No bluez errors (testing
this on Arch Linux, with bluez BT stack), no weird packets in the
snooped BT traffic (file available for analysis if needed), noting
relevant in the journal/systemd logging, no kernel messages).
So it seems that the OSTC3 just stops sending. So my question for
Matthias ... any idea what is going on here?
Do you get the ending 0x4D Byte as the last byte? Then it's possible
that the dive isn't stored correctly ("Internal pointer to the begin of
the profile data" and "Internal pointer to the end of the profile data"
are not correct). The OSTC uses the Bluetooth modules hardware handshake
lines to avoid overfilling the internal buffer but that does not skip
any bytes. I can't see a way that the OSTC just stops sending data
without being stuck completely (Timeout can only happen in the Bluetooth
idle loop) afterwards.
Please email me the raw data and I'll have a look here.
Regards,
Matthias
--
heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany
Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau
Geschäftsführer: Matthias Heinrichs, Christian Weikamp
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
