On 11 June 2018 at 17:49, Dirk Hohndel <d...@hohndel.org> wrote: > >> On Jun 10, 2018, at 5:36 PM, Lubomir I. Ivanov <neolit...@gmail.com> wrote: >> >> On 10 June 2018 at 16:04, Lubomir I. Ivanov <neolit...@gmail.com> wrote: >>> >>> BT classical mode works - i was able to download 10 dives, that >>> apparently already existed on the DC. >>> i need to debug the BLE response from the device. >>> >> >> status report: >> so sadly i'm observing a multitude of problems here with this DC >> (OSTC+) on Windows with BLE. >> >> 1) the native WINAPI does not have means to pair or connect to a BLE >> devices programatically, which means that the user has to find the >> devices using Control Panel methods and pair / connect to it manually. > > So how does the Control Panel do this, then, if there are no API calls > to connect to a BLE device?
it does it with calls that are not exposed to user space. > Case in point - DM5 does not require the user to somehow pair their > EON Steel with the computer, DM5 simply starts talking to it. Which makes > me think that we should try to just talk the OSTC and check if it responds... > it doesn't work for the OSTC. i've tried writing a native WINAPI test app, bypassing Qt, but there is no API for pairing or connecting. maybe there is a way to hack around it - waiting on response from QtConnectivty too. threads of interest: https://social.msdn.microsoft.com/Forums/vstudio/en-US/e321cb3c-462a-4b16-b7e4-febdb3d0c7d6/windows-10-pairing-a-ble-device-from-code?forum=wdk https://social.msdn.microsoft.com/Forums/en-US/65c9cf4e-e225-4fc3-8c2c-66cd2401d3ed/how-to-establish-a-connection-from-windows-8-pc-to-a-bluetooth-low-energy-device >> 2) so OSTC+ has a certain service with 4 WriteNoResponse >> characteristics (no READ, WRITE-ONLY) which is supposedly the service >> we have to use for communicating to the device. at least we assume >> that in Subsurface but i don't see a concrete reason for this >> assumption. we also assume that the first characteristic is the one we >> want to write the "0xBB" to. > > This code was written based on documentation of the BLE stack that the > OSTC implements. > I wonder if the four characteristics are in the same order. It would be > interesting > to dump all the information we can get on the four of them both under Windows > and Linux and see if this points at something odd. where can i find this documentation? if someone gives me the Linux UUIDs of the 4 chars i can compare. even a dump of the whole successful operation of downloading dives (command exchange etc) would help. > >> when i manually write the "0xBB" (INIT) command to the first >> characteristic the second characteristic becomes READ-ONLY and >> responds with 0x4D (READY) in "BLE explorer". i think the current >> BLE-Win32 stack in QtConnectivity does not handle that and the seconds >> characteristic remains WRITE-ONLY. this has to be discussed with >> QtConnectivity as well, i guess. > > If you write the 0xBB, do you get 0xBB anywhere on the characteristics that > you can see? after writing 0xBB to the first char, the second char (that suddenly becomes readable) either becomes "0xBB - 0x4D" or "0x4D". i don't know what dictates the differences here. > >> 3) i don't think we handle 2) well in Subsurface.also i don't have >> information if the BLE code in Subsurface and the code in >> libdivecomputer works for OSTC+ on other OSes... > > Linus and Jan should be able to answer most questions that you might have > on the BLE code / OSTC BLE interface. A lot of this is still rather fragile > and > hack-ish, but we should be able to figure out how this is supposed to work > and if you boot Linux on your laptop you should be able to create "identical" > interactions on Linux (where this all works) and Windows... i'm not allowed to dual boot this machine. my VMs have trouble gaining access to the BLE hardware - i can try that again. > >> i know that writing to a WriteNoResponse characteristic would not >> trigger our BLEObject::characteristicWritten(). >> BLEObject::characteristcStateChanged() also doesn't trigger. > > I don't understand what you are trying to tell us here. > writing to a characteristic that has the "WriteNoResponse" flag, means that no Qt signal will be emitted that someone wrote to that char. which means that a characteristicWritten() would not be reached. in the case of the OSTC+ we are writing to such a char (the first one). after that it becomes a question of how we detect if someone wrote to it in libdc or subsurface. i wasn't able to find the code for that, but please feel free to correct me as i was kind of tired when checking... >> this obviously needs more debugging, but not sure when i'm going to >> have more time - maybe tomorrow. >> also, i'm very interested how many people will respond to the testing >> request...3, 10, 30? > > Lots of people have these dive computers. The questions you are asking > is about the intersection of people who (a) have a Windows laptop with > BLE and one of these devices (large number), (b) who've seen your > announcement (a lot fewer), and (c) who feel comfortable that they can > follow the instructions and make this work (that I expect to be a fairly > small number - in part because this is not just "run this installer") > yes, i'm aware. just wondering, because some other DC might just work. > I will leave on a two week trip on Wednesday and much as I love our > users, I will not bring the Windows laptop on this trip. But since Jan is > now able to play along, I hope that we'll be able to make progress > nonetheless > sounds good. lubomir -- _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface