Downloading dives from multiple devices: how to avoid creating extra dive numbers?

[Goose_66]

Hello everybody,

I am a new user of subsurface 4.5.5 (excellent software and thank you to all contributors) on a MAC OS X 10.10.5.

I did search for this issue but I could not find any information so Iwill describe it with details and maybe someone can point me to the right place to look. Apologies if this has bean dealt with before... 

I was using Mac Dive and I successfully exporte all my dives in XML and reimported in subsurface.

It worked great, it took less than a minute and imported everything (great job on the XML import).

I dive an OSTC 2n (dive computer) upgrading to OSTC 2 and an APD Inspiration rebreather with the new 2020 handset (unsupported).

I do inport dives from the OSTC directly and the Inspiration is imported through the APD Log viewer copy to clipboard paste in text wrangler save as .APD and the reimport, as per manual (I actually do RTFM).

Fatc is now I have 2 dive log entries for the same dive.

Same entry time, same duration and pretty much same profile (is hard to keep both hans at same depth all the times :-) )

Is there a way not to incrase the dive number by two when I load duplicate dives? I.e. is there a way to let subsurface know that those are the log from different logging devices for the same dive? when I do dive 1234 and load it both from the rebreather and the computer I don not want to have dive 1234 and dive 1235 created but just dive 1234 alpha and bravo ot whatever. I did try to manually change dive number but looks like is a no duplicate/unique field (numeric/integer).

Any pointers?

Thanks

Fabio

[Dirk Hohndel]

On May 2, 2016, at 2:19 PM, Goose_66 <regist...@sardone.org> wrote:

Hello everybody,

I am a new user of subsurface 4.5.5 (excellent software and thank you to all contributors) on a MAC OS X 10.10.5.

I did search for this issue but I could not find any information so Iwill describe it with details and maybe someone can point me to the right place to look. Apologies if this has bean dealt with before... 

I was using Mac Dive and I successfully exporte all my dives in XML and reimported in subsurface.

It worked great, it took less than a minute and imported everything (great job on the XML import).

I dive an OSTC 2n (dive computer) upgrading to OSTC 2 and an APD Inspiration rebreather with the new 2020 handset (unsupported).

I do inport dives from the OSTC directly and the Inspiration is imported through the APD Log viewer copy to clipboard paste in text wrangler save as .APD and the reimport, as per manual (I actually do RTFM).

Fatc is now I have 2 dive log entries for the same dive.

Ideally you shouldn't. Ideally the two dive computers should be combined into ONE dive with both divecomputers listed (and the ability to switch between the profiles).

Can you send a sample divelog (just a couple of dives) so we can figure out why that didn't work for you?

Same entry time, same duration and pretty much same profile (is hard to keep both hans at same depth all the times :-) )

I know - I usually have between two and six dive computers with me on every dive - it's often funny just how different the profiles are, and even worse, how different the "no deco time" calculations end up being.

Is there a way not to incrase the dive number by two when I load duplicate dives? I.e. is there a way to let subsurface know that those are the log from different logging devices for the same dive? when I do dive 1234 and load it both from the rebreather and the computer I don not want to have dive 1234 and dive 1235 created but just dive 1234 alpha and bravo ot whatever. I did try to manually change dive number but looks like is a no duplicate/unique field (numeric/integer).

As I said, by design these should be combined and therefore just occupy one number...

/D

[Goose_66]

On Tuesday, May 3, 2016 at 12:11:14 AM UTC+2, Dirk wrote:

Ideally you shouldn't. Ideally the two dive computers should be combined into ONE dive with both divecomputers listed (and the ability to switch between the profiles).

Now that I know the intended behaviour I can tell that Subsurface is importing dives based on file timestamps and therefore does not understand that those are the same dive. The .apd file does not contain any timestamp. The rebreather only uses seconds from start of dive and saves the time of dive in the file name which is:

serialnumber_date_time.ccl therefore that is the issue .... I believe. I did try to modify timestamp of file with the touch -t command but I was unsuccessful.

 

Can you send a sample divelog (just a couple of dives) so we can figure out why that didn't work for you?

attached! 

Same entry time, same duration and pretty much same profile (is hard to keep both hans at same depth all the times :-) )

I know - I usually have between two and six dive computers with me on every dive - it's often funny just how different the profiles are, and even worse, how different the "no deco time" calculations end up being.

Yes, making those checks would be great!

 

As I said, by design these should be combined and therefore just occupy one number...

Perfect intended behaviour! 

[Miika Turkia]

Can you also provide me original logs? However, if there is no
date/time stamps on the logs, there isn't much we can do. The time
that is used (if timestamps are not available on the logs) is the
import time (or possibly minus one hour or similar adjustment). I
don't think we look at the file time stamp, as generally that is not
the time when the dive started.

> --
> You received this message because you are subscribed to the Google Groups
> "Subsurface Divelog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to subsurface-dive...@googlegroups.com.
> To post to this group, send email to subsurfac...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/subsurface-divelog/70131fdb-8c35-4410-af0d-9f8d9168b1d0%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Robert C. Helling]

Am Dienstag, 3. Mai 2016 06:58:15 UTC+2 schrieb Miika Turkia:

 

 I
don't think we look at the file time stamp, as generally that is not
the time when the dive started.

I understood, date and time are encoded in the filename.

Robert 

[Goose_66]

On Tuesday, May 3, 2016 at 6:58:15 AM UTC+2, Miika Turkia wrote:

Can you also provide me original logs? However, if there is no 

I am attaching a .apd file.

These files are obtained according to subsurface manual:

opening the .ccl file (it is a bynary file format proprietary and undisclused) in APD Log Viewer (windown only application)

copying the data to clipboard 

pasting this data in textwrangler

saving the resulting text file with .apd extension

 

date/time stamps on the logs, there isn't much we can do. The time 
that is used (if timestamps are not available on the logs) is the 
import time (or possibly minus one hour or similar adjustment). 

The dive timestamp is in the filename (the .ccl filename) than can be used as .apd filename (as I did).

My suggestion (if I am allowed to make one ...;-) ) would be twofolds:

a) parse the apd filename (format is nncnnnnnn_yymmdd_hhmmss.apd) if it match this format use it.

b) change the import dialog to allow setting date and time for the dive (using the data obtained from above parsing or presetting it with file creation time with a warning of invalid dive date/time for user to adjust) 

for those wondering the nncnnnnnn initial part of the file name is the machine serial 2 digit for construction year, one letter for construction month 6 digit serial number.

One last thing, working with this issue I found out a bug in OSTC 2n which did non compute 2016 as leap year (so the initial import were one day off ahead) and I forgot t set daylight saving time (dives logged one hour earlier than real), this not withstanding the dives did not merge upon import when data il the log had been corrected before importing the APD file or after changing the APD imported dive to the same date/time of the pre-existing dive.

Cheers

Fabio

[Miika Turkia]

On Tue, May 3, 2016 at 6:10 PM, Goose_66 <regist...@sardone.org> wrote:
>
> On Tuesday, May 3, 2016 at 6:58:15 AM UTC+2, Miika Turkia wrote:
>>
>> Can you also provide me original logs? However, if there is no
>
>
> I am attaching a .apd file.
> These files are obtained according to subsurface manual:
> opening the .ccl file (it is a bynary file format proprietary and
> undisclused) in APD Log Viewer (windown only application)
> copying the data to clipboard
> pasting this data in textwrangler
> saving the resulting text file with .apd extension
>
>>
>> date/time stamps on the logs, there isn't much we can do. The time
>> that is used (if timestamps are not available on the logs) is the
>> import time (or possibly minus one hour or similar adjustment).
>
>
> The dive timestamp is in the filename (the .ccl filename) than can be used
> as .apd filename (as I did).
> My suggestion (if I am allowed to make one ...;-) ) would be twofolds:

Suggestions are always welcome, but we reserve the right not to
implement them any time soon (or ever), or to wait for patches from
the suggester :D

> a) parse the apd filename (format is nncnnnnnn_yymmdd_hhmmss.apd) if it
> match this format use it.

I just implemented this. The pattern matching is now quite strict and
requires the above format exactly with some leeway with the serial
number part.

> b) change the import dialog to allow setting date and time for the dive
> (using the data obtained from above parsing or presetting it with file
> creation time with a warning of invalid dive date/time for user to adjust)

This is not as easy as we support importing multiple files on a single
go and your suggestion does not work in this case. However, having a
similar dialog after the import as we have on download from DC might
make sense. Thus user could validate the information we got out, and
possibly even fix the dates/times at that phase. At least I think this
idea deserves some more thought. (Too bad, GUI coding is not among my
strengths.)

> for those wondering the nncnnnnnn initial part of the file name is the
> machine serial 2 digit for construction year, one letter for construction
> month 6 digit serial number.

I wonder if this should also be imported...A bit more code here and
there, but should not be too hard to add.

> One last thing, working with this issue I found out a bug in OSTC 2n which
> did non compute 2016 as leap year (so the initial import were one day off
> ahead) and I forgot t set daylight saving time (dives logged one hour
> earlier than real), this not withstanding the dives did not merge upon
> import when data il the log had been corrected before importing the APD file
> or after changing the APD imported dive to the same date/time of the
> pre-existing dive.

Luckily my OSTC Sport ran out of battery and I had to set the date and
time before dipping in a few weeks ago.

[Goose_66]

On Tuesday, May 3, 2016 at 7:03:38 PM UTC+2, Miika Turkia wrote:

On Tue, May 3, 2016 at 6:10 PM, Goose_66 <regist...@sardone.org> wrote: 
> 


Suggestions are always welcome, but we reserve the right not to 
implement them any time soon (or ever), or to wait for patches from 
the suggester :D 

.... go figure :-)

 

> a) parse the apd filename (format is nncnnnnnn_yymmdd_hhmmss.apd) if it 
> match this format use it. 

I just implemented this. The pattern matching is now quite strict and 
requires the above format exactly with some leeway with the serial 
number part. 

 

Thanks, but it did NOT work on my machine ;-) just yet!

 

> b) change the import dialog to allow setting date and time for the dive 
> (using the data obtained from above parsing or presetting it with file 
> creation time with a warning of invalid dive date/time for user to adjust) 

This is not as easy as we support importing multiple files on a single 
go and your suggestion does not work in this case. However, having a 
similar dialog after the import as we have on download from DC might 
make sense. Thus user could validate the information we got out, and 
possibly even fix the dates/times at that phase. At least I think this 
idea deserves some more thought. (Too bad, GUI coding is not among my 
strengths.) 

Understood. But again facing real user problems and floating ideas around contributes to sw and code maturity.

I might start looking into the source code just for fun ... I used to be a programmer at the time of Fortran IV (and motorola 6502) way before a GUI was invented, so I can say GUI coding is not my bread and butter.

 

> for those wondering the nncnnnnnn initial part of the file name is the 
> machine serial 2 digit for construction year, one letter for construction 
> month 6 digit serial number. 

I wonder if this should also be imported...A bit more code here and 
there, but should not be too hard to add. 

This could be nice but unless you start tracking the equipment itself I see little practical use. Do you track the serial numbers of dive computers?

 

Luckily my OSTC Sport ran out of battery and I had to set the date and 
time before dipping in a few weeks ago. 

Well my OSTC 2N committed suicide while updating it to 2.13 and HW was kind enough to offer a good deal on upgrade to OSTC 2.

So now I am playing with a new one and different firmware family.

Let me know if I can help testing changes, I'll be glad to help.

Cheers

Fabio

 

[Miika Turkia]

On Tue, May 3, 2016 at 8:51 PM, Goose_66 <regist...@sardone.org> wrote:
> On Tuesday, May 3, 2016 at 7:03:38 PM UTC+2, Miika Turkia wrote:
>>
>> On Tue, May 3, 2016 at 6:10 PM, Goose_66 <regist...@sardone.org> wrote:
>>
>> > a) parse the apd filename (format is nncnnnnnn_yymmdd_hhmmss.apd) if it
>> > match this format use it.
>>
>> I just implemented this. The pattern matching is now quite strict and
>> requires the above format exactly with some leeway with the serial
>> number part.
>>
>
> Thanks, but it did NOT work on my machine ;-) just yet!

Just making sure that you tested with version that should include the
patch? I tested in Linux and it worked, the regex used should also
match backslash as directory separator. I guess I'll have to find
Windows from somewhere to test this out..

>> > b) change the import dialog to allow setting date and time for the dive
>> > (using the data obtained from above parsing or presetting it with file
>> > creation time with a warning of invalid dive date/time for user to
>> > adjust)
>>
>> This is not as easy as we support importing multiple files on a single
>> go and your suggestion does not work in this case. However, having a
>> similar dialog after the import as we have on download from DC might
>> make sense. Thus user could validate the information we got out, and
>> possibly even fix the dates/times at that phase. At least I think this
>> idea deserves some more thought. (Too bad, GUI coding is not among my
>> strengths.)
>
>
> Understood. But again facing real user problems and floating ideas around
> contributes to sw and code maturity.

Absolutely. And we are getting somewhere with this discussion..just
need to attempt to implement this :D

> I might start looking into the source code just for fun ... I used to be a
> programmer at the time of Fortran IV (and motorola 6502) way before a GUI
> was invented, so I can say GUI coding is not my bread and butter.

Just go for it. Usually when I get some sort of GUI implemented,
someone else steps up and makes it prettier and functional..

>> > for those wondering the nncnnnnnn initial part of the file name is the
>> > machine serial 2 digit for construction year, one letter for
>> > construction
>> > month 6 digit serial number.
>>
>> I wonder if this should also be imported...A bit more code here and
>> there, but should not be too hard to add.
>
>
> This could be nice but unless you start tracking the equipment itself I see
> little practical use. Do you track the serial numbers of dive computers?

We do store the serial number and DC model internally to distinguish
between different dive computers. But this information is not that
clearly available for the end user. Serial number is only shown on a
dialog where you can give a nick name for the DCs.

[Goose_66]

On Wednesday, May 4, 2016 at 5:31:10 AM UTC+2, Miika Turkia wrote:

On Tue, May 3, 2016 at 8:51 PM, Goose_66 <regist...@sardone.org> wrote:

>
> Thanks, but it did NOT work on my machine ;-) just yet!

Just making sure that you tested with version that should include the
patch? I tested in Linux and it worked, the regex used should also
match backslash as directory separator. I guess I'll have to find
Windows from somewhere to test this out..

 Miika,

I was just pulling your leg, hoping the smirky smiley made it clear.

I am running latest distribution 4.5.6 on Mac OSX, did not download (and possibly compile) the latest changes from sw repository ....

So no need to worry :-) about findinf a windown machine.

I am travelling away from home so I cannot deal properly with this at the hotel ...

Cheers

Fabio

[Dirk Hohndel]

All the latest changes are available in Mac daily builds. I'm confused.

http://subsurface-divelog.org/downloads/daily/Subsurface-4.5.6-8-g6a6f824caa53.dmg

/D

[Goose_66]

Sorry Miika,

its my fault. I am away from home and I am not familiar with the dailybuilds (also when away from home where I have my backups) usually I do not install new software in order to avoid data loss while on the go.

I will be back home Friday night.

Cheers and thanks

Fabio

[Goose_66]

Hello Dirk,

I am done with work, tomorrow is just a travel day ... so I can spend a little time on this.

I managed to download a dailybuild with Miika patch/change (Subsurface-4.5.6-8-g6a6f824caa53.dmg) and it imports the dive with date/time set according to the file name (thanks Miika! very much apreciated).

Now I get some dives showing different profiles by selectin show previous/nex DC but also (out of 4 I have 2 issue dives) which show dive number 0 it is next to the twin dive but are not merged. How can I diagnose this issue?

What parameters subsurface uses to join the dives?

Thanks

Fabio

On Wednesday, May 4, 2016 at 4:24:22 PM UTC+2, Dirk wrote:

[Miika Turkia]

- Dive number
- Date
- Time
- Duration

The date, time and duration needs to match roughly, but dive number needs only to exist (and be numeric). So we do the matching to existing dives by trying to figure out if the dives are the same, originally matching dives imported from multiple dive computers, thus the criteria. You can also manually merge dives by right clicking on dive list.