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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface