[TEST REQUEST] Windows Bluetooth LE build

Anton Lundin glance at acc.umu.se
Fri Sep 28 06:36:54 PDT 2018


On 27 September, 2018 - Lubomir I. Ivanov wrote:

> On 27 September 2018 at 07:16, Steve <stevewilliams at internode.on.net> wrote:
> >
> > May have spoken too soon.
> > Got an error dialog with "Dive data import error" message
> >
> > Last bit of the cmd window log below:
> 
> thanks a lot for testing!!
> 
> did you try more than once e.g. restarting and trying again?
> it worked nicely for me 2 of 2 times for this OSTC+ unit.
> 
> > QTime("13:36:36.353") packet READ "ffffffffffffffffffffffffffffffff"
> > read 20
> > QTime("13:36:36.354") packet WAIT
> > QTime("13:36:48.367") packet SEND "ff"
> > read 20
> > QTime("13:36:48.375") packet WAIT
> > QTime("13:36:48.508") packet RECV "4cff"
> > QTime("13:36:48.508") packet READ "4cff"
> > Deleting BLE object
> > Finishing download thread: "Dive data import error"
> > Set the current dive site: 72475123
> > Set the current dive site: 72475123
> >
> 
> this is entering the land of protocols and such in libdivecomputer
> that i don't understand.
> so i'm going to have to defer to others.

Ok. My memory was correct.

The 0xFF command sent is the "EXIT" command, and then we expect the dc
to echo the command back, but we get a extra 0x4c there, before the echo
0xff.

The 0x4c is the S_READY (service mode ready) byte, aka the whole memory
dump was sent.

So, some how we ended up being out of order.

I would need to look at the libdivecomputer log file to. It might tell
us what actually happened.
 
> i guess the biggest point here is that the BTLE Win32 stack works.

YEY.


//Anton


-- 
Anton Lundin	+46702-161604


More information about the subsurface mailing list