FTDI interface and Cochran EMC-20H

[Venkatesh Shukla]

On Tue, Jun 10, 2014 at 6:45 PM, 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.
>
>
>  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.


Yes. libftdi can indeed be used to exchange data. There are a few things to
keep in mind.

The first would be choosing appropriate baud rate for communication.
Selecting incorrect would lead to no communication. You can look up the
data sheet of the embedded chip and manufacturer provided information to
get this.

The second one would be permissions. This is a big issue. You would get -4
or -8 error codes if you do not have appropriate permissions. You should
make some udev rules as shown here
<http://pylibftdi.readthedocs.org/en/latest/installation.html#debian-raspberry-pi-ubuntu-etc>
to get yourself started.

I have attached a dummy code using which I was successful in download of
data from OSTC3 which has a FT232RL embedded. Modify it to suit your needs.
This is isn't a perfect code and doesn't even work correctly. It just
proves that libftdi can be used for communication.

Also, as Jef said, divecomputer would mostly work on request/response kind
of protocol. You can either decipher it using reverse engineering or
contact manufacturers to see if they are willing to share.


>
>
>  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'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.
>
>
Yes. This is important too. Ftdi chips keep sending status bytes on
interval of 16ms. They are taken in consideration by libftdi and ignored
but might pop up anyway. You have to find a way to deal with them. Visit
this
<http://www.ftdichip.com/Support/Knowledgebase/index.html?an232b_04smalldataend.htm>
for some detail.

One more suggestion. For very small applications, you can use pylibftdi
package for communication. It is python wrapper to actual libftdi. It might
save you some time.

I agree with Jef completely. Let all the ftdi communication details be
handled by your system. It would be easier to deal directly with tty.
-- 
Venkatesh Shukla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20140610/995c393d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: import_divedata.c
Type: text/x-csrc
Size: 8244 bytes
Desc: not available
URL: <http://libdivecomputer.org/pipermail/devel/attachments/20140610/995c393d/attachment-0001.c>