No p02 for Petrel (Divecan)?

[Jef Driesen]

On 11-10-15 01:52, "Paul-Erik Törrönen" wrote:
> I noticed an oddity when downloading dives from a rEvo RMS Divecan Petrel,
> the dive data did not contain any pO2-data. This was with the latest daily
> build of Subsurface, 4.4-98-56 on Windows XP
>
> When I downloaded the same dives to Shearwater Desktop (SD), it did
> contain the actual pO2-data, so the dc has stored the data, and it is
> present (for all 3 O2-sensors) when I eg. export the data from SD to
> CVS-format.

Does it give you the ppO2 from the sensors as millibar or millivolt? As far as I 
know, the petrel stores the three raw sensor values only in millivolt. Since 
libdivecomputer only supports millibar at the moment, those values are not 
reported. If SD gives you millibar, then that means they are somehow capable to 
convert the millivolt value into millibar, or newer firmware versions store 
millibar values too.

The final voted value is stored as millibar, and is returned by libdivecomputer. 
So that should be there.

> I noticed another peculiarity. Subsurface recognized the dive as OC, when
> it should have been CCR. I guess the detection is done earlier, and I
> found from the maillist archives[1], that when the dive is presumed to be
> OC, no pO2-data is collected by libdivecomputer. Maybe there's an issue on
> how the OC/CCR-mode is detected?
>
> 1. http://libdivecomputer.org/pipermail/devel/2015-February/000697.html

That's a subsurface specific patch. But if the dive is indeed a CC dive than 
this shouldn't cause any difference. So maybe there is indeed something wrong 
with the OC/CC detection? I'll need to have a look at the raw dive data to check 
(see below).

> I had to return the rEvo today as it was borrowed, so I can not
> immediately verify anything, the unit however is not that far from here,
> so I may be able to do testing.
>
> Partially related to this: There are instructions on how to capture the
> traffic between the DC and log software, but this seems to only work in
> those cases where the DC talks over the serial. In my case the Petrel
> seems to have been accessed in a more direct manner (there was no
> COM-device) and portcom was quiet the whole time.

Correct, sniffing serial communication works only when using bluetooth serial 
emulation, but not with native bluetooth.

> Is there a recommended way to capture the transmissions from Bt-devices? I
> tested with sniffusb which seemed to capture something (since the Bt is
> apparently connected to the USB-port), but I'm not that sure I got the
> correct data?

There is no need to capture the communication because we only need to have a 
look at the raw dive data. The easiest way to get that is to download 
libdivecomputer's universal application here:

http://www.libdivecomputer.org/builds/

and run it with these options:

universal -v -l petrel.log -d petrel.xml -b petrel <serialport>

where you replace <serialport> with the correct serial port (e.g. COMx on 
Windows and /dev/ttysomething on Linux/Mac). Send me back the petrel.log and 
petrel.xml, along with all the dive_*.bin files.

(The builds on the libdivecomputer website are patched to output the raw dives 
as those dive_*.bin files.)

Jef