On 12 December, 2023 - Dirk Hohndel via subsurface wrote:
> I just sent this message to the user forum. I think most of you are on there,
> but just in case...
>
> > Begin forwarded message:
> >
> >
> > The project hasn't made a release in quite a while - but a lot of people
> > are looking
On 09 December, 2023 - Philippe Massart via subsurface wrote:
> > Le 9 déc. 2023 à 10:57, Jef Driesen a écrit :
> >
> > On 8/12/2023 20:56, Philippe Massart via subsurface wrote:
> >> Since several years now, I import .DLF files from my Divesoft Freedom
> >> computer without any problem.
> >>
ersonally I use yubikeys or tpm bound secrets for important things,
depending on what and how it's supposed to be used.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-div
you run planner all over again, an so on.
> >
> > Example. What if I would like to add a feature, that shows the amount of
> > gas you need in case of emergency for any specific point of the dive right
> > under mouse pointer. No, for a second, lets drop the argument about: &
On 25 April, 2022 - Daniel Azuelos via subsurface wrote:
> My last computer died ( after 7 years ).
> I will choose the next one if it is supported by Subsurface because it seems
> a sign they do the job to make their data format interoperable with an open
> software.
>
> Which computers are
d when I did some test dives on RB with them. Proper loop volume
management is quite tricky as a OC diver =)
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
ate the sac rate based on the naive formula, and later
use those extrapolated values to calculate a real sac, so due to
compressibility we think we consume less gas in the beginning and more
towards the end.
A long time ago I took a stab at fixing this but it turned real messy
and I just
(sorry for the top post, on my cell)
I think we have come a long way in these years, and I'd like to send a special
thanks to you Dirk for keeping the project going for most of those years.
//Anton - who hopes to find some time for subsurface in the coming months.
On August 29, 2021 12:43:01
for that platform and how
well Qt supports that platform.
For example, I'd guess its a 2-20h project to port Subsurface-mobile to
Sailfish OS, and that's without usb/bluetooth support.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
nd then sends the app
into the background, and goes off to do something else. Will our code
still get scheduled or will we get suspended and the download will fail?
//Anton - Who might actually test this...
--
Anton Lundin+46702-161604
___
subsurf
y do we need the System.loadLibrary("subsurface-mobile") ? Shouldn't
qt figure that out some how?
I also would love a way for custom serial implementation to log to
libdivecomputers log system, so one can get consistent logging, even
when using a custom serial, but that's not a serial_
en any libusb (or similar abstractions) based cp210x
userspace drivers. Sure, the code can be written, but I think its way
too much work to be worth the effort.
I'd suggest you look into writing a custom-serial glue-layer which uses
jni to call into usb-serial-for-android. I'd suggest looking at the
QtAndroidExtras/QAndroidJniObject layer which makes jni way less
horrible.
I've bin hoping to get around to doing some of this, but due to personal
reasons I haven't had the time and energy. I'm glad to see you take up
this work and get it done.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
n't
crash if a network call returns unexpected data.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
On 09 January, 2020 - Gaetan Bisson wrote:
> Hi Anton,
>
> [2020-01-09 20:47:59 +0100] Anton Lundin:
> > So, can you re-run this and provide a libdivecomptuer logfile? I'd like
> > to see what the device actually says.
>
> Please find the log file attached. Let me kn
, So we compare apples with
apples, and not trying to adress elements outside our QStringList.
If we get a DC_EVENT_DEVINFO event from libdivecomputer with another
product than we provided, we change to that.
So, can you re-run this and provide a libdivecomptuer logfile? I'd like
to see what
m not sure if that functionality ever made it into the Qt ui. It was
there in the GTK+ version.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
use a debugger, or just log based debugging?
I have never managed to get a debugger to work for our stack, so I've
just used watched logcat.
If you ever figure out how, please write a couple of lines about it.
//Anton
--
Anton Lundin
On 19 November, 2019 - Dirk Hohndel wrote:
>
> > On Nov 19, 2019, at 7:09 AM, Anton Lundin wrote:
> >
> > So, somethings odd with the "zip" command on that Mac, causing it to not
> > store the execute flag in the zip.
>
> Yes, I'm sure there's an
releases. It looks like the latest set is
> >>> missing the macOS .app.zip file :-(
> >>>
> >>> I can push a current binary to the Subsurface website download area...
> >>> and I can try and figure out a way to make the upload or the CICD builds
issing? I have QT 5.13.2 installed in my app folder.
You need to have qmake in your path, or point it out with
QMAKE=path/to/qmake or by pointing CMAKE_PREFIX_PATH to the cmake files
in your qt install.
//Anton
--
Anton Lundin+46702-161604
__
tHub Actions.
> I just pushed it to master right before getting on a flight. What could
> possibly go wrong.
Great work!
I think the CI system fills a useful role. Its sad to see travis
dropping the ball, but that's not our problem, and if we have a better
alternative in github actions, go
On 30 September, 2019 - Dirk Hohndel wrote:
>
> > On Sep 30, 2019, at 12:05 AM, Anton Lundin wrote:
> >>
> >> I honestly think that this is the right approach. I started staring at the
> >> code and
> >> as expected the more I look the more I
On 29 September, 2019 - Dirk Hohndel wrote:
> As I try to catch up with my large backlog of email...
>
>
> > On Sep 23, 2019, at 7:45 AM, Anton Lundin wrote:
> >
> > First of all, I'd just try to run our current code on a libusb
> > containing:
> >
g this down, Anton!
The huge upside with android-x86/x86_x64 is that you can run the
emulator with hardware acceleration. The arm emulator is just so slow
that its unusable with modern android.
//Anton
--
Anton Lundin+46702-161604
___
subsurfac
tor in the meantime).
It might be related to:
https://www.qt.io/blog/2019/06/17/qt-5-12-4-released-support-openssl-1-1-1
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsu
RIAL), Vytec (SERIAL), Zoop
> (SERIAL), Zoop Novo (SERIAL)"
> "Tecdiving: DiveComputer.eu (SERIAL, BT)"
> "Tusa: Element II (IQ-750) (SERIAL), Zen (IQ-900) (SERIAL), Zen Air (IQ-950)
> (SERIAL)"
> "Uwatec: Aladin Air Twin (SERIAL), Aladin Air Z (SERIAL), Aladin Air Z Nitrox
> (SERIAL), Aladin Air Z O2 (SERIAL), Aladin Pro (SERIAL), Aladin Pro Ultra
> (SERIAL), Aladin Sport Plus (SERIAL), Memomouse (SERIAL)"
> qqwindow screen has ldpi/pdpi 72 137.184
> qrc:/org/kde/kirigami/GlobalDrawer.qml:258: TypeError: Cannot read property
> 'length' of undefined
> qrc:/org/kde/kirigami/GlobalDrawer.qml:293: TypeError: Cannot read property
> 'length' of undefined
> qrc:/org/kde/kirigami/GlobalDrawer.qml:292: TypeError: Cannot read property
> 'length' of undefined
> "28.136: AppState changed to suspended with no save ongoing and no unsaved
> changes"
> "28.139: AppState changed to inactive with no save ongoing and no unsaved
> changes"
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
On 27 September, 2019 - Anton Lundin wrote:
> On 26 September, 2019 - Dirk Hohndel wrote:
>
> >
> > > On Sep 26, 2019, at 1:49 PM, Anton Lundin wrote:
> > >
> > > On 26 September, 2019 - Dirk Hohndel wrote:
> > >
> > >> I didn
On 26 September, 2019 - Dirk Hohndel wrote:
>
> > On Sep 26, 2019, at 1:49 PM, Anton Lundin wrote:
> >
> > On 26 September, 2019 - Dirk Hohndel wrote:
> >
> >> I didn't think it would even install on Android 5.0... but looking through
> >> the G
ch the linker
can't find in such a old os, and fails there.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
_open_dev.
The upside is that we don't need a patched libusb any more, the downside
is that we drop support for the usb based libdivecomputer backends.
Third option, "The nuclear option" is to drop the whole libftdi based
custom serial backend serial_ftdi.c and write a custom_serial backend
which jni's into something like
https://github.com/mik3y/usb-serial-for-android instead.
The upside for this is that we can start supporting Prolific and Silabs
devices to, but the downside is that its hard to test on a "regular"
linux machine, and probably quite a bit of work.
This is really a "choose your own adventure" kind of deal.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
On 11 September, 2019 - liquid tcp wrote:
> On Wed, Sep 11, 2019 at 4:45 PM Anton Lundin wrote:
>
> > On 11 September, 2019 - Dirk Hohndel wrote:
> >
> > > On Wed, Sep 11, 2019 at 09:07:51AM +0200, liquid tcp wrote:
> > > >
> > > > Since I'm c
eems to fully understand what needs to be done
> doesn't have the time to work on this, and those who care enough and might
> have the time, don't have sufficient understanding how to make the libusb2
> integration with the native USB port access implementation on newer
> Android work.
On 31 May, 2019 - Mauro Besana wrote:
> Il gio 30 mag 2019, 20:14 Anton Lundin ha scritto:
>
> > On May 30, 2019 8:34:57 AM GMT+02:00, Mauro Besana
> > wrote:
> > >Good morning,
> > >I have a small problem with the font size of the software.
>
If you tell us on which platform you're on, we can tell you where the setting
is stored, so you can delete it or change it manually.
//Anton - sorry for top posting, in my phone.
On May 30, 2019 8:34:57 AM GMT+02:00, Mauro Besana wrote:
>Good morning,
>I have a small problem with the font size
.
Btw. It works just fine for the diving I tend to do, IE, drop to rock
bottom, swim around and deco.
I'd suggest we "expand" the planner dive points into some sane sample
size, like 10s intervals before doing this sort of calculations.
//Anton
--
Anton Lundin+46702
ce mode ready) byte, aka the whole memory
dump was sent.
So, some how we ended up being out of order.
I would need to look at the libdivecomputer log file to. It might tell
us what actually happened.
> i guess the biggest point here is that the BTLE Win32 stack works.
YEY.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Sorry for top posting, on my phone.
From memory, the ff in the end is the end communications command, and indeed
its a ff there in the response, it's just prepended by a aa there.
The memdump in the ostc3 back end dumps all the memory, so it doesn't matter if
there's one dive on the DC, or
s coordinate. Any issues we have with the
Garmin download, is probably the same there.
Quite a bit OT, but continuing in that tangent, it might be time for the
DLF thingie to grow up and become a proper libdivecomputer backend,
instead of the subsurface specific import
n't have a signature
> conflict when installing it?
>
This is how I do it:
commit eb42e3c0190acf0e03c57c83f0ef3f04c1f05599
Author: Anton Lundin
Date: Wed Jun 20 20:03:46 2018 +0200
JUNK: Rename mobile app for local dual install
diff --git a/android-mobile/AndroidManifest.xml
b/android-mobile/AndroidManifest.x
On 14 September, 2018 - Bill Perry wrote:
> 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.
in Sport Plus (SERIAL), Memomouse (SERIAL)"
> qqwindow screen has ldpi/pdpi 72 146.967
> "4.798: AppState changed to active with no save ongoing and no unsaved
> changes"
> "15.411: AppState changed to inactive with no save ongoing and no unsaved
> changes"
> "20.321: AppState changed to active with no save ongoing and no unsaved
> changes"
> "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.
> Finishing download thread: "Unable to open ftdi Aeris (Atmos AI)"
> "23.591: Unsupported operation"
> no new dives downloaded
> "23.592: DCDownloadThread finished"
> The item Settings_QMLTYPE_30(0x7ca5f068, "Settings") is already in the PageRow
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
nts to the existing dives.
Others might chime in with different ideas on how to solve this.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
0x80)
Type : Bulk (0x2)
Poll Interval : 0
Max Packet Size: 64
Attributes : 00010
Endpoint: #1
Address: 0x02 (00010)
Number : 2
Direction : Outbound (0x0)
Type : Bulk (0x2)
Poll Interval : 0
Max Packet Size: 64
Attributes : 00010
//Anton
--
Anton
On 11 August, 2018 - Dirk Hohndel wrote:
>
> > On Aug 10, 2018, at 11:08 PM, Anton Lundin wrote:
> >
> > I'd rather say that we don't have this pid listed in serial_ftdi.c
>
> You are of course correct.
>
> The fact that everywhere else we
On August 9, 2018 2:41:58 PM GMT+02:00, Dirk Hohndel wrote:
>On Wed, Aug 08, 2018 at 11:50:21PM -0500, Matt Thompson wrote:
>> Don't know why I didn't think to send this earlier with the other two
>but
>> here is the USB info for the Aqualung i750TC using the standard
>Aqualung
>> connector.
>
Nice work Dirk.
I'll dump some data from my devices when I get back home.
I'd love to see parts of this feature ported to the desktop ui to. On Linux we
can dig out info about ftdi devices from sysfs, and we might be able to do
something equivalent on windows and Mac.
//Anton - sorry for the
17df1f32)
>
>
>
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
+0x62/0x70 [rfcomm]
release_one_tty+0x3e/0xc0
process_one_work+0x1de/0x410
worker_thread+0x32/0x410
kthread+0x121/0x140
? process_one_work+0x410/0x410
? kthread_create_worker_on_cpu+0x70/0x70
? do_syscall_64+0x73/0x130
? SyS_exit+0x17/0x20
ret_from_fork+0x35/0x40
You know its time to go to bed when tho
evice that we might find. This makes it more inline with now the
Bluetooth thingie works.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
On 23 June, 2018 - Davide DB wrote:
> Anton,
>
> I don't see any compelling reason to express your antipathy toward me.
There's no antipathy, just answers to questions and statements.
//Anton
--
Anton Lundin+46702-161604
___
s
e calibration constants and the comment
from Shearwater back then was that this is a internal detail they didn't
want to say anything about it.
The answer might change when someone else asks them, but thats the last
thing I heard.
I don't have any Shearwater devices nor any contacts at that compa
decent way.
This way we can support the "pure usb" devices like EON Steel/Core,
Scubapro G2 and Cobalt in a more obvious way, and letting the user choose
the appropriate device in the box to use that in the open call instead
of just grabbing the first one.
There are probably only a few user
ks old!
> > Why is the libdivecomputer.log not updated when I run the app? I searched
> > the fs but this is the only file I found ... hmm ...
>
> It should be deleted when the app starts. I'll fix that.
This is sort of consistent with my t
it, which made me think that no one actually
> cared (given that the EON Core/Steel work with BLE)
Still no libdivecomputer log anywhere to be found.
I think we should always enable it, and plumb it up into qDebug() so it
all ends up in the same log buffe
libusb
based communication and sent a PR.
https://github.com/Subsurface-divelog/subsurface/pull/1416
Now I have working ftdi and libusb based downloads for both my OSTC3 and
Suunto Eon Steel.
Spoiler. For 6-7 dives on the Eon Steel its about a bazillion times
faster.
//Anton
--
Anton Lundin
Of course I forgot to even compile it, so here's a updated 0002 patch
which actually compiles.
//Anton
On 20 June, 2018 - Anton Lundin wrote:
> Here's the patches.
>
> I splitted them into two, so Jef can cherry-pick the first one, and a
> second one which adds a strings that say
ts.
> >>
> >> Since I'd hate to see you go, is there actually something that we can
> >do
> >> to fix this? Or are we (as in so many small odd corner cases) at a
> >point
> >> where we just don't have the right person to work on something (like
> >the
>
l chain and variable bouncing makes my head spin, so I
think its really hard to get anywhere here.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
replace the
serial_ftdi.c code all together with a implementation using the official
android ftdi driver (d2xx.jar) and doing jni calls into it. The downside
with this is that we would drop support for all pure libusb devices,
like the eon steel, and so on.
//Anton
--
Anton Lundin+46702-161604
_
g time, but
I've never gotten around to it, and with a rooted device, I have a
workaround, just manipulating the repo behind the back of the app.
If someone helps out, I might get motivated to actually do it. One
simple point to start at is to design the UI/UX.
//Anton
On 11 June, 2018 - Jef Driesen wrote:
> On 11-06-18 20:21, Anton Lundin wrote:
> >On 04 June, 2018 - Dirk Hohndel wrote:
> >
> >>I don't have an outstanding patch from you, so not sure what you are
> >>referring to.
> >
> >There was a diff a while b
shit crazy like I am, you can then transplant that repo
into the data folder of your mobile device, and you've loaded your
logbook into your mobile device without the cloud service. It requires a
lot of low level hacking, so its not recommended for anyone else.
//Anton
--
Anton Lundi
waves in my
legs) I might get around to making up a commit message and formating it
as a patch.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/m
; parameters of the OSTC+ 's second characteristic are, i would
> appreciate it.
> is it "Write without response" or "Notify" and on what OS / platform?
>
> cc Anton as i see him as a libdc contributor in this area.
I haven't played around with BLE that much, but I have a OSTC4 which I
can test things against, but no windows around.
On the higher layers of libdc, it doesn't care if its serial, BT or
BTLE, the protocol to talk with OSTC3's (OSTC3, OSTC+, OSTC Sport,
OSTC2, OSTC4 and so on) are all the same.
It's Jan who figured out how to talk with the BLE chip in those, and its
some sort of quasi-standard "serial over BLE" or something.
The current BLE code in Subsurface works just great against the OSTC4 I
got, on both android and Linux.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
If Dirk/Linus feels for it, hey can grab the diff and make up a commit message
and it will be in the next dev build.
I can't really do it because I'm on a diving trip in the baltic, in a storm,
making good head way on tonights target of getting hammered.
//Anton - skepp åhoj!
On June 4, 2018
ting access to
internal documentation which is not for the public to see, as long as
I can do what I want with the knowledge gained from it and the code
written based on that documentation.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
n no value.
It would be dead simple to emit a SAMPLE_EVENT_STRING, or a
DC_FIELD_STRING just saying, "hey, these are not the raw ppO2 values you
where looking for, but the next best thing", if you would have taken
those patches.
//Anton
--
Anton Lundin+46702-161604
__
On 23 May, 2018 - Anton Lundin wrote:
> On 23 May, 2018 - Jef Driesen wrote:
>
> > On 2018-05-23 14:58, Davide DB wrote:
> > >On Wed, May 23, 2018, 12:08 Willem Ferguson
> > ><willemfergu...@zoology.up.ac.za>
> > >wrote:
> > >>If this is t
>
> The only part that we can do something about, is restoring the
> average/voted ppO2 again. That's already on my todo list. But right
> now the libdivecomputer api doesn't have a way to indicate the type
> of the ppO2 value (e.g. average/voted or from an individual sensor),
> so that would cause confusing. So this will require some (backwards
> incompatible) changes, and that's why it's not done yet.
The simple solution is to just emit the average/voted ppO2 when we can't
find the calibration values.
Its a graceful degradation of functionality, and way better than not
showing any ppO2 at all.
It should be simple to write.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
t;mode == FREEDIVE) {
have_temperature = 0;
...
Aka, there are no temperature samples stored when in freediving mode.
Can you import the temperature details with some other software?
//Anton
--
Anton Lundin+46702-161604
___
subsu
Sorry for top posting, on my cell.
No image attached.
I'm guessing that the white circles you're seeing are info events, and you can
read about them in the info box when you hoover the event.
//Anton
On May 11, 2018 9:50:27 AM GMT+02:00, j...@apache.org wrote:
>Hi
>
>If you look at the
On 03 May, 2018 - Davide DB wrote:
> On Thu, 3 May 2018 at 13:15, Anton Lundin <gla...@acc.umu.se> wrote:
>
> > On 03 May, 2018 - Davide DB wrote:
> >
> > > On Wed, 2 May 2018 at 11:04, Anton Lundin <gla...@acc.umu.se> wrote:
> > >
> >
On 03 May, 2018 - Davide DB wrote:
> On Wed, 2 May 2018 at 11:04, Anton Lundin <gla...@acc.umu.se> wrote:
>
> >
> > Try to download them into a fresh logbook with the current desktop
> > version, to see what's happens then.
> >
>
> I've just
On 02 May, 2018 - Davide DB wrote:
> On Wed, 2 May 2018 at 11:04, Anton Lundin <gla...@acc.umu.se> wrote:
>
> > > > What's happening when you're trying to merge them?
> > > >
> > >
> > > The second dive (#175) disappear but the first dive
On 02 May, 2018 - Davide DB wrote:
> On Wed, 2 May 2018 at 10:31, Anton Lundin <gla...@acc.umu.se> wrote:
>
> > On 30 April, 2018 - Davide DB wrote:
> >
> > > Hi all,
> > >
> > > I was playing with 4.7.8 on Windows 7 and I noted a couple of th
t for
> merging?
It's not 11 minutes between those two, its 58 minutes.
There's a warning if you're trying to merge dives with more than 30
minutes between them.
What's happening when you're trying to merge them?
//Anton
--
Anton Lundin+46702-161604
__
this world, having a attribute in the xml named "po2" is just really
confusing, and we should probably rename it to setpoint, because that's
what we're using it for nowadays. With this, the problem of migrating
old data comes to.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
that will just
affect the deco data generated by your computer.
This way, you can compare dive computers deco algorithms with the
subsurface implementation.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsur
ial" release of the NG that is beeing maintained? Maibe
> > I am using the wrong one?
Maybe we should try to clarify the gf settings ontop of the profile so
its clear that those are the settings that _subsurface_ are using, and
not the ones from the dc.
//Anton
--
Anton Lundin
On 25 April, 2018 - Linus Torvalds wrote:
> On Wed, Apr 25, 2018 at 10:38 AM, Anton Lundin <gla...@acc.umu.se> wrote:
> >
> > I've tested it now, via the serial layer, libftdi layer, classic bt
> > layer, and with your latest patch BLE and they all work.
>
> O
layer, classic bt
layer, and with your latest patch BLE and they all work.
( I have a patch pending for fixing the ostc3 config code against firmware
2.97, that I should clean up and sed out to, any day now )
//Anton
--
Anton Lundin+46702-161604
___
su
nt to ensure that we don’t break the build…
Good work!
CI for the win.
Now we just need to start adding some functional tests, besides "it
compiles" =)
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsu
On 18 April, 2018 - Miika Turkia wrote:
> On Wed, Apr 18, 2018 at 6:19 PM, Anton Lundin <gla...@acc.umu.se> wrote:
>
> > On 18 April, 2018 - Willem Ferguson wrote:
> >
> > > On 18/04/2018 16:05, Miika Turkia wrote:
> > > >On Wed, Apr 18, 2018 at
seDL7()
params[pnr++] = intdup(-1);
params[pnr++] = strdup("pressureField");
params[pnr++] = intdup(-1);
- params[pnr++] = strdup("setpointFiend");
+ params[pnr++] = strdup("setpointField");
params[pnr++] = intdup(-1
g we can do to make the to delegates in DiveList.qml take less time
> will help
> with the smoothness of the scrolling...
>
> But I'm glad that right now no one appears to be seeing (2) anymore...
I did see it up until the latest beta update, where it went away.
I'm also really glad that its gone, it was driving me nuts, and I was
even thinking about learning qml to fix it =)
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
the libftdi support. There's no reason to use
it when you're running on a system with proper kernel drivers.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
ng, so we might run into each other out there =)
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
an someone help me?
It's sort of hard to help you without knowing what the problem is.
There's should be a subsurface.log on your /sdcard/ which might help
diagnosing the problem.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mail
etween OC, CCR and PSCR, independent of everything
else. That could be implemented as a bailout event between whatever mode
you're in and OC, or a dedicated mode switch event.
Ie CCR + bailout -> OC on you're current diluent, and so on.
//Anton
--
Anton Lundin+46702-161604
___
On 13 March, 2018 - Robert Helling wrote:
>
>
> Am 13.03.2018 um 12:25 schrieb Anton Lundin <gla...@acc.umu.se>:
>
> >> From subsurface point of view, it really doesn't matter if we represent
> > a bailout as a gasswitch event or not. The problem with the
n that up into some bailout sematics which works for
both SCR and CCR code, with or without o2 sensors.
If we implement that as a divemode switching event, a gaschange event
with some special flags, i don't really have a opinion until i see a
real suggestion. Nothing says we can't have a g
hould to be added to.
I haven't had the time to keep up with all the new interesting things
thats landed in hwos lately.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
the predator.
Are you sure you did pick "predator" ?
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
o build up some deco time,
and don't have anything better around...
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
A crazy idea is to do a linear regression on every dive with bogus cal
factors and actually calculate the real cal factors based on mV values
and average ppO2.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface
in some way.
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
On 11 December, 2017 - Davide DB wrote:
> On 11 December 2017 at 15:59, Anton Lundin <gla...@acc.umu.se> wrote:
> > On 11 December, 2017 - Davide DB wrote:
> >
> >> On 11 December 2017 at 10:16, Anton Lundin <gla...@acc.umu.se> wrote:
> >> >> I
On 11 December, 2017 - Davide DB wrote:
> On 11 December 2017 at 10:16, Anton Lundin <gla...@acc.umu.se> wrote:
> >> I calibrate my two Petrels ALWAYS when I assemble my unit as part of
> >> my checklist and ALWAYS the same day I dive and. No calibration No
> >
when I assemble my unit as part of
> my checklist and ALWAYS the same day I dive and. No calibration No
> party.
> I made other dives and all of them show the same error. Shearwater
> desktop tell me that everything is ok (like my Petrel underwater)
> while Subsurface reports pO2 over 1.6.
> Thank you for the detailed explanation.
> Where do we go from here?
Is this a divecan unit or something?
I'm just guessing that it might affect how/where the cal factors are stored.
//Anton
--
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
On 03 December, 2017 - Anton Lundin wrote:
> On 02 December, 2017 - Davide DB wrote:
>
> > On 2 December 2017 at 22:29, Anton Lundin <gla...@acc.umu.se> wrote:
> > >
> > > Your Sensor 3 reads a bit high towards the end of the dive, but
1 - 100 of 689 matches
Mail list logo
