- devel - libdivecomputer.org

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

Failure to download from OSTC Plus
by Gerard Storey 18 Aug '18

18 Aug '18

Hi I get the error: DC_STATUS_IO and the attached error report when I try to download. Any thoughts on how to rectify this? Many thanks, Gerard Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

1 0

Issue with parsing Mares Quad Air dump file
by Rick Balsano 11 Jun '18

11 Jun '18

Hello - I'm having an issue downloading dives from my Mares Quad Air in Subsurface, so I tried to see what I could find out more directly with libdivecomputer. The only issue I've found with libdivecomputer is the inability to parse a dump file for the Quad Air. I don't think this is related to my Subsurface issue, but figured I'd flag it anyway. I have downloaded and built livdivecomputer on OS X (10.13.4). I generated the attached dump file with: ./dctool -f iconhd -m 35 dump -o mares_quad_air.dump /dev/tty.SLAB_USBtoUART > dctool.log 2>&1 Parsing of the dump file fails: ./dctool -f iconhd -m 35 parse -o mares_quad_air_parsed.xml mares_quad_air.dump Creating the parser. Registering the data. Parsing the dive data. Parsing the datetime. ERROR: Buffer overflow detected! [in mares_iconhd_parser.c:149 (mares_iconhd_parser_cache)] ERROR: Error parsing the datetime. [in output_xml.c:229 (dctool_xml_output_write)] ERROR: Error parsing the dive data. [in dctool_parse.c:73 (parse)] ERROR: Data format error However, direct download of dives works (dive download attached): $ ./dctool -f iconhd -m 35 download -o mares_quad_air_dives.xml /dev/tty.SLAB_USBtoUART I see that dctool_parse calls dc_parser_new2 while dctool_download calls dc_parser_new. Am I wrong in thinking that dctool should be able to parse the dump file and produce the same results as a direct download? Regards, Rick

2 1

dctool: exporting dives to csv
by Simon Eigeldinger 20 Apr '18

20 Apr '18

Hi all, I am Simon and i I am a blind diver. Unfortunately i can't see whats on my dive computer. So i plan to use it as a kind of logger or blackbox. unfortunately most of the applications which are coming with dive computers aren't much accessible to blind and visually impaired people. so i thought it might be interesting to use dctool to get the data out of the computer. i currently don't have a dive computer but i might get a suunto zoop novo. can i export dive data to csv or other format using dctool? i know that the computers measure all their parameters every few seconds. can i get that data out as well? so i can see how fast we where going down and do my own statistics. Greetings and thanks, Simon --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus

3 4

dctool: access denied on win 10 home 64 bit
by Simon Eigeldinger 20 Apr '18

20 Apr '18

Hi all, Just downloaded dctool.exe from http://www.libdivecomputer.org/builds/stable/windows/ when doing a $ dctool --help on the command line i get a hanging program for a while and then the message access denied on the command line. Anyone knows why this is happening? also saw that on win 7 pro 64 bit. no dive computer is connected at the moment. admin privileges are available as well if needed. Greetings, Simon --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus

2 3

Critical bug in OSTC3 backend discovered
by Jef Driesen 19 Apr '18

19 Apr '18

Hi, I just fixed a nasty bug in the ostc3 backend that was introduced with the BLE support (commit 0978f8c0fa70710bad3fb865ffe3a20961c408dc). Ironically everything works fine when using BLE, but not for bluetooth classic or its serial emulation. Please upgrade asap, because this bug not only causes the download to fail, but it also appears to change random settings on the dive computer! Jef

1 0

AW: dctool: exporting dives to csv
by Eigeldinger Simon 18 Apr '18

18 Apr '18

Hi Kristaps, Thanks for the info. My main platform at the moment is Windows, though i have a linux box as well. though i prefer something windows based at the moment. but thanks for the info. sounds interesting to have a look at. Greetings, Simon Mit freundlichen Grüßen Simon Eigeldinger Informatik Nebengebäude 1, OG1 Stadt Hohenems Kaiser-Franz-Josef-Straße 4 6845 Hohenems T: +43 5576 7101-1143 | E: simon.eigeldinger(a)hohenems.at | www.hohenems.at Diese Nachricht und allfällige angehängte Dokumente sind vertraulich und nur für den/die Adressaten bestimmt. -----Ursprüngliche Nachricht----- Von: devel [mailto:devel-bounces@libdivecomputer.org] Im Auftrag von Kristaps Dzonsons Gesendet: Mittwoch, 18. April 2018 04:13 An: devel(a)libdivecomputer.org Betreff: Re: dctool: exporting dives to csv > I am Simon and i I am a blind diver. > Unfortunately i can't see whats on my dive computer. > So i plan to use it as a kind of logger or blackbox. > unfortunately most of the applications which are coming with dive > computers aren't much accessible to blind and visually impaired people. > so i thought it might be interesting to use dctool to get the data out > of the computer. > i currently don't have a dive computer but i might get a suunto zoop novo. > can i export dive data to csv or other format using dctool? > i know that the computers measure all their parameters every few seconds. > can i get that data out as well? > so i can see how fast we where going down and do my own statistics. divecmd (https://kristaps.bsd.lv/divecmd) is built atop libdivecomputer and has all sorts of ways of sifting through data. Including a simple tool for converting to CSV. (Though the XML produced by default is well-documented.) I used dctool as a starting point for it. It's UNIX only, however, and mostly built for freediving analysis. Works for libdivecomputer 0.6.0, though I'll need to retool it somewhat for the coming version. (And will patch the manpages whilst doing so... ;)) _______________________________________________ devel mailing list devel(a)libdivecomputer.org https://libdivecomputer.org/cgi-bin/mailman/listinfo/devel

1 0

I/O layer refactoring finished
by Jef Driesen 03 Apr '18

03 Apr '18

Hi, I just pushed the latest changes for the I/O layer refactoring to the master branch. Unfortunately these changes break backwards compatibility for anyone using libdivecomputer. In a nutshell, the main changes are: * The dc_device_open() function has been modified. Instead of a string with the name of the serial port, it now takes a pointer to a dc_iostream_t. That means that the application becomes responsible for opening the underlying I/O stream. * The dc_descriptor_get_transport() function has been replaced with a new dc_descriptor_get_transports() function (notice the extra "s" in the name). This new function returns a bitmask with all the transports supported by the device. * The dc_context_get_transports() function has been added to query the available built-in transports. These changes enables the use of Bluetooth Classic (rfcomm) with the built-in implementation (Windows and Linux), and Bluetooth Low Energy (ble) with a custom implementation. More details about these new features are in the remainder of this email. With the above changes, the typical sequence to download dives will now look similar to this: 1. Enumerate all supported dive computers and choose one 2. Choose the transport type 3. Ignore unsupported transport types 4. Enumerate the I/O devices 5. Open the I/O stream 6. Connect to the dive computer 7. Download dives Let's have a closer look at each step: 1. Enumerate all supported dive computers and choose one This is exactly the same as before. 2. Choose the transport type This is where the first important change will be. Previously, each device descriptor supported exactly one transport type (serial, usb, usbhid or irda). But with bluetooth we have devices that support more than just one transport. Therefore, the transport type has been changed into a bitmask: typedef enum dc_transport_t { DC_TRANSPORT_NONE = 0, DC_TRANSPORT_SERIAL = (1 << 0), DC_TRANSPORT_USB = (1 << 1), DC_TRANSPORT_USBHID = (1 << 2), DC_TRANSPORT_IRDA = (1 << 3), DC_TRANSPORT_BLUETOOTH = (1 << 4), DC_TRANSPORT_BLE = (1 << 5) } dc_transport_t; Now, each descriptor can support more than one transport, and you can query them using the new function: unsigned int dc_descriptor_get_transports (dc_descriptor_t *descriptor); For example, the Heinrichs Weikamp OSTC 2 will report DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH | DC_TRANSPORT_BLE. 3. Ignore unsupported transport types With support for custom I/O, libdivecomputer no longer knows which devices are actually supported. Hence the #ifdef's will be removed from the descriptor table, and thus libdivecomputer will always report all the devices it knows about. That means it's up to the application to filter out entries for which there is no suitable transport available (either built-in or custom). Therefore libdivecomputer provides a new function to query the built-in transports: unsigned int dc_context_get_transports (dc_context_t *context); This will again return a bitmask with the available built-in transports. With a simple bitwise AND operation, you can easily filter out transports for which no built-in implementation is available: unsigned int supported = dc_descriptor_get_transports(descriptor); unsigned int available = dc_context_get_transports(context); unsigned int usable = supported & available; When using custom I/O, the application should of course also keep the transports for which it has a custom I/O implementation. 4. Enumerate the I/O devices Once you have selected the underlying transport type, you want to scan the system for possible matches. Previously, libdivecomputer did this internally for irda and usbhid, and automatically picked the first available device. For serial communication, applications were supposed to enumerate the serial ports themselves and pass the name of the device node. Since every transport types has different parameters (e.g a vid/pid for usbhid, and address and port for irda and bluetooth classic, etc), this can't easily be extended to arbitrary transport types. Therefore, each of the built-in iostream implementations will provide its own enumeration api, based on the existing iterator api: dc_iterator_t *iterator = NULL; dc_xxx_iterator_new (&iterator, context, descriptor); dc_xxx_device_t *device = NULL; while (dc_iterator_next (iterator, &device) == DC_STATUS_SUCCESS) { dc_xxx_device_get_yyy(device); dc_xxx_device_free (device); } dc_iterator_free (iterator); Where xxx can be replaced with serial, irda, usbhid, etc. For serial, you'll be able to get the device node, for irda/bluetooth the address and device name, for usbhid the vid/pid, and so on. Of course we also don't want to push too much knowledge to the application. Ideally the application shouldn't need to know which VID/PID's match certain dive computers, or things like that. That's why the dc_xxx_iterator_new() function accepts an (optional) descriptor as argument. It will acts as a filter and return only those devices that match the selected dive computer. For example if you scan for usb hid devices with the Eon Steel descriptor, you'll only get devices matching the Eon Steel VID/PID. Same for bluetooth and irda, where we can filter on the device name. Note that for custom I/O, this whole discovery step is obviously always the responsibility of the application. 5. Open the I/O stream The next step is opening the I/O stream. To use one of the built-in implementations, you simply call one of these functions: dc_serial_open (&iostream, context, name); dc_irda_open (&iostream, context, address, 1); dc_usbhid_open (&iostream, context, device); dc_bluetooth_open (&iostream, context, address, 0); The values for the extra parameters (name, address, device, etc) are available from the device discovery in the previous step. To use a custom implementation, you need to implement a set of callback functions, and create an iostream for them as follows: dc_custom_cbs_t callbacks = { app_custom_set_timeout, /* set_timeout */ app_custom_set_latency, /* set_latency */ app_custom_set_break, /* set_break */ app_custom_set_dtr, /* set_dtr */ app_custom_set_rts, /* set_rts */ app_custom_get_available, /* get_received */ app_custom_get_lines, /* get_lines */ app_custom_configure, /* configure */ app_custom_read, /* read */ app_custom_write, /* write */ app_custom_flush, /* flush */ app_custom_purge, /* purge */ app_custom_sleep, /* sleep */ app_custom_close, /* close */ }; dc_custom_open (&iostream, context, transport, &callbacks, userdata); 6. Connect to the dive computer Instead of accepting a string with the device node (which only makes sense for serial communication), you now pass the iostream handle to the dc_device_open() function: dc_status_t dc_device_open (dc_device_t **device, dc_context_t *context, dc_descriptor_t *descriptor, dc_iostream_t *iostream); 7. Download dives This remains exactly the same as before. Jef

1 0