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
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
