devel

devel@libdivecomputer.org

291 discussions

Re: devel Digest, Vol 17, Issue 7
by Vincent Cresson 10 Sep '14

10 Sep '14

> > > > According to the usb device descriptors it's a USB HID device. That's > basically > everything I know. Once I discovered libusb doesn't seem to support USB > HID very > well, I didn't investigate much further due to a lack of time. > > I wouldn't be surprised if the high level communication protocol is still > the > same as the other Uwatec devices. For the Meridian Scubapro/Uwatec also > switched > only the low-level layer from IrDA to usb-serial, and kept everything else > the > same. But of course that's just an educated guess, and I could be complete > wrong. > > Jef > > Poor of me, the new scubapro aladin square is not integrated in libdivecomputer (not in subsurface too...), it's the son of the famous uwatec aladin pro... I've just tested hidapi testgui (https://github.com/signal11/hidapi) and i success in connecting scubapro aladin square. What can i do now to help (i'm not a programmer)? Vavincavent

1 0

Re: [PATCH] Added support for parsing temperature in the dive header
by Vincent Cresson 24 Aug '14

24 Aug '14

Is it possible now to have temperature from uwatec Aladin pro? Vavincavent

2 1

help for scubapro aladin square
by vavincavent 23 Aug '14

23 Aug '14

Jef, Poor of me, the new scubapro aladin square is not integrated in libdivecomputer (not in subsurface too...), it's the son of the famous uwatec aladin pro... I've just tested hidapi testgui (https://github.com/signal11/hidapi) and i success in connecting scubapro aladin square. What can i do now to help (i'm not a programmer)? Vavincavent

1 0

[PATCH] Unsigned int type can't be below zero
by Anton Lundin 05 Aug '14

05 Aug '14

This fixes a always false comparison that a unsigned int can never be below zero. This was found when compiling with clang. Signed-off-by: Anton Lundin <glance(a)acc.umu.se> --- src/ihex.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ihex.c b/src/ihex.c index 69df787..46b4b81 100644 --- a/src/ihex.c +++ b/src/ihex.c @@ -142,7 +142,7 @@ dc_ihex_file_read (dc_ihex_file_t *file, dc_ihex_entry_t *entry) /* Get the record type. */ type = data[3]; - if (type < 0 || type > 5) { + if (type > 5) { ERROR (file->context, "Invalid record type (0x%02x).", type); return DC_STATUS_DATAFORMAT; } -- 1.9.1

3 2

Still having issues with a Pro Plus 2
by Philip Balister 10 Jul '14

10 Jul '14

I'm not sure this issue was ever fixed: http://libdivecomputer.org/pipermail/devel/2012-January/000039.html I managed to go diving again this past weekend :) I renamed the old subsurface.ml file and now see this error in the log: INFO: Write: size=6, data=3401A901AC00 INFO: Read: size=1, data=5A INFO: Read: size=68, data=B007FE0617001400288321483500001645005000099F004BC00040001186004BC0E5004000137E004CC0004010147B004CC0C80140001332004CA0014000132D004C90CF INFO: Write: size=6, data=3401A501A800 INFO: Read: size=1, data=5A INFO: Read: size=68, data=2770000E12004D302770100C15004D40892770400910004D3000000000000000006D5E50051E4D56F10BBADCFE002143658754251FDC219F1B1413840D6C0B040A5B089B ERROR: Unexpected number of samples with the same timestamp. [in oceanic_vtpro_parser.c:284 (oceanic_vtpro_parser_samples_foreach)] INFO: Write: size=4, data=6A05A500 INFO: Read: size=1, data=5A INFO: Read: size=1, data=51 libdc is installed from the Fedora 20 rpm. libdivecomputer-0.4.2-1.fc20.x86_64 libdivecomputer-devel-0.4.2-1.fc20.x86_64 I'm using subsurface master. Let me know if you need any other info. Thanks Philip

2 4

Programming questions
by John Van Ostrand 07 Jul '14

07 Jul '14

Hi, I've started writing libdivecomputer code for the Cochran and I have a few questions that I expect are easy answers. 1. I'm wondering how much I should read in the _init function. It seems I should read enough to verify I'm talking to the right device and get the serial number. Is that right? 2. There are other reads I can do that will get things like # of dives, gas mixtures, conservatism, etc. I need number of dives to read the log book. Should I do this in _read? And does it make sense to do this read before setting progress information? 3. I have extra information that I can offer the user, pre- and post-dive things like battery voltage, tissue load, time to fly, previous SIT, repetitive dive count and dive profiles samples like tissue load every 24 seconds, NDL remaining (I think), deco required (I think), ascent rate. I can also get post dive off-gassing tissue load and temperature samples. The DC continues to log samples until off-gassed I can't see any structure for all of this, or a way to carry around that kind of data. 4. The DC requires some prodding to accept commands, after being prompted it emits a byte every second. Initially it's a 0xAA but after reading dive samples it's a 0x00. The only way I've been able to prompt it is to send a byte to it. The vendor software doesn't do this. Could it be a USB signal of some sort. I see "Sync Reset Pipe and Clear Stall" in the USB capture and "Vendor Device" and "Control transfer". Any ideas on what I might try? -- John Van Ostrand At large on sabbatical

2 1

Help needed decoding data
by John Van Ostrand 03 Jul '14

03 Jul '14

Hi All, I've been staring at and playing with this data for a week now and I don't feel any closer to deciphering the dive profile sample data from my Cochran EMC-20H. Personally I love a challenge like this and I'm hoping some of you do as well because this one is tough. Instead of digging into a good book this weekend why not sit back with a laptop or tablet and this puzzle. You'll find everything you need at the link below. I've removed the mundanely easy work from this puzzle. Included are binary files, annotated hexdumps to illustrate the data and some programs to extract and display data (don't judge, these are quick and dirty programs.) Start with the README and you'll be into the fun part within minutes. https://drive.google.com/file/d/0B-VD5cn7zgGHN1pVRWpib2pJc0k/edit?usp=shari… -- John Van Ostrand At large on sabbatical

4 9

[Patch] Added --with-examples option to configure
by Venkatesh Shukla 30 Jun '14

30 Jun '14

Example scripts may not be needed always. It might be a helpful option to disable its compilation. Added option of disabling using --with-examples=no option in for autoconf. Please find the attached patch. Regards -- *Venkatesh Shukla*

2 1

Libdivecomputer Android API discussion
by Venkatesh Shukla 30 Jun '14

30 Jun '14

Hello I have been working on bringing libdivecomputer on android. I have started with support for ftdi-chipset based divecomputers. For talking with ftdi based devices on android, I have implemented serial_ftdi.c. . I have tried to implement all the the necessary functions. Though some of them are left out due to their unavailability in libftdi. These left out functions are 1. serial_set_break - This is used only in reefnet_sensus_pro hanshaking. I do not know if it uses ftdi chipset. If it does, it would become important to implement this function. In the present implementation, it remains unusable. 2. serial_send_break - I could not find any usage of this function in libdivecomputer. 3. serial_get_transmitted - Even though the received bytes in the buffer can be accessed, I couldn't find any way to get the transmitted bytes. This function is used internally for logging. Returns -1 as it is not implemented. Changes made for building libdivecomputer for android are 1. Check for presence of libftdi1 2. serial_ftdi.c is compiled and used instead of serial_posix.c 3. libftdi1 is included in Libs.private in libdivecomputer.pc All these changes can be viewed here <https://github.com/venkateshshukla/libdivecomputer>. I have been testing it with universal script and subsurface-android. Results have been encouraging. Now, toward providing a workable API for android, I have following points in mind. These were mentioned by Jef in an earlier mail. 1. Support for only ftdi devices are implemented for now. But support for other chipsets need to be included later on. Hence, serial_ftdi.c alone is not enough. We need a serial_android.c which will redirect calls to respective chipset specific scripts. 2. I have come to the conclusion that for android, it will be best if we pass the file descriptor of the USB device after acquiring the necessary permissions. This fd can be used to create a libusb_device and subsequently all USB related features can be accessed. For making a libusb_device from file descriptor obtained from android, I had tweaked libusb. This tweaked version is present here ( https://github.com/venkateshshukla/libusb ). This libusb_device could be used to obtain VID and PID and then control can then be branched accordingly to ftdi, pl2303, cp210x and other chipset specific scripts on android. 3. We will require a generalized mechanism for passing parameters. This is especially needed now as we have several branches - Normal TTY usage ( posix/win32 , path to the device), android (file descriptor) and Bluetooth address. Please provide your thoughts on the above points. Also any other thing that I should keep in mind for android API? -- Venkatesh Shukla

3 4

Re: Working with bits
by Jef Driesen 11 Jun '14

11 Jun '14

On 2014-06-10 20:44, Linus Torvalds wrote: > On Tue, Jun 10, 2014 at 11:26 AM, John Van Ostrand > <john(a)vanostrand.com> wrote: >> >> I can create a function that extracts the bits into handy to use >> values and >> another to insert the bits back in. I can also use a struct with bit >> positions. >> >> What would you suggest is the best and portable way to handle this? > > I would strongly argue against using structures and bitfields, and > instead encourage using helper functions to extract bits. > > The structures with bitfields approach can result in nice source code, > but it tends to be a minefield of portability (you add the issue of > bit order in addition to the regular byte order). And that may not be > a huge deal for subsurface where all the current targets are x86, but > with hopefully eventually Android ports etc, it's just a bad direction > to go down. > > Also, bitfields work really badly when the data stream has things like > conditional bytes in the middle (which is what communication protocols > tend to have), so you easily end up with using bitfields that are just > for a particular part of the stream, and then doing byte offsets to > get to those bitfields. So you end up with this unholy mess of > "structure with bitfields cast at offset X". You're better off with a > helper function that says "extract X bits at bit offset Y" instead. I can only agree with Linus. For libdivecomputer, I'll simply not accept non-portable code (with only one small exception in the platform specific parts). Thus no structures with bitfields. Most bit manipulations aren't that ugly, and usually all you need is a simple mask with a right shift: value = (byte & 0xAB) >> C; Jef

1 0

← Newer
1
...
19
20
21
22
23
24
25
...
30
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel