SubSurface 4.8.5 on OSX Mojave can't download from Cressi Leonardo

[Howell Strain]

My wife is running  SubSurface 4.8.5 on OSX Mojave and trying to connect a Cressi Leonardo that works fine on PC. I am a PC guy so I may call something OSX related the wrong name.

I plugged in the computer interface and tried connecting to the dive computer (in PC link mode) on each of the existing "Device or Mount Point" but no joy. When I unplug the interface no devices go away so I'm thinking I'm missing what I need. See Screenshot 1.

The Appendix A section of the manual is a bit vague on information I can use to help myself but I have tried some random suggestions to other people from the forums. 

"On a Mac users sometimes have to manually hunt for the correct driver." How do I know if I'm one of those people?

Under System Information > Hardware > USB the Cressi interface shows up as shown in screenshot 2.

I did download and install the FTDI drive from their website but still no joy. What do I do next?

TIA.

[Robert C. Helling]

Am Montag, 18. Februar 2019 15:17:57 UTC+1 schrieb Howell Strain:

My wife is running  SubSurface 4.8.5 on OSX Mojave and trying to connect a Cressi Leonardo that works fine on PC. I am a PC guy so I may call something OSX related the wrong name.

I plugged in the computer interface and tried connecting to the dive computer (in PC link mode) on each of the existing "Device or Mount Point" but no joy. When I unplug the interface no devices go away so I'm thinking I'm missing what I need. See Screenshot 1.

 For me it looks like this. There should be an entry "FTDI" which should work as well as one like the last one /dev/tty.usbserial-somecypticnumber . Are you sure those aren't there?

Best

Robert

[Howell Strain]

Thanks for the screenshot. I am sure the only entries on the pull-down menu are shown in my screenshot, and that clicking the ellipsis does not do anything.

The box seems to accept free form entry but I am not sure what I would type there.

Howell

[Dirk Hohndel]

Try typing

ftdi

In reality there's always a fair chance that I messed up building the binaries and somehow managed to ship them without user space FTDI support.

I have a long checklist to test and much of this is automated, but embarrassingly often I get something wrong (but then, I do build quite a few different binaries...)

I'll look into this when I get to my computer later today


/D

--
From my phone

[Dirk Hohndel]

And indeed, this was my mistake.

I have replaced the Subsurface-4.8.5.dmg with an updated version (you can tell by the file date being today instead of Jan 24).

Please redownload and try that one. It will show the FTDI dropdown.

My apologies

/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/7CCB1E7F-2715-404A-A054-CACA76014651%40hohndel.org.
For more options, visit https://groups.google.com/d/optout.

[Howell Strain]

Thank you Dirk. We were able to download the file and reinstall but are now getting a different error: unable to open ftdi. We tried an uninstall/reinstall but no luck.

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

[Dirk Hohndel]

> On Feb 19, 2019, at 5:44 AM, Howell Strain <whst...@whstrain.us> wrote:
>
> Thank you Dirk. We were able to download the file and reinstall but are now getting a different error: unable to open ftdi. We tried an uninstall/reinstall but no luck.
>

That's disappointing.

Can you post the output of

/Volumes/Subsurface-4.8.5/Subsurface.app/Contents/MacOS/Subsurface -v > logfile.txt 2>&1

(run this in a Terminal.app window - this assumes that you have the Subsurface DMG opened)

Thanks

/D

[Howell Strain]

-bash: /Volumes/Subsurface-4.8.5/Subsurface.app/Contents/MacOS/Subsurface: No such file or directory

I can confirm that when the Subsurface application is open and the cradle is plugged in with the dive computer in mode, the /Volumes/Subsurface-4.8.5/ folder does not exist.

[Dirk Hohndel]

On Fri, Apr 12, 2019 at 06:48:27PM -0700, Howell Strain wrote:
> -bash: /Volumes/Subsurface-4.8.5/Subsurface.app/Contents/MacOS/Subsurface:
> No such file or directory

This pathh only exists when you have the DMG mounted. If you have
installed Subsurface locally by dragging it into your /Applications folder
(I believe that folder name gets localized for non English versions of
macOS):

/Applications/Subsurface.app/Contents/MacOS/Subsurface -v > logfile.txt 2>&1

/D

[Howell Strain]

Thanks for the help.

objc[18251]: Class FIFinderSyncExtensionHost is implemented in both /System/Library/PrivateFrameworks/FinderKit.framework/Versions/A/FinderKit (0x7fff941b8210) and /System/Library/PrivateFrameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride (0x122408dc8). One of the two will be used. Which one is undefined.
[0.000097] ERROR: No such file or directory (2) [in ../../src/serial_posix.c:295 (dc_serial_open)]
Subsurface v4.8.5,
built with libdivecomputer v0.7.0-devel-Subsurface-NG (072bef16666e0ec397b8236e92722b2f1347b59b)
built with Qt Version 5.11.1, runtime from Qt Version 5.11.1
built with libgit2 0.26.0
"validateGL(): created OpenGLContext."
"validateGL(): obtained QOpenGLFunctions."
"validateGL(): detected OpenGL version 2.1."
Plugins Directory:  QDir( "/Applications" , nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
loading dive data from ("/Users/[username]/Library/Application Support/Subsurface/[username].xml")

File locations:

cloud URL set as "https://cloud.subsurface-divelog.org//git/<em...@email.com>[em...@email.com]"
Local git storage: /Users/macbookpro/Library/Application Support/Subsurface/cloudstorage/6e6e9f29e7758575
Cloud URL: https://cloud.subsurface-divelog.org//git/<em...@email.com>[em...@email.com]

Image filename table: /Users/macbookpro/Library/Application Support/Subsurface/hashes
Local picture directory: /Users/macbookpro/Library/Application Support/Subsurface/picturedata/

Starting download from  FTDI
Finishing download thread: "Unable to open FTDI Cressi (Leonardo)"

[Dirk Hohndel]

The output seems a bit out of order... but from the looks of it it seems
like I managed to build the release binary without user space FTDI
support. I have just made a 4.8.6 release, but since it used the same
build process on the same machine, I'm guessing this has the same flaw.
Since 4.8.6 hasn't been announced, yet, maybe I can fix this in that
binary before too many people update...

I'm quite literally on an airplane right now which makes moving multi
megabyte installers a bit harder - but I'll try to look into this at some
point this weekend.

Thanks

/D

[Dirk Hohndel]

rsync to the rescue - it's impressively good in transferring huge files with only small changes.

Would you please download Subsurface 4.8.6 from our server and try with that?

https://subsurface-divelog.org/downloads/Subsurface-4.8.6.dmg

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/20190413154213.GB93910%40rrmbpvm.gr8dns.org.

[Howell Strain]

I updated and still have the same error.

[0.000095] ERROR: No such file or directory (2) [in ../../src/serial_posix.c:295 (dc_serial_open)]
Subsurface v4.8.6,
built with libdivecomputer v0.7.0-devel-Subsurface-NG (e4698c484461426a4cf4ef3fc1bdbb304b676f06)
built with Qt Version 5.11.1, runtime from Qt Version 5.11.1
built with libgit2 0.26.0
"validateGL(): created OpenGLContext."
"validateGL(): obtained QOpenGLFunctions."
"validateGL(): detected OpenGL version 2.1."
loading dive data from ("/Users/<username>/Library/Application Support/Subsurface/<username>.xml")

Starting download from  FTDI
Finishing download thread: "Unable to open FTDI Cressi (Leonardo)"

[Dirk Hohndel]

That output does not look like you used '-v' when calling Subsurface. Something is odd here...

/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/bdb9d527-adac-4a8b-996e-562708093198%40googlegroups.com.

[Howell Strain]

I ran it again to confirm and saw the same results. In the previous post I had removed the file locations section since i did not include error messages. For what its worth I do see the light on the interface come on when it is plugged in but I get the same errors if I run your command without it plugged in.

This is the full text:

[0.000095] ERROR: No such file or directory (2) [in ../../src/serial_posix.c:295 (dc_serial_open)]
Subsurface v4.8.6,
built with libdivecomputer v0.7.0-devel-Subsurface-NG (e4698c484461426a4cf4ef3fc1bdbb304b676f06)
built with Qt Version 5.11.1, runtime from Qt Version 5.11.1
built with libgit2 0.26.0
"validateGL(): created OpenGLContext."
"validateGL(): obtained QOpenGLFunctions."
"validateGL(): detected OpenGL version 2.1."
loading dive data from ("/Users/<username>/Library/Application Support/Subsurface/<username>.xml")

File locations:

cloud URL set as "https://cloud.subsurface-divelog.org//git/

<>"
Local git storage: /Users/<username>/Library/Application Support/Subsurface/cloudstorage/6e6e9f29e7758575
Cloud URL: https://cloud.subsurface-divelog.org//git/<emailaddress>[<emailaddress>]
Image filename table: /Users/<username>/Library/Application Support/Subsurface/hashes
Local picture directory: /Users/<username>/Library/Application Support/Subsurface/picturedata/

Starting download from  FTDI
Finishing download thread: "Unable to open FTDI Cressi (Leonardo)"

[Dirk Hohndel]

On Apr 13, 2019, at 2:17 PM, Howell Strain <whst...@whstrain.us> wrote:

I ran it again to confirm and saw the same results. In the previous post I had removed the file locations section since i did not include error messages. For what its worth I do see the light on the interface come on when it is plugged in but I get the same errors if I run your command without it plugged in.

This is the full text:

Local picture directory: /Users/<username>/Library/Application Support/Subsurface/picturedata/

Starting download from  FTDI
Finishing download thread: "Unable to open FTDI Cressi (Leonardo)"

Hmm - I now tried this again with my FTDI dive computer... and it turns out that illogically you need to use "ftdi" and not "FTDI" as device name (I'll fix that so that either works).

And you need to select "Save libdivecomputer logfile" to get all of the log information.

And then of course there is another oddity - on my Mac on which I have native FTDI drivers installed. I get an error that states

Starting download from  FTDI

INFO: in ftdi_open

INFO: serial_ftdi_open called

INFO: setting up ftdi_ctx

INFO: initialize ftdi_ctx

INFO: call serial_ftdi_open_device

INFO: serial_ftdi_open_device called

INFO: FTDI tried VID 0403 pid 6001 ret -5

ERROR: unable to claim usb device. Make sure the default FTDI driver is not in use

INFO: serial_ftdi_open() failed

Finishing download thread: "Unable to open FTDI Heinrichs Weikamp (OSTC 3)"

Not sure if that's the problem for you as well - or if it's just the incorrect case for the device name.

I think I'll need to create yet another test build in order for you to be able to test this. I'm rather surprised that no one else ran into this before...

/D

[Dirk Hohndel]

OK, I once again replaced the 4.8.6 DMG, so please re-download.

Also, please test to see if you have an FTDI kext installed:

kextstat | grep -i ftdi

If you do, please unload it with

kextunload -b <drivername>

Then try again with the NEW version of 4.8.6 that I just uploaded. Use 'FTDI' as device name. Enable libdivecomputer logfile.

Let's see what happens :-/

/D

[Howell Strain]

Changing the FTDI to lower case did not work but the most recent 4.8.6 DMG worked. 

FWIW, the kextstat command came back blank.

Thanks for all your patience and help Dirk.