devel

devel@libdivecomputer.org

291 discussions

Liquivision Xeo
by Christian Sandrini 13 Feb '14

13 Feb '14

Hi there I would like to contribute with the Liquivision Xeo (http://www.liquivision.com/xeo.php) computer. But I only have a Mac no Windows. Is there a portmon alternative for Mac OSX? Or is it maybe already in the loop? best Chris

2 1

[ANNOUNCE] Version 0.4.2 now available
by Jef Driesen 06 Feb '14

06 Feb '14

Hi, The v0.4.2 release is now available! http://www.libdivecomputer.org/releases/libdivecomputer-0.4.2.tar.gz The v0.4.2 release is a bugfix release. Bug fixes: * [iconhd] Use only 12 bits for the temperature. * [d9] Identify event 0x07 on Suunto d9-style computers as Below Floor. * [iconhd] Add Mares Puck 2 dive computer * [misc] Disable the cancellation callback during shutdown. * [misc] Add cancellation support to several backends. * [atom2] Fix the memory layout for the Atom 3.x and VT4.x. * [atom2] Mark the Oceanic Veo 2.0 as a non air integrated model. * [iconhd] Fix the memory layout descriptors. * [atom2] Add support for the Sherwood Amphos. * [atom2] Add support for the Oceanic OCi. * [smart] Add support for a new Uwatec Aladin 2G variant. * [shearwater] Buffer the slip packet before sending. * [shearwater] Use the correct vtable for the Shearwater Petrel. * [iconhd] Adds support for DC_FIELD_ATMOSPHERIC to the iconhd parser * [iconhd] Fix units for atmospheric pressure for iconhd type * [n2ition3] Add support for the Scubapro XTender 5. * [leonardo] Use only 11 bits for the depth. * [iconhd] Add iconhd gas change event * [atom2] Fix the memory layout for the VT4.x. * [eon] Remove the infinite timeout. * [eon] Improve the progress events. Jef

1 0

Trade show Boot Düsseldorf
by Jef Driesen 12 Jan '14

12 Jan '14

Hi, Anyone visiting the trade show Boot in Düsseldorf (Germany)? That may be an opportunity to meet people in person. I'll be there on Sunday 19th January. Jef

2 1

Problem connecting with Oceanic VT3
by Juan Pablo Sioffi 01 Apr '13

01 Apr '13

Hello: My name is Juan Pablo and I have a dive computer Oceanic VT3. I'm trying to download the dives from the computer using Dive Log 5.0 software, but all the time appears the same error: "time out". Can you help me to solve the problem, please? Thanks in adavance. Saludos, Juan Pablo Sioffi

2 1

Liquivision DC support?
by Lutz Vieweg 21 Feb '13

21 Feb '13

Hi Jef, a friend of mine happenes to use a Liquivision X1 computer. I understand libdivecomputer does not yet support that model, but wanted to ask whether there are any known attempts underway to change that? Or would it be realistic to assume that borrowing that computer for just a few days trying to sniff its protocol would deliver enough information to support it? Regards, Lutz Vieweg

3 8

Re: Liquivision DC support?
by Jef Driesen 19 Feb '13

19 Feb '13

On 2013-02-19 09:53, Reinout Hoornweg wrote: > On 2013-02-19 09:42, Henrik Brautaset Aronsen wrote: >> Maybe a talk with the Diving Log guys could help? >> "OK, great news: I've heard back from Liquivision and got already >> some material - and also a direct download with Diving Log seems not >> too far away, but I can't promise more about that right now. An >> import >> is almost working already." >> "So, here we go: Thanks to the documentation I got yesterday, I >> finally managed to read the Dive Log file format (*.lvd) and created >> a >> first import which you can test. It works with the 2 logbook files I >> have, but it is possible that it has still bugs. I managed to import >> almost all data, except profile events (e.g. warnings and gas >> switches). If you have any logbook files containing dive profiles >> with >> gas switches and warnings, please send me the files." >> (from http://www.divinglog.de/phpbb/viewtopic.php?f=4&t=1408 @ >> Nov.2011) > > A few months ago I asked the people at Liquivision about the > possibilities for using their Kaon and Lynx divecomputers with Linux > and if they had plans to support open source. > The reply I got was: > "At the moment, there is no way to use Linux with our computers. The > way the dive logs are transferred means that it is only compatible > with our own Dive Logger program for now which is only available on > Windows or Mac OS. > We are working on making our computers compatible with independent > software though! While our software team is focused on launching the > Lynx right now, we will definitely focus on improving the "openness" > of our computers after DEMA." That sounds promising! Now we only have to convince them to provide protocol documentation rather than a pre-build shared library (see my other email to the libdivecomputer and subsurface mailinglists). Jef

1 0

[ANNOUNCE] Version 0.3.0 now available
by Jef Driesen 06 Feb '13

06 Feb '13

Hi, The v0.3.0 release is now available! http://www.divesoftware.org/libdc/releases/libdivecomputer-0.3.0.tar.gz The v0.3.0 release introduces some interesting features for technical divers, support for a number of new devices and many smaller bugfixes. There have been a few minor changes to the public interface, to remove a few deprecated functions. Therefore this release is not completely backwards compatible with the previous release. However, most applications won't be affected by these changes. New features: * Add support for the Cressi Leonardo. * Add support for the Mares Nemo Wide 2, Matrix and Puck Pro. * Add support for the Shearwater Predator and Petrel. * Add support for decostop / ndl samples * Add support for setpoint, ppO2 and CNS * Add support for salinity and atmospheric pressure * Add a new gaschange2 event with O2 and He percentages. * Add a new vendor event. * Add some missing size macros. * Add timestamps to the default log function. * Include the git commit SHA1 in the version number. Removed/changed features: * Remove the suunto_vyper_device_set_delay function. * Remove the reefnet_sensusultra_device_set_maxretries function. * Remove the xxx_device_set_timestamp functions. * Remove the uwatec_smart_device_version function. * Remove the dc_device_version function. * Remove the page, packet and memory size macros from the public api. * Add a model parameter to the mares_iconhd_device_open function. Bug fixes: * [d9] Fix the fingerprint offset for the Suunto D4i, D6i and D9tx. * [d9] Add support for the new D6i firmware. * [veo250] Add support for the Seemann XP5. * [atom2] Add support for a second Aeris Elite T3 variant. * [atom2] Fix the tank pressure decoding for the Hollis DG03. * [vtpro] Fix the unit conversion for the max depth. * [iconhd] Decode the serial number as a 32 bit number. * [suunto] Fix the decoding of the Suunto serial numbers. * [d9] Add support for trimix gas changes. * [cobalt] Add gas changes and violation events for Atomic Aquatics Cobalt * [ostc] Fix gas handling for OSTC * [misc] Log the date/time and version in the example applications. * [puck] Add a small delay before retrying a packet. * [misc] Update the msvc project file. * [vyper2] Read the version info when opening the connection. * [atom2] Fix a typo in the Sherwood Wisdom 3 model number. * [misc] Fix a redefinition warning for the ERROR macro. * [ostc] Skip the size validation for unused divisors. * [atom2] Add support for the Aeris A300 AI. * [ostc] Autodetect the three OSTC variants. * [ostc] Fix a regression in the depth calculation. * [atom2] Add support for a second Sherwood Insight variant. * [ostc] This adds support for a subset of the events the OSTC provides. * [ostc] Correct the OSTC depth calculation * [atom2] Add support for a second Aeris Epic variant. * [atom2] Fix the parser for the Hollis DG03. Jef

1 0

Re: [PATCH 0/2] Clean up some of the dive computer nickname code
by Linus Torvalds 18 Jan '13

18 Jan '13

On Wed, Jan 9, 2013 at 12:31 PM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > > This is a small 2-patch series that makes the dive computer nickname > infrastructure be a more generic "device info" structure instead, and > splits it out into "device.[ch]". Side note: as discussed with Dirk, the intent of this series is that we can save other information about the dive computer (serial numbers etc) in the device info structure. However, quite frankly, looking at what we get at least right now from libdivecomputer, I doubt it is worth it. The "serial nr" thing is an integer, which is unlikely to actually match any serial numbering on the package or anything like that. For example, the Suunto serial number that libdivecomputer gives me for the helo2 is 389152795. The *actual* serial number of the device is "23500027". Guess what? Serial numbers are strings, not numbers. Look around, you'll notice that manufacturers almost always encode serial "numbers" with letters etc. The libdivecomputer interface is wrong. It so happens that the Suunto serial number strings are strings that have all numbers, but they aren't *one* number. They are four bytes representing two numbers each, and the "23500027" string is actually the four bytes 23 50 00 27 (0x17 0x32 0x00 0x1b). And libdivecomputer has incorrectly parsed those four bytes as one number, not as the encoded serial number string it is. So the value 389152795 is actually hex 0x1732001b, which is 0x17 0x32 0x00 0x1b, which is - 23 50 00 27. IOW, the serial numbers libdivecomputer gives us are useless. You could perhaps turn them into an actual serial number string on a per-vendor (or per-device) basis, if you know the vendor rules. The Suunto vendor rules *seem* to be pretty simple, based on the two devices I have (the Vyper Air clearly uses the same encoding, giving another 8-byte string). Other dive computers? Who knows? Anyway, the current libdivecomputer "serial number" information is wrong. It has some information, but the information is in the wrong format, and you need vendor-specific knowledge to turn it into the right string. As a result, there's no point in having subsurface save it. We can use the integer form for the device ID hash, and that's all it is actually useful for. It would be good if libdivecomputer continued to give the old "numeric serial number" for that use, but to make it *useful* we also need some interface to get the actual vendor string representation, so that we can save that. If we get the correct serial numbers in the proper format that the vendor uses, *that* information wou;ld be useful to save for things like warranty purposes etc. It could be as simple as a new libdivecomputer callback ("given this serial *number*, what is the string for it?"), but it would probably be better to expand the current DC_EVENT_DEVINFO event to simply give us a string in addition to the number. Because it's not necessarily the case that all serial number strings can even be represented as a single 32-bit integer. Linus

5 17

Next round of api improvements.
by Jef Driesen 05 Dec '12

05 Dec '12

Hi, For the next release, I'm planning to introduce a new dc_dive_t and dc_sample_t interface. This will again be a major change to the libdivecomputer api. Please note that the interface presented in this email is by no means a final version. It's intended to serve as a starting point for further discussions. Now, let's have a closer look. The role of the new dc_dive_t object has been discussed before [1], so I'll just summarize here. In a nutshell, the new dc_dive_t object is basically a container for the raw dive data, with the parser functionality built-in. As a result, there is no need anymore to create a dc_parser_t object explicitely. The dc_device_foreach() function will be modified to return dc_dive_t objects directly in the callback, instead of the raw dive data. The raw dive data (and fingerprint) can be retrieved from the dc_dive_t object by means of the dc_dive_get_raw() and dc_dive_get_fingerprint() functions. The dive metadata can be retrieved with a number of accessor functions, similar to the current dc_parser_t interface: int dive_cb (dc_dive_t *dive, void *userdata) { /* Get raw dive and fingerprint data. */ dc_dive_get_raw (dive, &data, &size); dc_dive_get_fingerprint (dive, &fpdata, &fpsize); /* Get dive metadata directly. */ dc_dive_get_datetime (dive, &datetime); dc_dive_get_maxdepth (dive, &maxdepth); ... } Note that this new dc_dive_t interface will also simplify the transition from a callback based interface to an iterator based interface, because the dc_iterator_next() function can now return the dc_dive_t object: dc_dive_t *dive; dc_iterator_t *iterator; dc_device_iterator (device, &iterator); while (dc_iterator_next (iterator, &dive) == DC_STATUS_SUCCESS) { /* Contents of the callback function goes here. */ } dc_iterator_free(iterator); Although this will be something for later, we can already keep this in mind of course. For parsing the samples, I have something very similar in mind. With the current interface, the application receives a stream of sample values (e.g. time, depth, etc), and the time sample serves as the marker to start a new sample. However, with the new interface, the sample values would be accumulated internally in the new dc_sample_t object. Once the entire sample has been parsed, the sample is passed to the callback function. As a result, there is no need anymore to treat the time sample as special, and the individual sample values can be retrieved with a number of accessor functions: void sample_cb (dc_sample_t *sample, void *userdata) { dc_sample_get_time (sample, &time); dc_sample_get_depth (sample, &depth); ... } With these new dive and sample objects it's also possible to add vendor specific extensions in the future. We just need a new accessor function and a corresponding data structure. So far the overview of the high level design that I had in mind. The remainder of this email consists of more detailed information on a number of technical challenges that will have to be addressed in this new design. 1. Object ownership, lifetime and memory management. ===================================================== How should we deal with the ownership of the new objects? With the current api, the application has to call dc_parser_new() function explicitly, and their is no doubt that the application is the owner of the returned object. However, because the new dive and sample objects will be allocated internally, their ownership is not immediately obvious. It all depends on the internal implementation. There are a couple of options, each with their own advantages and disadvantages: A. Library owns The first option is to make the library the owner of the objects. In this case, the object is allocated internally, passed to the callback function, and destroyed internally again: dc_device_foreach (...) { while (!finished) { dc_dive_t *dive = NULL; dc_dive_new (&dive, ...); callback (dive, userdata); dc_dive_free (dive); } } int dive_cb (dc_dive_t *dive, void *userdata) { ... } The consequence is that the lifetime of the object is limited to scope of the callback function, and an application won't be able to keep a reference to the object. This will be problematic for some legitimate scenario's. For example storing the objects in a list for later processing (e.g. after all dives have been downloaded), or passing objects between threads (e.g. download the dives in a worker thread, then and pass them to the main GUI thread to display them in real-time). The only way to keep a (valid) reference to the object is to make a copy. In the current design, this works fine because the raw data is trivial to copy. It's just a byte array after all. But the new dive/sample objects are opaque objects and can't be copied unless a helper function is provided to make a deep copy (e.g. a dc_dive_clone() functions). But that's not exactly the most elegant interface if you ask me. B. Application owns The second option is to make the application the owner of the objects. In this case, the object is allocated internally, passed to the callback function, and should be destroyed by the application, not the library: dc_device_foreach (...) { while (!finished) { dc_dive_t *dive = NULL; dc_dive_new (&dive, ...); callback (dive, userdata); } } int dive_cb (dc_dive_t *dive, void *userdata) { ... dc_dive_free (dive); } This may work well for those scenario's where you really need to take the ownership, but it adds unnecessary overhead when you don't need it and there is no way to avoid this extra overhead. Take the sample parsing for example. I think it's safe to assume that most applications will convert the sample data to their native format on the fly, and thus never keep a reference to the libdivecomputer sample objects. The result is that a large number of sample objects will be allocated and immediately destroyed again. Thus many memory allocations for no good reasons. I don't like that. We should primarly aim for a good design, but it doesn't hurt to keep an eye on the efficiency too. Note that in my code snippet for the previous "library owns" case, their is an equal amount of memory allocations taking place. But those can easily be avoided by allocating just a single object, and re-using it every time. However for the "application owns" case no such optimization is possible. C. Reference counting An alternative option would be to make the new objects reference counted. This changes nothing to the fact that we have to decide whether the application has to take a reference explicitly (e.g. case A) or gains it automatically (e.g. case B). But with the reference count, we can detect whether the application still holds a reference or not, and avoid unnecessary memory allocations: dc_device_foreach (...) { dc_dive_t *dive = NULL; while (!finished) { if (dive && --dive->refcount == 0) { /* We just dropped the last reference and we can safely re-use the previous dive. */ } else { /* The application still holds a reference to the previous dive and we have to allocate a new one. */ dc_dive_new (&dive, ...); } callback (dive, userdata); } dc_dive_free (dive); } int dive_cb (dc_dive_t *dive, void *userdata) { ... /* Optionally keep a reference. */ dc_dive_ref (dive); } It's of course slightly more complex to implement, and we have to make sure the reference counting is thread-safe too using atomic operations or protected with a mutex), but I think the resulting api will be more intuitive. Reference counting is pretty standard today. D. Mixed ownership The last option is to allow different ownership rules for the dive and sample objects. For example we could choose "applications owns" for the dives, and "library owns" for the samples. In that case, the dives can be used outside the callback function, while their is no unnecessary overhead for the samples. The obvious downside is less consistency. 2. Querying available sample values? ===================================== With the current design, the samples are pushed to the application, and there is no need to know which values are actually supported. You'll only get those values that are actually present. However, with the new design, the application has to call an accessor function to retrieve a piece of data, and thus it needs some way to query which values are presented. The only values that are guaranteed to be available for each sample are time and depth. Everything else is optional. The level at which we can tell whether a particular sample value is present varies. It can be at the device level (for example a non-air integrated model will never store tank pressure data), at the dive level (for example a model with a wireless pressure sensor can have dives with and without tank pressure stored), or even at the sample level (for example a tank pressure every x sample). To support all possible cases this querying should thus be done at the sample level. I think the simplest solution is to use the accessor function itself to probe for the presence of the info. You just call the accessor function and if the info isn't available, a special error code like UNSUPPORTED is returned: if (dc_sample_get_depth (sample, &depth) == DC_STATUS_SUCCESS) { /* Depth retrieved successfully. */ } else { /* No depth available (or an error occurred). */ } For multivalued data, like the tank pressure, we could then use an extra index parameter in the accessor function, and then call it repeatedly until the UNSUPPORTED error is returned: i = 0; while (dc_sample_get_pressure (sample, &pressure, i) == DC_STATUS_SUCCESS) { /* Tank pressure retrieved successfully. */ i++; } An alternative solution for the multivalued data would be to retrieve all values at once using an array: dc_sample_get_pressure (dc_sample_t *sample, double pressure[], unsigned int n); But then the caller somehow has to know the maximum value for n, and the api also has to communicate back the actual number of values returned. The second part is easy with an extra output parameter, but I don't know a nice solution for the first problem (other than a second dc_sample_get_pressure_count function). Alternatives for the probing approach outlined above, are an iterator like interface to iterator over the available sample values, or a function to retrieve a bitmap with the available sample values. 3. Supported dive and sample data ================================== Which dive data and sample data should we support? I already made a tentative list, but this is open for discussion of course. Items can be added or removed after discussion. Dives: * date/time * divetime * maxdepth * gasmixes * tank pressures (begin/end) * temperature * salinity, altitude/atmospheric pressure * dive mode (open/closed circuit, gauge, etc) Samples: * time * depth * temperature * tank pressure * heartrate * airtime Events: * Gas changes * Deco stops (depth and time) * Warnings, bookmarks, etc For the events, I'm not sure yet how the querying (see previous item) should be done. The normal samples are continuous values, and will usually appear at least every X sample, or not at all. But the events are discrete in nature and will only appear occasionally. Should this be done differently in the api? We'll also have to agree on a data structure and the exact semantics for each of those pieces of data. Some won't need much discussion, but others will. For example take the temperature. A device can record a single value which could be the minimum, maximum or average temperature. It can have all three, or a full temperature profile. How do we deal with that? Things are not always as easy as they may look. Closely related to the data structures is the choice of the unit system. The choice is either metric or SI. SI units have the advantage all values are positive, but applications are likely to use metric or imperial. We can also consider to introduce a unit system as used in subsurface, where all values are scaled to fit into an integer (e.g. depths in millimeters instead of meters, and so on)? Or are we happy with floating point values? That's it for now. Comments are welcome! If you think I missed something important, don't hesitate to bring it up. It's not unlikely that I forgot about something :-) [1] http://sourceforge.net/mailarchive/message.php?msg_id=29475503 Jef

4 16

Re: Mares Nemo Wide MY2013
by Tim Wootton 03 Dec '12

03 Dec '12

On 2012-09-27 17:15, Jef Driesen wrote: > A logfile from the test application is indeed the first step. > However, I received a few reports that the Mares Nemo Wide 2 doesn't > work. I don't know for sure, but I have the suspicion that this is > the same model. It's possible the transfer protocol has changed > compared to the old model, and in that case, I need a portmon log. Jef did you get any/enough logs for the Nemo Wide 2? I've just picked one up and happy to send logs if still needed. Tim

2 1

← Newer
1
...
22
23
24
25
26
27
28
29
30
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel