OSTC over BLE experiences and questions

Jan Mulder jlmulder at xs4all.nl
Tue Jul 4 10:04:15 PDT 2017


On 04-07-17 18:51, Matthias Heinrichs wrote:
> Am 04.07.2017 um 17:47 schrieb Matthias Heinrichs:
>> Then the first depth sample: 0xcf:0x46:0x00 -> 18127mbar depth (+0x00
>> additional bytes)??!
> 
> Ok, I should better have looked in our documentation before sending the 
> last mail. Sorry for that.
> 
> The first bytes in your log are the "small header" as documented: 
> :cf:46:00 (Profile length in bytes)
> :02 (Sampling rate)
> :07 (Amount of  divisors)
> :00:02:06
> :01:02:06
> :02:01:0c
> :03:09:02
> :04:0f:0c
> :05:02:0c
> :06:00:00 (7 divisors with ppO2 data)
> 
> First real samples:
> :91:01:00 -> 401mbar depth
> :dc:01:09:00:00:00:00:00:00:00:00:00 -> 476mbar depth + (empty) Sensor data
> :12:02:00 -> 530mbar depth
> :44:02:09:00:00:00:00:00:00:00:00:00 -> 580mbar depth + (empty) Sensor data
> :63:02:00 -> 611mbar depth
> 
> and so on. All fine sample data. It basically stops transmitting in 
> packet #395 for no known reason.
> 
> Regards,
> Matthias
> 

Ok, thanks for this update. Reading PIC assembler is not my biggest 
skill :-) What I can add to my use case ... even the communication 
stops, the "download mode enabled" stays on on the OSTC3. And my desktop 
shows that it is still connected. Only when I actively disconnect from 
the desktop, the OSTC3 reports "exit" and returns to the surface mode 
screen. This all might imply that the working of the OSTC3 is fully 
correct, and the issue is in the other (desktop BT controller etc.) end. 
However, as I said in my first post. Really nothing special to see on 
the desktop logs/kernel logs etc.

--jan


More information about the subsurface mailing list