OSTC over BLE experiences and questions

[Matthias Heinrichs]

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