June 2014 - devel - libdivecomputer.org

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

Working with bits
by John Van Ostrand 10 Jun '14

10 Jun '14

Hi All, Most of the configuration for the Cochran is stored in bits and I'm wondering how experience programmers would handle this. Here's a sense of the data: short int a5 consists of byte 0 : alarm clock minute byte 1, bit 7: alarm clock on byte 1, bits 6-0: alarm clock hour There are also 3 and 4 bit integers stored in bytes. Finally there are decimals stored as byte 0: decimal fraction * 256 byte 1: integer portion 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? Thanks -- John Van Ostrand At large on sabbatical

2 1

Advice for working with bits
by John Van Ostrand 10 Jun '14

10 Jun '14

Hi All, Most of the configuration for the Cochran is stored in bits and I'm wondering how experience programmers would handle this. Here's a sense of the data: short int a5 consists of byte 0 : second -- John Van Ostrand At large on sabbatical

1 0

Fwd: FTDI interface and Cochran EMC-20H
by John Van Ostrand 10 Jun '14

10 Jun '14

On Tue, Jun 10, 2014 at 9:15 AM, Jef Driesen <jef(a)libdivecomputer.org> wrote: > On 2014-06-10 00:27, John Van Ostrand wrote: > >> I recently purchased a Cochran EMC-20H which uses a FTDI USB chip to >> interface with the dive computer. I'm trying to initiate a conversation >> with the device using my own code to see if my understanding of the >> protocol is correct. I'm not getting what I expect and I think it has to >> do >> with my lack of understanding how the FTDI chip normally interfaces with >> devices like this. Is there anyone who can help me figure out what is >> wrong >> with the communication method? >> >> I've tried: >> >> cu -l /dev/ttyUSB0 -s .... -e -o and I get a stream of the same wrong >> character (~). >> > > I doubt this will work. Most dive computers use a request/response type of > communication, which means you have to send/receive specific data packets. > I could be wrong, but I don't think cu can do that. Cochran does non-printable characters in their protocol, but it's not packet based. For the most part it's send two bytes, read a fixed length response but in some cases it's a 6 byte request. typically with 0x00, and you're right, those are hard to type. > libftdi using ftdi_write_data and ftdi_read_data and I'll get FFs some 00s >> > > In theory using libftdi should work, although I haven't tried that myself. > Note that there is currently someone porting libdivecomputer to libftdi for > use on Android. So if you would like to go that route, it would a good idea > to share knowledge. > > > C language write/read using serial interface >> > > That's what libdivecomputer is doing. I suggest you start with this. Have > you already tried using the libdivecomputer serial communication code? I haven't. I'll take a look to see if I can use that code. From what you're saying Cochran might be an anomaly. I've wondered if the Cochran DC is using serial or the FTDI library. It doesn't ask for a serial port, it discovers it when plugged in. I'm wondering what it's doing because there are USB control packets that I can't seem to recreate and they seem to wake up the DC. > > I've captured a conversation using USBLyzer on Windows 7 and if my >> understanding of the data is correct I know some of the protocol but I >> have >> yet to receive anything that looks like good data using any of the methods >> I've tried. >> > > The ftdi chips use some data bytes (two bytes per usb packet if I remember > correctly) to communicate status. If you capture the usb communication, > you'll capture those status bytes too, but they are not part of the dive > computer communication. To reverse engineer the dive computer communication > protocol, it's easier to capture the serial communication instead, because > then you no longer have to deal with the USB and/or ftdi overhead. > Thanks, I caught onto the modem status bytes early and ignored them. Libftdi does strip them for me when doing a read. I finally had some success last night. I skeptically have reliable communications happening. I noticed 0xAA bytes in the data from the DC every second (among the modem status bytes every 16ms) and it seems that 0xAA is a token after which it's okay to communicate with the device. These won't happen by themselves. I've been able to wake up the DC by sending a null, and after about 500ms I get a 0xAA and I can communicate. Somehow Cochran's Analyst software is able to elicit these regularly without sending data like I've done. I see a USB Vender then a Control message before Analyst starts a conversation and this somehow wakes up the DC. I haven't been able to recreate this even when using a USB reset or buffer flush. I'm not sure what's causing this. I wonder if Analyst is closing the port (USB or serial) and opening on every conversation. I still am using libftdi to communicate but I'll look at switching to see if I can get the same results using a serial interface. -- John Van Ostrand At large on sabbatical -- John Van Ostrand At large on sabbatical

1 0

FTDI interface and Cochran EMC-20H
by John Van Ostrand 10 Jun '14

10 Jun '14

Hi All, I recently purchased a Cochran EMC-20H which uses a FTDI USB chip to interface with the dive computer. I'm trying to initiate a conversation with the device using my own code to see if my understanding of the protocol is correct. I'm not getting what I expect and I think it has to do with my lack of understanding how the FTDI chip normally interfaces with devices like this. Is there anyone who can help me figure out what is wrong with the communication method? I've tried: cu -l /dev/ttyUSB0 -s .... -e -o and I get a stream of the same wrong character (~). libftdi using ftdi_write_data and ftdi_read_data and I'll get FFs some 00s C language write/read using serial interface I've captured a conversation using USBLyzer on Windows 7 and if my understanding of the data is correct I know some of the protocol but I have yet to receive anything that looks like good data using any of the methods I've tried. -- John Van Ostrand At large on sabbatical

3 2