Can bitrates for Apeks/Dive Rite/Zeagle be configured?

[Andreas Hotz]

I am using subsurface 4.9.3 on linux mint 18  64bit and an Cressi Archimede II, which is not supported. After importing the native logbook of the computer into divelog.de and from there to subsurface, I found out that the Archimede II is citizen made and should be equivalent to Apeks Quantum X, Dive Rite NiTex Trio or Zeagle N2iTON3. So I tried these drivers without success. No data is read at all. The log says:

Subsurface: v4.9.3, built with libdivecomputer v0.7.0-devel-Subsurface-NG (ce6d9896a79afaa82641132e338f8744714c8593)
INFO: Open: name=/dev/ttyUSB0
INFO: Configure: baudrate=4800, databits=8, parity=0, stopbits=0, flowcontrol=0
INFO: Timeout: value=1000
INFO: Purge: direction=3
INFO: Write: size=6, data=02010041BF03
INFO: Read: size=6, data=02010041BF03
ERROR: Failed to receive the answer. [in zeagle_n2ition3.c:91 (zeagle_n2ition3_packet)]
INFO: Write: size=13, data=0208004DC07E40000000003503
INFO: Read: size=13, data=0208004DC07E40000000003503
ERROR: Failed to receive the answer. [in zeagle_n2ition3.c:91 (zeagle_n2ition3_packet)]
ERROR: Failed to read the configuration data. [in zeagle_n2ition3.c:264 (zeagle_n2ition3_device_foreach)]

My guess is the baudrate. 4800 is definitely wrong. I'd like to try 9600 or 19200 or even higher. Even if the cressi would not use identical data like its clone from the other companies, at least I could get more information. But I cannot change any comm parameters. Are they really hardcoded into subsurface? This is somewhat hard to believe. Any tip?

Thanks

Andreas

[Jef Driesen]

On 2020-03-04 22:13, Andreas Hotz wrote:
> I am using subsurface 4.9.3 on linux mint 18 64bit and an Cressi
> Archimede
> II, which is not supported. After importing the native logbook of the
> computer into divelog.de and from there to subsurface, I found out that
> the
> Archimede II is citizen made and should be equivalent to Apeks Quantum
> X,
> Dive Rite NiTex Trio or Zeagle N2iTON3. So I tried these drivers
> without
> success. No data is read at all. The log says:

Those models were manufactured by Seiko, not Citizen. Under the hood,
they all use the "n2ition3" backend. That's why you'll always get the
same result when selecting on of those models. There is another group of
Seiko based dive computers supported with the "edy" backend. You could
try that one by selecting the Cressi Edy. No guarantee it will work,
because the Archimede might use a different protocol, but it's worth
trying.

> My guess is the baudrate. 4800 is definitely wrong. I'd like to try
> 9600 or
> 19200 or even higher. Even if the cressi would not use identical data
> like
> its clone from the other companies, at least I could get more
> information.
> But I cannot change any comm parameters. Are they really hardcoded into
> subsurface? This is somewhat hard to believe. Any tip?

Why do you think changing the baudrate will make downloading work?

Both the sender and receiver side need to use the same baudrate (and
other) setting. Otherwise the serial communication will fail because the
other side won't be able to decode the signal correctly. In our case the
settings are chosen by the dive computer. So yes, the baudrates are
indeed hardcoded to the values used by the dive computer. If not,
downloading would fail.

Jef

[Andreas Hotz]

Why I want to change the baudrate? Because otherwise things won't work, as you wrote. I know that the computer uses a fixed baudrate, and I am 100% sure is not use the rate shown in the log. Therefore communication must fail, even if suburface would now the coding of the data. The subsurface FAQ tells people to send in a data dump if support for an additional dive computer is requested. How can I accomplis this if subsurface does not allow me to specify the com parameters?

Regards

Andreas

[Andreas Hotz]

Addition to my post: Of course you are right, it is a Seiko computer. Seems I's better onsult my own notes before writing :-(. I already tried the Edy driver, which tries both 1200 and 4800, but to no avail. So I am still stuck. I should be able to try the Zeagle protocol, but with other com parameters than 4800

Andreas

[Jef Driesen]

On 2020-03-05 10:47, Andreas Hotz wrote:
> Why I want to change the baudrate? Because otherwise things won't work,
> as
> you wrote. I know that the computer uses a fixed baudrate, and I am
> 100%
> sure is not use the rate shown in the log. Therefore communication must
> fail, even if suburface would now the coding of the data.

How do you know the baudrate is different? Is that based on some
evidence (e.g. from capturing the communication, decompiling the Cressi
application, or something like that), or just a guess?

> The subsurface
> FAQ tells people to send in a data dump if support for an additional
> dive
> computer is requested. How can I accomplis this if subsurface does not
> allow me to specify the com parameters?

The memory dump is mainly for diagnostics purposes, and for adding
support for new models using the same communication protocol. If the
communication protocol is different, you'll need to capture the
communication between the dive computer and the Cressi application. Note
that for the Seiko computers, that's a bit complicated because they
don't use a standard usb-serial driver. So a serial capture application
doesn't work and you'll need to capture at the USB level.

Jef

[Andreas Hotz]

I was an early user of thr Archimede II a long time ago, and the first serial interface I got from cressi was a hardware mess of several pieces that were cluttered together in an intable way. So I gave it back. They replaced it a year later with a neat, gripper like device with usb. Still works like a charm. At the moment, I run if with PC Logbook  in a VM with WinXP, which hosted on Linux Mint 18.2.

Back to your question:The software that came with the first hardware was not much better than the hardware. It had two settings, one with 9600 and one with 19200. I don't remember which it was, but it was not 4800. That is why I looked for the possibility to try different settings for the com parameters. It would hard to figure out the correct settings from the result you get. Back in the time of serial modems and accustic couplers in the eighties you had to do this on a regular basis.Both Seiko setups (one with 4800 and one with 1200 and 4800) result in absolutely no data received by subsurface

Andreas

[Jef Driesen]

On 5/03/2020 21:04, Andreas Hotz wrote:
> I was an early user of thr Archimede II a long time ago, and the first serial
> interface I got from cressi was a hardware mess of several pieces that were
> cluttered together in an intable way. So I gave it back. They replaced it a year
> later with a neat, gripper like device with usb. Still works like a charm. At
> the moment, I run if with PC Logbook  in a VM with WinXP, which hosted on Linux
> Mint 18.2.
>
> Back to your question:The software that came with the first hardware was not
> much better than the hardware. It had two settings, one with 9600 and one with
> 19200. I don't remember which it was, but it was not 4800. That is why I looked
> for the possibility to try different settings for the com parameters. It would
> hard to figure out the correct settings from the result you get. Back in the
> time of serial modems and accustic couplers in the eighties you had to do this
> on a regular basis.Both Seiko setups (one with 4800 and one with 1200 and 4800)
> result in absolutely no data received by subsurface

For this kind of test, you can easily use libdivecomputer's dctool command-line
application. You can modify the libdivecomputer source code and change the
baudrate. But because I don't know if you are comfortable building from source,
I prepared a modified version that takes the baudrate from an environment
variable. You can download the build here:

http://www.libdivecomputer.org/builds/experimental/linux/dctool-baudrate

First make it executable:

chmod +x dctool-baudrate

And then run with these options:

For n2ition3 backend:

N2ITION3=xx ./dctool-baudrate -vv -l n2ition3.log -f n2ition3 download -o
n2ition3.xml /dev/ttyUSB0

For edy backend:

EDY1=xx EDY2=yy ./dctool-baudrate -vv -l edy.log -f edy download -o edy.xml
/dev/ttyUSB0

Replace "xx" and "yy" with the baudrate you want.

Note that the edy backend uses two different baudrate. There is an initial setup
phase with the EDY1 baudrate (1200), and then a switch to the EDY2 baudrate
(4800) for the actual download. So this not an attempt to probe for the correct
baudrate, just two different phases.

Jef

[Andreas Hotz]

Thank you for your support, I really apreciate it. Building software would indeed bring me some hassle - last time I uses a compiler was in 1985, and it was COBOL. While compiling as such would not be a big problem, I sure would get even more gray hair than I already have, trying to sort out all the dependencies.

Dependencies strike even with the binary you provided: Linux Mint 18.2 seems to miss something required. It does not find a library needed:

 /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./dctool-baudrate)

libm.so.6 is a symbolc link: /lib/x86_64-linux-gnu/libm.so.6 -> libm-2.23.so

apt-get does not find anything containing glibc. Any advice?

Andreas

[Jef Driesen]

On 7/03/2020 12:43, Andreas Hotz wrote:
> Thank you for your support, I really apreciate it. Building software would
> indeed bring me some hassle - last time I uses a compiler was in 1985, and it
> was COBOL. While compiling as such would not be a big problem, I sure would get
> even more gray hair than I already have, trying to sort out all the dependencies.
>
> Dependencies strike even with the binary you provided: Linux Mint 18.2 seems to
> miss something required. It does not find a library needed:
>
>  /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by
> ./dctool-baudrate)
>
> libm.so.6 is a symbolc link: /lib/x86_64-linux-gnu/libm.so.6 -> libm-2.23.so
>
> apt-get does not find anything containing glibc. Any advice?

That's because I build the binary on distro (Ubuntu 19.10) that has a newer
glibc version than yours. Can you try this one:

http://www.libdivecomputer.org/builds/experimental/linux/dctool-baudrate2

Jef

[Andreas Hotz]

This verson works, it delivers a usage summary when run without parameters. I'll try your suggestions and will come back to you asap, hopefully tomorrow.

Many thanks

Andreas

[Andreas Hotz]

Still no working communication. I tried all baudrates with the N2ITION3 protocol from 150 up to 115200, but to no avail. No data is received. I have not tried all possible combinations on the EDY protocol yet, but I do not have much hope. I did some research and found that wireshark should be able to listen to the communication between the dive computer and the PC Logbook Software. I did some digging there too and found the newest version of this software for Windows. In its documentation I saw that during installatio, one has to specify a registration code:

Archimede I: DE51A-5060-1882
Archimede II: DE51B-5060-1882
EDY DE40C-5060-1882

From this I deduct that each computer needs som special handling, even the first and second version of the Archimede. This would explain that there es no reaction of the dive computer to anything dctool sends to it. I think it does not "hear" something that triggers it to send out data. Maybe the codes mentioned above look familiar to something in the EDI and N2ITION3 code to you, so I mentioned them, but I will proceed to get me wireshark and do some espionage on the data communication anyway.

It will take me some time to fiddle with wireshark to listen to the data exchange with the Archimede and will post the results.

Regards

Andreas

[Jef Driesen]

On 2020-03-08 15:01, Andreas Hotz wrote:
> Still no working communication. I tried all baudrates with the N2ITION3
> protocol from 150 up to 115200, but to no avail. No data is received. I
> have not tried all possible combinations on the EDY protocol yet, but I
> do
> not have much hope.

That's what I already expected. This is not about a change in the
baudrate, but a different communication protocol. That explains why you
don't get any response.

I think you can run the Cressi application inside a Windows VM, forward
the USB device tot he VM and capture on the Linux host system.

Jef