Sorry for top posting, on my phone.
From memory, the ff in the end is the end communications command, and indeed
its a ff there in the response, it's just prepended by a aa there.
The memdump in the ostc3 back end dumps all the memory, so it doesn't matter if
there's one dive on the DC, or 1000, it will download the same data volume.
I'll try to take a look at it tonight.
//Anton
On September 27, 2018 6:25:41 AM GMT+02:00, "Lubomir I. Ivanov"
<neolit...@gmail.com> wrote:
>On 27 September 2018 at 07:16, Steve <stevewilli...@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.
>
>i guess the biggest point here is that the BTLE Win32 stack works.
>
>lubomir
>--
>_______________________________________________
>subsurface mailing list
>subsurface@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
