subsurface accessibility

[Simon Eigeldinger]

Hi all,

Just made a short video of me navigating throughsubsurface on win 10.
though i don't know if that is useful or not. *smile*
https://www.dropbox.com/s/mymp7pmsxh7irkx/clip0001.mp4?dl=1



i navigate through the main window, also through the dialog for creating 
a new dive.


Greetings,
Simon


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

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

Re: Accessing Petrel downloads and events

[Jef Driesen]

On 2018-02-28 11:52, Willem Ferguson wrote:

1) In both CCR mode as well as SCR mode, the Petrel 2 allows switching
between OC bailout gases and CC gases. This done by performing
selecting either  BO->SC  or  SC->BO from the Shearwater menu. These
events must be recorded in the dive log but are presently not easily
accessible, at least from within Subsurface. How does libdivecomputer
see the events? Is there any way to acces them from Subsurface?


There is an OC/CC bit in every sample. It's currently only used for 
enabling/disabling the ppO2 and setpoint samples. But the value itself 
(or a change of the value) is not reported.



2) Shown below is the Subsurface log trying to download a Petrel 2
dive into a dump for better analysis. However, every time I try this,
the download aborts. With the "Save dumpfile" and Save logfile:
options NOT checked, the download goes flawlessly.


The Petrel protocol doesn't support downloading memory dumps.

(1) Download a memory dump using the older predator protocol. This 
protocol supports memory dumps, but the drawback is that not all 
information will be downloaded this way. Only the most recent dives are 
accessible and even the dives that can be downloaded have some 
information removed. (The Petrel sample size is twice as large as the 
Predator samples, so some info gets dropped when using the older 
protocol.)


(2) Dump the raw data of the individual dives. Unfortunately Subsurface 
doesn't support this and you'll need to use libdivecomputer's dctool 
command-line application:


dctool -vv -l petrel.log -f petrel download -o dive.%n.bin -f raw 



Or as an alternative, only enable the libdivecomputer logfile checkbox 
(but NOT the dumpfile checkbox). I can extract the raw data from the 
logfile.



One thing to notice is the warning below:

WARNING: Disabled all O2 sensors due to a default calibration value.

This is despite explicit calibration before the dive. This is similar
to your issue with my Predator download, previously discussed.
Unfortunately the Predator is in the UK at present, so I could not do
an analogous download from that dive computer.


This warning means that all O2 sensors are marked as being calibrated in 
the data, but the calibration values are left at their factory default 
settings. So the sensors were probably calibration (as you confirm), but 
for some reason the calibration values are not stored. And thus we can't 
convert the ppO2 data from millivolt to ppO2.


Do you have a divecan unit? I believe Anton mentioned a while ago that 
he suspects the calibration might be done a bit different there. In a 
way where the dive computer gets the ppO2 values directly and thus 
doesn't need the calibration values. But only the millivolt values are 
stored, but we can't convert them to ppO2 without the correct 
calibration values.


So this warning means you won't get any ppO2 samples from 
libdivecomputer.


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

Re: Latest update

[Lubomir I. Ivanov]

On 28 February 2018 at 13:35, Lubomir I. Ivanov  wrote:
> On 28 February 2018 at 13:23, Long, Martin  wrote:
>> I believe it is a simple setting in the manifest.  android:installLocation
>> which can be either "preferExternal" or "auto" (or not present, to disallow
>> moving to SD). I suspect this may have changed.
>>
>> However, there are certain types of app which can not/should not be moved to
>> SD. It may be that subsurface has started to fall into one of these
>> categories.
>
> i've checked the value in our manifest and it's 
> android:installLocation="auto".
>
> maybe our underlying framework is the cause - Qt.
> yet quickly googling about Qt apps that don't work from a SD card i
> can't find any results.
>
>>  The various reasons can be found here:
>> https://developer.android.com/guide/topics/data/install-location.html
>>
>
> "Applications That Should NOT Install on External Storage"
>
> i don't think we fall under that category in terms of our code base.
> again, it could be a generic Qt issue.
>
> it's best if you can log an issue in our github if you have an account:
> https://github.com/Subsurface-divelog/subsurface/issues
>

could be an issue with that particular device and we don't have
control over that - e.g. a Samsung specific sandobox.
can you try on another Android device?

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

Re: Latest update

[Jan Mulder]

And I just tested on my LineageOS 14.1 (Android 7.1.2) device. The app 
moves to SD card as it should.


Further, there are no changes in the git history related to this setting.

--jan


On 28-02-18 12:35, Lubomir I. Ivanov wrote:

On 28 February 2018 at 13:23, Long, Martin  wrote:

I believe it is a simple setting in the manifest.  android:installLocation
which can be either "preferExternal" or "auto" (or not present, to disallow
moving to SD). I suspect this may have changed.

However, there are certain types of app which can not/should not be moved to
SD. It may be that subsurface has started to fall into one of these
categories.


i've checked the value in our manifest and it's android:installLocation="auto".

maybe our underlying framework is the cause - Qt.
yet quickly googling about Qt apps that don't work from a SD card i
can't find any results.


  The various reasons can be found here:
https://developer.android.com/guide/topics/data/install-location.html



"Applications That Should NOT Install on External Storage"

i don't think we fall under that category in terms of our code base.
again, it could be a generic Qt issue.

it's best if you can log an issue in our github if you have an account:
https://github.com/Subsurface-divelog/subsurface/issues

thanks
lubomir
--




On 25 February 2018 at 15:43, Dirk Hohndel  wrote:


I'll admit that I have no idea what gates the ability of an app to be
moved to SD card. I don't own any Android devices that support SD card, so I
can't even test this...

/D

On February 25, 2018 2:58:48 AM PST, paul.e.c...@virgin.net wrote:


Hi,
 I have the Beta version of subsurface mobile on my Samsung tablet. I
had it stored on the SD card. The latest update could not update on the SD
card. I transferred the App to the tablet's memory and updated successfully.
I then tried to transfer the App back to the SD card but wasn't able to.
Regards,
 Paul Cole.


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

Re: Latest update

[Lubomir I. Ivanov]

On 28 February 2018 at 13:23, Long, Martin  wrote:
> I believe it is a simple setting in the manifest.  android:installLocation
> which can be either "preferExternal" or "auto" (or not present, to disallow
> moving to SD). I suspect this may have changed.
>
> However, there are certain types of app which can not/should not be moved to
> SD. It may be that subsurface has started to fall into one of these
> categories.

i've checked the value in our manifest and it's android:installLocation="auto".

maybe our underlying framework is the cause - Qt.
yet quickly googling about Qt apps that don't work from a SD card i
can't find any results.

>  The various reasons can be found here:
> https://developer.android.com/guide/topics/data/install-location.html
>

"Applications That Should NOT Install on External Storage"

i don't think we fall under that category in terms of our code base.
again, it could be a generic Qt issue.

it's best if you can log an issue in our github if you have an account:
https://github.com/Subsurface-divelog/subsurface/issues

thanks
lubomir
--


>
> On 25 February 2018 at 15:43, Dirk Hohndel  wrote:
>>
>> I'll admit that I have no idea what gates the ability of an app to be
>> moved to SD card. I don't own any Android devices that support SD card, so I
>> can't even test this...
>>
>> /D
>>
>> On February 25, 2018 2:58:48 AM PST, paul.e.c...@virgin.net wrote:
>>>
>>> Hi,
>>> I have the Beta version of subsurface mobile on my Samsung tablet. I
>>> had it stored on the SD card. The latest update could not update on the SD
>>> card. I transferred the App to the tablet's memory and updated successfully.
>>> I then tried to transfer the App back to the SD card but wasn't able to.
>>> Regards,
>>> Paul Cole.
>>>
>>> Virus-free. www.avg.com
>>
>>
>> --
>> from my phone.
>>
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface