OSTC over BLE experiences and questions

[Jan Mulder]

Hi Matthias,

On 04-07-17 15:09, Matthias Heinrichs wrote:

> 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.
> 

BT snoop file (made with btmon) is attached. Wireshark is your friend :-)

And no, the last byte is not the end 0x4D byte. I did not check the 
internal pointers, but I did check the length of the profile data and 
that looks a correct value for this dive (if I remember correctly, 
almost 19000 bytes).

In addition, I interfaced this same dive correctly over classic BT, and 
on the OSTC3 itself it shows correctly, so the internal loglook seems 
just fine.

And also from me a huge thanks for the support you and the company are 
giving to Subsurface.

regards,

--jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: snoop.log
Type: text/x-log
Size: 22826 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170704/1412f753/attachment-0001.bin>