- devel - libdivecomputer.org

Re: libdivecomputer sources?
by Paul-Erik Törrönen 09 Dec '16

09 Dec '16

On 2016-11-17 08:57, Jef Driesen wrote: > Yes, there is the mirror at sourceforge: > git clone git://git.code.sf.net/p/libdivecomputer/code There still is something off with the git.libdivecomputer.org-repo. If I do: $ git clone git://git.libdivecomputer.org/libdivecomputer.git Cloning into 'libdivecomputer'... remote: Counting objects: 7881, done. remote: Compressing objects: 100% (2326/2326), done. remote: Total 7881 (delta 6319), reused 6864 (delta 5551) Receiving objects: 100% (7881/7881), 1.50 MiB | 969.00 KiB/s, done. Resolving deltas: 100% (6319/6319), done. Checking connectivity... done. warning: remote HEAD refers to nonexistent ref, unable to checkout. $ cd libdivecomputer $ git checkout master error: pathspec 'master' did not match any file(s) known to git. $ git ls-remote origin 4df5e490083fe235293d3c17903b48d56100775a refs/heads/release-0.1 154fc82da1f249674cd1e3dd55b8aa0650eb7b2d refs/heads/release-0.2 1a3c919a8255cc35d05d3345a4e8531c38a583ca refs/heads/release-0.3 9f42f6b87d89b9957b266896e75aea3b16d86ab2 refs/heads/release-0.4 a5b009ed0c54b0b57e85735dea82db358b949dcc refs/tags/v0.1.0 c3ea5a16e49224a3007ee4f37b58bae594a84e1b refs/tags/v0.1.0^{} 653ec757a53d3056f24b04537d6bbd29f6de6741 refs/tags/v0.2.0 2ed54a204bb8f8167736505c02747d02a7a02fc9 refs/tags/v0.2.0^{} a52f856209d0b2aa022151471b1473c71bfb9c4c refs/tags/v0.3.0 82fadd89bfe16918904d47558dcea2bb1afcfbc1 refs/tags/v0.3.0^{} 26de43ef6bfba56fe13c3f1c36709ad3d710aed9 refs/tags/v0.4.0 bdd8e06786806bbc2dfa3b2628b7945b3ce25e21 refs/tags/v0.4.0^{} 4e03cd2d6237027a42baa44deadfc005d8542f19 refs/tags/v0.4.1 2d3e7078394f128d08b676e3d59e0f9f3e02963e refs/tags/v0.4.1^{} 00ac0105ffbd52ff30df027ad06ebb4e451c52c5 refs/tags/v0.4.2 9f42f6b87d89b9957b266896e75aea3b16d86ab2 refs/tags/v0.4.2^{} 67f05c38e2172b7b85bc2cfb05c1507e7d861773 refs/tags/v0.5.0 ba0e7224b0fd68fe319b0a0ffb4caaf721b3148b refs/tags/v0.5.0^{} While the clone from Sourceforge says: $ git ls-remote origin 296b13947f2f002929d60aaa29b1d686fc813d55 HEAD 296b13947f2f002929d60aaa29b1d686fc813d55 refs/heads/master 4df5e490083fe235293d3c17903b48d56100775a refs/heads/release-0.1 ... Should the Sourceforge be considered to be the primary source? Poltsi

3 5

shearwater Perdix AI
by Jon Gross 01 Dec '16

01 Dec '16

I have in my greedy little hands a Shearwater Perdix AI computer, which Shearwater says shares the same firmware with the Perdix and the Petrel, but it will have air consumption (if equipped with a sender). Is there anything I can send a developer that would help with support or this? I didn't see it in the list of supported computers. Thanks! -jon

5 12

Patches to add doxygen support to build and add some comments.
by Ryan McLean 22 Nov '16

22 Nov '16

3 8

[ANNOUNCE] Version 0.5.0 now available
by Jef Driesen 03 Oct '16

03 Oct '16

Hi, The v0.5.0 release is now available! http://www.libdivecomputer.org/releases/libdivecomputer-0.5.0.tar.gz After more than three years of development, the v0.5.0 release is long overdue. The main highlights are the support for many new devices, a few new features and lots of bug fixes. This release is fully backwards compatible with the previous one. New features: * Add support for new backends: - aqualand: Citizen Hyper Aqualand - commander: Cochran Commander and EMC - eonsteel: Suunto EON Steel - idive: DiveSystem iDive and iX3M - meridian: Scubapro Meridian, Mantis and Chromis - nitekq: Dive Rite NiTek Q * Add support for many new devices: - Aeris: 500 AI, A300, A300CS, F11, XR-1 NX - Aqualung: i300, i450T, i550T - Beuchat: Mundial 2, Mundial 3, Voyager 2G - Cressi: Giotto, Newton - Dive Rite: NiTek Trio - Heinrichs Weikamp: OSTC 2, 3+, 4, cR and Sport - Hollis: TX1 - Mares: Airlab, Smart, Smart Apnea, Puck 2 - Oceanic: F11, OCi, VTX - Scubapro: XTender 5 - Shearwater: Nerd, Perdix, Petrel 2 - Sherwood: Amphos, Amphos Air, Vision - Subgear: XP-3G, XP-Air - Suunto: Vyper Novo, Zoop Novo - Tusa: IQ-700 - Uwatec: Aladin 2G, Aladin Sport * Add a new sample with the active gas mix. * Add the temperature, tank and divemode fields. * Add support for updating the OSTC and OSTC3 firmware. * Add support for configuring the OSTC3 settings. * Add a new dc_parser_new2 convenience function. Removed/changed features: * The gas change events (SAMPLE_EVENT_GASCHANGE and SAMPLE_EVENT_GASCHANGE2) have been replaced with the new gasmix sample (DC_SAMPLE_GASMIX). The legacy events are considered deprecated, but kept for backwards compatibility. Bug fixes: * Many small improvements Jef

4 3

Problem reading Aladin Pro Ultra w/MemoMouse
by Garry Glendown 22 Sep '16

22 Sep '16

Hi, after some undesirable long diving hiatus I'm getting ready for a nice dive trip in October. In preparation, I started getting my tech stuff up to date. Not using my former XP Notebook, of course the old Datatrak software will (most likely - didn't try) not work on my current Win10 system. Browsing the web I came across the "Subsurface" program, which uses libdivecomputer. As my Notebook doesn't have a native serial port, I am using a USB-Serial adapter (which works fine for other serial connections, like Cisco routers and the likes). Subsurface also recognizes the port correctly, providing it in the Import window by default. I tried to use dctool, but somehow I can't put together the options to even access the serial port, or anything ("No device name or family type specified") - here's the command line I assumed: dctool -d COM6 -f Uwatec -m "Aladin Pro Ultra" download Any idea what I'm doing wrong? Thanks, -garry -- PGP Fingerprint: A79F A33F 5B13 BEB7 A51D 274F F99C 3AE2 4BCB 7015

2 2

[PATCH 3/3] Suunto EON Steel: extend our string space
by Linus Torvalds 30 Aug '16

30 Aug '16

From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Mon, 29 Aug 2016 15:03:02 -0700 Subject: [PATCH 3/3] Suunto EON Steel: extend our string space We only used to save 16 extended strings per dive from the EON Steel download, which is _plenty_: it's not like we actually generate that many strings. Firmware version, battery status, transmitter info - there's just not that many strings. Oops. Except if you have lots of transmitters. Then each wireless transmitter will have three strings each, for transmitter ID and beginning/ending battery status. I only have one, but Andreas Klein has four. And it took me embarrassingly long to realize that he really did have them on the dives, because after the first two transmitter IDs got recorded, the string space filled up and we silently dropped the rest. But I have learnt my lesson. Future generations will talk about how I said "32 strings will be enough for anybody". But at least it should be enough for a few more transmitters. Somebody should extend this some better way, but I'm still chasing other issues. Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> --- src/suunto_eonsteel_parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/suunto_eonsteel_parser.c b/src/suunto_eonsteel_parser.c index 8a7d3d15cbc8..fc1301d94139 100644 --- a/src/suunto_eonsteel_parser.c +++ b/src/suunto_eonsteel_parser.c @@ -80,7 +80,7 @@ struct type_desc { #define MAXTYPE 512 #define MAXGASES 16 -#define MAXSTRINGS 16 +#define MAXSTRINGS 32 typedef struct suunto_eonsteel_parser_t { dc_parser_t base; -- 2.10.0.rc0.2.g0a9fa47

1 0

[PATCH 2/3] Suunto EON Steel: initialize the tank 'gasmix' index
by Linus Torvalds 30 Aug '16

30 Aug '16

From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Mon, 29 Aug 2016 15:03:02 -0700 Subject: [PATCH 2/3] Suunto EON Steel: initialize the tank 'gasmix' index The gasmix query interface considers cylinders and gas mixes independent things, so the tank data structure has a pointer to the gasmix index. But the EON Steel treats cylinders as just having a gasmix (and so does subsurface, for that matter), so the gasmix index for the tank is just the same as the tank index. But we never filled it in, so you'd always see a "gas index" of zero, and subsurface would end up warning each time about how the gasmix index doesn't match the cylinder index (but because subsurface actually agreed with EON Steel, it worked despite the warning). Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> --- src/suunto_eonsteel_parser.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/suunto_eonsteel_parser.c b/src/suunto_eonsteel_parser.c index bba26ef71fda..8a7d3d15cbc8 100644 --- a/src/suunto_eonsteel_parser.c +++ b/src/suunto_eonsteel_parser.c @@ -1034,6 +1034,7 @@ suunto_eonsteel_parser_get_field(dc_parser_t *parser, dc_field_type_t type, unsi * that metric is (at least so far) always whole liters */ tank->volume = eon->cache.tanksize[flags]; + tank->gasmix = flags; /* * The pressure reported is NOT the pressure the user enters. -- 2.10.0.rc0.2.g0a9fa47

1 0

[PATCH 1/3] Suunto EON Steel: do the proper enum lookup for a few more cases
by Linus Torvalds 30 Aug '16

30 Aug '16

From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Sun, 28 Aug 2016 12:56:09 -0700 Subject: [PATCH 1/3] Suunto EON Steel: do the proper enum lookup for a few more cases Instead of hardcoding the enum values for setpoint type and gas type, use "lookup_enum()" to actually parse the enum data and use that. I don't think this matters right now, since the numeric translations haven't changed, but it is the RigthThing(tm) to do. Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> --- src/suunto_eonsteel_parser.c | 43 +++++++++++++++++++++++-------------------- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/src/suunto_eonsteel_parser.c b/src/suunto_eonsteel_parser.c index 2be21cf0483a..bba26ef71fda 100644 --- a/src/suunto_eonsteel_parser.c +++ b/src/suunto_eonsteel_parser.c @@ -776,21 +776,24 @@ static void sample_event_alarm_value(const struct type_desc *desc, struct sample static void sample_setpoint_type(const struct type_desc *desc, struct sample_data *info, unsigned char value) { dc_sample_value_t sample = {0}; + const char *type = lookup_enum(desc, value); - switch (value) { - case 0: + if (!type) { + DEBUG(info->eon->base.context, "sample_setpoint_type(%u) did not match anything in %s", value, desc->format); + return; + } + + if (!strcasecmp(type, "Low")) sample.ppo2 = info->eon->cache.lowsetpoint; - break; - case 1: + else if (!strcasecmp(type, "High")) sample.ppo2 = info->eon->cache.highsetpoint; - break; - case 2: + else if (!strcasecmp(type, "Custom")) sample.ppo2 = info->eon->cache.customsetpoint; - break; - default: - DEBUG(info->eon->base.context, "sample_setpoint_type(%u)", value); + else { + DEBUG(info->eon->base.context, "sample_setpoint_type(%u) unknown type '%s'", value, type); return; } + if (info->callback) info->callback(DC_SAMPLE_SETPOINT, sample, info->userdata); } @@ -1110,24 +1113,24 @@ static int add_gas_type(suunto_eonsteel_parser_t *eon, const struct type_desc *d { int idx = eon->cache.ngases; dc_tankinfo_t tankinfo = DC_TANKINFO_METRIC; + const char *name; if (idx >= MAXGASES) return 0; eon->cache.ngases = idx+1; - switch (type) { - case 0: - tankinfo = 0; - break; - case 3: + name = lookup_enum(desc, type); + if (!name) + DEBUG(eon->base.context, "Unable to look up gas type %u in %s", type, desc->format); + else if (!strcasecmp(name, "Diluent")) tankinfo |= DC_TANKINFO_CC_DILUENT; - break; - case 4: + else if (!strcasecmp(name, "Oxygen")) tankinfo |= DC_TANKINFO_CC_O2; - break; - default: - break; - } + else if (!strcasecmp(name, "None")) + tankinfo = 0; + else if (strcasecmp(name, "Primary")) + DEBUG(eon->base.context, "Unknown gas type %u (%s)", type, name); + eon->cache.tankinfo[idx] = tankinfo; eon->cache.initialized |= 1 << DC_FIELD_GASMIX_COUNT; -- 2.10.0.rc0.2.g0a9fa47

1 0

[PATCH 0/3] Some EON Steel libdivecomputer fixups
by Linus Torvalds 30 Aug '16

30 Aug '16

So I've been looking at the EON Steel backend because Andreas Klein has a slightly more complex situation than the one I use, notably multiple wireless transmitters. That showed a few issues. The first patch actually predates all this work, and was just a cleanup from before. The two other patches are trivial fixes for trivial issues I've found so far. One causes an annoying and misleading warning in subsurface, and the other one results in the transmitter information not being saved if you have more than two wireless transmitters. The actual *big* problem is that subsurface itself doesn't handle the issue of multiple concurrent transmitters right. Most (all?) other dive computers just give the pressure for the currently selected cylinder, if they support multiple pressure sensors at all. But these are real cleanups/fixes regardless. Linus Torvalds (3): Suunto EON Steel: do the proper enum lookup for a few more cases Suunto EON Steel: initialize the tank 'gasmix' index Suunto EON Steel: extend our string space src/suunto_eonsteel_parser.c | 46 ++++++++++++++++++++++++-------------------- 1 file changed, 25 insertions(+), 21 deletions(-) -- 2.10.0.rc0.2.g0a9fa47

1 0

Re: new restaurant opening
by david.lerouesnier 12 Aug '16

12 Aug '16

Hi friend! I've heard about a new fish restaurant opening next saturday, are you planning to go there? Here is some info about that <http://ntywophyva.hairon5thavenue.com/lnczrj> Yours, david.lerouesnier

1 0