new Subsurface-mobile for iOS in TestFlight with experimental Mares BlueLink Pro support

[Dirk Hohndel]

So this is experimental in a few ways:

a) I think I have figured out how to get iOS to allow the user access to the 
subsurface.log file

This is still a little fragile in my experimentation, but it seems to work 
reasonably well, at least with iOS 11.
Basically we tell iOS that we are making a document available for sharing. In 
older iOS version this apparently then requires some tricks with iTunes, but in 
iOS 11 you can now see a "Subsurface-mobile" folder in the Files app (or when 
attaching things to an email message) and you'll see a subsurface.log file in 
that folder. The trick is to do the things that you want to see the log for in 
Subsurface-mobile, then wait a little until the file size of the log file is 
several kB (initially in my tests it would show a few hundred bytes if you 
accessed it too soon). You can then open that file (actually rather hard to get 
it to open as text) or simply attach it to an email. This will contain the log 
data that we are interested in for the next step.

b) I have enabled the three Mares dive computers that support the BlueLink Pro 
(Puck Pro, Smart, Quad) on iOS - so these are now a valid option for dive 
computer downloads

c) I didn't know how those dive computers identify themselves to the BLE 
stack... so on iOS I recommend starting Subsurface-mobile, opening the AppLog 
(under Developer - you may have to enable Developer mode in Settings), finding 
your dive computer in the scan list, memorize the UUID (ok, a few characters of 
the UUID) and then in the download from dive computer screen pick that UUID 
(and Mares and your dive computer)

Now there is a small chance that it Just Works™ - and that's great. But even if 
it doesn't work, hopefully the data that we log in the subsurface.log file will 
help us figure out what was going on. So in either case, please send us that 
file.

I know - this is quite painful. But I'm hoping that this will help us get 
/real/ support for those three Mares dive computers over BLE...

Thanks

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

Re: Mares Quad with BLE Interface

[Jef Driesen]

On 2018-04-12 20:57, Linus Torvalds wrote:
On Thu, Apr 12, 2018 at 10:52 AM, Allen Hall  
wrote:
BLE communications log is attached.  I may be able to tease out more 
verbose

info if needed, but this looks pretty complete to me.


This looks like it does contain all the information. I won't have time
to look at it until next week, but maybe Jef will.

The one question I have, is what the iOS encoding is for the data. The
logs show the actual data transfers as strings like this:

   "value":"BQAdAGgfAwBIAO8="

and I'm *guessing* that is just a base64 encoding, but it would be
good to validate in case somebody knows the iphone logging model..

If it's base64-encoded, then it decodes to 20 bytes :

   000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
   020 00 00 00 ef

and this all should be possible to figure out.

In fact, I wrote a really stupid script to turn that into something
slightly more legible:

zcat < mares_bluelink_pro_ble.log.gz |
grep '"value"' |
sed 's/^.*{/{/' |
while IFS=, read a b c d e f g h
do
val=$(echo "$d" | sed 's/"value"://' | tr -d '"')
echo "$c $e:"
echo $val | base64 -d | od -t x1
done | less -S

and it superficially looks like it's the standard Mares Icon HD
protocol to me. I see one-byte 'aa' responses (which is just the ACK
character). And I see sequences like this:

"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" 
"status":"written":

000 e7 42
002
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 aa
001
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" 
"status":"written":

000 78 ad 00 00 04 00 00 00
010
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 78 13 00 00 ea
005
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" 
"status":"written":

000 e7 42
002
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 aa
001
"characteristic":"99A91EBD-B21F-1689-BB43-681F1F55E966" 
"status":"written":

000 1c ad 00 00 5c 00 00 00
010
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 f0 00 a3 01 79 00 02 00 14 00 0e 00 00 00 74 00
020 40 95 00 00
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 1e 00 78 05 20 80 78 05 32 80 78
013
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 05 00 00 00 00 1d 00 68 1f 03 00 48 00 00 00 00
020 00 00 00 ef
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef 18 ef
020 18 ef 18 f7
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 00 0d 01 cc 00 fa 00 00 00 00 00 00 00 00 00 00
020 00 00 00 00
024
"characteristic":"1D1AAE28-D2A8-91A1-1242-9D2973FBE571"
"status":"subscribedResult":
000 00 ea
002

where that "e7 42" is "device read", it gets "aa" back, then we send
eight bytes of data (address and length, little-endian 4-byte each),
then we get the data followed by "ea".

(The "status":"written" is the phone sending, the
"status":"subscribedResult" is the dive computer answering).

That all looks exactly like the Icon HD serial protocol.

Jef, any additional comments?

Anyway, I suspect it all might just automatically work if we just add
the Mares to the list of bluetooth targets. The BLE GATT layout looks
like the normal "hacky serial over GATT" and might even match what we
already try to do.


I haven't looked at the logfile in detail, but based on your description 
it looks indeed like the standard iconhd protocol. That's also what I 
expected: same protocol but send over BLE instead of usb-serial.


The base64 encoding is probably done by the iOS logger. I see absolutely 
no reason to use base64 encoding over ble. It's perfectly possible to 
send binary data over ble, and the large base64 overhead (about 33%) 
would only make the relative slow ble even slower.


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

Re: Mares Quad with BLE Interface

[Courtney Hall]

I’m happy to do any testing if someone sends me a patch.  I can build on MacOS.

> On Apr 13, 2018, at 01:08, Dirk Hohndel  wrote:
> 
> I have a dead Puck.
> But maybe we can find a Puck Pro somewhere. Let's see.
> 
> /D
> 
>> On April 12, 2018 12:15:23 PM PDT, Linus Torvalds 
>>  wrote:
>> On Thu, Apr 12, 2018 at 11:57 AM, Linus Torvalds
>>  wrote:
>>> 
>>> That all looks exactly like the Icon HD serial protocol.
>> 
>> Oh, I didn't realize, this, but the dive computer itself doesn't do
>> bluetooth, the whole "Bluelink Pro" is just the dongle that replaces
>> the cable, and does bluetooth.
>> 
>> So yes, it's almost certainly just the exact same serial protocol,
>> just encapsulated over BLE GATT.
>> 
>> Dirk - you had a Mares Puck, didn't you? Was it the "Puck Pro"?
>> Because then we could test this by just buying that "Bluelink Pro"
>> thing which seems to sell for $49.95.
>> 
>> Then we could test the thing.
>> 
>> Linus
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
> 
> -- 
> from my phone.
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Bluetooth fails on mobile

[Davide DB]

Just for info, this is the Nexus 7 first gen. log of the happy day
scenario (download aborted and partially downloaded dives successfully
saved)


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

Re: Bluetooth fails on mobile

[Davide DB]

On 12 April 2018 at 17:07, Davide DB  wrote:
> On 12 April 2018 at 17:01, Dirk Hohndel  wrote:
>>
>> Oops. On the first version Nexus 7? That should be impossible.
>> I own several first version Nexus 7 and they didn't support BLE, I'm
>> quite certain about that.
>> https://en.wikipedia.org/wiki/Nexus_7_(2012)
>> https://en.wikipedia.org/wiki/Nexus_7_(2013)
>> You will see that the 2012 version only support BT 3.0, it's the 2013
>> version that adds BT 4.0 (and therefore BLE).
>
> I will try again this evening (CET) at home.
> IIRC On the Nexus 5x once paired on the bluetooth info I see LE:address
> On the Nexus 7 once paired I see only the address (the same as the
> other phone) so I selected that address form Subsurface download drop
> down.
> This evening I will try to install a screen recorder on that ancient
> tablet so i will post a video.
>
>> I start the download
>> Subsurface start counting downloaded dives...
>> On Petrel I see SENDING PACKET messages
>> At some point on my Petrel I get ERROR SENDING PACKET and the Petrel UI
>> quits.
>>
>>
>> OK so far.
>>
>> On Subsurface mobile the UI is stuck on something like downloading
>> dive #[dive number]
>> The UI loops indefinitely with this message. Whatever I do when I go
>> back on the download from dive computer screen its' always in the
>> download state. Buttons don't work.
>>
>>
>> It should time out.
>> Can you try this? After you've seen about 5 dives downloaded (why is it
>> re-downloading dives you already have? you said only 3 were missing)
>> please tap the Cancel button on the UI. That should cancel the BT download
>> and show you the partial download which you can then save.
>>
>> Looking to the app logs via developer's options I see something like
>> this: (English translation between parenthesis are mine)
>>
>>
>> "143.271: dive #18 dom 24 set 2017 11:29"
>> "LocalDeviceBroadcastReceiver::onReceive() - event:
>> andorid.bluetooth.device.action.ACL_DISCONNECTED"
>> QMutex: destroying locked mutex
>> Executing queued closeSocket()
>> AppState changed to inactive with no save ongoing and unsaved changes
>> "Save changes to local cache"
>> Sincronizzazione dei dati in corso (ongoing data sinc)
>> preparazione al salvataggio dei dati (preparing to save data)
>> Inizio salvataggio dei dati (starting saving data)
>> Inizio salvataggio delle immersioni (starting saving dives)
>> AppState changed to active with save ongoing and unsaved changes
>> AppState changed to suspended with save ongoing and unsaved changes
>> Creazione della cache locale riuscita
>> QEGLPlatformContext: eglSwapBuffers failed: 300d
>> done saving to git local / remote
>>
>> I'm not a  developer but from logs I see that 18 dives where
>> downloaded (I need only the newest three of them)
>> it's like the downloading thread has successfully stopped and some of
>> the dives are being saved
>> somewhere... But even restarting Subsurface nothing has changed into
>> my dive list.
>>
>> I attached a screenshot of the whole log.
>> I know that I could get the log file connecting via USB but given that
>> we already have a text canvas (or something like that) wich shows me
>> the log why don't you enable the copy paste or use another kind of
>> widget so a user can easily forward it directly from Subsurface UI?
>>
>>
>> That's a QML problem (the UI toolkit that we use). I need to ping
>> the QML developers to find out when that will be possible.
>>
>> But if you have an email app on the Nexus 7, you should be able
>> to simply attach the subsurface.log from the root of your storage
>> device to an email...
>>
>> /D
>
> I could not find that file. i have to install some file manager app.
> Anyway I will test everything this evening.
>

I tried again yesterday.

When on my Petrel I get ERROR SENDING PACKET the Subsurface mobile UI
remains waiting in download mode endlessly no matter which button I
press.

I tried again and, as Dirk suggested, after few dives were downloaded
I tried canceling the download from Subsurface mobile UI and it works.
It shows me the successfully downloaded dives and I can save them.
WOW!!!

I made another test:

- During the download I cancel it.
- Petrel immediately exit the download mode.
- Subsurface shows me successfully downloaded dives.
- Now I have the option to accept /refuse them but I have the option
to resume/try again the download too.
- I try again to download but the Petrel is not in download mode anymore.
- Subsurface tells me that cannot find the Petrel.
- I quit the download procedure.
- Subsurface crash.

I inspected the log file but I found no trace of the crash or error. I
forgot to save the file, sorry. I was very tired and I will try again
soon.

I'll write a separate email on a small quirkiness I found on the
mobile UI strings.

Bye

-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org