- devel - libdivecomputer.org

Errors download ProPlus2
by Steve Boyd 08 Jul '12

08 Jul '12

I am using libdivecomputer0.0.0 on Windows 7. I am getting DEVICE_STATUS_ERROR returned during the download of my ProPlus2 with: [193.832] c:\development\libdivecomputer-0.0.0\src\oceanic_common.c:461: Unexpected profile size. in the log file. The dive that is causing the error downloads fine using OceanLog. I have attached a dump of the device. Any hints?

1 0

Re: API redesign progress
by Linus Torvalds 27 Jun '12

27 Jun '12

On Mon, Jun 25, 2012 at 5:17 AM, VG30DETT <vg30dett(a)gmail.com> wrote: > > I'm puzzled, besides updating to the latest LTS version of Ubuntu (not > really practical at this time), is it a problem on my side, or > something else ? It really sounds like ubuntu has some really old version of cairo installed. Googling a bit, it looks like ubuntu 10.04 has libcairo2-dev version 1.8.10, and afaik you need at least cairo-1.10 for the whole cairo_rectangle_int_t thing. And quite frankly, I don't know old cairo history well enough to say how that should be done in the pre-1.10 days. Nor do I have a system that old installed. Somebody who knows cairo better would need to figure it out. Or you'd need to update to a newer version. Looks like cairo 1.10 made it into Natty Narwhal. Linus

1 0

Problems to compile Subsurface under Ubuntu 10.04 LTS
by Mekong Leonidas 25 Jun '12

25 Jun '12

Hi everyone. Just a couple words about myself. I started to dive when I was 11 I started to work with computers when I was 12 I've been using C for more than 15 years in my life....about 15 years ago I'm using Linux (unless customer says "no way") Now...the technical part. I have the following problems I'm currently using Ubuntu 10.04 LTS on my main computer I downloaded libdivecomputer and torvalds-subsurface-058b84c I managed to resolve all the dependencies, and managed to compile libdivecomputer without any errors Here's what I got sheitan@sheitan-TSH:/usr/local/lib$ ls -las total 1432 4 drwxr-xr-x 4 root root 4096 2012-05-13 11:51 . 4 drwxr-xr-x 10 root root 4096 2012-04-26 09:38 .. 872 -rw-r--r-- 1 root root 892588 2012-05-13 11:51 libdivecomputer.a 4 -rwxr-xr-x 1 root root 999 2012-05-13 11:51 libdivecomputer.la 0 lrwxrwxrwx 1 root root 24 2012-05-13 11:51 libdivecomputer.so -> libdivecomputer.so.0.0.0 0 lrwxrwxrwx 1 root root 24 2012-05-13 11:51 libdivecomputer.so.0 -> libdivecomputer.so.0.0.0 540 -rwxr-xr-x 1 root root 552324 2012-05-13 11:51 libdivecomputer.so.0.0.0 4 drwxr-xr-x 2 root root 4096 2012-05-13 11:51 pkgconfig 4 drwxrwsr-x 4 root staff 4096 2010-08-16 11:35 python2.6 So, it seems that libdivecomputer is OK I tried to compile subsurface....ooppss First, I had to fix the dependencies...OK But when I launch the "make" command, here's the result sheitan@sheitan-TSH:~/Documents/Diving/torvalds-subsurface-058b84c$ make gcc -Wall -Wno-pointer-sign -g -I/usr/include/libxml2 -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -c profile.c In file included from profile.c:12: display.h:25: error: expected declaration specifiers or ‘...’ before ‘cairo_rectangle_int_t’ profile.c:1349: error: expected declaration specifiers or ‘...’ before ‘cairo_rectangle_int_t’ profile.c: In function ‘plot’: profile.c:1370: error: ‘drawing_area’ undeclared (first use in this function) profile.c:1370: error: (Each undeclared identifier is reported only once profile.c:1370: error: for each function it appears in.) make: *** [profile.o] Error 1 In case you wonder, "sudo make" gives the same results... It seems that the problem is about the function extern void plot(struct graphics_context *gc, cairo_rectangle_int_t *drawing_area, struct dive *dive); AFAIK, I can only see this function in display.h:extern void plot(struct graphics_context *gc, cairo_rectangle_int_t *drawing_area, struct dive *dive); and in sheitan@sheitan-TSH:~/Documents/Diving/torvalds-subsurface-058b84c$ grep 'plot(' *.c gtk-gui.c: plot(&gc, &drawing_area, dive); print.c: plot(&gc, &drawing_area, dive); profile.c:void plot(struct graphics_context *gc, cairo_rectangle_int_t *drawing_area, struct dive *dive) I'm puzzled, besides updating to the latest LTS version of Ubuntu (not really practical at this time), is it a problem on my side, or something else ? Thanks in advance, and best regards Henri

2 1

Re: Tine subsurface updates
by Jef Driesen 07 May '12

07 May '12

Hi, For those not on the subsurface mailinglist, you can read the first part of this discussion here: http://lists.hohndel.org/pipermail/subsurface/2012-May/000208.html On 2012-05-03 17:58, Linus Torvalds wrote: > It's the *ugly* and pointless breakage that I get so upset about. It > makes things harder for everybody for no actual reason. And it is > indicative of the same old "I don't think of libdivecomputer as a > library, I think of it as a random collection of internal routines" > problem. > > Interfaces are important. Even during development. They are doubly > important when it's a library that other projects use. Let's try to approach this discussion from another perspective. In the past, the libdivecomputer library provided no official releases, and there was just a single development branch (git master) where all the work was done. This development model didn't work well for applications, and therefore I introduced the new model with the 0.1.0 release. My idea was to proceed as follows: 1. We keep git master as the main development branch. This is where all the work towards the next stable release happens. New features can be introduced and backwards compatibility isn't guaranteed. 2. Stable releases (e.g. v0.x.0) are provided at the end of each development cycle. 3. Whenever bugfixes for a stable release are necessary, a new release branch is created. Only bugfixes are allowed here, and backwards compatibility is maintained. Releases from this branch will increment the micro number only (e.g. v0.x.y). This development model would allow me to introduce backwards-incompatible changes incrementally and also faster (e.g. no need to delay breaking changes). Applications should stick to the stable releases, and therefore require updating only when upgrading to the next stable release. Any incompatible changes will be documented with the new release. No more unexpected breaks anymore. Support for older versions can be kept by conditional compilation based on the libdivecomputer version macros. I assumed this would be a huge improvement compared to the previous situation, because it keeps the pain for applications to a minimum, while still providing enough flexibility to commit work-in-progress to the development branch. At some point, once we're all satisfied with the public api, we can move to v1.0.0 and never break backwards compatibility again. But let's concentrate on the road towards that goal first. If you (or anyone else) think this is not the right way to proceed, please tell me what you would do different. Jef

1 0

aeris epic - incorrect depth and time in samples
by Chad Burt 06 May '12

06 May '12

I'm having some trouble using the "universal" sample with my Aeris Epic dive computer. After running, I get what appears to be correct information for each dive, except for the samples. The depth is always 11.41, and despite the fact that my sampling interval is set to 1 second I only get a sample for every two seconds: <sample> <time>00:04</time> <vendor type="5" size="8">5A0057025A005702</vendor> <temperature>24.44</temperature> <pressure tank="0">0.00</pressure> <depth>11.41</depth> </sample> <sample> <time>00:06</time> <vendor type="5" size="8">5A00570257005702</vendor> <temperature>24.44</temperature> <pressure tank="0">0.00</pressure> <depth>11.41</depth> </sample> I've compiled the samples on my machine and used the pre-built binaries with the same result. I've also used the plugin from diveboard.com to connect to my computer as well and had the same problem. MacDive imports them just fine though. Odd, since I understand both of these apps use libdivecomputer. I'd very much appreciate any help. I'm hoping to develop some software for analyzing this xml output as well as UDCF from the perspective of the freediver. I've got some ideas for organization and visualization that I think will be a lot more useful than the typical scuba-focused software provides. -Chad

2 1

Re: Ascent rate and other stored information
by Jef Driesen 30 Apr '12

30 Apr '12

On 2012-04-17 17:07, Björn Spruck wrote: > Am 03.04.2012 10:04, schrieb Jef Driesen: >> Just to give an example, the ascent rate could be stored as a >> numeric >> value (e.g. in m/s), an index into an array with ranges (e.g. 0-5, >> 5-10, 10-15, 15+), etc. Because every model can have its own set of >> ranges, you need all of them. And that's just for the ascent rate. >> Is >> this really worth the trouble? I would say no, especially because >> ascent rate can be calculated from the profile data. The results may >> deviate slightly from the values reported by the dive computer, but >> is >> that really a problem? >> > Actually, yes, because this is an "instant rate" based on the > sampling > rate of the DC, while the one recalculated is from the stored 20s > intervalls. Are you sure about that? There is only one ascent rate value recorded for the entire sample interval. The dive computer can indeed sample more frequently, but in the end it will only record a single value. That value could be the minimum, maximum or average value within the sample interval, but regardless of how it's obtained, it will always be an approximation. Instant and interval don't really mix well. I doubt the differences between the recorded and calculated values will be very high anyway. Especially with the relative short sample intervals that are used nowadays. And if the dive computer uses ranges to express the ascent rate, there is already a huge amount of rounding going on, which is probably greater than the differences due to using a calculated value. Note that another advantage of calculating the ascent rate from the depth profile is that it will always yield a consistent result, independent of the type of dive computer you used. And last but not least you'll also have an ascent rate for dive computers that don't record that type of information. > But it is a very nice example, because in this case it is really easy > to > store the information in a way to satisfy most (all?) models: > Store a numerical lower and upper bound, the values (corresponding to > the integer values) can be found in the dive computers manual. > I see this as an opportunity to think now (based on the knowledge of > the > data of current DCs) to make decisions on the data formats. > > At least here it would be really bad to relay the work to the > front-end. > > The back-end should give values to the front-end in a way that the > front-end does not need to know anything on the DC model to display > (or > interpret) them correctly. > > Another example is the "deco" flag behaviour: (I mentioned this > before) > Some computers store a start and end deco flag. some flag all samples > where deco is "on". > Here I see the task of teh backend to "translate" that to some > uniform > behaviour. (either start/stop for all (prefered), or continous > flagging). Thus having a uniform behaviour from the front-end view. Don't get me wrong, I absolutely do want to move the interpretation as much as possible into the backends. That's exactly the reason why I want to get rid of the sample events as they exist today. They were never really carefully designed, with an inextensible format as the result. Removing them from the api right now and passing them as raw binary data instead, will allow us to re-introduce them later on, once we have figured out a more appropriate format. But it's not a trivial task due to the many different formats and feature sets. And certainly don't forget it's also a very time consuming process. Adding a single new field means reverse engineering that piece of info for all 20+ backends and even more different models. >> That's why I want to concentrate on the essential pieces of >> information and make sure those are very well supported. Squeezing >> the >> last bits of info out of the data is a huge amount of work, while >> the >> majority of the applications won't need it. > > Essentials are different for different people ;-) Of course! But I think you'll agree some are more essential than others. Things like date/time, divetime, maxdepth, gas mixes (e.g. the stuff you would write down in a paper logbook) are likely more essential for the majority of people than let's say ascent rate. I'm not claiming ascent rate is a useless piece of information, but only that it has a lower priority. Also my resources (time) are limited, so I rather prefer to satisfy the majority of people with a more limited but well supported set of information, than to spend huge amounts of time on features that are little used. Maybe a good start would be to make a list of what kind of information we consider essential and would like to see supported? Once we agree on what we want (or not), we can start discussing the corresponding data formats. > PS: maybe this discussion should continue on the list? Indeed. Jef

2 2

[ANNOUNCE] Version 0.1.0 now available
by Jef Driesen 28 Apr '12

28 Apr '12

Hi, The first release is now available! http://www.divesoftware.org/libdc/releases/libdivecomputer-0.1.0.tar.gz Jef

1 0

Problem importing from Suunto HelO2
by Henrik 23 Apr '12

23 Apr '12

Hi. I have a Suunto HelO2, and imports via libdivecomputer (MacDive) only work some times. It seems that the evening after a dive I cannot import, while on the next day it works. Here's a log: henrik@kollaps:~/Downloads$ ./vyper2 /dev/tty.SLAB_USBtoUART DATETIME 2012-04-21T16:37:37Z (1335026257) REVISION 5126ef389a0b8983752008568cf26bdbd46b3257 DEVICE=/dev/tty.SLAB_USBtoUART suunto_vyper2_device_open Configure: baudrate=9600, databits=8, parity=0, stopbits=1, flowcontrol=0 Timeout: value=3000 DTR: value=1 Sleep: value=100 Flush: queue=3, input=0, output=0 device_version Sleep: value=600 RTS: value=1 Sleep: value=6 Write: timer=8, size=4, data=0F00000F, remaining=0 RTS: value=0 Read: timer=3001, size=0, data=, remaining=0 ../../source/src/suunto_vyper2.c:193: Failed to receive the answer. Sleep: value=600 RTS: value=1 Sleep: value=6 Write: timer=8, size=4, data=0F00000F, remaining=0 RTS: value=0 Read: timer=3001, size=0, data=, remaining=0 ../../source/src/suunto_vyper2.c:193: Failed to receive the answer. Sleep: value=600 RTS: value=1 Sleep: value=6 Write: timer=7, size=4, data=0F00000F, remaining=0 RTS: value=0 Read: timer=3001, size=0, data=, remaining=0 ../../source/src/suunto_vyper2.c:193: Failed to receive the answer. ../../source/examples/suunto_vyper2_test.c:85: Cannot identify computer. suunto_vyper2_device_open Configure: baudrate=9600, databits=8, parity=0, stopbits=1, flowcontrol=0 Timeout: value=3000 DTR: value=1 Sleep: value=100 Flush: queue=3, input=0, output=0 device_version Sleep: value=600 RTS: value=1 Sleep: value=6 Write: timer=8, size=4, data=0F00000F, remaining=0 RTS: value=0 Read: timer=3001, size=0, data=, remaining=0 ../../source/src/suunto_vyper2.c:193: Failed to receive the answer. Sleep: value=600 RTS: value=1 Sleep: value=6 Write: timer=8, size=4, data=0F00000F, remaining=0 RTS: value=0 Read: timer=3001, size=0, data=, remaining=0 ../../source/src/suunto_vyper2.c:193: Failed to receive the answer. Sleep: value=600 RTS: value=1 Sleep: value=6 Write: timer=8, size=4, data=0F00000F, remaining=0 RTS: value=0 Read: timer=3001, size=0, data=, remaining=0 ../../source/src/suunto_vyper2.c:193: Failed to receive the answer. ../../source/examples/suunto_vyper2_test.c:45: Cannot identify computer. SUMMARY ------- test_dump_memory: Timeout test_dump_sdm: Timeout I've tried switching USB ports and rebooting the machine, without success. I use MacOSX Lion on a 2010 MacBook Pro. Best regards, Henrik

2 2

Early releases and backwards compatibility
by Jef Driesen 13 Apr '12

13 Apr '12

Hi, The original plan was to introduce all backwards incompatible changes on the roadmap all at once, and only then make a first official release. However this turns out to be very impractical and slows down the development process. Lately I'm also receiving requests from distribution packagers (Debian in particular) to make some real releases. Therefore, I propose the following intermediate strategy. We start making early releases with version numbers 0.x.y. Whenever a backwards incompatible change is introduced, the number x is increased. For fully backwards compatible changes, only the number y is increased. This would allow me to introduce new changes incrementally. I'm aware this won't be perfect for applications, but at least you can require a specific version, and/or support multiple versions with conditional compilation. Once the api is declared fully stable, we move on to version 1.0.0 and provide full backwards compatibility from there on. Would this be an acceptable solution for you? Feedback is always welcome! Jef

2 1

Enumeration of supported models
by Jef Driesen 04 Apr '12

04 Apr '12

Hi, I have been prototyping the device enumeration code (item #14 on the roadmap). I have a couple of questions for which I would like to get some feedback from users of the api. It's mainly about the naming of functions and data structures. > typedef dc_model_t { > const char *manufacturer; > const char *name; > device_type_t type; > unsigned int model; > } dc_model_t; I'm not that satisfied with the name "dc_model_t". I think it's too easy to confuse with the model code. Does anyone have some suggestions for a better name? The only alternative I came up with is the more general "dc_descriptor_t". A similar question for the "device_type_t" and "parser_type_t" enums. As explained before (see item #10 on the roadmap), I would like to merge both into a single enum. A simple change, but I'm still looking after a good general name for the new enum. Currently I have two suggestions: "dc_backend_t" or "dc_family_t". The dc_backend_t name feels a bit heavyweight to my taste, because I usually use the term backend to refer to the device/parser handle itself, rather than its type. Any other suggestions? And last but not least, how about the "manufacturer" and "name" fields? Everywhere else I'm using the term "vendor" instead of "manufacturer" (e.g. the vendor extensions in the events). Which name would you prefer here? And would you keep the "name" field, or rename it into "product". The full name of the device is in fact the concatenation of the manufacturer and the product name (e.g. Suunto Vyper). The reason for using two separate fields is to allow easy grouping by manufacturer in a GUI application. I assume most applications will use such grouping rather than showing one huge list to choose from, so having the two separated makes sense I think. > One possibility would be an iterator style api, similar to this: > > dc_iterator_t *iterator = dc_get_supported_models (); For retrieving the iterator, which name is preferred? dc_xxx_get_iterator (xxx, &iterator) dc_xxx_iterator (xxx, &iterator) dc_xxx_iterate (xxx, &iterator) I usually consider a getter (or setter) function as a lightweight function that just accesses some internal field of an opaque object. But depending on the underlying implementation this function could perform some more heavyweight action. Imagine we use the iterator concept for downloading dives too. There are several devices that maintain an index with the available dives. This index needs to be downloaded first to be able to locate the actual dive profiles. Downloading this index could be done when getting the iterator, or it could be delayed until you actually try to download the first dive. In the first case getting the iterator will perform some heavyweight I/O, while in the second case it's only creating a placeholder and the real work is done in the dc_iterator_next() function. For functions that perform real work, I usually use a verb. For example the dc_device_read function. But in this case, it's not really the dc_xxx_iterate() function that will be doing the enumeration. The dc_xxx_iterator() function would fall somewhere in between the other two options. > while (dc_iterator_next (iterator)) { > dc_model_t *model = dc_iterator_current (iterator); > > /* Do stuff here */ > dc_model_get_name (model); > dc_model_get_manufacturer (model); > ... > } For the iterator loop, an alternative would be to integrate the dc_iterator_current() functionality directly into the dc_iterator_next(), like this: while (dc_iterator_next (it, &item)) { ... } The benefit would be a little less overhead, because there is only one function call left. I don't see any disadvantages. Of course you can't iterate without fetching the item, but why would you need to do that in the first place? And last but not least, which status code should the dc_iterator_next() return to indicate: (a) an item has been returned, (b) the iterator has reached past the last item (e.g. an EOF condition). Either we introduce some new status code for the EOF condition: while ((status = dc_iterator_next (it, &item)) == DC_STATUS_SUCCESS) { ... } if (status != DC_STATUS_DONE) { /* Handle errors */ } Or we use the new status code to indicate a data item has been retrieved: while ((status = dc_iterator_next (it, &item)) == DC_STATUS_DATA) { ... } if (status != DC_STATUS_SUCCESS) { /* Handle errors */ } Remember DC_STATUS_SUCCESS is equal to zero, and error codes are negative. So I think it makes sense to use a positive value (e.g. the number one) for this new status code, so it is clearly distinct from the real errors. Jef

1 0