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