direct import form dive computer

[Jef Driesen]

On 2017-03-12 18:52, Alessandro Volpi wrote:
> I apologize for not having actually loaded the
> subdirectory galileo_trimix_import on my Dropbox folder. The Galileo 
> data
> download was executed on a laptop computer. The Ubuntu trusty system is 
> not
> set up so that it automatically starts the Dropbox sync operation, as 
> usual
> for laptops, which may not be always connected to Internet. I just 
> forgot
> to manually start the Dropbox sync, after having created the mentioned
> directory. If you open my Dropbox folder right now you are going to 
> find it
> as expected.
> 
> In the same folder you will also find the subdirectory Smarttec_import 
> ,
> with the log file.

No problem. I have them now.

> I have not hitherto considered the chance of installing the Windows 
> version
> of subsurface on the WXP VM .  I thought it might have been be a good
> suggestion, just in order to try to get the memory dump. It is  a bit
> funny, since I have begun to look for linux dive log software mainly in
> order to get rid of the WXP virtual machine ...
> 
> I have also tried this possible solution. Subsurface seems to be 
> flawlessly
> installed, but it does not work. As I try to launch it I only get an 
> error
> pop-up saying : "The procedure entry-point qsort_s could not be located 
> in
> the dynamic link library msvcrt.dll" .  This is not surprising since, 
> in
> the subsurface web site, WXP is not mentioned in the list of the 
> subsurface
> supported Microsoft operating systems.

That's probably a subsurface issue on Windows XP. As a workaround, you 
can download the memory dump using libdivecomputer's command-line tool. 
You can get it here:

http://libdivecomputer.org/builds/stable/windows/dctool.exe

Execute with these options:

dctool.exe -v -l smart.log -f smart dump -o smart.bin


What I would like to confirm with this test is very simple: Since you 
are able to download your smarttec with smarttrak, we know that IrDA is 
working fine on this system. That allows us to check whether the problem 
is located. If downloading with libdivecomputer works on this system, 
then the failure on linux is an IrDA related issue, if it fails then 
it's in libdivecomputer.

> As far as the reasons for not being able to connect the SmartTec to the
> linux ( Ubuntu trusty ) IR interface, I think it may be related to the 
> fact
> that, even with the SmartTrak program running on the WXP VM, the 
> SmartTec
> takes much more time than the Galileo for the download, in spite of the
> fact that the amount of data sent by the former is much smaller than 
> that
> sent by the latter. This means that the transmission data rate of the
> SmartTec is much lower.

For the smarttec, we don't even get a chance to download any data. The 
IrDA device was discovered successfully, but connecting to the device 
failed:

INFO: Discover: address=f0e03201, name=Aladin Smart Tec, charset=00, 
hints=8000
INFO: Connect: address=f0e03201, lsap=1
ERROR: Connection reset by peer (104) [in irda.c:369 
(dc_irda_connect_lsap)]
ERROR: Failed to connect the device. [in uwatec_smart.c:188 
(uwatec_smart_device_open)]

This might indeed indicate a problem with the IrDA.

Jef