- devel - libdivecomputer.org

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

[PATCH] Minor error in serial_configure
by Venkatesh Shukla 28 May '14

28 May '14

I have attached a patch to a minute mistake that I noticed in the code. -- *Venkatesh Shukla*

3 5

Qt Bluetooth and maybee serial support
by Anton Lundin 22 May '14

22 May '14

Hi. I just saw that Qt 5.3 was released and that contains bluetooth support, and that includes android too: http://qt-project.org/doc/qt-5/qtbluetooth-index.html I think it would be awesome if we could add Qt Bluetooth support to libdivecomputer, and while where at it, maybe Qt Serial support to. We would probably build them as a default-off build option. Do you think it would be a patch you can accept Jef? At least one if the libdivecomputer based apps, Subsurface, is built with Qt and it would be a nice way to abstract it away. And it would probably help a bit in getting Subsurface more usable on Android. //Anton -- Anton Lundin +46702-161604

3 2

Native bluetooth communication
by Jef Driesen 07 May '14

07 May '14

Hi, The last few days, I received several questions related to the status of native bluetooth communication. In order to avoid having to repeat myself, let's give a small overview of the current status. A while ago, I have been prototyping a native bluetooth communication backend for libdivecomputer. The goal is to be able to replace the serial emulation in the future. The main reason behind this effort is that the current situation, where we rely on serial emulation, is less than ideal. It requires some setup by the end-user, and last but not least it doesn't appear to work very well on linux! I have arrived at a point where I have a functional implementation for windows and linux. With functional, I mean I'm able to connect to the dive computer and successfully download dives. What is still missing is device discovery, which means you have to figure out the bluetooth address of the device manually. Certainly not perfect yet, but it does work! I have attached the patches with my prototype code. These patches include the bluetooth communication code, together with the necessary changes to integrate it into the Shearwater Predator/Petrel backend (the same could be done for the Heinrichs Weikamp Frog too). The linux and windows implementations are very similar because they both provide a socket interface [1,2]. (I actually spend most of the time debugging a failure on Windows. In the end, the problem turned out to be caused by a bug in the mingw header files, and not my code. The bug was already fixed upstream [3], but not yet included in the packages I was using.) I'm now looking at Mac OS X support, but this appears to be much harder than I expected. The developer documentation [4] isn't very helpful. It contains lots of information, but appears to lack the info I'm looking after (e.g. how to connect to a device, send/receive data, etc). The fact that I don't have any experience with Objective-C code or the Mac framework doesn't really help either. So if anyone can provide some assistance here, that would be great! Ideally, I would like to avoid using Objective-C code completely and use the C api of the Mac framework instead. Of course help is not limited to the Mac OS X part only. If you have some knowledge about bluetooth in general, or have some experience with the Windows/Linux bluetooth api's, then any help in that area is appreciated too! [1] http://people.csail.mit.edu/albert/bluez-intro/ [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa362932%28v=vs.85%… [3] http://sourceforge.net/p/mingw-w64/code/6249/ [4] https://developer.apple.com/library/mac/#documentation/DeviceDrivers/Concep… Jef

2 1

setting aside SAMPLE_EVENT_xxx ranges for applications
by Dirk Hohndel 07 May '14

07 May '14

Hey Jef, chasing a bug in Subsurface today I realized that we are abusing existing event types internally since we don't have reserved event types that we know will not be used by libdivecomputer in the future. I guess there would be two solutions: a) we ask you to add events that you haven't seen in any dive computer, yet, so we can use them as synthetic events for our own purposes (so far this is only a "setpoint change" event that we use in the planner). b) you add a reserved range of numbers that we can simply redefine SAMPLE_EVENT_APP_RESERVED_1 ... SAMPLE_EVENT_APP_RESERVED_8 (or some reasonable number) Then we can do a #define SAMPLE_EVENT_SUBSURFACE_SP_CHANGE SAMPLE_EVENT_APP_RESERVED_1 and all is well. What do you think? /D

3 9

Hollis TX1
by Tino Mueller 02 Apr '14

02 Apr '14

Hi Jef, I've purchased two Hollis TX1 trimix dive computers last week and thought you may be interested in getting some logdata. As I am a Diving Log user I would like to import my dives direct via your universal downloader, if possible. I have attached a dive download (2 dives) and a dive computer settings download. Log files are in Hex and have been captured via "SerialMon" (http://www.serialmon.com) I'm happy to provide more data if you need. Best regards, Tino

2 1