devel

devel@libdivecomputer.org

3 participants
290 discussions

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

Send commands to Vyper
by Jahn Thomas Fidje 01 Oct '15

01 Oct '15

Hello all! This is totally awesome! :-) Is it possible to send commands to the Vyper in any way? Ex. to reset the computer or to change values? Thanks in advance! - Covey

2 1

[PATCH] Skip unconnected ppo2 sensors
by Anton Lundin 09 Sep '15

09 Sep '15

The HwOS devices logs ppo2 sensor values even in Auto / Fixed SP mode, but they log them as reading zero, if there are no sensors there. This skips us reporting those zero values. Signed-off-by: Anton Lundin <glance(a)acc.umu.se> --- This shows one of the flaws with re-using the DC_SAMPLE_PPO2 value. Should we report unconnected sensors? how should a application actually handle them? Maybee we should look at the ppO2 value too, but for now this POC only looked at the mV values. src/hw_ostc_parser.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/hw_ostc_parser.c b/src/hw_ostc_parser.c index 6db9d27..954f6f7 100644 --- a/src/hw_ostc_parser.c +++ b/src/hw_ostc_parser.c @@ -885,6 +885,9 @@ hw_ostc_parser_samples_foreach (dc_parser_t *abstract, dc_sample_callback_t call value = data[offset + j]; } else { value = data[offset + j * 3]; + // Skip zero mV sensors, as they are most likely unconnected + if (array_uint16_le (data + offset + j * 3 + 1) == 0) + continue; } sample.ppo2 = value / 100.0; if (callback) callback (DC_SAMPLE_PPO2, sample, userdata); -- 2.1.4

2 7

Re: Mares Smart Apnea
by Jef Driesen 09 Sep '15

09 Sep '15

On 2015-09-04 12:25, Giorgio Marzano wrote: > Right now, I noticed a bug in the mares_iconhd_get_model function, line > 120 > of mares_iconhd.c, where sizeof should be actually strlen. > > if (memcmp (device->version + 0x46, models[i].name, /*sizeof*/ strlen > (models[i].name) - 1) == 0) { This is not a bug. The name field is a 16 byte array, not a string. The initialization with a sting literal is convenient. The remainder of the array will automatically get padded with zero bytes, which is exactly what we need. The correct fix is to add a new entry containing "Mares Smart". Then, the next question is: what's the correct model number? According to the model number in the memory dump (e.g. byte at offset 0), it's 0x10 or SMART: {"Smart", SMART}, + {"Smart Apnea", SMART}, {"Icon HD", ICONHD}, But then how do we distinguish the normal smart from the apnea variant? That will be important, because both appear to use a different data format. The strange thing here is that the normal smart already had a freedive mode. The main difference is that we now not only get a summary of each freedive in the session, but also a detailed profile. I wonder if there is some kind of format indicator in the header that we can use to distinguish between dives with the enhanced apnea format and the more limited normal format. Jef

2 7

← Newer
1
...
10
11
12
13
14
15
16
...
29
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel