Re: testing smtk2ssrf_4.6.2-33-g14971e912875_x86_64-20170224.AppImage
On 2017-03-02 21:57, Salvador Cuñat wrote: 2017-03-01 0:20 GMT+01:00 Alessandro Volpi : After my latest test run I am able to send you this message with my remarks about the observed behavior of smtk2ssrf : Some "data format errors" are detected in a number of dives carried out with the old Aladin Air Z O2 ; nevertheless the profiles of said dives ( Dive #241 and older) seem to be error free. I guess that some samples are missing, but the general trend of the time/depth plot is practically unaffected. Yes, the the profiles are good. I think, the data format error only affects the Nitrox & O2 series. I never got one of this with my own smarttrak file (aladin X & Z imported from datatrak), but I've noticed them with some sample dives from old aladin series. I'll need to look into libdivecomputer. May be it can be fixed and put into libdc upstream. The special events flags produced by the SmartTec device are simply IGNORED. This, again, will look into libdc. Send me a memory dump of those dive computers, and I'll have a look. If you don't have a full memory dump anymore, I can work with the raw data of the individual dives too. Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface-Mobile download from dive computer
> On Mar 2, 2017, at 9:58 PM, Willem Ferguson > wrote: > > On 03/03/2017 07:34, Jérémie Guichard wrote: >> Hello guys, >> >> I was lately thinking that being able to load dives from dive computer >> directly to mobile app would be a great addition. I already use an OTG cable >> to plug thumb or hard drives to my mobile when I want to back things up >> without PC or fast internet connection. My guess is that it could be >> feasible to use that connector to simply plug computer and mobile to each >> other and get the recorded dives this way. >> >> Seeing the title of your post, it seems this is what you are working on, am >> I right? >> >> If so, I would be more than willing to give a hand here :) >> >> Cheers, >> >> Jeremie > > Hi Jérémie, > > Thank you very much for the offer. The code is in QML/Qt and Dirk implement > Kirigami controls where it could make life easier. Are you conversant with > QML? I would be delighted to discuss this with you off-group. My email > addresses are willemfergu...@zoology.up.ac.za and fergusonwil...@gmail.com. > Please send any email to BOTH of these addresses. While I of course can't tell you what to do, I'd PREFER if you discussed this on list, so that more of us see the discussion and can at least learn from it or maybe even help. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface-Mobile download from dive computer
On 03/03/2017 07:34, Jérémie Guichard wrote: Hello guys, I was lately thinking that being able to load dives from dive computer directly to mobile app would be a great addition. I already use an OTG cable to plug thumb or hard drives to my mobile when I want to back things up without PC or fast internet connection. My guess is that it could be feasible to use that connector to simply plug computer and mobile to each other and get the recorded dives this way. Seeing the title of your post, it seems this is what you are working on, am I right? If so, I would be more than willing to give a hand here :) Cheers, Jeremie Hi Jérémie, Thank you very much for the offer. The code is in QML/Qt and Dirk implement Kirigami controls where it could make life easier. Are you conversant with QML? I would be delighted to discuss this with you off-group. My email addresses are willemfergu...@zoology.up.ac.za and fergusonwil...@gmail.com. Please send any email to BOTH of these addresses. Kind regards, willem ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface-Mobile download from dive computer
Hello guys, I was lately thinking that being able to load dives from dive computer directly to mobile app would be a great addition. I already use an OTG cable to plug thumb or hard drives to my mobile when I want to back things up without PC or fast internet connection. My guess is that it could be feasible to use that connector to simply plug computer and mobile to each other and get the recorded dives this way. Seeing the title of your post, it seems this is what you are working on, am I right? If so, I would be more than willing to give a hand here :) Cheers, Jeremie 2017-03-03 2:31 GMT+07:00 Dirk Hohndel : > > > On Mar 2, 2017, at 10:48 AM, Willem Ferguson < > willemfergu...@zoology.up.ac.za> wrote: > > > > Hallo Dirk, > > > > I am in a position now to try some more towards achieving FTDI downloads. > > > > Between April 2016 and now one hell of a lot has changed on the QML > side. Most importantly, Kirigami (largely?) replaced mobilecomponents. The > folder mobile-widgets replaced the previous qt-mobile. > > > > 1) What of the archived mobilecomponents code for > downloadFromDiveComputer from 2016 is still usable? Would it be better to > start from scratch? > > It should still mostly work. I haven't played with it in a while, but I > don't think the changes required should be too hard. > > > 2) Do you have any useful reference material about Kirigami? > > We are still using Kirigami 1, so that would be http://notmart.org/misc/ > kirigami1-docs/html/ > > > 3) Any suggestions would be appreciated. > > I'd start with that see where you get stuck. Marco ist still on the > mailing list and usually extremely helpful when you have specific questions. > > /D > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: testing smtk2ssrf_4.6.2-33-g14971e912875_x86_64-20170224.AppImage
Good evening Alessandro. Thank you very much for your exhaustive testing. 2017-03-01 0:20 GMT+01:00 Alessandro Volpi : > > After my latest test run I am able to send you this message with my > remarks about the observed behavior of smtk2ssrf : > > >Some "data format errors" are detected in a number of dives carried >out with the old Aladin Air Z O2 ; nevertheless the profiles of said dives >( Dive #241 and older) seem to be error free. I guess that some samples are >missing, but the general trend of the time/depth plot is practically >unaffected. > Yes, the the profiles are good. I think, the data format error only affects the Nitrox & O2 series. I never got one of this with my own smarttrak file (aladin X & Z imported from datatrak), but I've noticed them with some sample dives from old aladin series. I'll need to look into libdivecomputer. May be it can be fixed and put into libdc upstream. > > The special events flags produced by the SmartTec device are simply > IGNORED. > This, again, will look into libdc. > >The events produced by Galileo Sol and Galileo trimix are >accurately recorded but their type is ignored. Moving the cursor on the red >flags with diagonal white stripe results in a pop-up label with the >"Bookmark" caption. Ascent and workload warnings are thus labeled as >"Bookmark" ; surprisingly the manually added Bookmarks are totally IGNORED. > This was the reason I told you to keep your .slg log file. Most (all) alarms in Galileo are marked as bookmarks as they are not correctly known. BTW, when you say "manually added bookmarks", are you talking about bookmarks set in Galileo or bookmarks set in smarttrak? If they are set in the device, they should be imported by libdc, if we are talking about that bookmarks set in smartrak, I don't think they can ever be imported as they are not stored as a time function, but (x,y) coordinates related to a (possibly) fixed space or (probably not) screen position. > >In my past test runs I have observed that the tank "description" >field, although correct in most cases, is sometimes classified as "unknown" >in spite of the presence of a reasonable tank description in the SmartTrak >dive log. I was thinking that these glitches were somehow related to the >type of dive computer and to the presence and the health of the pressure >transmitter. This was DEFINITELY WRONG. The tank description is IGNORED >when, and ONLY WHEN the Start and End pressure fields ARE LEFT EMPTY. This This was an intentional assumption in my side. The actual workflow of smtk2ssrf with tanks is: 1- libdc has parsed the raw dive data and may or may not have got tank data (whichever is the reason). If libdc got tank data, we have an initial pressure for sure. 2- If there is no initial pressure read the smarttrak data (the user may have set it manually), including start and end pressure and mixes. 3- If we still don't have an initial pressure, discard the tank (assuming it hasn't been used). If we have an initial pressure complete the tank data (type and working pressure). The flaw in this marvelous workflow is in point 2. Let's see your #449 dive. Second and third tanks have not been used (there are no initial press) *BUT* they had set the O2% (the second, not shown, is set to 21%). So we end up with three tanks, two of them unnamed. Subsurface doesn't support unnamed tanks so it changes the description to "unknown". I still think that is better not to show tanks which haven't been used, but fixing this issue seems easy: get the mix only if we have an initial pressure. I will send a fix for this ASAP. > > > BTW I have seen that somehow smtk2ssrf and subsurface are able to DETECT A > FLAWED PRESSURE probe. The Start and End pressure fields in the "Equipment" > tab are filled with a pink background, when a transmitter is not working > properly: see dives # 457, 458, 459, 464, 465, 466, 468, 469, 470, 472, > 473, 478, 480, 481, 484 and 486. > > It IS SPECIALLY REMARKABLE that subsurface IS DETECTING the malfunctioning > probes, whilst SmartTrak IS NOT ! > Unsure about this. Whichever is the reason the credit must go to libdivecomputer and subsurface developers, smtk2ssrf has little to say here, just tries to translate the data. Best regards. Salva. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Pressure transducers
Dear Willem, as far as the subsurface and smtk2ssrf development is concerned I have sent a message to Salva and to the mailing list on February 28. The program for importing the SmartTrak dive log works very well, all my comments having been reported in the cited message. The only detail I failed to mention is that the gas switch (or tank switch) events are flawlessly imported by smtk2ssrf and displayed in the dive profile plot by subsurface. I would also like to spend some more words about the issue of the pressure transmitters ... I promise this post will be MY LAST POST about the subject. I agree with suggestion that such a discussion is not totally pertinent to the scope of the subsurface mailing list. I would only add that I have NOT been as LUCKY as you with my UWATEC pressure transmitters. This is, according to my experience, the typical life cycle of such devices : 1. I buy a new transmitter 2. For a few dives it work well, albeit with some "SIGNAL LOST" warnings on the Galileo display. 3. The FREQUENCY of such warnings gets higher and higher. Their DURATION does the same. 4. It happens that, sometimes, the transmitter refuses to work for the entire dive. 5. I replace the battery, although the voltage measurement shows that plenty of energy is still stored in the cell ... 6. No improvement is observed 7. I go back to point 1. for another cycle I went through this cycle many times and each time I have paid 250 Euro ... It is just enough. Very best regards. Alessandro On Thu, Mar 2, 2017 at 6:06 AM, Willem Ferguson < willemfergu...@zoology.up.ac.za> wrote: > On 01/03/2017 23:47, Alessandro Volpi wrote: > >> My knowledge about the technical details of pressure transmitters is >> quite limited. Nevertheless I think it is worth while to explain why I >> would like to test some kind of ultrasonic transmitter. >> >> My personal experience is limited to UWATEC transmitters; I have been >> using them since 1998 and I have thus tested at least three generations of >> such devices. I have also asked the opinion of some friends of mine about >> Suunto dive computers and pressure probes. >> >> Very best regards. >> >> >> Alessandro >> > I have been using a Galileo for more than 250 dives and, although the link > between sensor and dive computer is not perfect, my setup has been robust > enough to be classed as reasonably reliable. I have one older generation > sensor and a more recent generation sensor. I sometimes lose the signal for > a few seconds but it always comes back soon. My sidemount setup with a > sensor on each cylinder works pretty well. Although I change to the > alternate cylinder fairly frequently but at significant longer than 5 min > intervals (typically within 30 bar of one another, i.e. a 60 bar drop on a > cylinder, from 30 bar above the other cylinder to 30 below) the system > works pretty well. Maybe it is because in sidemount, the dc and sensors > are not far apart. But even when using a twinset (where I use only 1 sensor > [on RH twin cylinder and Galileo on RH arm]) it has been reasonably > reliable. My only failure has been due to a flat battery. On sidemount I > still have an additional button SPG on each cylinder and on twinset I have > a fullsize SPG on the LH cylinder. This system has worked very well and has > been extremely convenient for me for long time now. > > Alessandro, If you have any specific issues with your Galileo and > Subsurface, please raise these so that we can see what can be done about > them. The Galileo import is reasonably efficient but not perfect by any > means because there are still several known issues. I need to find the time > to track down some things in the dive log and converse with Jef about these. > > Kind regards, > willem > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface-Mobile download from dive computer
> On Mar 2, 2017, at 10:48 AM, Willem Ferguson > wrote: > > Hallo Dirk, > > I am in a position now to try some more towards achieving FTDI downloads. > > Between April 2016 and now one hell of a lot has changed on the QML side. > Most importantly, Kirigami (largely?) replaced mobilecomponents. The folder > mobile-widgets replaced the previous qt-mobile. > > 1) What of the archived mobilecomponents code for downloadFromDiveComputer > from 2016 is still usable? Would it be better to start from scratch? It should still mostly work. I haven't played with it in a while, but I don't think the changes required should be too hard. > 2) Do you have any useful reference material about Kirigami? We are still using Kirigami 1, so that would be http://notmart.org/misc/kirigami1-docs/html/ > 3) Any suggestions would be appreciated. I'd start with that see where you get stuck. Marco ist still on the mailing list and usually extremely helpful when you have specific questions. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Subsurface-Mobile download from dive computer
Hallo Dirk, I am in a position now to try some more towards achieving FTDI downloads. Between April 2016 and now one hell of a lot has changed on the QML side. Most importantly, Kirigami (largely?) replaced mobilecomponents. The folder mobile-widgets replaced the previous qt-mobile. 1) What of the archived mobilecomponents code for downloadFromDiveComputer from 2016 is still usable? Would it be better to start from scratch? 2) Do you have any useful reference material about Kirigami? 3) Any suggestions would be appreciated. Kind regards, willem ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.6.3
On Thu, Mar 02, 2017 at 09:23:46AM +0100, Martin Gysel wrote: > Am Donnerstag, 2. März 2017, 08:05:38 CET schrieb Dirk Hohndel: > > I tagged it, built it, pushed it, posted the announcement to our site, but > > for once didn't post it on FB, G+ or anywhere else - this way the > > translators have a chance to translate the announcement on github... let's > > see if that works and I can then post the announcement to FB tomorrow > > > > Thank you so much for all the hard work on getting Greek and Italian all > > the way done and many of the other translations significantly improved. > > Dirk, tags on marble and libdc are missing Sorry, had them locally, but forgot to push them. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.6.3
Dirk, > On 2 Mar 2017, at 07:05, Dirk Hohndel wrote: > > I tagged it, built it, pushed it, posted the announcement to our site, but > for once didn't post it on FB, G+ or anywhere else - this way the > translators have a chance to translate the announcement on github... let's > see if that works and I can then post the announcement to FB tomorrow I created a pull request for the German translation. Note please: The typo in the saturation/desaturation rate affects not only Buehlmann but all our deco calculations. So I changed the wording in all translations. Below is a patch for the release notes in the main repository: From a0f110e16c80dd05af7da4a58fe369f4a5c631b8 Mon Sep 17 00:00:00 2001 From: "Robert C. Helling" Date: Thu, 2 Mar 2017 09:36:01 + Subject: [PATCH] Release notes: saturation rate affects all deco calculations To: subsurface@subsurface-divelog.org Signed-off-by: Robert C. Helling --- ReleaseNotes/ReleaseNotes.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ReleaseNotes/ReleaseNotes.txt b/ReleaseNotes/ReleaseNotes.txt index a114d95..b9e7cc9 100644 --- a/ReleaseNotes/ReleaseNotes.txt +++ b/ReleaseNotes/ReleaseNotes.txt @@ -15,7 +15,7 @@ Some of the changes since _Subsurface_ 4.6.2 - Make sure column labels for cylinder table get translated - Improve dive merging: deal with water temperature, better handling of dive sites -- Fix typo in saturation / desaturation rates used in Buehlmann +- Fix typo in saturation / desaturation rates used in decompression calculations; this has a small impact on some dive plan deco times - Improve some icons used in Preferences dialog - Fix CSV export of weights in lbs -- 2.10.1 (Apple Git-78) Best Robert signature.asc Description: Message signed with OpenPGP ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.6.3
Am Donnerstag, 2. März 2017, 08:05:38 CET schrieb Dirk Hohndel: > I tagged it, built it, pushed it, posted the announcement to our site, but > for once didn't post it on FB, G+ or anywhere else - this way the > translators have a chance to translate the announcement on github... let's > see if that works and I can then post the announcement to FB tomorrow > > Thank you so much for all the hard work on getting Greek and Italian all > the way done and many of the other translations significantly improved. Dirk, tags on marble and libdc are missing /martin ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
