TUSA IQ-700 (DC Hunter) Support

[Michael Holmes]

Support for download from the TUSA IQ-700 on windows 7 apparently does not exist anywhere.

I am using Windows 7 Home Premium with Service pack I 

I have the interface sold for the computer but cannot get the TUSA software to install correctly.

Is there any possibility of implementing this computer in Subsurface?

[Dirk Hohndel]

TUSA is one of the many brands of Pelagic... we support many different
variations of their dive computers. Sadly Pelagic has the unfortunate
habit of making small changes from version to version of their dive
computers... the IQ-950, IQ-900, and IQ-750 are all supported by the Atom2
backend, but I believe the IQ-700 actually a rebranded Zeagle N2ition.
Can you try importing with that setting?

And also, could you (in the dialog for downloading from the divecomputer)
check the libdivecomputer dump and libdivecomputer log functions and send
us those two files?

Thanks

/D

[Michael Holmes]

Thanks for the response Dirk, I am unable to get the usb serial device to install correctly for the interface. 

I have included that log file but cannot get the computer to dump. 

Looking at the N2ition it is the same computer from Seiko (Diverite Nitek Duo is also the same computer.)

Currently when I try to download from the computer I get the message "Insuficient privilidges to open the device Zeagle (N2ition)

No com port is indicated.  Any ideas would be appreciated.

Thanks,

Mike

[Jef Driesen]

On 2015-02-10 21:42, Michael Holmes wrote:
> Thanks for the response Dirk, I am unable to get the usb serial device
> to
> install correctly for the interface.
> I have included that log file but cannot get the computer to dump.
> Looking at the N2ition it is the same computer from Seiko (Diverite
> Nitek
> Duo is also the same computer.)
> Currently when I try to download from the computer I get the message
> "Insuficient privilidges to open the device Zeagle (N2ition)
> No com port is indicated. Any ideas would be appreciated.

The IQ-700 is indeed a Seiko based model. But it's using the "edy"
instead of the "n2ition3" protocol. Thus try selecting the "Cressi Edy"
as the device.

On Windows, there is one extra complication. The Seiko application uses
a special usb-only driver, and not the standard prolific usb-serial
driver. This usb-only driver can't be used by libdivecomputer/subsurface
and needs to be replaced. But due to the fact that the pc interface uses
a custom USB VID/PID, the normal prolific driver won't recognize it. So
you need to patch the driver. The procedure is explained here:

http://libdivecomputer.org/drivers.html#seiko
http://libdivecomputer.org/seiko.html

(This procedure was tested a few years ago on Windows XP, but I don't
know if it still works on newer Windows versions.)

Jef

[Michael Holmes]

Thanks for the response Jef, I think I have the drive patched OK (looks right in Device manager at least.) My problem seems to be that the device driver will not start under Windows 7.  I will post a more detailed description of the process I went through at a later time. Particularly if I get it working.

Mike

[Jef Driesen]

On 2015-02-18 00:35, Michael Holmes wrote:
> Thanks for the response Jef, I think I have the drive patched OK (looks
> right in Device manager at least.) My problem seems to be that the
> device
> driver will not start under Windows 7. I will post a more detailed
> description of the process I went through at a later time. Particularly
> if
> I get it working.

If the OS tries to use the driver, then the VID/PID patching is fine. If
the driver refuses to start, there are two possible causes (that I know
of). The first one is the driver signing. The VID/PID patching breaks
the driver signature, so you may have to configure Windows to load
unsigned drivers. The other issue is the check for counterfeit chips in
the latest Prolific driver. If that's the problem, then you'll have to
use an older version of the driver.

http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=155&pcid=41
http://wp.brodzinski.net/hardware/fake-pl2303-how-to-install/

Jef

[Michael Holmes]

After a lot of frustration with Windows 7 I decided to try installing ubuntu on a flash drive to see if I could get some kind of response. I still have not been able to get a dump or a download, but I do have the log file generated so I am uploading it here.  

[Michael Holmes]

Logfile content

INFO: Configure: baudrate=1200, databits=8, parity=0, stopbits=1, flowcontrol=0

INFO: Timeout: value=1000

INFO: DTR: value=1

INFO: RTS: value=0

INFO: Flush: queue=1, input=0, output=0

INFO: Write: size=3, data=414243

INFO: Read: size=3, data=414243

ERROR: Failed to receive the answer. [in cressi_edy.c:103 (cressi_edy_transfer)]

INFO: Flush: queue=1, input=0, output=0

INFO: Write: size=1, data=44

INFO: Read: size=1, data=44

ERROR: Failed to receive the answer. [in cressi_edy.c:103 (cressi_edy_transfer)]

INFO: Flush: queue=1, input=0, output=0

INFO: Write: size=1, data=0C

INFO: Read: size=1, data=0C

ERROR: Failed to receive the answer. [in cressi_edy.c:103 (cressi_edy_transfer)]

INFO: Configure: baudrate=4800, databits=8, parity=0, stopbits=1, flowcontrol=0

INFO: Flush: queue=1, input=0, output=0

INFO: Write: size=3, data=520000

INFO: Read: size=3, data=520000

ERROR: Failed to receive the answer. [in cressi_edy.c:103 (cressi_edy_transfer)]

INFO: Flush: queue=1, input=0, output=0

INFO: Write: size=1, data=46

INFO: Read: size=1, data=46

[Jef Driesen]

Michael,

It looks like when we send a command to the dive computer, we get back an echo
(which is normal for the edy protocol), but not the actual data packet.

Just to be sure, I assume that it's not the first time you use this pc
interface, so you know the correct procedure to download? Things like activate a
PC mode on the device, etc. (I haven't used one myself, so I don't know.)


This could be some timing related issue. It's not unlikely that the device needs
a bit more time after changing settings. That's very common with other dive
computers too. So I made a build with a few extra sleep calls here and there.
Can you give this a try? Download the "iq700" test application from the
libdivecomputer website (pick the OS of your choice):

http://www.libdivecomputer.org/builds/experimental/

and run it with these options:

iq700 -v -l iq700.log -m iq700.bin -b edy <serialport>

where you replace <serialport> with the correct serial port. Send back both the
iq700.log and iq700.bin files. Note that the latter file will only be created
after a successful download.


Next step will be to capture the communication between the dive computer and the
tusa application. Due to the usb-only driver, you won't be able to capture
serial communication with portmon, and you'll have to capture at the usb level.
Have a look here for some windows application:

http://libdivecomputer.org/usb.html

They are not very intuitive, so don't hesitate to ask help if necessary. It's
also possible to capture on linux (using usbmon) with the cressi software
running inside a VM.

A few years ago, I received another request for the IQ-700, and we noticed the
same symptoms. I have an usbsnoop capture from back then, and the protocol is
certainly identical to edy protocol. I can't notice any obvious mistakes. The
only odd thing are the serial line settings. From the usb trace, I get this:

b0 04 00 00 01 00 08 -> 1200 8N1.5
c0 12 00 00 01 00 08 -> 4800 8N1.5

But at least on windows, 8N1.5 is an invalid combination. You can't set this
mode through the win32 serial api. It might be that the usb-only driver allows
this. libdivecomputer is using 8N1.

(If anyone wants this usbsnoop capture file to have a look, just ask. It's
pretty large, so I didn't attach it here.)

Jef

[Michael Holmes]

Thanks again Jef,
Still no joy on the dump but getting closer with the interface device.  I am confident that the setup is correct and on Linux the driver at least seems to be accessing the thing.
Had to install 32 bit support but I did get the usb sniff and the log file to work.
Uploadiing here.

[Jef Driesen]

On 2015-02-22 23:04, Michael Holmes wrote:
> Still no joy on the dump but getting closer with the interface device.
> I
> am confident that the setup is correct and on Linux the driver at least
> seems to be accessing the thing.
> Had to install 32 bit support but I did get the usb sniff and the log
> file
> to work.

The test run was not a complete failure. The initialization was
successful now! That more or less confirms my suspicion about a timing
related problem, because I only added a few 300ms delays.

The main data transfer is still failing. My next attempt is to simply
retry the failed command, with another 300ms delay in between. I have
updated the iq700 application. Can you download it again, and give it
another try?

Jef

[Michael Holmes]

Jef,
To my untutored mind this looks very much like success though I still do not see the dump file being output!
Mike

[Jef Driesen]

On 23-02-15 17:55, Michael Holmes wrote:
> To my untutored mind this looks very much like success though I still do
> not see the dump file being output!

We get some data now, but there is still something wrong. We always get back the
same packet. It's very unlikely that all these packets have the same contents,
so there must still be something wrong.

The reason why there is no bin file is because the retrying failed at page
0x100. That might indicate the device has only 8K of memory instead of 32K. But
that's just a minor issue for now.

Every first attempt to send a command fails. So instead of waiting between
retries, I modified the code to wait before sending the command. I have uploaded
a new "iq700_v2" build to try.

If you are able to capture the communication between the official Tusa
application and the device, that might give me some extra clues. The usb.txt
that you send before is not a capture file. It's the usb descriptors. That was
useful to confirm you have indeed a Seiko VID/PID, but it doesn't contain any
communication. You'll need to use usbsnoop (on windows XP) for that (or some
other usb capture application).

Jef

[Michael Holmes]

Unfortunately I don't have an XP system available so no usb
capture from the original applicationn.  On the other hand we appear to now have a dump file from the computer..
Mike

[Jef Driesen]

On 2015-02-24 00:03, Michael Holmes wrote:
> Unfortunately I don't have an XP system available so no usb
> capture from the original applicationn.

It's possible that usbsnoop also runs on newer version. I haven't tried.
I don't even know if the Tusa software runs on newer Windows versions.
The easiest solution to work around such problems is to setup a virtual
machine with Windows XP.

It found another open source application that should support newer
Windows versions too:

http://desowin.org/usbpcap/

I've never used it before, but it's worth trying.

> On the other hand we appear to now have a dump file from the computer..

That's only because I set the amount of memory to just 8K. The main
problem with the repeating packets remains. Also, every first attempt
still fails too. So something is still wrong.

Jef

[Michael Holmes]

Jef.

The problem that started me looking for an answer was that the current TUSA software was installing but not being registered in Windows 7 64 bit. I could install the older TUSA software but that would not run under Windows 7.  I couldn't get any of the drivers to start with the interface and was really getting frustrated.  I will try to get access to a system running XP but it may take me a couple of weeks.Meanwhile I will look at some emulators and see if I can get any results.  Again thanks for the help you have given so far and I will be back when I can get a capture from the usb interface.

Thanks,

Mike

[Michael Holmes]

https://drive.google.com/file/d/0B5dzn9AjvRG9X2JqbW5jTW0zWkE/view?usp=sharing

OK Jef,

It went faster than I expected. Here is a link to the USB snoop log. Let me know if I haven't done this correctly,

Mike

[Jef Driesen]

On 2015-02-26 02:00, Michael Holmes wrote:
> https://drive.google.com/file/d/0B5dzn9AjvRG9X2JqbW5jTW0zWkE/view?usp=sharing

>
> It went faster than I expected. Here is a link to the USB snoop log.
> Let me
> know if I haven't done this correctly,

I haven't fully analyzed the file yet, but I did already extract the
bulk data transfers (see attached file) and noticed something very
interesting.

When we request the first packet (page 0x0000), we get:

Write: size=3, data=520000
Read: size=132,
data=52000000880124056202000250002890470824010000000000F021FC0000000000000020862106211221072101210321072107210721102114211721132112211021152118212021162113210821042104210621052101210221022104210421042107210921032098207020702070207420622019202720002000200020002000204145

The Tusa application also request this page, but the response is
completely different:

WRITE: 520000
READ:
5200002218222422232209220322052211221022142239224522472229222422202206220722172225222222212213219721882165214421262104208520882087208620812073206620662067207020682059206420622063206020562045ff38200001170221151282400260002740501130010000000000f021fc0000000000000045

The response we got is identical to the response that the Tusa
application gets for page 0x0052:

WRITE: 520052
READ:
52005200880124056202000250002890470824010000000000f021fc0000000000000020862106211221072101210321072107210721102114211721132112211021152118212021162113210821042104210621052101210221022104210421042107210921032098207020702070207420622019202720002000200020002000204145

The only difference here is the echo of the command. But I wouldn't be
surprised if this echo is generated by the pc interface, and not send by
the dive computer. Can you verify this by running the test application
without a dive computer connected (only the pc interface)? The download
will fail, but if I'm right we should still receive the echos.

Notice how the command type (first byte) and page number (last byte) are
identical (0x52) for this request! So I suspect that somehow the command
type ends up being interpreted as the page number. (This probably also
explains why we're always getting the same response: as far as the
device is concerned we're always requesting page 0x52.) I suspect that
this is related to the fact that the device doesn't respond after the
first request. It's not impossible that if the first command wasn't
received correctly and we resend the command, the device receives
something that contains parts of both attempts. The question is of
course why does this happen and how can we prevent it?

Jef

[Michael Holmes]

Ok Jef,

Attached is the usbsnoop log of the interface alone and just for grins a copy of the csv exported from the computer program.

[Jef Driesen]

On 2015-02-26 18:19, Michael Holmes wrote:
> Attached is the usbsnoop log of the interface alone and just for grins
> a
> copy of the csv exported from the computer program.

WRITE: 414243
READ: 414243

This confirms my suspicion that the echo is generated by the pc
interface and not the dive computer.

Jef

[Michael Holmes]

Hi Jef,

So the interface echo's the command written to the computer? Does this affect how the commands are sent to the computer?

Mike

[Jef Driesen]

On 2015-03-03 20:13, Michael Holmes wrote:
> So the interface echo's the command written to the computer? Does this
> affect how the commands are sent to the computer?

No, it only explains why the echo is correct although the main data
packet is completely wrong.

I have a new build available with a small change. I doubt that it will
fix anything, but it's always worth trying:

http://libdivecomputer.org/builds/experimental/linux/iq700_v3

Jef

[Michael Holmes]

OK Jef version 3 output is attached

[Jef Driesen]

On 09-03-15 21:49, Michael Holmes wrote:
> OK Jef version 3 output is attached

Still the same problem. Let's try another idea:

http://libdivecomputer.org/builds/experimental/linux/iq700_v4

[Michael Holmes]

Here's the output, no dump this time.

[Jef Driesen]

On 2015-03-17 01:17, Michael Holmes wrote:
> Here's the output, no dump this time.

Now it failed during the initialization, before it even reached the
change I wanted to try. This worked before, so this was probably some
temporary error. Can you try again?

I have also prepared yet another build:

http://libdivecomputer.org/builds/experimental/linux/iq700_v5

This one sends the command byte by byte, instead of all at once.

Jef

[Michael Holmes]

OKJef this is the output from version 5. With version 4 I get the same result as before. When the program starts it throws the computer out of pc mode which is what I think we are seeing. 
Mike

[Jef Driesen]

On 2015-03-18 20:13, Michael Holmes wrote:
> OKJef this is the output from version 5.

This doesn't shown any sign of the changes I made, so I probably made a
mistake and uploaded the wrong build. This should be the right one:

http://libdivecomputer.org/builds/experimental/linux/iq700_v6

> With version 4 I get the same
> result as before. When the program starts it throws the computer out of
> pc
> mode which is what I think we are seeing.

Always send back the log. Even if the test failed, there might be a
subtle difference that can give me a bit more insight in what is going
on.

Jef

[Michael Holmes]

Version 6 output

[Jef Driesen]

On 19-03-15 19:58, Michael Holmes wrote:
> Version 6 output

Great, it looks like this one worked! Now I'll have to figure out the data
structure. That will take some time. Once I have some news, or need more
testing, I'll get back to you. Feel free to ping me if you haven't heard
anything from me in a few weeks.

Jef

[Michael Holmes]

Hi Jef,, 

Any luck on data structure yet?

Mike

[Jef Driesen]

On 2015-04-11 20:39, Michael Holmes wrote:
> Any luck on data structure yet?

I have most parts figured out now. I actually spend most of the time
chasing a nasty bug in the edy backend. I should have a new version
available for testing soon.

Jef

[Jef Driesen]

I have a new build ready:

http://libdivecomputer.org/builds/experimental/linux/iq700

Run with these options:

./iq700 -v -l iq700.log -d iq700.xml -b edy /dev/ttyUSB0

And then check the generated xml file for errors. Everything looks fine
to me, but it's not impossible that I missed something.

There is one thing left that I haven't found yet, and that's gas
changes. According to the manual, the iq700 supports up to two gas
mixes. There are some unused bits available, that might contain the gas
change events. But it looks like none of your dives uses multiple gases,
so I can't locate the bits. If you don't mind, can you record a dive
with two different mixes enabled, and then during your dive switch to
the second mix and back again. A pool dive is fine for this purpose. (If
you do a real dive, set your second mix to something close to your real
mix (e.g. air and 22%), and do the (fake) switches at the very end of
your dive, so it won't have any impact on safety.)

Jef

[Michael Holmes]

Doesn't look like it worked. Here are the log and xml files. It may be quite a while before I can do the gas change as I live in Colorado and don't like to dive in cold water only get to dive about once a year.
Mike

[Jef Driesen]

On 20-04-15 20:18, Michael Holmes wrote:
> Doesn't look like it worked. Here are the log and xml files.

I removed some of the delays, to speedup the download again. I guess one of
those is still necessary. Let's find out which one, by adding them back one by
one. First attempt:

http://libdivecomputer.org/builds/experimental/linux/iq700

> It may be quite a
> while before I can do the gas change as I live in Colorado and don't like to
> dive in cold water only get to dive about once a year.

If you have access to a pool, that works too for recording a short test "dive" :-)

It's not a big deal. We can always disable the gas changes for now and fix them
later.

Jef

[Michael Holmes]

Somehow I missed this looks like it worked! Put a bunch of dive_nn.bin files on the desktop, but here are the .xml and .log files.

[Michael Holmes]

Switched back from Linux to Windows and imported the xml file. Profiles look good and I will reconcile with my paper logbook and compare with the results of the tusa divelog software when I have a chance but first pass looks really good.  Next time I get to dive I will try changing mixes between dives and maybe you can find the last little bit.  Great work adding this to subsurface should add some life to this dive computer.

Thanks,

Mike

[Jef Driesen]

On 2015-04-29 16:41, Michael Holmes wrote:
> Somehow I missed this looks like it worked! Put a bunch of dive_nn.bin
> files on the desktop, but here are the .xml and .log files.

Excellent. I pushed the changes to the libdivecomputer master branch.
The IQ-700 support will show up in the next subsurface release.

Jef

[Michael Holmes]

Hi Jef,

Just installed 4.4.2 for windows and did not see the iq-700 as a dive computer option.  

Am I missing something?

Mike

[Dirk Hohndel]

It appears that I messed up the Windows binary of 4.4.2 for some reason.
I could have sworn that I checked for the correct libdivecomputer version
but then apparently I uploaded the wrong binary.

Would you download 4.4.2 again and try one more time, please?

Thanks

/D

> --
> You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
> To post to this group, send email to subsurfac...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/814ce8e3-660f-470e-9da0-308fc340ca8a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Michael Holmes]

Sorry I missed this Jef, re downloaded 4.4.2 again and it is now there, thanks

Mike

On Monday, May 25, 2015 at 7:13:46 PM UTC-6, Dirk wrote:

It appears that I messed up the Windows binary of 4.4.2 for some reason.
I could have sworn that I checked for the correct libdivecomputer version
but then apparently I uploaded the wrong binary.

Would you download 4.4.2 again and try one more time, please?

Thanks

/D

On Mon, May 25, 2015 at 10:39:18AM -0700, Michael Holmes wrote:
> Hi Jef,
> Just installed 4.4.2 for windows and did not see the iq-700 as a dive
> computer option.  
> Am I missing something?
>
> Mike
>
> On Wednesday, April 29, 2015 at 11:45:25 PM UTC-6, Jef Driesen wrote:
> >
> > On 2015-04-29 16:41, Michael Holmes wrote:
> > > Somehow I missed this looks like it worked! Put a bunch of dive_nn.bin
> > > files on the desktop, but here are the .xml and .log files.
> >
> > Excellent. I pushed the changes to the libdivecomputer master branch.
> > The IQ-700 support will show up in the next subsurface release.
> >
> > Jef
> >
>
> --
> You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsub...@googlegroups.com.