Download dives from dive computer on mobile, status report.

Dirk Hohndel dirk at hohndel.org
Sat May 27 07:29:35 PDT 2017


On Sat, May 27, 2017 at 11:10:58AM +0200, Jan Mulder wrote:
> > 
> > I have tried the following:
> > 1) mobile on desktop, reading from the libdc simulator => working (as
> > expected),

Same here :-)

> > 2) mobile on desktop,reading from OSTC3 over BT. For this, I hardcoded
> > the BT address of my OSTC, and set the BT mode to true (obviously). The
> > OSTC goes correctly in download mode, and stays there for multiple
> > minutes. The console finally shows "Finishing the thread dives
> > downloaded 125". So, the next breakthrough today :-) The first download
> > over BT from a real dive computer :-) And most impressive, without
> > changing any of the code from Tomaz.

This I haven't tried, yet - I still have problems with BT on both of my
active development systems :-(

> > Obviously, there is something
> > needed: a progress (toast) style thingy, or any other indication that it
> > is downloading.

Sure

> > Further, I was downloading in my normal logbook, so I
> > did not expect any dives downloaded that were already downloaded
> > (without looking to any code at this point).

So you are saying it is downloading old dives that it shouldn't be
downloading, correct?

> > 3) mobile on mobile ... ok, this is not working yet. I verified that
> > pairing is ok, and I can trigger a download over my mobile (using
> > terminal input), so raw serial traffic. So the two devices can
> > communicate. It seems that subsurface mobile is not attempting any
> > communication.
> 
> And some more progress. Just downloaded 125 dives from my OSTC3 to the
> mobile app on my phone. Ok, all device specific stuff is hard coded at this
> point. The reason that 3) above did not work is that we have to open the
> socket based on  uuid as port number is not supported on Android. So in,
> qtserialbluetooth.cpp we need to something like:
> 
>     QLatin1String serviceUuid(<the UUID of the already paired
> divecomputer>);
>     QBluetoothAddress remoteDeviceAddress(<the BT address of the paired
> divecomputer>);
>     QBluetoothUuid uuid(serviceUuid);
>     serial_port->socket->connectToService(remoteDeviceAddress, uuid,
> QIODevice::ReadWrite | QIODevice::Unbuffered);

More magic we need to address. And of course we need to figure out BLE
stuff (I think Linus is talking to the Qt BT maintainer about this).

> Thinking of some QML and other things:
> - it might be nice when the list of dive computers is filtered (in the BT
> case) to the set of paired dive computers. Why bother the user with a long
> list of dive computers that are not paired (so not ready for communication)?
> Obviously, I am assuming that pairing will be done at OS/Android level, and
> not in the mobile app.

That seems reasonable

> - the list of downloaded dive on the phone looks crap. Font sizing is way
> off.

Should be easy to fix.

> that's all for today, now time from a nice dive on this almost tropical day
> in the Netherlands.

Enjoy!

I'll look through Tomaz code some more to see if I can pull all of this
into master. Not sure, yet. In the meantime I tried to catch up on the
other patches and PRs that were pending over the past two weeks.

/D



More information about the subsurface mailing list