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
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
