Oceanlog Dive Details Pressure Readings Incorrect?

[msanderson]

Hi all,

I'm running Oceanlog 2.2.3 built 09.09.08 and I'm diving with a VT3

I just noticed that the pressures in the Pressure Reading column of the Dive Details are incorrect. The start pressure and the end pressure on the Dive page are correct (I have read some reports that this didn't work for others, but seems to work for me). In my case, the end of the dive I had 1700 psi, but the dive details page says I ended the dive with 456 psi. I just checked the tank with my analog guage to confirm that the end pressure shown on the VT3 was correct ... it is.

I've been following the discussion about the evolution of Oceanlog, and I also experience many of the "gotchas" that are in the current code. Is this another to add to the list of defects? Or is there something I might be doing wrong?

Cheers,
Mike

P.S. As another person who develops s/w for a living, please add another vote for open sourcing Oceanlog. Even if this is against the policy of the company, another solution would be to have some of us volunteers execute NDAs and then give us access to the source code repository so we can help out the development.

 

[DiveMaven]

It's so frustrating that all the "bugs" aren't always the same for everyone. I haven't had any problem with the pressures being incorrect, but my Oceanlog keeps defaulting my last logged dive to some random dive site. Doesn't matter how many times I correct it, it still reads wrong. <sigh> I can't help but think it has something to do with VISTA since it isn't happening on my older computer that runs XP, but we'll see when I get my new travel computer and download the dives again.

 

[AndyDragon]

Mike, the reason for the pressure being off during the dive details but final pressure is correct is simple, but hard to fix.

The VT3 (and all the other Pelagic PDCs) store samples during the dive as one of two sample types.

The first type is a "tank switch" sample which records the pressure of the tank when that tank is first in use. This is a full pressure reading. It also records nitrox type and a few other details like which transmitter is in use.

The second type is a "dive data" sample which records the delta pressure from the last sample. This is not a full pressure reading but the change. It also records lots of dive information like temp, PO2, etc.

This works very well IF and ONLY IF the tank switch sample is taken when the link to the transmitter is NOT lost. If the link IS lost during the tank switch, the VT3 tries to "guess" and then deltas are run after that. The problem is, if the recorded value is wrong, all the samples will be wrong.

Why is it recorded this way? The delta pressure takes less room in the sample than the full reading. This means a dive data sample can record more information than the tank switch sample. In fact, the tank switch sample records mostly information about the new tank whereas the dive data sample records delta pressure, delta temp, PO2, delta, etc.

At the end of the dive, the VT3 records the final pressure for the final tank used. That's why the end pressure is correct.

So, how to fix? In my download library, I try the tank switch sample. If the link is not lost, I use it as normal. If the link IS lost however, I walk through all the samples to the end and try to work backwards. This works pretty well IF and only IF there is no other tank switch samples between the one lost and the end. Remember that the VT3 (and some of the other computers like the Elite T3) allow 3 transmitters and you can switch between them. If there IS a tank switch, you just need to accept the wrong value.

I too noticed this in OceanLog (that it doesn't seem to try to walk back from the end pressure) and just accepts a pressure which is not accurate since the link was lost when it was recorded.

Hopefully the new work that PPS is doing on the "next" version of OceanLog/ACI will also incorporate the walk-backward-attempt. Currently, there is nothing that can be done in OceanLog (and ACI) because it's closed source.

 

[AndyDragon]

PS, this is one reason why my dive log software which I am working on stores the raw downloaded data for the dive along with the parsed data. This way, if and when a bug is discovered and can be fixed, the original data can be reparsed and the parsed data updated (if not changed by hand). This is a manual operation but I use UI markers to show that a newer parser is available than the version used to parse before. It takes a bit more space, but it's a binary BLOB, so it's not really that big a deal.

 

[msanderson]

Andrew,

Thanks for the reply. I *think* that I understand what you are saying. On my dive, scanning the Dive Details there are no occurrences of the computer and the transmitter being "unlinked" (every samples says linked), and I don't recall any Link Lost alarms in the last few dives. BTW I use 2 second collection intervals.

Do you know how the readings are sent? I wonder if a low battery on the transmitter could cause any issues? I've probably got 100+ dives on the transmitter. Is there any kind of Forward Error Correction or Checksum for the data to make sure it is coming across the link okay? .

I can appreciate the desire to save memory, particularly on an small footprint device like the VT3. That being said, I'd say it might make sense to add some features: First, if the computer and the transmitter ever lose link, then the system should note that it is in "dead reconning" or "extrapolation" mode. When (if) the connection between the computer and the tranmistter recovers, them the system ought to take some the full reading again. I'd even go so far as to have thew system periodically say every 30 samples take a full reading. I'd make this configurable via the Oceanlog software so that the divers could select the intervals to "reset" ...

I certianly wouldn't expect them to open the source of the computer itself ... just too much IP there. So we'll have to wait for the engineers to address this issue.

Cheers,
Mike

 

[msanderson]

PS, this is one reason why my dive log software which I am working on stores the raw downloaded data for the dive along with the parsed data. This way, if and when a bug is discovered and can be fixed, the original data can be reparsed and the parsed data updated (if not changed by hand). This is a manual operation but I use UI markers to show that a newer parser is available than the version used to parse before. It takes a bit more space, but it's a binary BLOB, so it's not really that big a deal.

Just saw this item, haw are you approaching the new code? Are you reverse engineering the dive computer <-> host protocol? Or are you going to extract info after Oceanlog has downloaded it from the computer? I wonder how many people are also working on their own log software? I've been considering it ... maybe it would be good to pool our resources?

Cheers,
Mike

 

[AndyDragon]

There are a group of us working on this problem from different angles (on different target platforms - I am working on the .NET/Mono version, TnT and BPerry are working on a C++ version). Basically, we are watching the communication between OceanLog and the interface using a COM port monitor (portmon). Once we see how the communication is handled, we set up utilities to download all the memory from the PDC. From there it was using knowledge of other computers to figure out the memory layout. The problem with this, is it's mostly trail and error (for example, to find how the settings are stored, each of us wrote a simulator and using com0com we watch what OceanLog sends to us and matching changes in the UI to changes in the output). Having published standards would definitely improve our accuracy.

If you are interested in helping out, I'll send you a PM with the link to the portal site I have set up with information, some computer dumps, access to the SVN repository for the code and the discussion forums.

 

[Cleavitt]

... On my dive, scanning the Dive Details there are no occurrences of the computer and the transmitter being "unlinked" (every samples says linked), and I don't recall any Link Lost alarms in the last few dives. BTW I use 2 second collection intervals.

Change the polling interval back to 15 seconds and this issue will go away. I reported the same thing several months ago after encountering the same issue. My dives didn't show link-lost either and I wasn't switching tanks during those dives, but I suspect it has someting to do with what AndyDragon was explaining. Since the computer records the pressure change rather than the actual PSI value, it is possible that it is doing some rounding (or math error) on the stored value. With a 15 second interval the rounding would not add up to a significant difference, but with a 2 second polling interval it is possible that a rounding issue would add up and cause quite a descrepancy. This is just a guess because I don't have time to reverse engineer some bad programmers code (I already do that all day at work). I do know that setting the polling back to 15 seconds resolved the issue.

AndyDragon, if you are interested in seeing an example of this issue take a look at dives 23 - 25 in the log I emailed you a while back.

 

[AndyDragon]

I remember looking into this. If you look in the Access DB, the first sample is a tank-switch (first sample always is) and the link was lost. OceanLog doesn't show tank-switch samples so link-lost tank-switch samples are not listed. In fact, your dump is the reason I worked on this issue because on one dive, by the end you had -400psi...

Mike, if you are interested in pursuing this, I can send you the downloader application and dump the computer's memory and we can take a look at the samples individually and see if this is the issue.

 

[msanderson]

Andy,

Sure ... I'd like to pursue. I'm in Europe at the moment on business, and staying here through the latter half of February so I won't be able to do the download right away ... but I'm sure i'll get some evening downtime to get familiar with the work done so far ...

Cheers,
Mike

Mike, if you are interested in pursuing this, I can send you the downloader application and dump the computer's memory and we can take a look at the samples individually and see if this is the issue.