<div dir="ltr">On Tue, Jun 10, 2014 at 9:15 AM, Jef Driesen <span dir="ltr"><<a href="mailto:jef@libdivecomputer.org" target="_blank">jef@libdivecomputer.org</a>></span> wrote:<br>
<div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 2014-06-10 00:27, John Van Ostrand wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I recently purchased a Cochran EMC-20H which uses a FTDI USB chip to<br>
interface with the dive computer. I'm trying to initiate a conversation<br>
with the device using my own code to see if my understanding of the<br>
protocol is correct. I'm not getting what I expect and I think it has to do<br>
with my lack of understanding how the FTDI chip normally interfaces with<br>
devices like this. Is there anyone who can help me figure out what is wrong<br>
with the communication method?<br>
<br>
I've tried:<br>
<br>
cu -l /dev/ttyUSB0 -s .... -e -o and I get a stream of the same wrong<br>
character (~).<br>
</blockquote>
<br></div>
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.</blockquote><div>


<br></div></div><div>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.<br>


<br></div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
libftdi using ftdi_write_data and ftdi_read_data and I'll get FFs some 00s<br>
</blockquote>
<br></div>
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.<div>


<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
C language write/read using serial interface<br>
</blockquote>
<br></div>
That's what libdivecomputer is doing. I suggest you start with this. Have you already tried using the libdivecomputer serial communication code?</blockquote></div><div><br>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.<br>


 <br></div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've captured a conversation using USBLyzer on Windows 7 and if my<br>
understanding of the data is correct I know some of the protocol but I have<br>
yet to receive anything that looks like good data using any of the methods<br>
I've tried.<br>
</blockquote>
<br></div>
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.<span><font color="#888888"></font></span><br>


</blockquote></div></div><br><br></div><div class="gmail_extra">Thanks, I caught onto the modem status bytes early and ignored them. Libftdi does strip them for me when doing a read.<br><br>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. <br>


<br></div><div class="gmail_extra">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.<br clear="all"></div><div class=""><div class="gmail_extra">

<br></div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div dir="ltr"><div>John Van Ostrand<br></div><div>At large on sabbatical<br></div><br></div>
</div></div></div>
</div><br><br clear="all"><br>-- <br><div dir="ltr"><div>John Van Ostrand<br></div><div>At large on sabbatical<br></div><br></div>
</div>