Fwd: FTDI interface and Cochran EMC-20H

[John Van Ostrand]

On Tue, Jun 10, 2014 at 9:15 AM, Jef Driesen <jef at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20140610/100fd4d6/attachment.html>