Re: FTDI user space on Windows

[Lubomir I. Ivanov]

On 15 September 2018 at 01:48, Bill Perry  wrote:
> Yes, I can do PR. (once I figure out how to do signing)

feel free to ask any github related questions, if any.

> but I don't understand:
>
>> sleeping for small chunks of time can end up being better.
>
> The modification I did used the exact same constant 1ms sleep after each 
> ftdi_read_data() call that the current code does but it checked elapsed time 
> prior each 1ms sleep
> rather than counting the number of 1ms sleeps until they equaled the desired 
> millisecond timeout.
> Counting the number of 1ms sleeps done does not work since it does account for
> the time inside the loop (which can be significant like 100+ ms) since 
> sometimes the ftdi_read_data() doesn't return immediately
> when there is no data.
> That is why looking at elapsed time is required.
>
> Are you wanting something smarter than changing the way the loop exits by 
> checking elapsed time instead of blindly looping {timout} times?
>

ah, i misunderstood the initial comment, sorry.
i'd encourage you to send the PR so that we can have a look at the
code and discuss it.

thanks
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: FTDI user space on Windows

[Lubomir I. Ivanov]

On 13 September 2018 at 21:44, Bill Perry  wrote:
> Just a reminder that last summer I saw that the code in serial_ftdi_read() 
> doesn't guarantee that a timeout occurs
> in the desired timeout period.
> Due to the way it is written, you can get MUCH longer delays when the bytes 
> don't stream in right away or
> This was an issue I was fighting last year when I was trying to get retries 
> to work on the Pelagic data cable with Android.
> It actually affects any ftdi device.
> This is likely an issue on Windows as well.
>
> ftdi_read_data() took a few milliseconds of time before returning and that 
> time is not accounted for.
> And on android the the LIBUSB_ERROR_INTERRUPTED was also happening.
> This caused the while loop to loop for several minutes before timing out.
> My solution (which I posted a patch for to the list back in Nov 2017) was to 
> get rid of slept and to always sleep for 1ms.
> Then rather than comparing slept >= timeout - which doesn't work, was to use 
> gettimofday()
> to check for the elapsed time to check for the desired timeout period.
>

sleeping for small chunks of time can end up being better.
would you like to submit a github PR to address this improvement as
per your experiments?

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: planning for 4.8.2 / 2.1.2

[Dirk Hohndel]

> On Sep 14, 2018, at 11:01 AM, Willem Ferguson 
>  wrote:
> 
> On 14/09/2018 18:40, Dirk Hohndel wrote:
>> I’ve been a bit distracted with other stuff this week so I’m not as far as I 
>> wanted to be wrt being able to release 4.8.2
>> 
>> I don’t think I’ll get it ready this weekend, but I’ll try.
>> It would be good to collect things that need to get done before a release 
>> here if possible.
>> 
>> E.g., how are we doing with respect to the user manual changes proposed?
> Will be done by Sunday mid-day PDT. Will finish tomorrow & send to Berthold 
> for review.

Excellent. Thanks

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: planning for 4.8.2 / 2.1.2

[Dirk Hohndel]

> On Sep 14, 2018, at 11:05 AM, Pedro Neves  wrote:
> 
> 
>> On 14/09/2018 18:40, Dirk Hohndel wrote:
>> 
>>> I’ll pull translations today - I think I’ve seen a lot of progress there, 
>>> but I need to check if there are obvious gaps.
>>> I started looking through the issues something like four times in the last 
>>> few days and always immediately got side-tracked.
>>> 
>>> Any help and especially TESTING would be welcome.
> 
> 
> Dirk:
> 
> There seems to be a string missing for translation:
> 
> On the Export dialog, there's a new option "Anonymize" which doesn't show up 
> in Transifex...

Thanks for the reminder… I’ll push out one more time.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: planning for 4.8.2 / 2.1.2

[Pedro Neves]

On 14/09/2018 18:40, Dirk Hohndel wrote:

I’ll pull translations today - I think I’ve seen a lot of progress 
there, but I need to check if there are obvious gaps.
I started looking through the issues something like four times in the 
last few days and always immediately got side-tracked.


Any help and especially TESTING would be welcome.



Dirk:

There seems to be a string missing for translation:

On the Export dialog, there's a new option "Anonymize" which doesn't 
show up in Transifex...


Cheers:


Pedro

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: planning for 4.8.2 / 2.1.2

[Dirk Hohndel]

I’ve been a bit distracted with other stuff this week so I’m not as far as I 
wanted to be wrt being able to release 4.8.2

I don’t think I’ll get it ready this weekend, but I’ll try.
It would be good to collect things that need to get done before a release here 
if possible.

E.g., how are we doing with respect to the user manual changes proposed?
I’ll pull translations today - I think I’ve seen a lot of progress there, but I 
need to check if there are obvious gaps.
I started looking through the issues something like four times in the last few 
days and always immediately got side-tracked.

Any help and especially TESTING would be welcome.

And to state clearly what I hadn’t mentioned before - I also want to release a 
new Subsurface-mobile version so that Teric support is added on Mobile as well.

Thanks
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Android FTDI support not working with fresh app build

[Bill Perry]

On 09/14/2018 08:56 AM, Anton Lundin wrote:
> On 13 September, 2018 - Bill Perry wrote:
>
>> The android app downloaded from the Playstore behaves differently than the 
>> one I just built from current sources.
> How did you build the mobile app for android?
note: did you see the latest strangeness: 
http://lists.subsurface-divelog.org/pipermail/subsurface/2018-September/033025.html
Where libdivecomputer command/message delays don't work on the 4.8.1 app from 
the playstore but do work with the 4.8.1 that I built.
This was verified with a logic analyzer with the apps running on a Galaxy S4 
with Android 4.4.4 and a Galaxy S7 running Android 8.0.0

I followed the instructions from the INSTALL file, except the only package I 
added to a newly installed Mint 18 OS install was cmake.
I'm building on freshly installed fully up to date 64bit Linux Mint MATE 18.3 
in a virtual box vm.
I forked the subsurface repository then cloned from my github repo.
I did the submodule update to get the proper libdivecomputer
I then ran bash subsurface/packaging/android/android-build-wrapper.sh to build 
the .apk
I never built the code for the desktop.

After I sent the first post about this, I went back and started over with clean 
clone of the repo and
I installed all the recommended Ubuntu 18.04 packages (even though Mint 18 is 
based on Ubuntu 16.04)
and rebuilt the app after a clean/fresh clone.
That build would come up but immediately crash on both Android 4.4.4 and 
Android 8.0.0
I then started over again with a clean/fresh clone and checked out v4.8.1 and 
then
followed the same steps to build the apk
Nothing else was changed on the machine other then I started with a clean clone 
and checked out v4.8.1 vs using the head of Master.
This apk worked as expected including having the proper command/message delays
whereas the current app from the app store (4.8.1) does not have the proper 
delays.

I'm at a loss to explain the delay issue, but I can see it on a logic analyzer.


>
>> I'm currently testing on a Samsung GS4 running kitkat 4.4.4
>>
>> With the one from the play store: version 2.1.0(4.8.0)
>>
>> - When the cable is plugged in OS asks to run subsurface.
>> NOTE: it will not do this if running the app in no cloud mode.
>> and it also won't talk over the ftdi cable either.
>> Once in cloud mode,
> Nope. This has nothing to do with each other.
I hear you and agree it shouldn't be related but I saw this more than once.
I wasn't focusing on this at the time so I just went ahead and connected to the 
cloud account so I
could get the serial port to spit out some data to look at the timing.
I'll go back and try to replicate and verify this and the details on if/how to 
replicate it
assuming I can replicate it.

Also, there is no way to download using the FTDI cable if Bluetooth is not 
enabled.
If bluetooth is not enabled, it won't let you download at all.

>
>> - It can open the port and push bytes out the data cable
>> However, the timing between the bytes & messages is wrong (which is what I'm 
>> trying to fix)
>>
>> With the one I just built: version 2.1.2(4.8.1.413)
>> It appears to not be able to open the serial connection.
>> The libdivecomputer log shows:
>> 
>> Subsurface: v4.8.1-413-g76c4fb397512, built with libdivecomputer 
>> v0.7.0-devel-Subsurface-NG (8f2ac8f61e8768d4774983de1f367f73c8c34ea2)
>> INFO: Open: name=ftdi
>> ERROR: No such file or directory (2) [in 
>> /home/bill/Documents/devel/Subsurface-devel/subsurface/libdivecomputer/src/serial_posix.c:295
>>  (dc_serial_open)]
>> 
>> Which seems to indicate it is trying open the device "ftdi" vs checking for 
>> the magic "ftdi" name and calling the ftdi serial code instead of 
>> serial_posix code.
>> Have I not built the app properly, or is the code broken right now and I 
>> should go back to the tagged code from the last release?
> You haven't built the app properly.
I figured as much, but I didn't really know why.
I can only assume (perhaps incorrectly) that the 
subsurface/packaging/android/android-build-wrapper.sh script
looks for the existence of libusb being installed and if it doesn't see it 
installed doesn't include support for it in the mobile build.
The first build I did, I didn't have libusb-1.0-0-dev package installed on the 
machine.

The big clue for me is that dc_serial_open() is being called.
This only gets called for /dev type devices.
It should not be called for the fake/magic "ftdi" device filename that is used 
when selecting the "FTDI" device
from the download UI.


>
>> "23.558: DCDownloadThread started for Aeris Atmos AI on FTDI"
>> Starting download from  ftdi
>> "23.579: Looking at device with VID/PID 1478/36940"
>> "23.579: Looking at device with VID/PID 1027/24577"
>> "23.580: usbManager tells us we don't have permission to access this device"
> This is the money shot: You didn't give Subsurface mobile access to this
> usb device, thus android denies us access to it.

To me the money 

Re: Android FTDI support not working with fresh app build

[Anton Lundin]

On 13 September, 2018 - Bill Perry wrote:

> The android app downloaded from the Playstore behaves differently than the 
> one I just built from current sources.

How did you build the mobile app for android?

> I'm currently testing on a Samsung GS4 running kitkat 4.4.4
> 
> With the one from the play store: version 2.1.0(4.8.0)
> 
> - When the cable is plugged in OS asks to run subsurface.
> NOTE: it will not do this if running the app in no cloud mode.
> and it also won't talk over the ftdi cable either.
> Once in cloud mode,

Nope. This has nothing to do with each other.

> - It can open the port and push bytes out the data cable
> However, the timing between the bytes & messages is wrong (which is what I'm 
> trying to fix)
> 
> With the one I just built: version 2.1.2(4.8.1.413)
> It appears to not be able to open the serial connection.
> The libdivecomputer log shows:
> 
> Subsurface: v4.8.1-413-g76c4fb397512, built with libdivecomputer 
> v0.7.0-devel-Subsurface-NG (8f2ac8f61e8768d4774983de1f367f73c8c34ea2)
> INFO: Open: name=ftdi
> ERROR: No such file or directory (2) [in 
> /home/bill/Documents/devel/Subsurface-devel/subsurface/libdivecomputer/src/serial_posix.c:295
>  (dc_serial_open)]
> 
> Which seems to indicate it is trying open the device "ftdi" vs checking for 
> the magic "ftdi" name and calling the ftdi serial code instead of 
> serial_posix code.
> Have I not built the app properly, or is the code broken right now and I 
> should go back to the tagged code from the last release?

You haven't built the app properly.

> Here is the subsurface log
> 
> "0.012: Successfully opened logfile /storage/emulated/0/subsurface.log at Thu 
> Sep 13 19:49:06 2018"
> "0.013: Starting Subsurface-mobile:2.1.2(4.8.1.413):Android KitKat 
> (4.4):arm:en-US"
> "0.013: built with libdivecomputer v0.7.0-devel-Subsurface-NG 
> (8f2ac8f61e8768d4774983de1f367f73c8c34ea2)"
> "0.014: built with Qt Version 5.11.1, runtime from Qt Version 5.11.1"
> "0.014: built with libgit2 0.26.0"
> "localDevice bperrybap-SGH-M919 is valid, starting discovery"
> paired BT classic device type 1 with address "00:00:00:00:00:01"
> paired BT classic device type 1 with address "B8:27:EB:AA:44:2B"
> paired BT classic device type 1 with address "00:BA:55:56:45:2E"
> Found new device: "obd-2" "00:00:00:00:00:01"
> Not recognized as dive computer
> Found new device: "GreenIceZero" "B8:27:EB:AA:44:2B"
> Not recognized as dive computer
> Found new device: "AB SHUTTER 3" "00:BA:55:56:45:2E"
> Not recognized as dive computer
> Paired = "obd-2" "00:00:00:00:00:01"
> Paired = "GreenIceZero" "B8:27:EB:AA:44:2B"
> Paired = "AB SHUTTER 3" "00:BA:55:56:45:2E"
> "Created position source android"
> "0.095: Created position source android"
> "Set GPS service update interval to 300 s"
> "0.096: Set GPS service update interval to 300 s"
> "0.096: location service is available"
> "1.702: Synchronising data file"
> "1.707: Load dives from local cache"
> "1.731: Successfully opened dive data"
> "1.737: 26 dives loaded from cache"
> "1.740: have cloud credentials, but user asked not to connect to network"
> "Set GPS service update interval to 300 s"
> "1.741: Set GPS service update interval to 300 s"
> checkPendingIntents
> Using the following font: Roboto
> qqwindow devicePixelRatio 3 3
> Supported dive computers:
> "Aeris: 500 AI (SERIAL), A300 (SERIAL), A300 AI (SERIAL), A300CS (SERIAL), 
> Atmos 2 (SERIAL), Atmos AI (SERIAL), Atmos AI 2 (SERIAL), Compumask (SERIAL), 
> Elite (SERIAL), Elite T3 (SERIAL), Epic (SERIAL), F10 (SERIAL), F11 (SERIAL), 
> Manta (SERIAL), XR-1 NX
> (SERIAL), XR-2 (SERIAL)"
> "Aqualung: i200 (SERIAL), i300 (SERIAL), i450T (SERIAL), i550 (SERIAL), 
> i750TC (SERIAL, BT)"
> "Atomic Aquatics: Cobalt (USB), Cobalt 2 (USB)"
> "Beuchat: Mundial 2 (SERIAL), Mundial 3 (SERIAL), Voyager 2G (SERIAL)"
> "Cochran: Commander I (SERIAL), Commander II (SERIAL), Commander TM (SERIAL), 
> EMC-14 (SERIAL), EMC-16 (SERIAL), EMC-20H (SERIAL)"
> "Cressi: Drake (SERIAL), Giotto (SERIAL), Leonardo (SERIAL), Newton (SERIAL)"
> "Garmin: Descent Mk1 (USBSTORAGE)"
> "Genesis: React Pro (SERIAL), React Pro White (SERIAL)"
> "Heinrichs Weikamp: Frog (SERIAL, BT), OSTC (SERIAL), OSTC 2 (SERIAL, BT, 
> BLE), OSTC 2 TR (SERIAL, BT, BLE), OSTC 2C (SERIAL), OSTC 2N (SERIAL), OSTC 3 
> (SERIAL), OSTC 4 (SERIAL, BT, BLE), OSTC Mk2 (SERIAL), OSTC Plus (SERIAL, BT, 
> BLE), OSTC Sport
> (SERIAL, BT, BLE), OSTC cR (SERIAL)"
> "Hollis: DG02 (SERIAL), DG03 (SERIAL), TX1 (SERIAL)"
> "Mares: Puck Pro (SERIAL, BLE), Quad (SERIAL, BLE), Quad Air (SERIAL, BLE), 
> Smart (SERIAL, BLE), Smart Air (SERIAL, BLE)"
> "Oceanic: Atom 1.0 (SERIAL), Atom 2.0 (SERIAL), Atom 3.0 (SERIAL), Atom 3.1 
> (SERIAL), Datamask (SERIAL), F10 (SERIAL), F11 (SERIAL), Geo (SERIAL), Geo 
> 2.0 (SERIAL), OC1 (SERIAL), OCS (SERIAL), OCi (SERIAL), Pro Plus 2 (SERIAL), 
> Pro Plus 2.1 (SERIAL), Pro
> Plus 3 (SERIAL), VT 4.1 (SERIAL), VT Pro 

Re: planning for 4.8.2

[Dirk Hohndel]

> On Sep 14, 2018, at 5:58 AM, Jef Driesen  wrote:
> 
> On 2018-09-08 01:48, Dirk Hohndel wrote:
>>> On Sep 7, 2018, at 3:11 PM, Linus Torvalds  
>>> wrote:
>>> So realistically I'm weeks away, and that's not some guarantee either.
>>> I'm really happy with how quickly the Garmin parser came together, and
>>> we have that going for us, but plan on it being USB-only for the
>>> immediate future.
>> Thanks - that’s good to know for planning purposes.
>> In the meantime I have started working on the Shearwater Teric download, 
>> which
>> will also significantly change the download from most other Shearwater
>> dive computer
>> (anything but Predator and /possibly/ the very oldest Petrels). I have
>> all the docs I need,
>> I had dive computers to test with, all I need is the time to implement
>> this and I think I
>> might be able to get this into testable state this weekend.
>> I know that Jef has also been planning to look into this, but haven’t
>> seen anything from
>> him, so I hope I’m not duplicating work that already exists.
> 
> Sorry for the late response. I've had some problems with internet access 
> lately, and the past few weeks I've also been fully occupied with some other 
> things in life. So I'm running a bit behind at the moment and I'll have a lot 
> to catch up with. But I probably won't have much time for doing 
> libdivecomputer related work until next month.

Life happens...

> But the answer your question, I had not started working on the Teric support 
> yet.

We have what I believe fairly complete Teric support in the Subsurface-NG 
branch of our libdivecomputer repo that is referenced in Subsurface master.
Feel free to look at / use. If you have comments or would like changes, please 
let me know - as you know I'd prefer to have our code as close to your upstream 
as possible.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: planning for 4.8.2

[Jef Driesen]

On 2018-09-08 01:48, Dirk Hohndel wrote:
On Sep 7, 2018, at 3:11 PM, Linus Torvalds 
 wrote:


So realistically I'm weeks away, and that's not some guarantee either.
I'm really happy with how quickly the Garmin parser came together, and
we have that going for us, but plan on it being USB-only for the
immediate future.


Thanks - that’s good to know for planning purposes.

In the meantime I have started working on the Shearwater Teric 
download, which

will also significantly change the download from most other Shearwater
dive computer
(anything but Predator and /possibly/ the very oldest Petrels). I have
all the docs I need,
I had dive computers to test with, all I need is the time to implement
this and I think I
might be able to get this into testable state this weekend.

I know that Jef has also been planning to look into this, but haven’t
seen anything from
him, so I hope I’m not duplicating work that already exists.


Sorry for the late response. I've had some problems with internet access 
lately, and the past few weeks I've also been fully occupied with some 
other things in life. So I'm running a bit behind at the moment and I'll 
have a lot to catch up with. But I probably won't have much time for 
doing libdivecomputer related work until next month.


But the answer your question, I had not started working on the Teric 
support yet.


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Fwd: Re: Cressi Leonardo not Accessable to Download Logs

[Willem Ferguson]

On 14/09/2018 08:49, kets...@gmail.com wrote:
I've been trying to download the logs from my Cressi Leonardo dive 
computer without any success when using Subsurface.

But if I use Diving Log v6.0 software I have no problems at all.
I much prefer to use Subsurface not only because it a free product but 
also because I've invested so much time in manually inputting all my 
dives.


I'm sure I'm not the only one to have come up against this problem, 
either with the Cressi Leonardo or any of the many dive computers 
Subsurface claims it's able to download logs from.


I'm using the lastest Cressi PC Interface drivers thinking that the 
old ones may have been the Com Port 3 communications problem, this was 
not the case.
Subsurface has a problem with communicating with Com Port 3. My PC 
sees the interface at Com Port 3 obviously otherwise Diving Log v6.0 
wouldn't be able to download my logs.


Hope there is some help coming soon to fix this problem.

Cheers,
Alan
Since you mention COM3, it appears you are using Windows on a 
desktop/laptop, and not the Android version.
Since Divinglog 6 works with your Leonardo, it appears your download 
cable works ok.
One question: For what possible reason do you need the Cressi interface 
drivers? This would normally only be required if you use the Cressi 
software to download dives.

Read the user manual section that deals with USB downloads.
A suggestion: Open a command prompt in Windows. Then run Subsurface as 
follows:


subsurface -vvv

This opens Subsurface and produces a verbose output of what Subsurface 
does while you are running it and also includes information on any 
errors encountered.
Capture the text of the output in your command window and send that to 
this forum.

Kind regards,
willem


--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Android FTDI support not working with fresh app build

[Bill Perry]

Ok, there is something very strange going on.
Here is what I've done.
I started over. I completely removed the subsurface directory and re-cloned the 
subsurface repo.
Followed the instructions in the INSTALL file and built an android .apk image 
from the head of the tree.
It was slightly larger than the previous .apk image I had previously built that 
wasn't able to open the ftdi port.
This newly built app did not show up when the ftdi cable was plugged in 
(neither did the first one)
When the app was started manually, the app would come up and the immediately 
crash.
I decided to start over again clean and checkout v4.8.1 and see if I could 
build that.
The .apk built from the v4.8.1 code was installed, the app would show up when 
the cable was plugged in.
This newly built v4.8.1 build could talk to the FTDI cable just like the 4.8.1 
app downloaded from the playstore.

Now for the REALLY strange stuff!
The timing that is wrong in the app installed from the playstore is now correct 
with the app I just built.
With the 4.8.1 app I just built, downloads work on both the Galaxy S4 and the 
S7.

I have a logic analyzer hooked to a  h/w & s/w simulator test jig that 
simulates the Pelagic data cable and an Atmos AI
to be able to monitor data and signals on the FTDI chip to see what the host is 
doing.
There is a critical delay that must happen between RTS dropping and the first 
command sent to the PIC inside the Pelagic data cable.
The delay should be 100ms (that is what libdivecomputer code is asking for.)

With the 4.8.1 apk from the play store, this delay is
2.5ms on the Galaxy S4
600us on the Galaxy S7
Both are way too short and that is why downloads don't work. The PIC inside the 
Pelagic datacable misses the command because it isn't listening yet.

With the 4.8.1 code I checkout from the repository and built on my machine, the 
delays are:

103ms on the Galaxy S4
100ms on the Galaxy S7
These are the proper delays and downloads work as they should with this build.

I can post logic analyzer timing diagrams if people are interested in that 
level of detail.

There is something very odd going on.
I'm at a total loss as to what is happening and why my build has working delays 
whereas
the code from the playstore appears to not have working delays.

--- bill


On 09/14/2018 12:53 AM, Dirk Hohndel wrote:
> The Ubuntu package won't help, you need to build it for Android. I thought 
> the scripts did that, but I'm not at my computer and trying to figure this 
> out on the phone is now than I am ready for...
>
> On September 13, 2018 9:11:00 PM PDT, Bill Perry 
>  wrote:
>
> I figured as much.
> I hadn't installed libusb-1.0.0-dev
> so I went back an installed all the Ubuntu packages listed in the INSTALL 
>file, including libusb-1.0.0-dev
> and re-ran the build script. But no difference.
> I must still be missing something, probably really simple.
>
> On 09/13/2018 10:20 PM, Dirk Hohndel wrote:
>
>  On Sep 13, 2018, at 6:05 PM, Bill Perry 
> wrote:
>
>  The android app downloaded from the Playstore behaves 
>differently than the one I just built from current sources.
>  I'm currently testing on a Samsung GS4 running kitkat 4.4.4
>
>  With the one from the play store: version 2.1.0(4.8.0)
>
>  - When the cable is plugged in OS asks to run subsurface.
>  NOTE: it will not do this if running the app in no cloud mode.
>  and it also won't talk over the ftdi cable either.
>  Once in cloud mode,
>  - It can open the port and push bytes out the data cable
>  However, the timing between the bytes & messages is wrong (which 
>is what I'm trying to fix)
>
>  With the one I just built: version 2.1.2(4.8.1.413)
>  It appears to not be able to open the serial connection.
>  The libdivecomputer log shows: Subsurface: 
>v4.8.1-413-g76c4fb397512, built with libdivecomputer 
>v0.7.0-devel-Subsurface-NG (8f2ac8f61e8768d4774983de1f367f73c8c34ea2)
>  INFO: Open: name=ftdi
>  ERROR: No such file or directory (2) [in 
>/home/bill/Documents/devel/Subsurface-devel/subsurface/libdivecomputer/src/serial_posix.c:295
> (dc_serial_open)] Which seems to indicate it is trying open the device "ftdi" 
>vs checking for the magic
"ftdi" name and calling the ftdi serial code instead of serial_posix code.
>  Have I not built the app properly, or is the code broken right 
>now and I should go back to the tagged code from the last release?
>
>  You are building the app without libftdi
>
>  /D
>
>
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface