On 2014-06-10 00:27, John Van Ostrand wrote: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.
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 (~).
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.
libftdi using ftdi_write_data and ftdi_read_data and I'll get FFs some 00s
That's what libdivecomputer is doing. I suggest you start with this. Have you already tried using the libdivecomputer serial communication code?
C language write/read using serial interface
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.
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.