MacDive Forums

Nick,

I'm having what appears to be a common connection problem with the Oceanic OC1.

My error is:

Failed connecting to dive computer on serial port '/dev/tty.usbserial-20030001' (Error Code: -6)

I have read forum entries that suggest that this is a cable connection problem and that what is necessary is to jiggle the cable and to try again. After almost three hours of experimentation, I do not believe that this is a cable issue.

I have tested two different (brand new) OC1s, with three different cables, on two different computers, with Mac OS 10.6 and 10.7. I tested MacDive (native) and Oceanic's OceanLog under VMware.

OceanLog worked each and every time with all combinations of PDC and cables. MacDive on the same computer failed to establish a connection approximately 80% of the time. Cable jiggling/wiggling/etc. did not affect connection success rates. Retrying the connection over and over was all that mattered.

My speculation was that there is a timing issue with the initial handshake with the OC1 and that the mac is overrunning the OC1's receive buffer. To test this, I started loading the CPUs with free running apps, and started MacDive with nice. After doing this, the connection failure rate improved dramatically, dropping to around 30%.

I note that when the connection fails, the following is output from MacDive:

/Users/nick/Projects/DiveComputer/Mac/DiveComputer/../../src/oceanic_atom2.c:212: Unexpected answer start byte(s).
/Users/nick/Projects/DiveComputer/Mac/DiveComputer/../../src/oceanic_atom2.c:212: Unexpected answer start byte(s).
/Users/nick/Projects/DiveComputer/Mac/DiveComputer/../../src/oceanic_atom2.c:212: Unexpected answer start byte(s).

Perhaps a delay loop or two in the initial handshake would fix it?

If there is anything that I can do to help narrow if further, please let me know.

Regards,

Denny

Can you follow the instructions in this topic, to generate a detailed logfile?

This topic:

http://www.mac-dive.com/forum/viewtopic.php?f=5&t=407

Nick,

Apologies for the delay. Here is the file with results, both of a bad run (init fails) and of a good run (lots of output).

Note that there are no stored dives in the computer tested. I can hit the pool and put a dive on, but it will be late next week.

Regards,

Denny

Thanks for this - let us take a look and see if we can't get this working a little better/more reliably.

Nick,

I put a couple of dives on the device. Would you like an new upload?

Regards,

Denny

Yes, please - the more the merrier!

Nick,

I've isolated the timing issue in libdivecomputer, and sent an email off to Jef regarding a fix. Email is below for your reference. Please let me know if you would still like the sample files.

Regards,

Denny

-----

Jef,

I've been diagnosing a problem with MacDive and the Oceanic OC1. You can view the forum thread here:

http://www.mac-dive.com/forum/viewtopic.php?f=2&t=965

I pulled the current git repo and did some further experimentation to isolate the problem. There does appear to be a timing problem with the initialization routine for the computer. In oceanic_atom2_init(), we send an initial command sent to the device, followed by a check for an acknowledgement. After the acknowledgement is processed, we call to serial_flush() to discard any additional bytes sent by the device after the ack. The device appears to send quite a bit of additional data, resulting in a race condition between the device sending bytes related to the initial command and the call to serial_flush(). The solution is to add a delay prior to the call to serial_flush(). The diff is below.

Regards,

Denny

-----

diff --git a/src/oceanic_atom2.c b/src/oceanic_atom2.c
index 8465eef..177c045 100644
--- a/src/oceanic_atom2.c
+++ b/src/oceanic_atom2.c
@@ -259,14 +259,15 @@ oceanic_atom2_init (oceanic_atom2_device_t *device)
// Send the command to the dive computer.
unsigned char command[3] = {0xA8, 0x99, 0x00};
device_status_t rc = oceanic_atom2_send (device, command, sizeof (command), NAK);
if (rc != DEVICE_STATUS_SUCCESS)
return rc;

// Discard all additional bytes (if there are any)
+ serial_sleep (1500);
serial_flush (device->port, SERIAL_QUEUE_INPUT);

return DEVICE_STATUS_SUCCESS;
}


static device_status_t

Can you also drop me an email - I will apply your patch after work and send through a beta for you to try, to see if that helps out?

It does need to be tested with various other devices, however.

With the new Macdive version, connecting to the OC1 does work much better.
Thanks dannypage that you took time to look into it....