Accessing Dive Info on the UEMIS SDA

[dirkhh]

Wow, it seems like a heck of alot of progress has been made. Thanks so much to the folks that have put the time and effort into this. I ran the script (Mac) and it seems to have worked ok, except it got hung on Dive 9 and the Uemis hung in Sync mode. I broke out of the script and unplugged/replugged in the Uemis and was able to finish transferring the dives. Here is the archive of dives 1-10. I can get 11-20 if you decide you need them.


View attachment 99174

BTW: the uemis.xml file numbers were off by one - so dive2.xml corresponds to dive1.uemis.xml in your zip file.

Making this adjustment the latest version of my parser appears to create identical copies of the XML files from the UEMIS website (with the known exception of the date_time field).

Thanks again for sending these!

 

[Kussi]

Are you SURE that you have the matching uemis.xml file? The reason I'm asking is that the files don't correspond at all.

Looking at the files I'm thinking that you may have packaged the wrong *.uemis.xml files...

The dive number and object id that are used by the SDA and by our tools is the one that's in diveNN.SDA - in your case
<val key="object_id">
<int>30</int>
</val>

Strangely, the object_id and dive number in the corresponding divelog file is one bigger than that, so it should read
<val key="object_id">
<int>31</int>
</val>

So the same should hold true in the xml files:
dive30.uemis.xml: <dive_no label="Dive Number" nativetype="int">143</dive_no>
divelog30.uemis.xml: <dive_number>30</dive_number>

Can you see the problem? Given the SDA files that you sent me I would expect to see:
dive30.uemis.xml: <dive_no label="Dive Number" nativetype="int">30</dive_no>
divelog30.uemis.xml: <dive_number>31</dive_number>

Am I making sense? Can you try to find the correct two uemis.xml files?

Yes, I can see your point...
I deleted the whole folder I created a few hours ago and recreated one with the dives 30 & 31 only.

The numbering is still not the way you expected it would be. The reason behind it could be simple: When I started diving with the Uemis I decided to keep the numbering of my dives from my manual written logbook: so dive number 143 from the written logbook is my 30th dive with the UEMIS SDA, etc.

I hope it helps...

 

[BB1]

I also changed the number of the first dive in my SDA to follow the last number in my written dive log. Makes keeping up with number of dives easier. I also deleted the inbuilt example dive a long time ago as well.

Dirk would that explain the miss match in numbers that you found with the files I sent you?

The numbering is still not the way you expected it would be. The reason behind it could be simple: When I started diving with the Uemis I decided to keep the numbering of my dives from my manual written logbook: so dive number 143 from the written logbook is my 30th dive with the UEMIS SDA, etc.

 

[dirkhh]

Yes, I can see your point...
I deleted the whole folder I created a few hours ago and recreated one with the dives 30 & 31 only.

The numbering is still not the way you expected it would be. The reason behind it could be simple: When I started diving with the Uemis I decided to keep the numbering of my dives from my manual written logbook: so dive number 143 from the written logbook is my 30th dive with the UEMIS SDA, etc.

I hope it helps...

This helps quite a bit. In that now dive30 corresponds to the dive31 files from uemis.

dive_no appears to be the numbering in your logbook.
object_id appears to be the way to connect the different files.

Let me explain still a bit more.

dive30.SDA contains object_id 30 and dive_no 143
dive31.SDA contains object_id 31 and dive_no 144

as expected, the divelogNN.SDA files contain object_id values that are one higher:

divelog30.SDA contains object_id 31
divelog31.SDA contains object_id 32

Sadly, the divelog files don't contain the dive_no. So the only way to match the corresponding diveNN.SDA and divelogNN.SDA files is by knowing that the object_id field is just offset by 1.

(BTW: this has me quite worried because it is SO inexplicable... are we /really/ extracting the matching pairs from the SDA using myuemis.jar? But I digress)

To make things more complicated, the divelogNN.xml files contains neither a dive_no nor an object_id. It contains a dive_number - and that appears to match the object_id of the divelogNN.SDA file (i.e., the number that's one higher than the number in the diveNN.SDA file).

So for the files that you sent to me, the divelog31.uemis.xml appears to match dive30 - and if you diff the two divelog files you'll see that they cover the same dive (I still need to post my latest version of the parser to this forum - the one that you have still mis-parses quite a few elements; with the version I run it's really easy to see that these match).

So what have I learned so far? Matching the files seems to be a real mess.
And once we figure out which is which, we appear to be doing a very good job parsing the files.

 

[dirkhh]

I need help from those of you able to extract files from your uemis Zurich using myuemis.jar.

For all dives I can extract from my SDA, the date timestamps of the diveNN.SDA and divelogNN.SDA file match within a second or two.

Yet for almost all files that have been sent to me from other community members, the dates were significantly different, making me think that they may not come from the same dive. Or it could be that this is just a random anomaly on my SDA and these aren't supposed to match?

Could people take a look at that? Both files contain a section that looks like
<val key="date">
<ts>2011-04-26T08:35:43</ts>
</val>
(the diveNN.SDA file has another date in there with a val key="ctime" - that one you can ignore).

Even better, the diveYYY.xml files that you get from the uemis website also have that timestamp. There it is in a section that looks like
<date label="Date" nativetype="ts">
<![CDATA[2011-05-29T14:04:41]]>
</date>
As far as I can tell, these should match as well. For example, here's what I can extract from one of my dives:
dive11.SDA: 2011-06-05T13:03:34
divelog11.SDA: 2011-06-05T13:03:34
dive11.uemis.xml: 2011-06-05T13:03:34

Can people take a look and see if my data is just a coincidence (seems unlikely) and if not if they can figure out matching sets of .SDA and .xml files that they could send me for more investigation?

 

[Kussi]

Good morning
I just checked the dates of 7 different dives (attachment) and found out that the numbers match only for diveNN.SDA and diveNN.xml files in my case. The dates in the divelogNN.SDA are different...
But I noticed that the divelogNN.SDA files are just one second away from the diveNN.SDA file of the next dive... (did not check all dives)

View attachment Dive 32-38.zip

 

[dirkhh]

I have been working with nicklesshead on this. There may be an off by one error in myuemis.jar - especially if dives have been deleted from the SDA at any point.

Looking at the files that you included it's pretty obvious that you are suffering from that problem.

But if I take your dive33.SDA and divelog32.SDA and run my latest parser against those two files (renaming the dive33.SDA to dive32.SDA) then I get a perfect match for divelog32.uemis.xml.

I know this is frustrating for the rest of you to watch us figure these things out in real time, but the good news is that we are getting much closer to understanding all the problems. Right now we certainly are able to completely reproduce the divelogNNN.xml file - for the diveNNN.xml file we still need to extract and parse the additional databases from the device.

Good morning
I just checked the dates of 7 different dives (attachment) and found out that the numbers match only for diveNN.SDA and diveNN.xml files in my case. The dates in the divelogNN.SDA are different...
But I noticed that the divelogNN.SDA files are just one second away from the diveNN.SDA file of the next dive... (did not check all dives)

View attachment 99307

 

[Koni]

Hi dirkhh,
I also had a look into the issue. While extracting the data from my SDA, both the diveNN.SDA as well as the divelogNN.SDA are off by one.

I attached the files from my dive 553 with ID #148. The files are numbered as #147 when extracting from SDA with myuemis.jar, the object-ID on the uemis server is 71919. Further I attached the xml files downloaded from the uemis server after the sync.

Here an extract of the dive147.SDA, in there you'll find an object_id=147 and further down logfilenr=148. Maybe this gives you an idea what causes the problem.

<hash ref="dive" version="1.0">
<val key="computer_id">
<int>18877</int>
</val>
<val key="user_id">
<int>1</int>
</val>
<val key="object_id">
<int>147</int>
</val>
<val key="remote_object_id">
<int>71919</int>
</val>
<val key="sync_id">
<int>30742</int>
</val>
<val key="deleted">
<bool>false</bool>
</val>
<val key="ctime">
<ts>2011-07-20T17:54:14</ts>
</val>
<val key="dive_no">
<int>553</int>
</val>
<val key="logfilenr">
<int>148</int>
</val>
<val key="date">
<ts>2011-07-20T18:16:50</ts>
</val>​

 

[dirkhh]

Very interesting. Can you (using timestamps) find the matching divelogXXX.SDA file? What's the object_ID in there?

Hi dirkhh,
I also had a look into the issue. While extracting the data from my SDA, both the diveNN.SDA as well as the divelogNN.SDA are off by one.

I attached the files from my dive 553 with ID #148. The files are numbered as #147 when extracting from SDA with myuemis.jar, the object-ID on the uemis server is 71919. Further I attached the xml files downloaded from the uemis server after the sync.

Here an extract of the dive147.SDA, in there you'll find an object_id=147 and further down logfilenr=148. Maybe this gives you an idea what causes the problem.

<hash ref="dive" version="1.0">
<val key="computer_id">
<int>18877</int>
</val>
<val key="user_id">
<int>1</int>
</val>
<val key="object_id">
<int>147</int>
</val>
<val key="remote_object_id">
<int>71919</int>
</val>
<val key="sync_id">
<int>30742</int>
</val>
<val key="deleted">
<bool>false</bool>
</val>
<val key="ctime">
<ts>2011-07-20T17:54:14</ts>
</val>
<val key="dive_no">
<int>553</int>
</val>
<val key="logfilenr">
<int>148</int>
</val>
<val key="date">
<ts>2011-07-20T18:16:50</ts>
</val>​

 

[Koni]

Hi dirkhh,
on my computer, the coresponding diveXXX.SDA and divelogXXX.SDA get the same number, simply 1 too low.

I already included the corresponding divelog147.SDA file into the zip in my previous reply. Both files include the identical date and time 2011-07-20T18:16:50 and it is further corresponding with the date/time in the base64 data stream.

Strangely in divelog147.SDA the object_id now says 148. It looks like they made a real mess with their ID's.

<hash ref="divelog" version="1.0">
<val key="computer_id">
<int>18877</int>
</val>
<val key="object_id">
<int>148</int>
</val>
<val key="date">
<ts>2011-07-20T18:16:50</ts>
</val>
...


​