devel

devel@libdivecomputer.org

3 participants
290 discussions

Re-syncing with Jef's upstream..
by Linus Torvalds 12 May '20

12 May '20

Ok, so I've just spent several hours re-synchronizing our subsurface branch with Jef's upstream. The most trivial part of that was to just pull the changes from Jef's tree - they merged cleanly, nothing odd there. But then I tried to basically re-base all our changes on top of Jef's unmodified tree, to see what all our changes actually are these days. This resulted in two different things: (a) a number of trivial updates to the 'Subsurface-NG' branch itself (b) the actual new branch itself. That (a) is basically stuff I noticed while doing the rebasing, and where I decided that the differences to Jef's upstream should be minimized rather than carried forward. So this is things like just unnecessary left-overs from other development that just isn't relevant any more. Some of it was literally just plain whitespace differences. And (b) is basically "throw out all of our history, and try to re-create the exact same end result as we got in (a)". Dirk, I'm not exactly sure what you think is the best option here. Both branches are in the usual places, I called the new branch DS9 (I'm not sure if your "NG" naming was a Star Trek reference, but I decided it was, and that the "new new generation" is thus "deep space nine"). You can see them both at github: https://github.com/subsurface/libdc/tree/Subsurface-NG https://github.com/subsurface/libdc/tree/Subsurface-DS9 and the important part here is that the DS9 branch should _not_ be pulled into the NG branch - the two have exactly the same tree content-wise, but they have very different history. The DS9 branch has thrown out all our old history, and is just a linear series of 27 commits on top of what is Jef's upstream as of today: Update compiler flags and dc version suffix for Subsurface-NG Fix up .gitignore file Clean up 'dc_tankvolume_t' type and make it 'dc_tankinfo_t' Add generic field cache and string field infrastructure Add time-to-surface sample type Add string event sample type Extend on the event flag type with severity and types Add 'usbstorage' iostream Add backend for Garmin Descent Mk1 Add support for the Deepblu Cosmiq+ dive computer Suunto Eon Steel: sort the dive list properly Use the extended parsing facilities for the Suunto EON Steel backend Atomics Cobalt: use the new DC string fields Make custom iostream read/write wrapper more rebust Add back Mares BlueLink Pro bluetooth support tweaks Add serial number to parser creation for ostc, atom2, shearwater and suunto d9 Heinrichs Weikamp OSTC: add extended information parsing Suunto D9 family: add extended information parsing Oceanic Atom2: add extended string information parsing Oceanic: when encountering an unknown device, report the version string i770R: parse tank pressure and water salinity like the i750tc Mark Aqualung i750TC as Bluetooth capable Cressi: mark Cartesio and Goa as supporting BLE Shearwater Petrel: make the hardware ID decoding a bit easier to read Shearwater Teric: add support for the TAG INFO_EVENT Shearwater: fix (again) per-cell ppO2 reporting Shearwater: add extended information parsing while our "real" history (in Subsurface-NG) right now is 114 commits of development, and 28 merges.. So the DS9 branch is very much a simplified history that tries to make it much more obvious exactly what we've changed. In contrast, the commits in our current NG branch are a mix of development (ie you can see the history of how some of the backends have been developed), and updates that Jef has taken and merged back (sometimes in different versions), and various updates related to interface changes (either the libdivecomputer iostream changes, or just our own cleanups to unify the field cache and string helpers. Jef - that "Suunto Eon Steel: sort the dive list properly" commit is very much a bug-fix. You should take it, regardless of any subsurface interface issues. So is the BlueLink Pro thing, for that matter. The rest is mostly either new backends (ie the Garmin Descent and the Deeplu Cosmiq), or the extended string interface support. Anyway, exactly *because* the new tree is bit-for-bit identical between the NG and DS9 branches, there's no difference on a code level between the two, and the only real difference is that DS9 makes it much easier to see what the changes are from Jef's point. Dirk, I'm not sure you care deeply. I decided to do it mainly because I wanted to know what our state was. It's not too bad. The only really annoying thing I found was the 'unsigned int serial' number differences to the parser creation fucntions, but those haven't been much of a pain lately. But if you think that switching over to the DS9 branch makes sense, that would make it (possibly) easier to do any backporting of our work (or, alternatively, just do this kind of rebase again in a couple of years, to keep track of our differences wrt Jef's upstream and never let them become too overwhelming). Linus

3 2

Release versions
by Vincent Hagen 12 May '20

12 May '20

Hi Jef and others, I was wondering, the last release of libdivecomputer was from 2017 which was v6. Are there any plans to create another release? Or is the general idea to use the latest version on the master branch? If it is the idea to use the latest master version, what about the documentation on http://www.libdivecomputer.org/manual.html? I used it for integrating v5, but it seems out of date with the master. If so, do you accept any contributions for the manual, when I implement the newer version of libdivecomputer into my application, I can write something up for you. With kind regards, Vincent Hagen

2 1

PID/VID list: is it complete?
by Christof Arnosti 06 Mar '20

06 Mar '20

Hi, I'm currently implementig usb-serial-for-android support in subsurface (https://github.com/Subsurface-divelog/subsurface/pull/2647). For the list of VID/PIDs of the supported dive computers I'm currently looking at https://www.libdivecomputer.org/drivers.html. Do you know if this list is current or if there are some possibly missed pairs? Thanks in advance Christof

2 2

Suunto D5 USB interface
by Brendan Horan 12 Jan '20

12 Jan '20

Hi all, >From my understanding the Suunto D5 is supported via bluetooth. This commit seems to support that. https://github.com/libdivecomputer/libdivecomputer/commit/0dc10062ced1be609… However I do not think the D5 is supported via USB connectivity? The only kernel messages I see are : -------------------------- hid-generic 0003:1493:0035.0012: hiddev97,hidraw4: USB HID v1.01 Device [Suunto GURU3] on usb-0000:03:00.0-2/input0 -------------------------- I don't get a /dev/tty$$$ device node either. Is this a libdivecomputer limitation or the USB interface may not be supported in the Linux kernel? I also may not have enabled kernel support for the USB device, unsure what it actually is yet. Thank you, Brendan

5 21

Planned changes to the I/O layer
by Jef Driesen 06 Jan '20

06 Jan '20

Hi, In the next few days, I'm planning to commit some non-backwards compatible changes to the I/O layer: A new dc_iostream_ioctl function will be introduced to perform I/O specific requests. This allows to extend the I/O layer with some driver specific features, without having to modify the api. The first candidate to use this feature will be the Oceanic BLE communication. The dc_iostream_set_latency function will be removed, and re-implemented as an ioctl. This function isn't used anywhere in libdivecomputer, and is only relevant for the serial communication. Hence it's a perfect example of a feature than can be implemented as an ioctl. A new dc_iostream_poll function will be added. This provides a more efficient alternative to using using a combination of the dc_iostream_get_available and dc_iostream_sleep functions. For all the built-in I/O transports, these changes will be completely transparent. But users of the custom I/O will need to update their code because the corresponding function pointers will be added/removed to/from the dc_custom_cbs_t structure. Jef

1 1

Cressi Goa/Cartesio support Github Issue #1
by Brendan Horan 04 Nov '18

04 Nov '18

Hi, I am not sure what method the libdivecomputer project prefers github or mailing list. However since I saw an open issue on github I left my feedback there. I am also attaching the dumps I got from portmon in this email encase there are uses who do not wish to use Github. I have a Cressi Goa dive computer. I've used portmon to dump two connections. I hope its right. If not let me know what is missing/wrong and I can try again. The files are : * cressi-goa-full-transfer.LOG , this is a full connection and download from the dive computer to the Cressi application * cressi-goa-app-open.LOG, This is just a dump of attaching the USB interface while the Cressi application is running. Thanks Brendan

2 1

Shearwater Teric
by Dirk Hohndel 09 Sep '18

09 Sep '18

I have a first version of the "Petrel Native Format" log parser working. It turns out that while the Teric is the first Shearwater computer that no longer provides the old "Predator-like" log format, the new format was actually added way back for the Petrel, it just hadn't been documented before. Based on the new documentation we received last week I have modified the parser to figure out which log format the dive computer can provide and updated it to parse the PNF log if that is available. Downloads from my Teric look sane (but I have only a few dives on it and nothing really exciting in those dives). I'll clean up the code and post it on GitHub so people can take a look, and I'll also make test binaries available so people can try it. The interesting part is that this code will be used on most every current Shearwater dive computer because as I said, all but the oldest of them support this format and Shearwater recommends using it instead of the older format. Which means there's a LOT of testing we need to do to ensure that nothing got broken. One of the new things in this log format is a free diving mode that allows storing sample at sub-one-second intervals. I am not decoding those samples, yet. And I am trying to figure out what to do about them in the first place, as a lot of the libdivecomputer (and Subsurface) code assumes a 1 second granularity... Should we drop the additional samples? Should we add them all, just with the same time stamp? Should we increase the time stamp resolution? Thanks /D

1 2

Wisdom 3 Download Problem
by Jack Plunkett 07 Sep '18

07 Sep '18

Hi, I am trying to download new dives from my Sherwood Wisdom 3 Dive Computer. The PC it is trying to communicate with is a Microsoft Surface Pro using Windows 10. Previous dives uploaded easily. Presently getting an error message that says: *"DC_Status_Protocol"* Would appreciate any thoughts. Many thanks. Jack Plunkett

2 1

configure and clock_gettime for macOS
by Peter Balck 07 Sep '18

07 Sep '18

Hi Jef Found a problem regarding the timer.c ifdefs in the dc_timer_new function.. When I build libdivecomputer on my mac running the latest version of macOS the configure script will find the clock_gettime function and define HAVE_CLOCK_GETTIME. This however, will cause anyone running my app on an older version of macOS where clock_gettime is not available to crash. Is there an easy way to override the configure script without changing any of the source or config files ? I also found that logs downloaded from the Mares Smart Apnea have the max and min temperature mixed up. Thanks Peter

2 1

Re: Divecomputer.eu - no gas-changes
by Linus Torvalds 19 Aug '18

19 Aug '18

On Sun, Aug 19, 2018 at 3:47 AM Grey Wolf <megroeger(a)gmail.com> wrote: > > maybe there are two possibilyties: > > the data is transfered to subsurface, but it is not interpreted the right way > the data is not uploaded to subsurface > > I suppose its number 2 ;-) This is a libdivecomputer issue - the Divecomputer.EU support seems to be somewhat bare. It doesn't support any events at all, just the basic dive samples. Jef? Is it a lack of documentation, or you just don't have the data? Linus

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel