- devel - libdivecomputer.org

Re: Getting back to Cochran coding.
by Jef Driesen 08 Jan '16

08 Jan '16

On 2016-01-07 17:13, John Van Ostrand wrote: > Now that the main dive season is well over and I'm only getting out > every > couple of weeks I felt the urge to get back on this. It's been a year > since > my last exchange. > > Jeff, do you still have a branch for my code? Do you need a full patch > or > just a merge patch? I'm quite new at git so it's best if you're > explicit > when explaining. I still have a local branch with all your cochran patches. We can continue from there again. I haven't really touched that code since last time. Been occupied with other things. It's probably a good idea to rebase everything on current master, but I'm not sure I'll have time this weekend to take care of that. Jef

1 0

Getting back to Cochran coding.
by John Van Ostrand 07 Jan '16

07 Jan '16

Hi, Now that the main dive season is well over and I'm only getting out every couple of weeks I felt the urge to get back on this. It's been a year since my last exchange. Jeff, do you still have a branch for my code? Do you need a full patch or just a merge patch? I'm quite new at git so it's best if you're explicit when explaining. -- John Van Ostrand At large on sabbatical

1 0

Re: Sentinel (and rEvo)
by Jef Driesen 01 Jan '16

01 Jan '16

On 2015-11-01 10:53, Paul-Erik Törrönen wrote: > Hello, finally got all the necessary pieces to do a log download on the > Sentinel, and I followed the instructions on the libdive web-page. > > I captured the USB/serial traffic in 2 separate files, the first one¹ > is > when the original piece of software (OPOS, Prolink) is fired up and > connects to the rebreather. > > The second² is when I hit the dowload button on the OPOS and it fetches > the (2) dives. > > ¹ http://poltsi.fi/Sukeltaminen/Sentinel/Log/sentinel-connect.log.7z > ² http://poltsi.fi/Sukeltaminen/Sentinel/Log/sentinel-download.log.7z > > Regarding the rEvo, I probably will be able to borrow one diveCan SW > for a > couple of days during the week, so I will get back to you regarding > that. Unfortunately I don't have time at the moment to look into adding a new communication backend. Sorry, but maybe you can have a look yourself? I quickly ran your logs through my portmon parsing scripts, and it seems the dive computer sends back plain ascii data. The attached *.log file contains the I/O operations, and the *.txt contains the raw data received from the dive computer. Jef

2 8

Example data format to college
by Leonardo Santos 31 Dec '15

31 Dec '15

Hello, My english is as poor as bad, but I am a brazilian that would like finishing my last work from college. I need figure out this, although I'm not a developer... Please, Who can help me ? I'd like to know, what's the default of data format to a dive computer ( is there a default sure ? ) and I need show a example or be able getting this information from a "new device" ( as I propose in my last work from college - MBA IT to an executive ) Regards Leonardo Santos Project Manager - CSM, LPI I, BSCI leonardo.santos(a)wanconnect.com.br +55 21 9 9267-2181 +55 61 9294-8906 +55 21 9 7294-7606

2 2

Mares Smart: Pointer out of range
by Gilbert Forkel 03 Dec '15

03 Dec '15

Hello, downloading the dives of a Mares Smart divecomputer not containing any dives (just unpacked new device and connected to computer) i get the following errror: ERROR: Ringbuffer pointer out of range. [in mares_iconhd.c:481 (mares_iconhd_extract_dives)] Looks like memory locations 0x2001 and 0x3001 are empty (0xffffffff). Maybe we can just check for this case and return SUCCESS ? Gilbert

2 1

Re: ideas for representing repetitive dives
by Jef Driesen 06 Nov '15

06 Nov '15

Giorgio, Sorry for the late response. I have been a bit occupied with other things the past few weeks. I don't think libdivecomputer provides only a "least common denominator" experience. The majority of the information (and if you ask me, also the most interesting info) is common between all dive computers. We're talking about general info like the date/time, maxdepth, divetime, and of course the sample data. Those are the features that are supported today. There is no doubt room for improvement here, but I think we already cover quite some info. You are absolute right that most devices also provide some additional info that is not supported by libdivecomputer at all. There are two reasons for that. Usually not only the encoding, but also the data itself is highly device specific. That makes it rather difficult to support it through a common device independent api. The other reason is a more practical one. I only have a limited amount of time available, so I try to spend it on those features that benefits most users, instead of some exotic feature that only a few users care about. My point of view is that if you want to squeeze out every single bit of information, then you're probably better of with a device specific application (like the one from the manufacturer), instead of a general purpose application. Having said all that, I'm not saying no to the idea of vendor specific additions, if it doesn't have a major impact on the rest of the api, but it's definitely not at the top of my priority list. Going back to the subdives topic, I'm not convinced supporting such a concept can be implemented without a major impact on the rest of the api. Altering the behavior of the api, depending on whether the application enables some special subdive mode, is also not my favorite option. Having two separate code paths will make the api more complex and harder to maintain. Right now the two approaches that seems to make the most sense to me is to: 1. Merge all subdives into one large dive. That's basically what we are doing now. The main disadvantage in your particular case, is the we loose the min/max temperature of each subdives. We can't use the DC_FIELD_XXX api here (because that's per dive) and we can't use the sample temperature either (because we don't know at which sample the min/max temperature was measured). 2. Deliver each subdive separately. Since each subdive is now a separate dive we can use the DC_FIELD_XXX api for the min/max temperature. The main drawback here might be the large amount of very short dives. But on the other hand, applications can easily group (free)dives again based on the date/time information. Similar to how subsurface does group dives into trips. If necessary we can always introduce a new field containing the index in the subdive session to assist there. Some dive computers have a similar concept for scuba dives: the repetitive dive number. These two options is also how most other dive computers record freedives: record one large dive covering the entire freedive session, or record each freedive in the session as a separate dive. The difference usually depends on the depth and/or surface time thresholds of the dive computers. A short surface time threshold will result in individual dives, while a larger threshold will result in one large dive. (I already discussed the above with Giorgio, but for the mailing list it will be useful to provide some more context.) Jef On 2015-10-26 10:43, Giorgio Marzano wrote: > Hi, > > I didn’t had much spare time in the last weeks, but I kept thinking > about > the idea of representing repetitive dives on libdivecomputer > > > Initially I wrote a simple spreadsheets to summarize the pros and cons > of > > possible > > approaches > > . Colors represents the “severity” of a drawback or of an impact and > are my > guesses. > > We may use it to confront ideas. > > Generally speaking I think that the API > > should really > > include a way to pass free-form data to the > > app, while right now everything is codified in the "least common > multiple" > of all the DC capabilities. > > It may seems a weird thing to do, but consider that > > each dc may have specific information which the > > user (who chooses and bought that DC) > > may want to be represented on the profile. > > I am thinking about alarms and statistics, and also the whole “subdive” > stuff. > > > It could be a good idea to introduce some kind of USER_EVENT (or > USER_SAMPLE) with name, type (int, float, bool, string) and value > fields. > > Parsers should use the USER_EVENT to report info which the app may > choose > to skip, draw as it is or elaborate. > > > Then we may define policies on such events. Such that 'alarms name > shall > start with "AL_'" or similar to hint the apps. > > > This would be, in my opinion, a > > progressive and > > low-impact > > way > > to improve flexibility of the API. > > Referring to the attached table, such change would allow for a simple a > straight forward implementation of the workaround > > for the drawbacks of the “Merge Subdives” approach or for the whole > “report > session and dives in an unstructured way” stuff. > > > > Let me know what do you think about it. > > G

1 0

Release request
by Richard Houser 02 Nov '15

02 Nov '15

I just realized my dive computer is supported in in git trunk, but there hasn't been a tagged release in a LONG time. Comparing the supported devices list between stable and trunk implies a LOT of users would be in a similar state. Any chance we could get a tagged release soon on a particularly stable, recent version of libdivecomputer. At the least, that would really help with packaging concerns, etc. I have the latest git compiling, but when I attempt to import dives in subsurface 4.4.2 from my Aeris A300 CS, I get a parse failure. My extremely limited understanding is that is handled within this library. If this should already be working in the current trunk, I'll gladly go through some information gathering, submit a report with logs, etc. I'm personally trying to get an Aeris A300 CS working with latest subsurface. Once I do so, I'll get with the current Mageia maintainer and see about getting an update pushed out to cauldron for testing.

3 2

Sentinel (and rEvo)
by "Paul-Erik Törrönen" 01 Nov '15

01 Nov '15

Hello, finally got all the necessary pieces to do a log download on the Sentinel, and I followed the instructions on the libdive web-page. I captured the USB/serial traffic in 2 separate files, the first one¹ is when the original piece of software (OPOS, Prolink) is fired up and connects to the rebreather. The second² is when I hit the dowload button on the OPOS and it fetches the (2) dives. ¹ http://poltsi.fi/Sukeltaminen/Sentinel/Log/sentinel-connect.log.7z ² http://poltsi.fi/Sukeltaminen/Sentinel/Log/sentinel-download.log.7z Regarding the rEvo, I probably will be able to borrow one diveCan SW for a couple of days during the week, so I will get back to you regarding that. Poltsi -- Paul-Erik Törrönen poltsi(a)777-team.org +358 40 703 1231 http://poltsi.fi/ Science, it reduces the stupid

1 0

(no subject)
by Giorgio Marzano 26 Oct '15

26 Oct '15

Hi, I didn’t had much spare time in the last weeks, but I kept thinking about the idea of representing repetitive dives on libdivecomputer Initially I wrote a simple spreadsheets to summarize the pros and cons of possible approaches . Colors represents the “severity” of a drawback or of an impact and are my guesses. We may use it to confront ideas. Generally speaking I think that the API should really include a way to pass free-form data to the app, while right now everything is codified in the "least common multiple" of all the DC capabilities. It may seems a weird thing to do, but consider that each dc may have specific information which the user (who chooses and bought that DC) may want to be represented on the profile. I am thinking about alarms and statistics, and also the whole “subdive” stuff. It could be a good idea to introduce some kind of USER_EVENT (or USER_SAMPLE) with name, type (int, float, bool, string) and value fields. Parsers should use the USER_EVENT to report info which the app may choose to skip, draw as it is or elaborate. Then we may define policies on such events. Such that 'alarms name shall start with "AL_'" or similar to hint the apps. This would be, in my opinion, a progressive and low-impact way to improve flexibility of the API. Referring to the attached table, such change would allow for a simple a straight forward implementation of the workaround for the drawbacks of the “Merge Subdives” approach or for the whole “report session and dives in an unstructured way” stuff. Let me know what do you think about it. G

1 0

No p02 for Petrel (Divecan)?
by "Paul-Erik Törrönen" 19 Oct '15

19 Oct '15

I noticed an oddity when downloading dives from a rEvo RMS Divecan Petrel, the dive data did not contain any pO2-data. This was with the latest daily build of Subsurface, 4.4-98-56 on Windows XP When I downloaded the same dives to Shearwater Desktop (SD), it did contain the actual pO2-data, so the dc has stored the data, and it is present (for all 3 O2-sensors) when I eg. export the data from SD to CVS-format. I noticed another peculiarity. Subsurface recognized the dive as OC, when it should have been CCR. I guess the detection is done earlier, and I found from the maillist archives[1], that when the dive is presumed to be OC, no pO2-data is collected by libdivecomputer. Maybe there's an issue on how the OC/CCR-mode is detected? I had to return the rEvo today as it was borrowed, so I can not immediately verify anything, the unit however is not that far from here, so I may be able to do testing. Partially related to this: There are instructions on how to capture the traffic between the DC and log software, but this seems to only work in those cases where the DC talks over the serial. In my case the Petrel seems to have been accessed in a more direct manner (there was no COM-device) and portcom was quiet the whole time. Is there a recommended way to capture the transmissions from Bt-devices? I tested with sniffusb which seemed to capture something (since the Bt is apparently connected to the USB-port), but I'm not that sure I got the correct data? Poltsi 1. http://libdivecomputer.org/pipermail/devel/2015-February/000697.html -- Paul-Erik Törrönen "When science and the Bible differ, poltsi(a)777-team.org science has obviously misinterpreted +358 40 703 1231 its data" http://poltsi.fi/ Henry Morris, father of 'modern creationism'

3 8