devel

devel@libdivecomputer.org

3 participants
290 discussions

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

Problems while using divecomputer-simulator for linux
by Venkatesh Shukla IIT BHU 02 Apr '14

02 Apr '14

Hello guys I am facing certain errors while trying to use simulator with universal script. I have taken the following steps. 1. I git cloned the libdivecomputer repository. Then I used these commands to compile and build. $ autoreconf --install $ ./configure --enable-pty --disable-shared $ make $ sudo make install 2. Then I used socat to make virtual serial connections. I confirmed that files ttyS0 and ttyS1 are present in /tmp folder $ socat PTY,link=/tmp/ttyS0 PTY,link=/tmp/ttyS1 3. I attached binary of Suunto Gekko to /tmp/ttyS0 $ ./simulator-linux -b vyper -p /tmp/ttyS0 -l simulator.logs gekko.linus.bin > CONFIGURATION: > backend=3 > devname=/tmp/ttyS0 > devtime=0 > systime=0 > model=0 > filename=gekko.linus.bin > size=8192 > header=gekko.linus.bin.header, size=0 > systime=gekko.linus.bin.systime, ticks=0 > lines=0 0 > is_spyder=0 4. I tried to download the dive data present in this binary by using both subsurface and the universal script. $ ./universal -n "Suunto Gekko" -b vyper -l divedownload.log -d divelogs.xml /tmp/ttyS1 > DATETIME 2014-03-30T18:00:39Z (1396202439) > VERSION 0.5.0-devel (fa90009c293a9ca1a4eaf49a478b381477695c0a) > Opening the device (Suunto Gekko, /tmp/ttyS1). > ERROR: Invalid argument (22) [in ../../source/src/serial_posix.c:415 (serial_configure)] > ERROR: Failed to set the terminal attributes. [in ../../source/src/suunto_vyper.c:121 (suunto_vyper_device_open)] > ../../source/examples/universal.c:681: Error opening device. > Result: Input/output error It used to work earlier. I don't understand what went wrong. I also tried switching to the release-0.4 branch. But the error persists. Can anyone please help? *Venkatesh Shukla B. Tech ( Electrical Engineering )III YearIndian Institute of TechnologyBanaras Hindu UniversityPh No. +91 8960 579 122* *Email: venkatesh.shukla.eee11(a)iitbhu.ac.in <venkatesh.shukla.eee11(a)iitbhu.ac.in>*

4 12

[PATCH] Fix building for Android
by Anton Lundin 28 Mar '14

28 Mar '14

This makes libdivecomputer build via Android NDK. Its currently unusable due to the fact that Android usually doesn't provide any kernel serial drivers. Signed-off-by: Anton Lundin <glance(a)acc.umu.se> --- src/serial_posix.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/serial_posix.c b/src/serial_posix.c index 2748957..fc0e79e 100644 --- a/src/serial_posix.c +++ b/src/serial_posix.c @@ -53,6 +53,11 @@ #define NOPTY 1 #endif +/* Android is missing tcdrain, so use ioctl version instead */ +#ifdef __ANDROID__ +#define tcdrain(x) ioctl(x, TCSBRK, 1) +#endif + #include "serial.h" #include "context-private.h" @@ -433,7 +438,7 @@ serial_configure (serial_t *device, int baudrate, int databits, int parity, int // Configure a custom baudrate if necessary. if (custom) { -#if defined(TIOCGSERIAL) && defined(TIOCSSERIAL) +#if defined(TIOCGSERIAL) && defined(TIOCSSERIAL) && !defined(__ANDROID__) // Get the current settings. struct serial_struct ss; if (ioctl (device->fd, TIOCGSERIAL, &ss) != 0 && NOPTY) { -- 1.8.3.2

2 4

← Newer
1
...
20
21
22
23
24
25
26
...
29
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel