Re: latest Windows binary crashes

[Lubomir I. Ivanov]

On 5 July 2017 at 01:53, Davide DB  wrote:
> On 5 July 2017 at 00:22, Lubomir I. Ivanov  wrote:
>>
>> here is an animated gif of it in action -> extract the gif from the
>> zip file and drag & drop it in a browser to view it.
>> https://www.dropbox.com/s/oinkj5jjvjaf3yy/WebKitGoogleMapsAnimatedGifPreview.zip?dl=0
>
>
> Lubomir, do you pretend I dive into that river? :)
>

doesn't look like the best diving spot. i agree. :)

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

Re: latest Windows binary crashes

[Davide DB]

On 5 July 2017 at 00:22, Lubomir I. Ivanov  wrote:
>
> here is an animated gif of it in action -> extract the gif from the
> zip file and drag & drop it in a browser to view it.
> https://www.dropbox.com/s/oinkj5jjvjaf3yy/WebKitGoogleMapsAnimatedGifPreview.zip?dl=0


Lubomir, do you pretend I dive into that river? :)

PS
Its' time to refresh an old idea I proposed years ago...

-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: latest Windows binary crashes

[Lubomir I. Ivanov]

On 4 July 2017 at 20:11, Lubomir I. Ivanov  wrote:
> On 4 July 2017 at 19:26, Dirk Hohndel  wrote:
>>
>>
>> I like Lubomir's idea of just using a web browser pointing at an 
>> appropriately
>> customized web page. Let's see where this takes us. We only use Marble on
>> the desktop, so the restrictions with showing web pages don't bother us.
>>
>
> other than that the custom POC is almost done. i need like 2-3 hours
> more, so it's going to be finished later today or tomorrow.
>

here is an animated gif of it in action -> extract the gif from the
zip file and drag & drop it in a browser to view it.
https://www.dropbox.com/s/oinkj5jjvjaf3yy/WebKitGoogleMapsAnimatedGifPreview.zip?dl=0

this is the source code:
https://www.dropbox.com/s/e9fbgcbjd8zyk3s/WebKitGoogleMapsSrc.zip?dl=0

to build:
extract the source zip in ~/
cd ~/
qmake
make

the binary needs "libeay", "libssl", "ssleay" the same way the current
webkit in subsurface needs them.

random notes:
- there seems to be some delay until the map loads for the first time,
i think we can listen for that
- also the first markers are not added immidiatelly (maybe it's my internet)
- better animations can be added when clicking on markers, so that the
map zooms and pans smoothly. the built-in animation isn't great for
that.
- the green tick images are just downloaded from the internet. a
marker image as Qt resource should be used instead
- the info boxes contents can be customized
- if someone has taken photos near a dive site - even the street view
thing works (by dragging the street view "human figure" from the
right).
- this example is running using a public API key that i've created,
this probably needs to be changed to another google account.
- localization is supported - e.g. passing "en_US"

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

Re: Android BT/BLE with Petrel 2

[Rick Walsh]

On 5 Jul. 2017 4:09 am, "Linus Torvalds" 
wrote:

On Tue, Jul 4, 2017 at 6:31 AM, Dirk Hohndel  wrote:
>> 07-04 19:19:20.268  2423  2520 D /data/newandroid/subsurface/
qt-models/messagehandlermodel.cpp: INFO: Creating Android Central/Client
support for BTLE
>> 07-04 19:19:20.272  2423  2520 D /data/newandroid/subsurface/
qt-models/messagehandlermodel.cpp: INFO: qt_ble_open( 00:13:43:0E:6B:D0 )
>> 07-04 19:19:20.394  5484 32204 D BtGatt.GattService: 
>> clientConnect(org.subsurfacedivelog.mobile)
- address = 00:13:43:0E:6B:D0, isDirect=true transport =2 set own addr =
false own addr type:0, clientIf: 4
>> 07-04 19:19:20.877  2423  2423 D /data/newandroid/subsurface/
qt-models/messagehandlermodel.cpp: INFO:
"LocalDeviceBroadcastReceiver::onReceive()
- event: android.bluetooth.device.action.ACL_CONNECTED"
>> 07-04 19:19:20.898  2423  2520 D /data/newandroid/subsurface/
qt-models/messagehandlermodel.cpp: INFO: Connection updated: error:
QLowEnergyController::Error(NoError) oldState: QLowEnergyController::
ControllerState(ConnectingState) newState: QLowEnergyController::
ControllerState(ConnectedState)
>> 07-04 19:19:21.000  2423  2520 D /data/newandroid/subsurface/
qt-models/messagehandlermodel.cpp: INFO: connected to the controller for
device 00:13:43:0E:6B:D0
>> 07-04 19:19:21.001  2423  2520 D /data/newandroid/subsurface/
qt-models/messagehandlermodel.cpp: INFO:   .. discovering services
>> 07-04 19:19:21.006  2423  2520 D /data/newandroid/subsurface/
qt-models/messagehandlermodel.cpp: INFO: Service discovery initiated
>> 07-04 19:19:33.409  2423  2520 D /data/newandroid/subsurface/
qt-models/messagehandlermodel.cpp: INFO:  .. done discovering services
>> 07-04 19:19:33.409  2423  2520 D /data/newandroid/subsurface/
qt-models/messagehandlermodel.cpp: INFO: failed to find suitable service on
00:13:43:0E:6B:D0
>> 07-04 19:19:33.420  5484 27635 D BtGatt.GattService:
clientDisconnect(org.subsurfacedivelog.mobile) - address=00:13:43:0E:6B:D0,
connId=4, clientIf: 4
>> 07-04 19:19:33.439  5484 27630 D BtGatt.GattService:
clientDisconnect(org.subsurfacedivelog.mobile) - address=00:13:43:0E:6B:D0,
connId=null, clientIf: 4
>
> That's odd. Not sure if Linus will have a moment to look at this.

It doesn't seem to be discovering any services at all, much less one
that is write/notify. So it gives up.

I have no idea why. Testing with the Nordic nRF app would be good, and
maybe making sure it's bonded there and shows all services..

I downloaded the Nordic nRF Connect app. It shows the Petrel (2) as bonded
and I can connect with it. But the DC screen still continues with its
countdown.
3 client primary service's are shown:
Generic access 0x1800
Device incformation 0x180a
Unknown service fe25c237-0ece-443c-b0aa-e02033e7209d

Interestingly, the device list shows the Petrel as type: ble only. That is
consistent with the subsurface-mobile logcat output. But i have definitely
used it as traditional Bluetooth.

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

Re: OSTC over BLE experiences and questions

[Jan Mulder]

On 04-07-17 20:30, Linus Torvalds wrote:

On Tue, Jul 4, 2017 at 10:04 AM, Jan Mulder  wrote:


:-) What I can add to my use case ... even the communication stops, the
"download mode enabled" stays on on the OSTC3.


Looking at the dump, I think this is a flow control issue with that
"rx/tx credit" thing.

In particular, I think - if I read that dump correctly - that in
packet 90 you set that receive credit to the max by writing one byte
of 255 to handle 18.

And I didn't count the exact number of Handle Value Notification
packets you get on the handle 0x0f, but it's definitely in the ~250
packet range (starts at packet 131, ends at packet 395, with roughly a
dozen packets that we send in between.

If it's not exactly 255 packets, it's something very close.

So I think you may need to write that credit thing every once in a while..

   Linus



Indeed, that was something I was thinking of myself. And to check this 
idea I already did write the 255 value to that same descriptor I write 
it to in the initialization on every call of the write() function. They 
showed up correctly in the logging, including write confirmation. But 
all this, the stopping behavior was identical. That made me think it was 
not related to the initial credit setting.


This all said. I just counted the received packets ... and it is spot on 
255 packets. So I'm now sure that it is related to that credit thing, 
but still very unsure how to fix that, given my earlier attempt. I just 
further tested setting the initial credits to 200, and, yes, I receive 
exactly 200 packets from the OSTC.


A relevant fragment of that TIO doc: "It is the Terminal I/O client's 
responsibility to track the number of UART credits granted by the server 
(peripheral) by adding the number of received credits to a
credit counter and decrementing the credit counter for each UART data 
packet written to the server. Once the credit counter reaches 0, the 
Terminal I/O client shall not send any UART data until having received 
additional UART credits from the server." (in this text, the Terminal 
I/O client is Subsurface, and the "server" is the TIO implementation on 
the Telit/Stollmann chip).


Ok, the current Subsurface code does not track "the credit counter", but 
the quoted section is highly unclear (to me). Only tracking the counter 
on Subsurface side will not help the OSTC to decide to stop sending. It 
needs to be communicated too, and the only way seems the already tried 
resetting it back to 255. What I'm going to try is, indeed tracking the 
counter, and send the newly wanted packets, but taking care not to ask 
more than the 1 byte can handle (that might explain why just asking for 
255 when there al still 50 left does not work) ... what a pain ...


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

Re: latest BLE code plus new Android APK

[Linus Torvalds]

On Tue, Jul 4, 2017 at 11:55 AM, Dirk Hohndel  wrote:
> On the road.
>
> I switch the Android app to a test account. I have one for each dive
> computer I'm testing. And then I delete the last couple of dives and trigger
> a new download...

Ahh, ok. I guess I should try something similar. Not going to work on
that right now, though.

> The Pedix doesn't work in Android, yet. I'll need to build Qt with the patch
> that Alex proposed to see if they fixes the problem...
>
> I was wondering if it still works for you on Linux with your patched bluez.

Yes, works fine with current subsurface on my desktop.

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

Re: Subsurface-mobile user manual

[Dirk Hohndel]

If it's in the master of the repo that you shared with me, I can extract and 
merge, no problem.

Thanks!

/D

⁣--
>From my phone​


 Original Message 
From: Willem Ferguson 
Sent: Tue Jul 04 11:24:34 PDT 2017
To: Subsurface Mailing List 
Subject: Subsurface-mobile user manual

I need some help to send a pull request. I created a private repository in
GitHub and changed the mobile manual in my private master. Now I need to
get the appropriate notification to Dirk.

I cannot find the step by step procedure that Dirk wrote about maybe 2
weeks ago. Perhaps it would be a good idea to put this information as part
of the Subsurface source?

Kind regards,
willem




___
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

Re: OSTC over BLE experiences and questions

[Linus Torvalds]

On Tue, Jul 4, 2017 at 10:04 AM, Jan Mulder  wrote:
>
> :-) What I can add to my use case ... even the communication stops, the
> "download mode enabled" stays on on the OSTC3.

Looking at the dump, I think this is a flow control issue with that
"rx/tx credit" thing.

In particular, I think - if I read that dump correctly - that in
packet 90 you set that receive credit to the max by writing one byte
of 255 to handle 18.

And I didn't count the exact number of Handle Value Notification
packets you get on the handle 0x0f, but it's definitely in the ~250
packet range (starts at packet 131, ends at packet 395, with roughly a
dozen packets that we send in between.

If it's not exactly 255 packets, it's something very close.

So I think you may need to write that credit thing every once in a while..

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

Subsurface-mobile user manual

[Willem Ferguson]

I need some help to send a pull request. I created a private repository in
GitHub and changed the mobile manual in my private master. Now I need to
get the appropriate notification to Dirk.

I cannot find the step by step procedure that Dirk wrote about maybe 2
weeks ago. Perhaps it would be a good idea to put this information as part
of the Subsurface source?

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

Re: Android: crash on deleting dives

[Willem Ferguson]

>From phone. I reliably get a crash when using the red button for delete.
Deleting from details (profile) view appears to delete dives reliably.
Kind regards,
Willem

On 04 Jul 2017 4:43 PM, "Dirk Hohndel"  wrote:

>
> > On Jul 4, 2017, at 12:18 AM, Rick Walsh  wrote:
> >
> > Hi,
> >
> > Testing the latest daily Subsurface-mobile Android build, 4.6.4.333, I
> get a crash sometimes when deleting a dive.  It may be a coincidence, but
> it only appears to crash when deleting a dive that is not the most recent.
> Below is the output from 'adb logcat | grep -i subsurface', where I opened
> Subsurface-mobile and successfully deleted some dives, before crashing on
> the fourth or fifth.  I first noticed this problem a week or so ago, so
> this does not appear to be caused by one of the most recent changes.
>
> We've seen this on and off and if I was able to reproduce it reliably I'd
> love to fix it... really.
>
> I just spent about ten minutes on my phone with test data, randomly
> deleting dives, undo-ing the deletes, doing more deletes. Can't make it
> crash.
>
> Quick question: do you use the delete on the action button in the dive
> details view, or do you use the tap-and-hold delete from the dive list?
>
> /D
> ___
> 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

Re: progress report

[Benjamin]

The file for Mac works, apart from downloading still failing with the
"insufficient permissions" error.

Benjamin

On 4 July 2017 at 08:38, Dirk Hohndel  wrote:

>
> (1) Subsurface-mobile for Android
>
> We now have confirmed that this works for the Suunto EON Steel (BLE), the
> Scubapro G2 (BLE), and the BT versions of the Shearwater family
> I bumped the version to Subsurface-mobile 2.0 (seems justified with the
> significant new feature) and am hoping to push this out as a beta on Google
> Play. But since I'll be on a family road trip for the next two days, maybe
> tonight is not the best time to do this. Maybe in the meantime people here
> could give this a bit more testing.
>
> http://subsurface-divelog.org/downloads/test/Subsurface-
> mobile-4.6.4.333-arm.apk
>
>
> (2) Subsurface for Mac
>
> I figured out why the signature failed. Please test this DMG:
>
> http://subsurface-divelog.org/downloads/test/Subsurface-4.6.
> 4-333-gbc1a313c9f13.dmg
>
> BT should work with this. I ran out of time testing BLE.
>
>
>
> Windows is still broken (sorry), while Robert started on iOS, I ran out of
> time to continue to work on that.
>
> Have fun
>
> /D
>
> ___
> 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

Re: Images needed: Subsurface-mobile user manual

[Salvador Cuñat]

Good evening

El 04/07/2017 15:25, "Dirk Hohndel"  escribió:
>
> FTDI doesn't really work right now :-(
> Let me rephrase this, it doesn't work on any of my devices.
>
Well, it actually *almost* does for my OSTC 2N.  It downloads 9 out of 20
dives from the DC, just the older.
Haven't figured out how to get a log from the Android phone with the USB
port busy with the device.

Best regards.

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

Re: latest Windows binary crashes

[Lubomir I. Ivanov]

On 4 July 2017 at 19:26, Dirk Hohndel  wrote:
>
>
> I like Lubomir's idea of just using a web browser pointing at an appropriately
> customized web page. Let's see where this takes us. We only use Marble on
> the desktop, so the restrictions with showing web pages don't bother us.
>

ultimatelly if QtLocation supports satellite images it might be the
better solution.
other than that the custom POC is almost done. i need like 2-3 hours
more, so it's going to be finished later today or tomorrow.

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

Re: OSTC over BLE experiences and questions

[Jan Mulder]

On 04-07-17 18:51, Matthias Heinrichs wrote:

Am 04.07.2017 um 17:47 schrieb Matthias Heinrichs:

Then the first depth sample: 0xcf:0x46:0x00 -> 18127mbar depth (+0x00
additional bytes)??!


Ok, I should better have looked in our documentation before sending the 
last mail. Sorry for that.


The first bytes in your log are the "small header" as documented: 
:cf:46:00 (Profile length in bytes)

:02 (Sampling rate)
:07 (Amount of  divisors)
:00:02:06
:01:02:06
:02:01:0c
:03:09:02
:04:0f:0c
:05:02:0c
:06:00:00 (7 divisors with ppO2 data)

First real samples:
:91:01:00 -> 401mbar depth
:dc:01:09:00:00:00:00:00:00:00:00:00 -> 476mbar depth + (empty) Sensor data
:12:02:00 -> 530mbar depth
:44:02:09:00:00:00:00:00:00:00:00:00 -> 580mbar depth + (empty) Sensor data
:63:02:00 -> 611mbar depth

and so on. All fine sample data. It basically stops transmitting in 
packet #395 for no known reason.


Regards,
Matthias



Ok, thanks for this update. Reading PIC assembler is not my biggest 
skill :-) What I can add to my use case ... even the communication 
stops, the "download mode enabled" stays on on the OSTC3. And my desktop 
shows that it is still connected. Only when I actively disconnect from 
the desktop, the OSTC3 reports "exit" and returns to the surface mode 
screen. This all might imply that the working of the OSTC3 is fully 
correct, and the issue is in the other (desktop BT controller etc.) end. 
However, as I said in my first post. Really nothing special to see on 
the desktop logs/kernel logs etc.


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

Re: latest BLE code plus new Android APK

[Linus Torvalds]

On Tue, Jul 4, 2017 at 9:37 AM, Dirk Hohndel  wrote:
>
> I'm about to leave and will have limited access for the next two days.
>
> I merged Jan's initial code for OSTC support plus a fix to make it work for
> the EON Steel again. I verified that it still works on my old BT-only
> Petrel.
>
> Linus, can you check the Perdix AI with the latest master?

The EON Steel seems to work, but since it doesn't do the "force
download all dives", it's hard to tell (I have all dives from it
already). How do you usually that?

The Perdix seems to do the first command and get the first reply, but
that's it. The log doesn't look wrong, but it also doesn't seem to
download any dives (not even the first dive to test).

Hmm. Also, the Perdix didn't work at all until I used the "Paired
devices" case - trying to do it with the vendor/type just got me
rfcomm. That may be intentional.

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

Re: OSTC over BLE experiences and questions

[Matthias Heinrichs]

Am 04.07.2017 um 17:47 schrieb Matthias Heinrichs:

Then the first depth sample: 0xcf:0x46:0x00 -> 18127mbar depth (+0x00
additional bytes)??!


Ok, I should better have looked in our documentation before sending the 
last mail. Sorry for that.


The first bytes in your log are the "small header" as documented: 
:cf:46:00 (Profile length in bytes)

:02 (Sampling rate)
:07 (Amount of  divisors)
:00:02:06
:01:02:06
:02:01:0c
:03:09:02
:04:0f:0c
:05:02:0c
:06:00:00 (7 divisors with ppO2 data)

First real samples:
:91:01:00 -> 401mbar depth
:dc:01:09:00:00:00:00:00:00:00:00:00 -> 476mbar depth + (empty) Sensor data
:12:02:00 -> 530mbar depth
:44:02:09:00:00:00:00:00:00:00:00:00 -> 580mbar depth + (empty) Sensor data
:63:02:00 -> 611mbar depth

and so on. All fine sample data. It basically stops transmitting in 
packet #395 for no known reason.


Regards,
Matthias

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

latest BLE code plus new Android APK

[Dirk Hohndel]

I'm about to leave and will have limited access for the next two days.

I merged Jan's initial code for OSTC support plus a fix to make it work for the 
EON Steel again. I verified that it still works on my old BT-only Petrel.

Linus, can you check the Perdix AI with the latest master?

Android APK is here:

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.6.4.343-arm.apk
 


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

Re: latest Windows binary crashes

[Dirk Hohndel]

> On Jul 4, 2017, at 9:19 AM, Thiago Macieira  wrote:
>> I was told on the Qt list that there is a MUCH newer branch that I should
>> try - they have updated to a current WebKit. The thing that's odd... between
>> 5.7.1 (which the Windows binaries used to be based on) and 5.9 there
>> shouldn't really have been any WebKit changes... so why does it crash now.
> 
> There are a number of minor changes submitted to the 5.8 and 5.9 branches by 
> people like Konstantin, Allan and me. Mine were mostly just to make it, but 
> looking at the diff there appear to be a couple of backports from upstream.

OK. For now I have given up on upgrading the libraries in the Windows
binary. BLE isn't supported, anyway, so whatever. I'll stick with 5.7.1 as
that creates working builds for me.

I'll revisit this when I have an excess of time on my hands :-)

>>> i mean i can possibly find the offending line of code, but i won't
>>> really have a good fix for it. after seeing that unpredictable Marble
>>> multi-threading crash on Windows, i think we are entering the
>>> territory of big, complicated but unmaintained libraries that simply
>>> may not run with the latest Qt version. Qt 6.0 is coming too...
>> 
>> I think they are working on 5.10 ...
> 
> Qt 6.0 will be discussed at the Contributor Summit this year in Berlin. The 
> current idea is that 5.12 will be LTS and then 6.0. That would put 6.0 about 
> two years away from now.

Interesting. Will 6.0 once again be incompatible as the major version bump
implies? What will change?

>>> so we need to:
>>> 1) move away from these unmaintained libraries
>>> WebKit - currently we are stuck with WebKit on Windows
>>> Grantlee - we are stuck with Grantlee due to the template syntax which
>>> the users are already using
>>> Marble - we probably should start using a 2D map of sorts
>> 
>> WebKit - I think we are stuck with that for a while
>> Marble - Tomaz has this working with the latest, maintained Marble
>> Grantee - I have this working on Mac
> 
> What happened to the idea of using QtLocation for maps?

We talked about this here a few times.
We absolutely have to have satellite images. Maps are useless for a dive log.
And QtLocation appears to only support maps. So no go.

I like Lubomir's idea of just using a web browser pointing at an appropriately
customized web page. Let's see where this takes us. We only use Marble on
the desktop, so the restrictions with showing web pages don't bother us.

>>> BTW you can try building this QtWebKit port as it's actively updated:
>>> https://github.com/annulen/webkit/releases
>> 
>> Yes, and that appears to be in the 5.212 branch of Qt that I need to
>> find the time to investigate...
> 
> 5.212 builds with CMake, not qmake anymore. My recommendation is that you 
> build it after all the rest of Qt.

Hmm. I still haven't looked at this. Too many parts of the code that are in
motion, too many platforms, too little help, too little time...

So 5.212 is just QWebKit that I build against an existing Qt build?
Of course, I will still have to build from source for Linux and Android, it 
seems,
as in both cases 5.9.1 is missing BLE patches from Alex that we need...

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

Re: latest Windows binary crashes

[Linus Torvalds]

On Tue, Jul 4, 2017 at 9:19 AM, Thiago Macieira  wrote:
>
> What happened to the idea of using QtLocation for maps?

As noted elsewhere, we require high-quality satellite imagery for dive
site location - seeing shallow reefs under water world-wide and things
like smallish coastal features. That effectively means google maps
data.

I see maptype::SatelliteMapDay, but no actual documentation or hints
about how well it actually works (googling for images I didn't find
anything that looked promising)

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

Re: latest Windows binary crashes

[Thiago Macieira]

On segunda-feira, 3 de julho de 2017 14:32:35 PDT Dirk Hohndel wrote:
> Grumble.
> 
> I was told on the Qt list that there is a MUCH newer branch that I should
> try - they have updated to a current WebKit. The thing that's odd... between
> 5.7.1 (which the Windows binaries used to be based on) and 5.9 there
> shouldn't really have been any WebKit changes... so why does it crash now.

There are a number of minor changes submitted to the 5.8 and 5.9 branches by 
people like Konstantin, Allan and me. Mine were mostly just to make it, but 
looking at the diff there appear to be a couple of backports from upstream.

> > i mean i can possibly find the offending line of code, but i won't
> > really have a good fix for it. after seeing that unpredictable Marble
> > multi-threading crash on Windows, i think we are entering the
> > territory of big, complicated but unmaintained libraries that simply
> > may not run with the latest Qt version. Qt 6.0 is coming too...
> 
> I think they are working on 5.10 ...

Qt 6.0 will be discussed at the Contributor Summit this year in Berlin. The 
current idea is that 5.12 will be LTS and then 6.0. That would put 6.0 about 
two years away from now.

> > so we need to:
> > 1) move away from these unmaintained libraries
> > WebKit - currently we are stuck with WebKit on Windows
> > Grantlee - we are stuck with Grantlee due to the template syntax which
> > the users are already using
> > Marble - we probably should start using a 2D map of sorts
> 
> WebKit - I think we are stuck with that for a while
> Marble - Tomaz has this working with the latest, maintained Marble
> Grantee - I have this working on Mac

What happened to the idea of using QtLocation for maps?

> > BTW you can try building this QtWebKit port as it's actively updated:
> > https://github.com/annulen/webkit/releases
> 
> Yes, and that appears to be in the 5.212 branch of Qt that I need to
> find the time to investigate...

5.212 builds with CMake, not qmake anymore. My recommendation is that you 
build it after all the rest of Qt.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

Re: Android BT/BLE with Petrel 2

[Linus Torvalds]

On Tue, Jul 4, 2017 at 6:31 AM, Dirk Hohndel  wrote:
>> 07-04 19:19:20.268  2423  2520 D 
>> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
>> Creating Android Central/Client support for BTLE
>> 07-04 19:19:20.272  2423  2520 D 
>> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
>> qt_ble_open( 00:13:43:0E:6B:D0 )
>> 07-04 19:19:20.394  5484 32204 D BtGatt.GattService: 
>> clientConnect(org.subsurfacedivelog.mobile) - address = 00:13:43:0E:6B:D0, 
>> isDirect=true transport =2 set own addr = false own addr type:0, clientIf: 4
>> 07-04 19:19:20.877  2423  2423 D 
>> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
>> "LocalDeviceBroadcastReceiver::onReceive() - event: 
>> android.bluetooth.device.action.ACL_CONNECTED"
>> 07-04 19:19:20.898  2423  2520 D 
>> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
>> Connection updated: error: QLowEnergyController::Error(NoError) oldState: 
>> QLowEnergyController::ControllerState(ConnectingState) newState: 
>> QLowEnergyController::ControllerState(ConnectedState)
>> 07-04 19:19:21.000  2423  2520 D 
>> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
>> connected to the controller for device 00:13:43:0E:6B:D0
>> 07-04 19:19:21.001  2423  2520 D 
>> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:   .. 
>> discovering services
>> 07-04 19:19:21.006  2423  2520 D 
>> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Service 
>> discovery initiated
>> 07-04 19:19:33.409  2423  2520 D 
>> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:  .. 
>> done discovering services
>> 07-04 19:19:33.409  2423  2520 D 
>> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: failed 
>> to find suitable service on 00:13:43:0E:6B:D0
>> 07-04 19:19:33.420  5484 27635 D BtGatt.GattService: 
>> clientDisconnect(org.subsurfacedivelog.mobile) - address=00:13:43:0E:6B:D0, 
>> connId=4, clientIf: 4
>> 07-04 19:19:33.439  5484 27630 D BtGatt.GattService: 
>> clientDisconnect(org.subsurfacedivelog.mobile) - address=00:13:43:0E:6B:D0, 
>> connId=null, clientIf: 4
>
> That's odd. Not sure if Linus will have a moment to look at this.

It doesn't seem to be discovering any services at all, much less one
that is write/notify. So it gives up.

I have no idea why. Testing with the Nordic nRF app would be good, and
maybe making sure it's bonded there and shows all services..

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

Re: OSTC over BLE experiences and questions

[Matthias Heinrichs]

Am 04.07.2017 um 17:53 schrieb Jan Mulder:

Not sure it is relevant ... dive is made with the OSTC3 in fixed
setpoint CCR mode. Going to look at your code tonight.


Not relevant. After the final 0xFB, 0xFB comes the first depths sample. 
And this is wrong already (Well, at least in your Wireshark log)


One thing that's interesting (And Jef, didn't we had a 
bug/incompatibility with this some months ago?) .cf:46:00 (Which I 
thought is your first sample) is the number of bytes for the profile 
(See header).


The famous, non-documented feature in our profile data which I promised 
to describe in the documentation months ago...


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

Re: OSTC over BLE experiences and questions

[Jan Mulder]

On 04-07-17 17:47, Matthias Heinrichs wrote:

Hi Jan,

Am 04.07.2017 um 15:23 schrieb Jan Mulder:

BT snoop file (made with btmon) is attached. Wireshark is your friend :-)


The funny stuff happens between Packet #365 and #366 (most likely). 
Until then, the header (first 256byte) looks quite perfect (A dive from 
the 2nd July 2017 to 3082mbar max depth, 57min and 26seconds). It's 
properly closed with the 0xFB, 0xFB at the end.


Then the first depth sample: 0xcf:0x46:0x00 -> 18127mbar depth (+0x00 
additional bytes)??!
Second sample is just as wrong: 0x02:0x90:0x03:... -> 36866mbar depth 
(+0x03 additional bytes which are non-sense on their own like a manual 
gas change within the first two seconds PLUS a normal gas change).


I checked my code and I can't see any difference between sending the 
header bytes and the profile bytes. Look for "comm_send_dive1:" in 
https://bitbucket.org/heinrichsweikamp/hwos_code/src/7db10ebae205ebb391cb15fe613a3d8301b87cba/src/comm.asm?at=default=file-view-default 



Hmm...

Regards,
 Matthias




Not sure it is relevant ... dive is made with the OSTC3 in fixed 
setpoint CCR mode. Going to look at your code tonight.


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

Re: OSTC over BLE experiences and questions

[Matthias Heinrichs]

Hi Jan,

Am 04.07.2017 um 15:23 schrieb Jan Mulder:

BT snoop file (made with btmon) is attached. Wireshark is your friend :-)


The funny stuff happens between Packet #365 and #366 (most likely). 
Until then, the header (first 256byte) looks quite perfect (A dive from 
the 2nd July 2017 to 3082mbar max depth, 57min and 26seconds). It's 
properly closed with the 0xFB, 0xFB at the end.


Then the first depth sample: 0xcf:0x46:0x00 -> 18127mbar depth (+0x00 
additional bytes)??!
Second sample is just as wrong: 0x02:0x90:0x03:... -> 36866mbar depth 
(+0x03 additional bytes which are non-sense on their own like a manual 
gas change within the first two seconds PLUS a normal gas change).


I checked my code and I can't see any difference between sending the 
header bytes and the profile bytes. Look for "comm_send_dive1:" in 
https://bitbucket.org/heinrichsweikamp/hwos_code/src/7db10ebae205ebb391cb15fe613a3d8301b87cba/src/comm.asm?at=default=file-view-default 



Hmm...

Regards,
Matthias


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

Re: Android: crash on deleting dives

[Dirk Hohndel]

> On Jul 4, 2017, at 12:18 AM, Rick Walsh  wrote:
> 
> Hi,
> 
> Testing the latest daily Subsurface-mobile Android build, 4.6.4.333, I get a 
> crash sometimes when deleting a dive.  It may be a coincidence, but it only 
> appears to crash when deleting a dive that is not the most recent.  Below is 
> the output from 'adb logcat | grep -i subsurface', where I opened 
> Subsurface-mobile and successfully deleted some dives, before crashing on the 
> fourth or fifth.  I first noticed this problem a week or so ago, so this does 
> not appear to be caused by one of the most recent changes.

We've seen this on and off and if I was able to reproduce it reliably I'd love 
to fix it... really.

I just spent about ten minutes on my phone with test data, randomly deleting 
dives, undo-ing the deletes, doing more deletes. Can't make it crash.

Quick question: do you use the delete on the action button in the dive details 
view, or do you use the tap-and-hold delete from the dive list?

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

Re: Android BT/BLE with Petrel 2

[Dirk Hohndel]

> On Jul 4, 2017, at 6:44 AM, Jan Mulder  wrote:
> 
> On 04-07-17 15:31, Dirk Hohndel wrote:
>>> On Jul 4, 2017, at 12:29 AM, Rick Walsh  wrote:
>>> 
>>> Hi,
>>> 
>>> I tried to download dives from my Shearwater Petrel 2 to my phone (Samsung 
>>> Galaxy S7) with the latest daily Android build, 4.6.4.333-arm.  With 
>>> previous builds, download was working correctly with standard Bluetooth.  
>>> Now Subsurface-mobile is now trying to connect using BLE, but failing to 
>>> connect.  The dive computer screen continues with the waiting for PC 
>>> countdown the entire time.
>>> 
>>> I tried first by selecting Vendor: Paired Bluetooth, DC: Petrel 
>>> (LE:00:13)
>>> 
> 
> 
> More in general, I have seen weird things related to BT/BLE switching. For 
> example, my OSTC3 paired as a type 1 (classic), type 2 (ble only), and type 3 
> (bt and ble). This all just on OS (Android) level. Re-pairing solved it most 
> of the time (as it is definitely a type 3).
> 
> @Rick, in the app log, there is in de beginning some debug data printed about 
> found paired devices. If that reports a wrong type, things will get confusing.

I just realized that in his crash report for deleting dives, Rick included the 
very beginning with the pairing information:

07-04 19:03:24.687   306   333 D 
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
"localDevice Samsung Galaxy S7 is valid, starting discovery"
07-04 19:03:24.698   306   333 D 
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: paired 
Device type 2 with address "LE:00:13:43:0E:6B:D0"
07-04 19:03:24.704   306   333 D 
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: paired 
Device type 1 with address "00:19:0E:16:D6:FE"
07-04 19:03:24.710   306   333 D 
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: paired 
Device type 1 with address "44:85:00:1D:12:6B"
07-04 19:03:24.710   306   333 D 
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Found new 
device: "Petrel" "LE:00:13:43:0E:6B:D0"
07-04 19:03:24.710   306   333 D 
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: "this 
could be a Shearwater Petrel"
07-04 19:03:24.710   306   333 D 
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: adding new 
btDCs entry (detected DC) "Petrel" 2 1 "LE:00:13:43:0E:6B:D0"

The Petrel is found as a type 2 (BLE only) device, not as type 3 (dual stack) 
device. That's why we only try to connect via BLE and only offer it once in the 
drop down.

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

Re: Android BT/BLE with Petrel 2

[Dirk Hohndel]

> On Jul 4, 2017, at 6:44 AM, Jan Mulder  wrote:
> 
> On 04-07-17 15:31, Dirk Hohndel wrote:
>>> On Jul 4, 2017, at 12:29 AM, Rick Walsh  wrote:
>>> 
>>> Hi,
>>> 
>>> I tried to download dives from my Shearwater Petrel 2 to my phone (Samsung 
>>> Galaxy S7) with the latest daily Android build, 4.6.4.333-arm.  With 
>>> previous builds, download was working correctly with standard Bluetooth.  
>>> Now Subsurface-mobile is now trying to connect using BLE, but failing to 
>>> connect.  The dive computer screen continues with the waiting for PC 
>>> countdown the entire time.
>>> 
>>> I tried first by selecting Vendor: Paired Bluetooth, DC: Petrel 
>>> (LE:00:13)
>>> 
> 
> 
> More in general, I have seen weird things related to BT/BLE switching. For 
> example, my OSTC3 paired as a type 1 (classic), type 2 (ble only), and type 3 
> (bt and ble). This all just on OS (Android) level. Re-pairing solved it most 
> of the time (as it is definitely a type 3).
> 
> @Rick, in the app log, there is in de beginning some debug data printed about 
> found paired devices. If that reports a wrong type, things will get confusing.

Unfortunately my one dual mode device seems to be broken, so this has become 
harder to test.

But yes, Android seems to do odd things when it comes to pairing / bonding to 
BT/BLE devices. I tend to use the Nordic nRF Connect app to get a better sense 
as to whether things are the way they should be before starting 
Subsurface-mobile

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

Re: Android BT/BLE with Petrel 2

[Jan Mulder]

On 04-07-17 15:31, Dirk Hohndel wrote:



On Jul 4, 2017, at 12:29 AM, Rick Walsh  wrote:

Hi,

I tried to download dives from my Shearwater Petrel 2 to my phone (Samsung 
Galaxy S7) with the latest daily Android build, 4.6.4.333-arm.  With previous 
builds, download was working correctly with standard Bluetooth.  Now 
Subsurface-mobile is now trying to connect using BLE, but failing to connect.  
The dive computer screen continues with the waiting for PC countdown the entire 
time.

I tried first by selecting Vendor: Paired Bluetooth, DC: Petrel (LE:00:13)




More in general, I have seen weird things related to BT/BLE switching. 
For example, my OSTC3 paired as a type 1 (classic), type 2 (ble only), 
and type 3 (bt and ble). This all just on OS (Android) level. Re-pairing 
solved it most of the time (as it is definitely a type 3).


@Rick, in the app log, there is in de beginning some debug data printed 
about found paired devices. If that reports a wrong type, things will 
get confusing.


--jan

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

Re: Android BT/BLE with Petrel 2

[Dirk Hohndel]

> On Jul 4, 2017, at 12:29 AM, Rick Walsh  wrote:
> 
> Hi,
> 
> I tried to download dives from my Shearwater Petrel 2 to my phone (Samsung 
> Galaxy S7) with the latest daily Android build, 4.6.4.333-arm.  With previous 
> builds, download was working correctly with standard Bluetooth.  Now 
> Subsurface-mobile is now trying to connect using BLE, but failing to connect. 
>  The dive computer screen continues with the waiting for PC countdown the 
> entire time.
> 
> I tried first by selecting Vendor: Paired Bluetooth, DC: Petrel (LE:00:13)
> 
> 07-04 19:18:50.429  2423  2458 D libGLESv2: STS_GLApi : DTS is not allowed 
> for Package : org.subsurfacedivelog.mobile
> 07-04 19:18:50.526  2423  2451 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Using 
> the following font: Roboto
> 07-04 19:18:50.528  2423  2451 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
> qrc:/templates/ApplicationHeader.qml:123: TypeError: Cannot read property of 
> null
> 07-04 19:18:50.542  4980  5777 V WindowManager: Relayout Window{f2e9452d0 u0 
> org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity}: 
> viewVisibility=0 req=1080x1920 WM.LayoutParams{(0,0)(fillxfill) sim=#10 ty=1 
> fl=#81810100 fmt=-3 wanim=0x10303ea vsysui=0x600 needsMenuKey=2 
> naviIconColor=0}
> 07-04 19:18:50.912  2423  2451 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: qqwindow 
> devicePixelRatio 3 3
> 07-04 19:18:50.912  2423  2451 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: qqwindow 
> screen has ldpi/pdpi 72 144.501
> 07-04 19:18:51.122  2423  2451 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: "1.745: 
> Credential scrn: hide kbd was: invisible"
> 07-04 19:18:54.844  4980  7703 D GameManagerService: identifyGamePackage. 
> org.subsurfacedivelog.mobile
> 07-04 19:19:10.578  2423  2451 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Both 
> point size and pixel size set. Using pixel size.
> 07-04 19:19:10.582  2423  2451 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Both 
> point size and pixel size set. Using pixel size.
> 07-04 19:19:15.652  2423  2451 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
> getDetectedProductIndex 1
> 07-04 19:19:17.431  2423  2451 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
> getDetectedProductIndex 0
> 07-04 19:19:20.255  2423  2451 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: matched 
> "LE:00:13:43:0E:6B:D0"
> 07-04 19:19:20.255  2423  2451 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: "30.878: 
> DCDownloadThread started for LE:00:13:43:0E:6B:D0"

For dual mode dive computers we now add both LE and classic BT versions. This 
clearly will trigger an LE download.

> 07-04 19:19:20.257  2423  2520 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Starting 
> download from  BT
> 07-04 19:19:20.257  2423  2520 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Starting 
> the thread 0
> 07-04 19:19:20.268  2423  2520 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Creating 
> Android Central/Client support for BTLE
> 07-04 19:19:20.272  2423  2520 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
> qt_ble_open( 00:13:43:0E:6B:D0 )
> 07-04 19:19:20.394  5484 32204 D BtGatt.GattService: 
> clientConnect(org.subsurfacedivelog.mobile) - address = 00:13:43:0E:6B:D0, 
> isDirect=true transport =2 set own addr = false own addr type:0, clientIf: 4
> 07-04 19:19:20.877  2423  2423 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
> "LocalDeviceBroadcastReceiver::onReceive() - event: 
> android.bluetooth.device.action.ACL_CONNECTED"
> 07-04 19:19:20.898  2423  2520 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
> Connection updated: error: QLowEnergyController::Error(NoError) oldState: 
> QLowEnergyController::ControllerState(ConnectingState) newState: 
> QLowEnergyController::ControllerState(ConnectedState)
> 07-04 19:19:21.000  2423  2520 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: 
> connected to the controller for device 00:13:43:0E:6B:D0
> 07-04 19:19:21.001  2423  2520 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:   .. 
> discovering services
> 07-04 19:19:21.006  2423  2520 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Service 
> discovery initiated
> 07-04 19:19:33.409  2423  2520 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:  .. done 
> discovering services
> 07-04 19:19:33.409  2423  2520 D 
> /data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: failed 
> to find suitable service on 

Re: OSTC over BLE experiences and questions

[Jan Mulder]

Hi Matthias,

On 04-07-17 15:09, Matthias Heinrichs wrote:

Do you get the ending 0x4D Byte as the last byte? Then it's possible 
that the dive isn't stored correctly ("Internal pointer to the begin of 
the profile data" and "Internal pointer to the end of the profile data" 
are not correct). The OSTC uses the Bluetooth modules hardware handshake 
lines to avoid overfilling the internal buffer but that does not skip 
any bytes. I can't see a way that the OSTC just stops sending data 
without being stuck completely (Timeout can only happen in the Bluetooth 
idle loop) afterwards.


Please email me the raw data and I'll have a look here.



BT snoop file (made with btmon) is attached. Wireshark is your friend :-)

And no, the last byte is not the end 0x4D byte. I did not check the 
internal pointers, but I did check the length of the profile data and 
that looks a correct value for this dive (if I remember correctly, 
almost 19000 bytes).


In addition, I interfaced this same dive correctly over classic BT, and 
on the OSTC3 itself it shows correctly, so the internal loglook seems 
just fine.


And also from me a huge thanks for the support you and the company are 
giving to Subsurface.


regards,

--jan

btsnoop
Ñ%%ÿÿâ1.—XšLinux version 4.11.7-1-ARCH (x86_64)!!ÿÿâ1.—XBluetooth subsystem version 2.22â1.—Xž
qÚ}hci0â1.—X 
â1.—X¡qÚ}
â1.—X¢DownloadThreadÿÿâ1.—X£


bluetoothdÿÿâ1.—Xµ

btmonÿÿâ1.˜ØšèDownloadThreadÿÿâ1.˜Øšóâ1.˜ØšôDownloadThread

â1.˜Ø©ô `0
â1.˜Ø±«
 â1.˜Ø±à 

â1.˜Ø¹ª
 â1.˜ßXø>
ÃJ%€
ÿ	°
Äâ1.˜ßY= â1.˜ßlw
 â1.˜ßlÅ
 ``ÃJ%€ Xâ1.˜ß‹¸

 â1.˜ó#5>
GÃJ%€ Xâ1.˜ó#­ÃJ%€

ÿ	°
â1.˜ó#­
ÃJ%€

ÿ	°
â1.˜ó#õ Gâ1.˜ó:z â1.˜ó]šG  Xâ1.˜÷
â1.˜øC°>G
â1.˜øDÃJ%€

 Xâ1.˜øD
ÃJ%€

 Xâ1.˜øDG
â1.˜øD G Xâ1.˜øO.
 â1.˜øhÏGâ1.˜øãÑ
G
â1.˜øç‹
G
â1.˜ùxFG â1.˜ù‚G
ÿÿ(â1.˜úl
G
â1.˜úÌ G 

	
â1.˜úåÎG
ÿÿ(â1.˜ûPê
G
â1.˜ûéGG 
ûþâ1.˜ûüÛG
(â1.˜ü…€>
G Xâ1.˜ü‰8
G


â1.˜ý!ÀG 	


â1.˜ý:eGÿÿ(â1.˜ýÁå
G
â1.˜þZ>G ÿÿ0001VRESOIRETMTSâ1.˜þx¹G
(â1.˜þúd
G
â1.˜ÿ®G 	%€€
â1.˜ÿ¶?G
ÿÿ
(â1.™2â
G


â1.™Ë:G 	


â1.™Ì‚G(â1.™
k6
G
â1.™¼G 	%€€â1.™	×G(â1.™£Þ
G
â1.™<;G 	%€€â1.™G“G(â1.™Ü_
G
â1.™t¶G 	 %€€â1.™…UG(â1.™Û
G


â1.™­6G 	



â1.™Ä+G	
â1.™h°
G
â1.™å°G 

(

â1.™rG	
â1.™… 
G
â1.™2G %€€


â1.™@ÉG	

â1.™¾U
G
â1.™	V­G 


)

â1.™	YG	â1.™	ö¥
G
â1.™
)G 

(

â1.™
•°G	â1.™/R
G
â1.™Ç­G %€€

â1.™ÓMG	â1.™ƒ'
G
â1.™
(G 

)

â1.™
¸G	â1.™
 L
G
â1.™8¨G 

(

â1.™OG	â1.™ØË
G
â1.™q!G %€€

â1.™LG	â1.™H
G
â1.™©¥G 

)

â1.™Ë¢G	

Re: OSTC over BLE experiences and questions

[Matthias Heinrichs]

Hi Jan,

Am 04.07.2017 um 14:02 schrieb Jan Mulder:
So, far so good. All this data is correctly received and processed on 
the Subsurface/libdc side.

- 0x66: send one dive including profile, for index 0x86
This results in correct reception of the header (256 bytes), followed by 
some samples (in total 624 bytes) so a very small fraction of the 
selected approx 1 hour dive, that results in approx 20kb).
And then is just stops, until a timeout is hit. No bluez errors (testing 
this on Arch Linux, with bluez BT stack), no weird packets in the 
snooped BT traffic (file available for analysis if needed), noting 
relevant in the journal/systemd logging, no kernel messages).


So it seems that the OSTC3 just stops sending. So my question for 
Matthias ... any idea what is going on here?


Do you get the ending 0x4D Byte as the last byte? Then it's possible 
that the dive isn't stored correctly ("Internal pointer to the begin of 
the profile data" and "Internal pointer to the end of the profile data" 
are not correct). The OSTC uses the Bluetooth modules hardware handshake 
lines to avoid overfilling the internal buffer but that does not skip 
any bytes. I can't see a way that the OSTC just stops sending data 
without being stuck completely (Timeout can only happen in the Bluetooth 
idle loop) afterwards.


Please email me the raw data and I'll have a look here.

Regards,
Matthias


--
heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany

Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau
Geschäftsführer: Matthias Heinrichs, Christian Weikamp
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

OSTC over BLE experiences and questions

[Jan Mulder]

I have been trying to implement the connection over BLE to an OSTC 
device (in my case an OSTC3 with the Telit/Stollmann BT/BLE hardware). 
From the current status, I constructed a pull request for Subsurface 
(https://github.com/Subsurface-divelog/subsurface/pull/466).


Basically, I'm stuck at the current point. The download over BLE works 
perfect for a short period, in which the following sequence of commands 
are issued:


- 0xBB: init the OSTC3 in Download mode

- 0x60: hardware and Features

- 0x69: version/identity

- 0x6D: send compact headers (4Kb data)

So, far so good. All this data is correctly received and processed on 
the Subsurface/libdc side.



- 0x66: send one dive including profile, for index 0x86


This results in correct reception of the header (256 bytes), followed by 
some samples (in total 624 bytes) so a very small fraction of the 
selected approx 1 hour dive, that results in approx 20kb).



And then is just stops, until a timeout is hit. No bluez errors (testing 
this on Arch Linux, with bluez BT stack), no weird packets in the 
snooped BT traffic (file available for analysis if needed), noting 
relevant in the journal/systemd logging, no kernel messages).


So it seems that the OSTC3 just stops sending. So my question for 
Matthias ... any idea what is going on here?



regards,


--jan

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

Re: French translation

[Guillaume Gardet]

Hello Philippe,

For the french documentation, the complete flow is the following:
1) download the latest version of the GIT repo
2) go to Documentation/ folder
3) run ./make_POT.sh script
4) run ./make_PO_to_ASCIIDOC.sh
5) Translate the PO files (fr/po/subsurface-mobile-manual.fr.po and/or   
fr/po/subsurface-user-manual.fr.po)
6) Run ./make_PO_to_ASCIIDOC.sh to generate the translated  *.txt files
7) Generate HTML files with : "make user-manual_fr.html" and "make 
mobile-manual_fr.html"
8) Send a patch to add the new translations

I just sent a patch to merge and update the french translations. So, please 
wait that this patch is merged before starting your work. Thanks for your help! 
:)


Guillaume



Le 04/07/2017 à 09:26, Philippe Massart a écrit :

Hello all,

I plan to take some time this summer to work on the French documentation.

But unlike other language, it seems there are 2 « workable » files: a .txt 
file, and a .po (to use with QtLinguist, I guess). Which one is the best to 
work on?

Philippe
___
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

Re: Images needed: Subsurface-mobile user manual

[Werner Macho]

I can do a screenshot downloading from a OSTC sport with BT today evening
if nobody else is faster ;)

regards
Werner

On Tue, Jul 4, 2017 at 10:53 AM, Willem Ferguson <
willemfergu...@zoology.up.ac.za> wrote:

> I am updating the user manual. I need someone to send me an Android
> download screen using a FTDI USB dive computer. I also need a download
> screen using a BT dive computer. Help, please?
>
> Kind regards,
>
> willem
>
>
> ___
> 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

Images needed: Subsurface-mobile user manual

[Willem Ferguson]

I am updating the user manual. I need someone to send me an Android
download screen using a FTDI USB dive computer. I also need a download
screen using a BT dive computer. Help, please?

Kind regards,

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

Android BT/BLE with Petrel 2

[Rick Walsh]

Hi,

I tried to download dives from my Shearwater Petrel 2 to my phone (Samsung
Galaxy S7) with the latest daily Android build, 4.6.4.333-arm.  With
previous builds, download was working correctly with standard Bluetooth.
Now Subsurface-mobile is now trying to connect using BLE, but failing to
connect.  The dive computer screen continues with the waiting for PC
countdown the entire time.

I tried first by selecting Vendor: Paired Bluetooth, DC: Petrel
(LE:00:13)

07-04 19:18:50.429  2423  2458 D libGLESv2: STS_GLApi : DTS is not allowed
for Package : org.subsurfacedivelog.mobile
07-04 19:18:50.526  2423  2451 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Using
the following font: Roboto
07-04 19:18:50.528  2423  2451 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
qrc:/templates/ApplicationHeader.qml:123: TypeError: Cannot read property
of null
07-04 19:18:50.542  4980  5777 V WindowManager: Relayout Window{f2e9452d0
u0
org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity}:
viewVisibility=0 req=1080x1920 WM.LayoutParams{(0,0)(fillxfill) sim=#10
ty=1 fl=#81810100 fmt=-3 wanim=0x10303ea vsysui=0x600 needsMenuKey=2
naviIconColor=0}
07-04 19:18:50.912  2423  2451 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
qqwindow devicePixelRatio 3 3
07-04 19:18:50.912  2423  2451 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
qqwindow screen has ldpi/pdpi 72 144.501
07-04 19:18:51.122  2423  2451 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
"1.745: Credential scrn: hide kbd was: invisible"
07-04 19:18:54.844  4980  7703 D GameManagerService: identifyGamePackage.
org.subsurfacedivelog.mobile
07-04 19:19:10.578  2423  2451 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Both
point size and pixel size set. Using pixel size.
07-04 19:19:10.582  2423  2451 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: Both
point size and pixel size set. Using pixel size.
07-04 19:19:15.652  2423  2451 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
getDetectedProductIndex 1
07-04 19:19:17.431  2423  2451 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
getDetectedProductIndex 0
07-04 19:19:20.255  2423  2451 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
matched "LE:00:13:43:0E:6B:D0"
07-04 19:19:20.255  2423  2451 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
"30.878: DCDownloadThread started for LE:00:13:43:0E:6B:D0"
07-04 19:19:20.257  2423  2520 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
Starting download from  BT
07-04 19:19:20.257  2423  2520 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
Starting the thread 0
07-04 19:19:20.268  2423  2520 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
Creating Android Central/Client support for BTLE
07-04 19:19:20.272  2423  2520 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
qt_ble_open( 00:13:43:0E:6B:D0 )
07-04 19:19:20.394  5484 32204 D BtGatt.GattService:
clientConnect(org.subsurfacedivelog.mobile) - address = 00:13:43:0E:6B:D0,
isDirect=true transport =2 set own addr = false own addr type:0, clientIf: 4
07-04 19:19:20.877  2423  2423 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
"LocalDeviceBroadcastReceiver::onReceive() - event:
android.bluetooth.device.action.ACL_CONNECTED"
07-04 19:19:20.898  2423  2520 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
Connection updated: error: QLowEnergyController::Error(NoError) oldState:
QLowEnergyController::ControllerState(ConnectingState) newState:
QLowEnergyController::ControllerState(ConnectedState)
07-04 19:19:21.000  2423  2520 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
connected to the controller for device 00:13:43:0E:6B:D0
07-04 19:19:21.001  2423  2520 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:   ..
discovering services
07-04 19:19:21.006  2423  2520 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:
Service discovery initiated
07-04 19:19:33.409  2423  2520 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO:  ..
done discovering services
07-04 19:19:33.409  2423  2520 D
/data/newandroid/subsurface/qt-models/messagehandlermodel.cpp: INFO: failed
to find suitable service on 00:13:43:0E:6B:D0
07-04 19:19:33.420  5484 27635 D BtGatt.GattService:
clientDisconnect(org.subsurfacedivelog.mobile) - address=00:13:43:0E:6B:D0,
connId=4, clientIf: 4
07-04 19:19:33.439  5484 27630 D BtGatt.GattService:
clientDisconnect(org.subsurfacedivelog.mobile) - address=00:13:43:0E:6B:D0,
connId=null, clientIf: 4
07-04 19:19:33.448  2423  2520 D
/data/newandroid/subsurface/core/libdivecomputer.c: INFO: dc_deveice_open
error value of -6
07-04 

French translation

[Philippe Massart]

Hello all,

I plan to take some time this summer to work on the French documentation.

But unlike other language, it seems there are 2 « workable » files: a .txt 
file, and a .po (to use with QtLinguist, I guess). Which one is the best to 
work on? 

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

Android: crash on deleting dives

[Rick Walsh]

Hi,

Testing the latest daily Subsurface-mobile Android build, 4.6.4.333, I get
a crash sometimes when deleting a dive.  It may be a coincidence, but it
only appears to crash when deleting a dive that is not the most recent.
Below is the output from 'adb logcat | grep -i subsurface', where I opened
Subsurface-mobile and successfully deleted some dives, before crashing on
the fourth or fifth.  I first noticed this problem a week or so ago, so
this does not appear to be caused by one of the most recent changes.

07-04 19:03:23.319  4980  5777 I ActivityManager: START u0
{act=android.intent.action.MAIN typ=null flg=0x1020
cmp=ComponentInfo{org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity}}
from uid 10064 on display 0
07-04 19:03:23.327  4980  5777 D ActivityManager: computeStackFocus: New
stack r=ActivityRecord{99aa06ed0 u0
org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity
t-1} stackId=1
07-04 19:03:23.327  4980  5777 I MultiWindowManagerService:
setTaskDimensions: Task=TaskRecord{5d4557ad0 #4314
A=org.subsurfacedivelog.mobile U=0 StackId=1 sz=1} minWidth=-1 minHeight=-1
maxWidth=-1 maxHeight=-1
07-04 19:03:23.328  4980  5777 D ActivityManager: moveToFront() :
reason=startedActivity setFocusedActivity isAttached=true
TaskRecord{5d4557ad0 #4314 A=org.subsurfacedivelog.mobile U=0 StackId=1
sz=1}
07-04 19:03:23.329  4980  5777 D ActivityManager:
resumeTopActivityInnerLocked() : #1 prevTask=TaskRecord{5d4557ad0 #4314
A=org.subsurfacedivelog.mobile U=0 StackId=1 sz=1}
next=ActivityRecord{99aa06ed0 u0
org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity
t4314} mFocusedStack=ActivityStack{885a8c1d0 stackId=1, 22 tasks}
07-04 19:03:23.337  4980  5073 D ActivityManager:
resumeTopActivityInnerLocked() : #1 prevTask=TaskRecord{edc3b6cd0 #4204
A=com.sec.android.app.launcher U=0 StackId=0 sz=1}
next=ActivityRecord{99aa06ed0 u0
org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity
t4314} mFocusedStack=ActivityStack{885a8c1d0 stackId=1, 22 tasks}
07-04 19:03:23.338  4980  5073 D MountService: getExternalStorageMountMode
: final mountMode=3, uid : 10233, packageName : org.subsurfacedivelog.mobile
07-04 19:03:23.352  4980  5073 I ActivityManager: Start proc
306:org.subsurfacedivelog.mobile/u0a233 for activity
org.subsurfacedivelog.mobile/org.qtproject.qt5.android.bindings.QtActivity
07-04 19:03:23.357   306   306 I SELinux : SELinux: seapp_context_lookup:
seinfo=untrusted, level=s0:c512,c768, pkgname=org.subsurfacedivelog.mobile
07-04 19:03:23.378  4980  5778 I ActivityManager: DSS on for
org.subsurfacedivelog.mobile and scale is 1.0
07-04 19:03:23.379  4980  5116 V WindowManager: Relayout Window{9aaa159d0
u0 Starting org.subsurfacedivelog.mobile}: viewVisibility=0 req=1080x1848
WM.LayoutParams{(0,0)(fillxfill) sim=#20 ty=3 fl=#1830118 pfl=0x11 fmt=-3
wanim=0x103038a needsMenuKey=2 naviIconColor=0}
07-04 19:03:23.401  4980  4980 D GameManagerService: NotifyRunnable. pkg:
org.subsurfacedivelog.mobile, type: 4, isMinimized: false, isTunableApp:
false
07-04 19:03:23.405  4980  7703 D GameManagerService: identifyGamePackage.
org.subsurfacedivelog.mobile
07-04 19:03:23.407  4980  5116 D WindowManager: finishDrawingWindow:
Window{9aaa159d0 u0 Starting org.subsurfacedivelog.mobile}
mDrawState=DRAW_PENDING
07-04 19:03:23.407  4980  7703 D GameManagerService: identifyGamePackage.
org.subsurfacedivelog.mobile
07-04 19:03:23.412  4980  5116 D WindowManager: finishDrawingWindow:
Window{9aaa159d0 u0 Starting org.subsurfacedivelog.mobile}
mDrawState=HAS_DRAWN
07-04 19:03:23.417  4980  7703 D GameManagerService: identifyGamePackage.
org.subsurfacedivelog.mobile
07-04 19:03:23.417  4980  7703 D GameManagerService: identifyGamePackage.
org.subsurfacedivelog.mobile
07-04 19:03:23.534  4980  5406 D MdnieScenarioControlService:  packageName
: org.subsurfacedivelog.mobileclassName :
org.qtproject.qt5.android.bindings.QtActivity
07-04 19:03:23.536   306   306 W linker  :
/data/app/org.subsurfacedivelog.mobile-1/lib/arm/libQt5Concurrent.so:
unsupported flags DT_FLAGS_1=0x81
07-04 19:03:23.539   306   306 W linker  :
/data/app/org.subsurfacedivelog.mobile-1/lib/arm/libQt5Gui.so: unsupported
flags DT_FLAGS_1=0x81
07-04 19:03:23.549   306   306 W linker  :
/data/app/org.subsurfacedivelog.mobile-1/lib/arm/libQt5Widgets.so:
unsupported flags DT_FLAGS_1=0x81
07-04 19:03:23.563   306   306 W linker  :
/data/app/org.subsurfacedivelog.mobile-1/lib/arm/libQt5Svg.so: unsupported
flags DT_FLAGS_1=0x81
07-04 19:03:23.566   306   306 W linker  :
/data/app/org.subsurfacedivelog.mobile-1/lib/arm/libQt5Positioning.so:
unsupported flags DT_FLAGS_1=0x81
07-04 19:03:23.569   306   306 W linker  :
/data/app/org.subsurfacedivelog.mobile-1/lib/arm/libQt5Network.so:
unsupported flags DT_FLAGS_1=0x81
07-04 19:03:23.574   306   306 W linker  :
/data/app/org.subsurfacedivelog.mobile-1/lib/arm/libQt5Qml.so: unsupported
flags DT_FLAGS_1=0x81
07-04 19:03:23.588   306   306 W