- devel - libdivecomputer.org

can't download Oceanic VT3 on linux
by Hamish Moffatt 10 Mar '14

10 Mar '14

Hi, I'm trying to download from my VT3. I've built libdivecomputer 0.4.2 on Linux (64-bit) but downloading is very slow and eventually fails. I've tested with both Subsurface and using the "universal" example. It does retrieve some dive data ok though. Downloading my VT3 does work on Windows though, using Diving Log 5.0 (includes libdivecomputer 0.4.2, 32-bit) or the "universal" app binary which I downloaded directly from the libdivecomputer.org site. I've included a bit of the output log from "universal" on linux below. I checked that nothing else has the port open with lsof - earlier modem-manager was running but I've killed and removed that now. Any suggestions? Thanks, Hamish [0.000037] DATETIME 2014-03-07T01:56:02Z (1394157362) [0.000068] VERSION 0.4.2 [0.000092] Opening the device (Oceanic VT3, /dev/ttyUSB0). [0.000865] INFO: Configure: baudrate=38400, databits=8, parity=0, stopbits=1, flowcontrol=0 [0.001106] INFO: Timeout: value=3000 [0.001115] INFO: Sleep: value=100 [0.101194] INFO: Flush: queue=3, input=263, output=0 [0.101437] INFO: Write: size=2, data=8400 [0.103572] INFO: Read: size=1, data=00 [0.103586] ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:337 (oceanic_atom2_send)] [0.103602] INFO: Sleep: value=100 [0.203686] INFO: Flush: queue=1, input=118, output=0 [0.203937] INFO: Write: size=2, data=8400 [0.204913] INFO: Read: size=1, data=5A [0.208911] INFO: Read: size=17, data=4F43452056543320523244203531324BBF [0.208939] Registering the event handler. [0.208948] Registering the cancellation handler. [0.209039] Downloading the dives. [0.209046] Event: progress 0.00% (0/64992) [0.209067] Event: vendor=4F43452056543320523244203531324B [0.209269] INFO: Write: size=4, data=B1000000 [3.212314] INFO: Read: size=0, data= [3.212333] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [3.212341] INFO: Sleep: value=100 [3.312423] INFO: Flush: queue=1, input=0, output=0 [3.312656] INFO: Write: size=4, data=B1000000 [3.314042] INFO: Read: size=1, data=5A [3.324885] INFO: Read: size=17, data=0416041120081001425800730000000075 [3.324901] Event: progress 0.02% (16/64992) [3.324920] Event: model=16984 (0x00004258), firmware=0 (0x00000000), serial=7300 (0x00001c84) [3.325176] INFO: Write: size=4, data=B1000400 [6.328221] INFO: Read: size=0, data= [6.328240] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [6.328248] INFO: Sleep: value=100 [6.428331] INFO: Flush: queue=1, input=0, output=0 [6.428523] INFO: Write: size=4, data=B1000400 [6.430266] INFO: Read: size=1, data=5A [6.441137] INFO: Read: size=17, data=200210028003480530BE70B70000000019 [6.441154] Event: progress 0.05% (32/63408) [6.441357] INFO: Write: size=4, data=B1005400 [6.443109] INFO: Read: size=1, data=A5 [6.443125] ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:337 (oceanic_atom2_send)] [6.443133] INFO: Sleep: value=100 [6.543215] INFO: Flush: queue=1, input=0, output=0 [6.543519] INFO: Write: size=4, data=B1005400 [6.544642] INFO: Read: size=1, data=5A [6.555511] INFO: Read: size=17, data=39111F172E0CABB4258302172E4B7BB785 [6.555528] Event: progress 0.08% (48/63408) [6.555756] INFO: Write: size=4, data=B1005300 [9.558799] INFO: Read: size=0, data= [9.558818] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [9.558826] INFO: Sleep: value=100 [9.658909] INFO: Flush: queue=1, input=0, output=0 [9.659097] INFO: Write: size=4, data=B1005300 [9.660614] INFO: Read: size=1, data=5A [9.671487] INFO: Read: size=17, data=26861F1F16936AAD3389021F16D7BAB0DE [9.671502] Event: progress 0.10% (64/63408) [9.671799] INFO: Write: size=4, data=B1005200 [9.673490] INFO: Read: size=1, data=A5 [9.673521] ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:337 (oceanic_atom2_send)] [9.673530] INFO: Sleep: value=100 [9.773608] INFO: Flush: queue=1, input=0, output=0 [9.773854] INFO: Write: size=4, data=B1005200 [9.774985] INFO: Read: size=1, data=5A [9.785865] INFO: Read: size=17, data=02111F1E1BA689A22685021E1B292AA91E [9.785881] Event: progress 0.13% (80/63408) [9.786098] INFO: Write: size=4, data=B1005100 [12.789144] INFO: Read: size=0, data= [12.789163] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [12.789171] INFO: Sleep: value=100 [12.889257] INFO: Flush: queue=1, input=0, output=0 [12.889449] INFO: Write: size=4, data=B1005100 [12.890959] INFO: Read: size=1, data=5A [12.901835] INFO: Read: size=17, data=43861F0ACA45B9965088020ACA6C599A5D [12.901851] Event: progress 0.15% (96/63408) [12.902035] INFO: Write: size=4, data=B1005000 [12.903804] INFO: Read: size=1, data=A5 [12.903819] ERROR: Unexpected answer start byte(s). [in oceanic_atom2.c:337 (oceanic_atom2_send)] [12.903827] INFO: Sleep: value=100 [13.003939] INFO: Flush: queue=1, input=0, output=0 [13.004197] INFO: Write: size=4, data=B1005000 [13.005314] INFO: Read: size=1, data=5A [13.016331] INFO: Read: size=17, data=45100F18AAC6E88F09041F09CAFF48943D [13.016347] Event: progress 0.18% (112/63408) [13.016648] INFO: Write: size=4, data=B1004F00 [16.019691] INFO: Read: size=0, data= [16.019710] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [16.019718] INFO: Sleep: value=100 [16.119803] INFO: Flush: queue=1, input=0, output=0 [16.120080] INFO: Write: size=4, data=B1004F00 [16.121183] INFO: Read: size=1, data=5A [16.132159] INFO: Read: size=17, data=24060D18AA57088910090E18AA91588C3F [16.132168] Event: progress 0.20% (128/63408) [16.132373] INFO: Write: size=4, data=B1004E00 [19.135409] INFO: Read: size=0, data= [19.135429] ERROR: Failed to receive the answer. [in oceanic_atom2.c:331 (oceanic_atom2_send)] [19.135437] INFO: Sleep: value=100 [19.235521] INFO: Flush: queue=1, input=0, output=0 [19.235775] INFO: Write: size=4, data=B1004E00 [19.237157] INFO: Read: size=1, data=5A

3 6

[PATCH] Ignore ostc-fwupdate binary
by Anton Lundin 06 Mar '14

06 Mar '14

Signed-off-by: Anton Lundin <glance(a)acc.umu.se> --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 4de81fd..d730b08 100644 --- a/.gitignore +++ b/.gitignore @@ -44,6 +44,7 @@ Makefile.in /examples/n2ition3 /examples/nemo /examples/ostc +/examples/ostc-fwupdate /examples/predator /examples/puck /examples/sensus -- 1.8.3.2

1 0

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