SEAC Action support

[Peter Kisdaroczi]

Hi there,

Could you add support for the SEAC Action computers? I can send you a DB file, if you want. I has wired connection only, for now.

[James W.]

Hi Peter,

I actually just today wrote a Python script to export the Seac DB into CSV files. I joined the usergroup to try to figure out how I can help implement importing them, but here is the link if you want to try converting them yourself: https://github.com/jwobser/SeacDBConvert

[James W.]

And for the development team, I also have an example DB and the PRAGMA table_info() output from SQLite uploaded in the linked github project.

It looks like Suunto DM software already uses SQLite3? I'm still trying to find the source module which handles import, but if there is already an SQL parser it may not be too difficult to add the Seac Action.

[Robert C. Helling]

Am Montag, 13. Juli 2020 23:33:21 UTC+2 schrieb James W.:

And for the development team, I also have an example DB and the PRAGMA table_info() output from SQLite uploaded in the linked github project.

It looks like Suunto DM software already uses SQLite3? I'm still trying to find the source module which handles import, but if there is already an SQL parser it may not be too difficult to add the Seac Action.

Indeed, there are only two tables, on with dive meta data and one with samples. Have a look at 

https://github.com/subsurface/subsurface/blob/master/core/import-suunto.c

That one uses an sqlite database as well (but more complex). With that as an example, it should not be too hard to get something for SEAC to work (too bad I am currently super occupied with the day job).

Best

Robert 

[Miika Turkia]

Yep, we do have a couple of dive computers/log software imported from sqlite databases. Testing which log format is used is done in core/file.c and the actual imports are in files core/import-cobalt.c, core/import-divinglog.c, core/import-shearwater.c, core/import-suunto.c. If you James want to implement this, do not hesitate to ask if you need help with anything. Or just let me know, if you prefer me to write the importer.

miika

[James W.]

Hi Miika,

Thanks for the offer of help. I think I would like to give it a try. I probably won't have a ton of time to work on it until the weekend, however.

I was able to clone and build from source yesterday, now I'm trying to grok the import process.

Here's some rough psedocode of how I understand the process:

dive_start()
     // input dive information
settings_start()
dc_settings_start()
     // set up divecomputer struct
dc_settings_end()
settings_end()

// At this point the state struct should be all configured to accept samples and associate them with the correct dc stuct

char get_dive_data[] = "SELECT * from dive_data WHERE dive_id = ?"
sql_stmt = sqlite3_prepare_v2();

// bind parameter to SQL statement object to get only samples for current dive
sqlite3_bind_int(sql_stmt,1,(int)dc->dive_id)

int sqlresult = sqlite3_step();

while (sqlresult != SQLITE_DONE) {
     sample_start()
          // read SQL row from dive_data table
          sample_data = sqlite3_column_int(col_num);
          // process into subsurface format
          sample->pressure.mbar =  ... ;
     sample_end();

     // get next row
     sqlresult = sqlite3_step();
     if (sqlresult == SQLITE_ERROR) {
           fprintf(stderr , ....)
           break;
     }
}

[Miika Turkia]

Looks like a good start. (Of course, there will also be dive_end() after the samples are parsed.) I have used sqlite3_exec with a call-back function to handle each returned row, but writing the import without the convenience wrapper works just as well.

Take your time with the code, there are no dead-lines here :D

miika

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/6a15a434-e8c3-41ba-b40c-f4435cefa4a0o%40googlegroups.com.

[James W.]

I could not for the life of me get a branch to push to Github, so here's a pretty strong start in patch form.

Successfully pulls in depth and temperature profiles, (my flaky dive computer notwithstanding), along with the date and time and the notes entered in the SeacSync software.

On Thursday, July 16, 2020 at 11:38:40 AM UTC-4, Miika Turkia wrote:

Looks like a good start. (Of course, there will also be dive_end() after the samples are parsed.) I have used sqlite3_exec with a call-back function to handle each returned row, but writing the import without the convenience wrapper works just as well.

Take your time with the code, there are no dead-lines here :D

miika

To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsub...@googlegroups.com.

[Linus Torvalds]

On Thu, Jul 16, 2020 at 5:42 PM James W. <james....@gmail.com> wrote:
>
> I could not for the life of me get a branch to push to Github, so here's a pretty strong start in patch form.
> Successfully pulls in depth and temperature profiles, (my flaky dive computer notwithstanding), along with the date and time and the notes entered in the SeacSync software.

Are those spikes in the original too? Because that kind of odd sample
noise looks like an import error to me.

And if your dive computer really is _that_ flaky, I think you should
seriously consider a new one. It can't be doing a good job on deco
calculations if it actually sees those bounce spikes from 45ft to
surface (and that odd beginning profile).

But the fact that the temperature has the same spikes in the beginning
makes me suspect there's something you might be doing wrong in parsing
the original.

Is that really what the native SEAC action dive log looks like when
you look at it on whatever SEAC logger app?

Again, I guess it's _possible_ that it really is that your dive
computer is that flaky, but then I'd expect it to have stopped working
entirely..

Maybe there's some other signal mixed in with the depth/temperature
that you didn't account for?

Linus

[James W.]

Unfortunately it does show up in the Seac program as well. I've reached out to Seac support about a replacement but no response yet.

I agree it's an odd failure mode. It's like the sensor module has intermittent opens or shorts. Depth and temp match my dive buddy's computer, and the reported min-temp and max depth on the computer itself seem to be accurate. Possibly the serial cable dropping out, but I've blown away the DB and re-imported and the spikes seem to still be present. I haven't done a diff on the DB files to see if they differ between imports to verify though.

Here's the query directly from SQLite, and also the screenshot from SeacSync.

On Thursday, July 16, 2020 at 10:55:30 PM UTC-4, Linus Torvalds wrote:

[Kisdaróczi Péter]

SEAC answered me that they knew about this problem and are working on a new sync software.

I compared the computer in water to a few other models and seems good. Using it for last two months.

Peter

2020. júl. 17. dátummal, 5:32 időpontban James W. <james....@gmail.com> írta:



Unfortunately it does show up in the Seac program as well. I've reached out to Seac support about a replacement but no response yet.

I agree it's an odd failure mode. It's like the sensor module has intermittent opens or shorts. Depth and temp match my dive buddy's computer, and the reported min-temp and max depth on the computer itself seem to be accurate. Possibly the serial cable dropping out, but I've blown away the DB and re-imported and the spikes seem to still be present. I haven't done a diff on the DB files to see if they differ between imports to verify though.

Here's the query directly from SQLite, and also the screenshot from SeacSync.

<Auto Generated Inline Image 1>

<Auto Generated Inline Image 2>

On Thursday, July 16, 2020 at 10:55:30 PM UTC-4, Linus Torvalds wrote:

On Thu, Jul 16, 2020 at 5:42 PM James W. <james...@gmail.com> wrote:
>
> I could not for the life of me get a branch to push to Github, so here's a pretty strong start in patch form.
> Successfully pulls in depth and temperature profiles, (my flaky dive computer notwithstanding), along with the date and time and the notes entered in the SeacSync software.

Are those spikes in the original too? Because that kind of odd sample
noise looks like an import error to me.

And if your dive computer really is _that_ flaky, I think you should
seriously consider a new one. It can't be doing a good job on deco
calculations if it actually sees those bounce spikes from 45ft to
surface (and that odd beginning profile).

But the fact that the temperature has the same spikes in the beginning
makes me suspect there's something you might be doing wrong in parsing
the original.

Is that really what the native SEAC action dive log looks like when
you look at it on whatever SEAC logger app?

Again, I guess it's _possible_ that it really is that your dive
computer is that flaky, but then I'd expect it to have stopped working
entirely..

Maybe there's some other signal mixed in with the depth/temperature
that you didn't account for?

                   Linus

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/62dbeb75-1d87-4562-8014-16510b26c418o%40googlegroups.com.

<Auto Generated Inline Image 1>

<Auto Generated Inline Image 2>

[Miika Turkia]

Looks good. A few comments. First of all, check out our CODINGSTYLE.md in the sources directory. I.e. spacing is something you need to tweak quite a bit. I also noticed that there are a couple of compiler warnings to take care of at some point. Quite a few unused variables and this:

---8<---

/home/mturkia/source/subsurface/core/file.c: In function ‘try_to_open_db’:
/home/mturkia/source/subsurface/core/file.c:200:12: warning: implicit declaration of function ‘parse_seac_buffer’; did you mean ‘parse_dlf_buffer’? [-Wimplicit-function-declaration]
   retval = parse_seac_buffer(handle, filename, mem->buffer, mem->size, table, trips, sites);
            ^~~~~~~~~~~~~~~~~

            parse_dlf_buffer

---8<---

Check also CONTRIBUTING.md, especially the need for SOB https://gerrit-review.googlesource.com/Documentation/user-signedoffby.html. Of course, you might already know all this, but just making sure.

I would assume the dive time to be somewhat complex to handle. You will need to account for date changes as well, if the timezone calculation over or under flows. However, if the logged time is in local time, there is no need to do any math on it. Subsurface always stores dives in local time so we don't have to worry about timezones at all.

miika

To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/6a15a434-e8c3-41ba-b40c-f4435cefa4a0o%40googlegroups.com.

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/83c20266-7839-4776-817e-17a339714d8bo%40googlegroups.com.

[Kisdaróczi Péter]

I also got a “downloaded data might be corrupted, try re-sync” (or something like that) message from the SEAC Sync app, so it might be the cable or the sync app itself.
The computer itself shows good max depth and min temp values, while the sync app shows these spikes and oddly, at one dive, the max temperature is 1.5 Celsius, while the min is 16...

> 2020. júl. 17. dátummal, 5:32 időpontban James W. <james....@gmail.com> írta:
>

[Kisdaróczi Péter]

Today, I updated the SeacSync PC software and it’s good now. Though, I had to renove the old database, because it mixes in the new data. Interestingly, with a new computer serial number.

But after removing the old data and re-syncing my Action, the imported dives look good.

P

2020. júl. 17. dátummal, 5:32 időpontban James W. <james....@gmail.com> írta:



Unfortunately it does show up in the Seac program as well. I've reached out to Seac support about a replacement but no response yet.

I agree it's an odd failure mode. It's like the sensor module has intermittent opens or shorts. Depth and temp match my dive buddy's computer, and the reported min-temp and max depth on the computer itself seem to be accurate. Possibly the serial cable dropping out, but I've blown away the DB and re-imported and the spikes seem to still be present. I haven't done a diff on the DB files to see if they differ between imports to verify though.

Here's the query directly from SQLite, and also the screenshot from SeacSync.

<Auto Generated Inline Image 1>

<Auto Generated Inline Image 2>

On Thursday, July 16, 2020 at 10:55:30 PM UTC-4, Linus Torvalds wrote:

On Thu, Jul 16, 2020 at 5:42 PM James W. <james...@gmail.com> wrote:
>
> I could not for the life of me get a branch to push to Github, so here's a pretty strong start in patch form.
> Successfully pulls in depth and temperature profiles, (my flaky dive computer notwithstanding), along with the date and time and the notes entered in the SeacSync software.

Are those spikes in the original too? Because that kind of odd sample
noise looks like an import error to me.

And if your dive computer really is _that_ flaky, I think you should
seriously consider a new one. It can't be doing a good job on deco
calculations if it actually sees those bounce spikes from 45ft to
surface (and that odd beginning profile).

But the fact that the temperature has the same spikes in the beginning
makes me suspect there's something you might be doing wrong in parsing
the original.

Is that really what the native SEAC action dive log looks like when
you look at it on whatever SEAC logger app?

Again, I guess it's _possible_ that it really is that your dive
computer is that flaky, but then I'd expect it to have stopped working
entirely..

Maybe there's some other signal mixed in with the depth/temperature
that you didn't account for?

                   Linus

--

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.

[James W.]

Szia Péter,

Glad to hear the new version of the software works better. I don't have a Mac, so I'm still stuck with the 0.4.1 version for windows.

I do have the import working pretty well right now, detecting gas changes and copying over notes made in the SeacSync software.

I have a couple of other things to check, such how 0:30 timezones are handled, and if salt-water versus freshwater is recorded correctly. I have some saltwater dives in my sample DB, and they report the same water_type as my freshwater dives.

Once I have that completed, and the code cleaned up to meet the coding style, I'll initiate a pull request.

You received this message because you are subscribed to a topic in the Google Groups "Subsurface Divelog" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/subsurface-divelog/J7SXb3qaR6U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to subsurface-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/A7FAFF83-337C-41BD-8741-D09442FB5533%40gmail.com.

[Kisdaróczi Péter]

I have a Windows PC too. It’s also updated to 0.5.0.

[Miika Turkia]

Do you really need to handle the timezones? If the dive computer records local time, that is what Subsurface uses internally and it should be fine to import as is. (We made a decision early on not to mess with time zones as that is irrelevant for divers. Local time at the site of the dive is what we want to see. Theoretically it is possible to travel to different timezone for next dive and have dives overlap, but that is not worth taking into account, especially when considering the additional complexity and the fact that such case is highly unlikely ot ever occur.)

On Tuesday, July 21, 2020 at 7:58:08 PM UTC+3, James W. wrote:

Szia Péter,

Glad to hear the new version of the software works better. I don't have a Mac, so I'm still stuck with the 0.4.1 version for windows.

I do have the import working pretty well right now, detecting gas changes and copying over notes made in the SeacSync software.

I have a couple of other things to check, such how 0:30 timezones are handled, and if salt-water versus freshwater is recorded correctly. I have some saltwater dives in my sample DB, and they report the same water_type as my freshwater dives.

Once I have that completed, and the code cleaned up to meet the coding style, I'll initiate a pull request.

On Tue, Jul 21, 2020 at 12:05 PM Kisdaróczi Péter <pki...@gmail.com> wrote:

Today, I updated the SeacSync PC software and it’s good now. Though, I had to renove the old database, because it mixes in the new data. Interestingly, with a new computer serial number.

But after removing the old data and re-syncing my Action, the imported dives look good.

P

To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/62dbeb75-1d87-4562-8014-16510b26c418o%40googlegroups.com.

<Auto Generated Inline Image 1>

<Auto Generated Inline Image 2>

--
You received this message because you are subscribed to a topic in the Google Groups "Subsurface Divelog" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/subsurface-divelog/J7SXb3qaR6U/unsubscribe.

To unsubscribe from this group and all its topics, send an email to subsurface-divelog+unsub...@googlegroups.com.

[James W.]

Yes, unfortunately the computer tracks UTC, and only reports the dive start time with a time zone offset. It allows half hour offsets, but the offset is stored as an int. If I simply multiply the offset by 0.5 hours, the time is not correct. 

If I subtract the offset directly (I'm -5 timezone, but Seac recorded offset is 10), the time is correct. I'm not sure if they are using some sort of isOdd() logic to add/subtract 30 minutes.

I haven't had a chance to set my dive computer to a half hour time zone for testing.

To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/62dbeb75-1d87-4562-8014-16510b26c418o%40googlegroups.com.

<Auto Generated Inline Image 1>

<Auto Generated Inline Image 2>

--
You received this message because you are subscribed to a topic in the Google Groups "Subsurface Divelog" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/subsurface-divelog/J7SXb3qaR6U/unsubscribe.

To unsubscribe from this group and all its topics, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/A7FAFF83-337C-41BD-8741-D09442FB5533%40gmail.com.

--

You received this message because you are subscribed to a topic in the Google Groups "Subsurface Divelog" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/subsurface-divelog/J7SXb3qaR6U/unsubscribe.

To unsubscribe from this group and all its topics, send an email to subsurface-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/46bc8b09-ec8d-4c0b-9c7e-cc66e58b92eco%40googlegroups.com.

[Miika Turkia]

bummer. Do they also support 15 minute resolution for the time zone? i.e. Nepal.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CAO68dE%3D2ahC1k6gvZCn7Jwjf2U270e9C0HF%2BHPkBjFccoUkTAQ%40mail.gmail.com.

[Kisdaróczi Péter]

I just realized that the SeacSync app shows times in UTC, regardless of the current timezone settings. The previous version was good.

2020. júl. 21. dátummal, 20:11 időpontban James W. <james....@gmail.com> írta:



To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CAO68dE%3D2ahC1k6gvZCn7Jwjf2U270e9C0HF%2BHPkBjFccoUkTAQ%40mail.gmail.com.

[James W.]

Ah, the app will update itself, but the seac website still has the old version listed for download.

The new sync works so much better!

No more drop outs, only reporting one gas as expected!

And Miika, good catch on the timezone. It does allow 0:15 minute timezones as well. I wonder now if it is a lookup table. Just scrolled through the full list. Here are all the available TZ settings:

{-12, -11, -10, -9:30, -9, -8, -7, -6, -5, -4:30,

-4, -3:30, -3, -2, -1, 0, +1, +2, +3, +3:30,

+4, +4:30, +5, +5:30, +5:45, +6, +6:30,

+7, +8, +8:45, +9, +9:30, +9:45, +10,

+10:30, +11, +11:30, +12, +12:45, +13,

+13:45, +14}

On Tuesday, July 21, 2020 at 2:46:36 PM UTC-4, Kisdaróczi Péter wrote:

I just realized that the SeacSync app shows times in UTC, regardless of the current timezone settings. The previous version was good.

2020. júl. 21. dátummal, 20:11 időpontban James W. <james...@gmail.com> írta:



Yes, unfortunately the computer tracks UTC, and only reports the dive start time with a time zone offset. It allows half hour offsets, but the offset is stored as an int. If I simply multiply the offset by 0.5 hours, the time is not correct. 

If I subtract the offset directly (I'm -5 timezone, but Seac recorded offset is 10), the time is correct. I'm not sure if they are using some sort of isOdd() logic to add/subtract 30 minutes.

I haven't had a chance to set my dive computer to a half hour time zone for testing.

To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/62dbeb75-1d87-4562-8014-16510b26c418o%40googlegroups.com.

<Auto Generated Inline Image 1>

<Auto Generated Inline Image 2>

--
You received this message because you are subscribed to a topic in the Google Groups "Subsurface Divelog" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/subsurface-divelog/J7SXb3qaR6U/unsubscribe.

To unsubscribe from this group and all its topics, send an email to subsurface-divelog+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/A7FAFF83-337C-41BD-8741-D09442FB5533%40gmail.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Subsurface Divelog" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/subsurface-divelog/J7SXb3qaR6U/unsubscribe.

To unsubscribe from this group and all its topics, send an email to subsurface-divelog+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/46bc8b09-ec8d-4c0b-9c7e-cc66e58b92eco%40googlegroups.com.

--
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-divelog+unsub...@googlegroups.com.

[Robert C. Helling]

Am Dienstag, 21. Juli 2020 20:35:27 UTC+2 schrieb Miika Turkia:

bummer. Do they also support 15 minute resolution for the time zone? i.e. Nepal.

I wonder if anybody ever logged a dive in Nepal in Subsurface....

R.