On 07 February, 2017 - Willem Ferguson wrote: > I am working with the Android version of Subsurface desktop and > attempting download of dive logs from a FTDI dive computer. > > Hardware issues: > > Firstly, the Tusa does not turn into PC download mode if the USB bus > does not supply power. Possibly on this phone the mini-USB plug does > not supply power to devices. Therefore, connect the Android USB plug > to a USB hub that supplies power to all connected devices. This > connection actually is via mini-USB to full-sized US cable, through > a female/female USB adaptor-plug and another cable to the USB hub. > The Tusa DC USB plug is plugged into the USB hub via yet another > cable. With this setup, at least, the Tusa DC goes into download > mode. > > Secondly tested most of this cable setup by download onto the Linux > desktop using the custom FTDI driver and using the USB hub to supply > power to the Tusa DC. Download works perfectly (i.e. with some > ideosyncracies that Anton has already seen, dealing with cylinder > gas composition, maybe a libdivecomputer issue. These are not > relevant now). Fact is download works well onto Linux. >
As far as I've remember, thats a libdivecomputer issue. You should probably send a trace log to Jef and he can help us figure out whats going on. Maybe I've done something stupid in the custom-serial layer which corrupts the data, or maybe its a parsing error in libdivecomputer. Anyway, we probably need Jef's help to figure that one out. > Android driver configuration: > > When downloading dives onto the Anfroid device, I get an error > message "Insufficient privileges to open the device ftdi Tusa (Zen > (IQ-900))". This is the same error message that I get if downloading > to Linux and I have not chown-ed the USB port or I did not build > Subsurface-desktop with -DFTDISUPPORT=ON on the cmake command line. > This does not necessarily mean that on Android it is exactly the > same reason as on Linux. In android/build.sh, it looks like > FTDISUPPORT is pretty much hard-wired into the cmake command line. > Possibly the Android port also needs some configuration, for > instance performed using chown on Linux? > > Any comments? The permissions handling and device node open is done in a completely different way on Android. All the usb vid/pid's we support needs to be listed in the manifest. Make sure the vid/pid for your usb-chip is listed in android/res/xml/device_filter.xml The ftdi on android code is as far as I've know compliant with the android sdk/ndk api's, and doesn't really use anything it shouldn't. That said, there might be something in the I've missed, which breaks on a specific vendor implementation of hal/usb on some devices. There might also be something that broke in newer Android version. Last time I tested this was on a Nexus 5 running ... KitKat or Lollipop. My current phone is seriously b0rked, and doesn't do USB-OTG so I can't really test it. I'd might need to borrow my wife's phone and see if that can be tricked into doing USB-OTG and test the ftdi code on. I could probably test it in a emulator to, but that hal is probably even simpler and more standard so I bet it already works there. Goldfish ftw. //Anton - there's some complexity to this... -- Anton Lundin +46702-161604 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
