> On Apr 27, 2018, at 2:53 PM, Dirk Hohndel <[email protected]> wrote: > > >> On Apr 27, 2018, at 2:49 PM, Lubomir I. Ivanov <[email protected]> wrote: >> >>> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 >>> ) QLowEnergyServicePrivate(0xc5271c00) >> >> just realized that 9 / 9 mean the start and end handle for this service. >> so i guess that also confirms that the service has no characteristics >> if they are equal. > > That makes sense
More testing shows even less reasonable results. Android only ever sees the Petrel 2 as type 2 (BLE only) device (even though it should be a type 3 (dual stack) device). Trying to force a BLE bonding from nRF Connect makes the BT stack crash. Trying to download over BLE from Subsurface-mobile on Android fails as described. But… ignoring the “BLE only” designation and instead downloading via rfcomm succeeds. Hrmpf. I guess I’ll have to add a special case for Petrel devices that if they fail on BLE they should try BT after all, anyway? Not my preferred solution, but I’m not sure what else to try. /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
