devel

devel@libdivecomputer.org

3 participants
290 discussions

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

libdivecomputer server migration
by Jef Driesen 20 Jan '18

20 Jan '18

Hi, The libdivecomputer infrastructure is being migrated to another server. This will affect the following services: * Website and mailinglist These services have already been migrated. This is supposed to be fully transparent, although you might experience a little downtime today. * Git The git repository on github will become the primary repository. Sourceforge will remain as a mirror, but the libdivecomputer git server will be shut down at the end of the month. You can easily change the repository url with: git remote set-url origin https://github.com/libdivecomputer/libdivecomputer.git * Trac tickets and wiki The trac bug tracker and wiki pages will also be replaced with github. The existing tickets will NOT be migrated. There are only a few tickets in the system, so it's not really worth the effort. The wiki pages will be imported into github (once I have figured out how to do that). The trac server will also be shutdown at the end of the month. Jef

2 4

Permanent mirror of repository on GitHub?
by Henrik B A 05 Jan '18

05 Jan '18

Hi Jef. Would you consider creating a permanent & updated mirror of libdevcomputer on GitHub? I like browsing the source code in a browser, and GitHub is such a good tool for doing that. The web interface at http://git.libdivecomputer.org/?p=libdivecomputer.git;a=summary is slow, times out a lot, and is really not very usable. Cheers, Henrik

4 7

V3: Coverity / static analysis based cleanups
by Dirk Hohndel 04 Jan '18

04 Jan '18

Third version of this series. I addressed Jef's comments and dropped both patches that dealt with the dc_buffer code as they did more damage than good. Maybe I'll do a new set of patches just for the buffer code if I feel bored later. /D [PATCH 01/12] Cleanup: correctly handle upper bound of array [PATCH 02/12] Cleanup: avoid memory leaks [PATCH 03/12] Cleanup: avoid memory leak [PATCH 04/12] Cleanup: avoid memory leak [PATCH 05/12] Cleanup: avoid memory leak [PATCH 06/12] Cleanup: ensure string is 0 terminated [PATCH 07/12] Cleanup: avoid undefined shift operation [PATCH 08/12] Cleanup: remove dead code and return the correct return [PATCH 09/12] Cleanup: check return value of ioctl() [PATCH 10/12] Cleanup: consistently check return value of iostream [PATCH 11/12] Cleanup: bail on error [PATCH 12/12] Cleanup: remove confusing NULL check

2 14

← Newer
1
2
3
4
5
6
7
...
29
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel