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.
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?
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.
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?
Poltsi
1. http://libdivecomputer.org/pipermail/devel/2015-February/000697.html
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
Does it give you the ppO2 from the sensors as millibar or millivolt?
Ah, you are correct. The exported CVS file contains the specific sensor reading in mV only. What caused my mistake was that the file also contained a pO2-number called 'Average PPO2' which is in bar. It may be that, as you say, this is a calculated number derived from the mV-readings.
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.
Hmm... but this would not work in my case, as there is apparently no COMx to listen to? As I wrote, the portmon was completely silent during the transfer, and it was configured to read all COMx ports.
(The builds on the libdivecomputer website are patched to output the raw dives as those dive_*.bin files.)
I'll have a go with this next time I get my laptop near one of the rEvos :-)
Poltsi
On 2015-10-11 19:35, Paul-Erik Törrönen wrote:
Does it give you the ppO2 from the sensors as millibar or millivolt?
Ah, you are correct. The exported CVS file contains the specific sensor reading in mV only. What caused my mistake was that the file also contained a pO2-number called 'Average PPO2' which is in bar. It may be that, as you say, this is a calculated number derived from the mV-readings.
Indeed. This average PPO2 is what libdivecomputer will report as the PPO2 value.
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.
Hmm... but this would not work in my case, as there is apparently no COMx to listen to? As I wrote, the portmon was completely silent during the transfer, and it was configured to read all COMx ports.
I think you misunderstood me. The universal tool is not a sniffer tool for capturing the communication between the shearwater desktop (SD) application and your petrel. It's a standalone application that will download the dives from your petrel. But unlike the SD application it does use serial communication. Hence the need to specify the serial port. Does that make it more clear?
(The builds on the libdivecomputer website are patched to output the raw dives as those dive_*.bin files.)
I'll have a go with this next time I get my laptop near one of the rEvos :-)
Great!
Jef
I think you misunderstood me. The universal tool is not a sniffer tool for capturing the communication between the shearwater desktop (SD) application and your petrel. It's a standalone application that will download the dives from your petrel.
This I understand, but...
But unlike the SD application it does use serial communication. Hence
the need to specify the serial
port. Does that make it more clear?
Yes, and hence it requires that the comX is actually present, no?
As I stated previously, there was no comX assigned to the Petrel when I used the SD to download, which led me to assume that the SD does it in some other way.
So to be clear, when I use the universal tool, I need to first configure the Petrel Bt-device to be a serial device, then use that comX-device to do a dump of the dives, yes?
I'll have a go with this next time I get my laptop near one of the rEvos :-)
Great!
Alas, I had a chance to do this just a moment ago, but with no result. I only had about 20 minutes, so what I did was trying the Subsurface (maybe I should really post this on Subsurface-maillist), checking the dump-option:
Latest Subsurface from git on Linux FC 22 with Dell-laptop: The Bt is found, paired, but when I hit download, the DC immediately switches out of the Bt-state with an error message (abrupt command or something therewith). No dump-file.
Latest Subsurface from git on Linux FC 22 with Dell-laptop: Instead of using the Bt-configuration in Subsurface, configure it separately with Blueman to use /dev/rfcomm0 -> Same result as above, no dump-file.
Subsurface 4.5 on Windows 7 with Dell-laptop: Same result as above, no dump-file.
Subsurface 4.4.93 on Windows XP with Compal 91. Ditto
If I used the SD on the Compal XP, then it downloaded everything without a hitch.
I will try to get one unit, or at least the Shearwater-handset borrowed for a full day, to get into this more thoroughly.
Poltsi
On 18 October, 2015 - "Paul-Erik Törrönen" wrote:
I think you misunderstood me. The universal tool is not a sniffer tool for capturing the communication between the shearwater desktop (SD) application and your petrel. It's a standalone application that will download the dives from your petrel.
This I understand, but...
But unlike the SD application it does use serial communication. Hence
the need to specify the serial
port. Does that make it more clear?
Yes, and hence it requires that the comX is actually present, no?
As I stated previously, there was no comX assigned to the Petrel when I used the SD to download, which led me to assume that the SD does it in some other way.
So to be clear, when I use the universal tool, I need to first configure the Petrel Bt-device to be a serial device, then use that comX-device to do a dump of the dives, yes?
I'll have a go with this next time I get my laptop near one of the rEvos :-)
Great!
Alas, I had a chance to do this just a moment ago, but with no result. I only had about 20 minutes, so what I did was trying the Subsurface (maybe I should really post this on Subsurface-maillist), checking the dump-option:
Latest Subsurface from git on Linux FC 22 with Dell-laptop: The Bt is found, paired, but when I hit download, the DC immediately switches out of the Bt-state with an error message (abrupt command or something therewith). No dump-file.
Latest Subsurface from git on Linux FC 22 with Dell-laptop: Instead of using the Bt-configuration in Subsurface, configure it separately with Blueman to use /dev/rfcomm0 -> Same result as above, no dump-file.
Subsurface 4.5 on Windows 7 with Dell-laptop: Same result as above, no dump-file.
Subsurface 4.4.93 on Windows XP with Compal 91. Ditto
If I used the SD on the Compal XP, then it downloaded everything without a hitch.
I will try to get one unit, or at least the Shearwater-handset borrowed for a full day, to get into this more thoroughly.
The magic trick is that you need to use the Predator protocol to talk with your DC. Over the older Predator protocol we can do memory dumps, which we can't do over the Petrel protocol.
//Anton
On 2015-10-18 20:10, Anton Lundin wrote:
On 18 October, 2015 - "Paul-Erik Törrönen" wrote:
I think you misunderstood me. The universal tool is not a sniffer tool for capturing the communication between the shearwater desktop (SD) application and your petrel. It's a standalone application that will download the dives from your petrel.
This I understand, but...
But unlike the SD application it does use serial communication. Hence
the need to specify the serial
port. Does that make it more clear?
Yes, and hence it requires that the comX is actually present, no?
As I stated previously, there was no comX assigned to the Petrel when I used the SD to download, which led me to assume that the SD does it in some other way.
So to be clear, when I use the universal tool, I need to first configure the Petrel Bt-device to be a serial device, then use that comX-device to do a dump of the dives, yes?
I'll have a go with this next time I get my laptop near one of the rEvos :-)
Great!
Alas, I had a chance to do this just a moment ago, but with no result. I only had about 20 minutes, so what I did was trying the Subsurface (maybe I should really post this on Subsurface-maillist), checking the dump-option:
Latest Subsurface from git on Linux FC 22 with Dell-laptop: The Bt is found, paired, but when I hit download, the DC immediately switches out of the Bt-state with an error message (abrupt command or something therewith). No dump-file.
Latest Subsurface from git on Linux FC 22 with Dell-laptop: Instead of using the Bt-configuration in Subsurface, configure it separately with Blueman to use /dev/rfcomm0 -> Same result as above, no dump-file.
Subsurface 4.5 on Windows 7 with Dell-laptop: Same result as above, no dump-file.
Subsurface 4.4.93 on Windows XP with Compal 91. Ditto
If I used the SD on the Compal XP, then it downloaded everything without a hitch.
I will try to get one unit, or at least the Shearwater-handset borrowed for a full day, to get into this more thoroughly.
The magic trick is that you need to use the Predator protocol to talk with your DC. Over the older Predator protocol we can do memory dumps, which we can't do over the Petrel protocol.
Depending on why you need the memory dump, this is not always a good idea. The legacy predator has some major drawbacks when used with a petrel: The predator protocol can only download a fraction of the petrel's memory (the last 128K out of 16M), so only the most recent dives can be downloaded. And for those dives you loose half of the info, because for each sample you get only the first 10 bytes instead of the full 20 bytes.
So in most cases, it will be more interesting to dump the individual dives, instead of downloading a memory dump with the predator protocol.
Jef
On 2015-10-18 17:43, Paul-Erik Törrönen wrote:
I think you misunderstood me. The universal tool is not a sniffer tool for capturing the communication between the shearwater desktop (SD) application and your petrel. It's a standalone application that will download the dives from your petrel.
This I understand, but...
But unlike the SD application it does use serial communication. Hence the need to specify the serial port. Does that make it more clear?
Yes, and hence it requires that the comX is actually present, no?
Indeed.
As I stated previously, there was no comX assigned to the Petrel when I used the SD to download, which led me to assume that the SD does it in some other way.
Correct. The SD application doesn't need a serial port because it's using the native bluetooth api, and not the serial emulation.
So to be clear, when I use the universal tool, I need to first configure the Petrel Bt-device to be a serial device, then use that comX-device to do a dump of the dives, yes?
Also correct.
I'll have a go with this next time I get my laptop near one of the rEvos :-)
Great!
Alas, I had a chance to do this just a moment ago, but with no result. I only had about 20 minutes, so what I did was trying the Subsurface (maybe I should really post this on Subsurface-maillist), checking the dump-option:
Latest Subsurface from git on Linux FC 22 with Dell-laptop: The Bt is found, paired, but when I hit download, the DC immediately switches out of the Bt-state with an error message (abrupt command or something therewith). No dump-file.
Latest Subsurface from git on Linux FC 22 with Dell-laptop: Instead of using the Bt-configuration in Subsurface, configure it separately with Blueman to use /dev/rfcomm0 -> Same result as above, no dump-file.
Subsurface 4.5 on Windows 7 with Dell-laptop: Same result as above, no dump-file.
Subsurface 4.4.93 on Windows XP with Compal 91. Ditto
If I used the SD on the Compal XP, then it downloaded everything without a hitch.
I will try to get one unit, or at least the Shearwater-handset borrowed for a full day, to get into this more thoroughly.
The petrel protocol doesn't support memory dumps. Libdivecomputer will immediately fail with DC_STATUS_UNSUPPORTED. That's why I asked to run the universal tool from the website: instead of trying to download a memory dump it will download the dives (just like a normal application would do), and then write each dive to a binary file. It's not exactly the same as a memory dump, but it's good enough for investigating the parser problem you reported.
Jef
On 11 October, 2015 - "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
That contained a subsurface-specific bug, that i fixed the other day: http://lists.subsurface-divelog.org/pipermail/subsurface/2015-October/022660...
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.
I'm actually looking at how to decode that data. I haven't really figured it out yet, but someday maybe.
//Anton
-
"Paul-Erik Törrönen" -
Anton Lundin -
Jef Driesen