On Tue, Jul 11, 2017 at 03:44:44PM +0200, Jan Mulder wrote: > > > > I asked Linus to take a look at that commit, given that he understands > > that code much better than I do. > > Yes, very good. Despite me changing it, I also do not fully understand why > the code was as it was.
Story of a maintainer's life :-) > In my testing I have not seen any cases of 32 being not enough. So, yes, > comfortable with it. The 118 dives where a serious stress test. > > > Not advocating to do this, just trying to understand how you picked 32. > > It is coming from the Telit code samples :-) I just copied it, tested it > with this value, and it just works. That's an excellent reason > > Thanks for all the work on that. I keep hoping that with every flavor of > > BLE that we add we will cover more of the "typical" cases and that the > > next one to add will become easier. > > Indeed. The step to OSTC was a pretty difficult one, with that weird credit > thing, 4 characteristics to deal with, and a different parser concept than > the "one-packet is fine" types as before. In a way each one was remarkably different from the previous one. I'm hoping that we are getting closer to having the typical cases covered. > And in the meantime, I tried Android, with Qt 5.9.1 but no success yet. > Cannot open device (BLE that is, BT just works). Often that means that they are not connected / bonded. Since we don't try to do the scan / connect ourselves, we are relying on Android doing that for us. What reliably works for me is to have nRF Connect scan, connect, then bond, and THEN start Subsurface-mobile. But of course it's possible that there's yet more oddity here with the chip used on the OSTC... /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
