[TEST REQUEST] Windows Bluetooth LE build

Jan Mulder jlmulder at xs4all.nl
Sun Jun 10 01:56:23 PDT 2018


On 10-06-18 03:56, Lubomir I. Ivanov wrote:
> On 10 June 2018 at 03:26, Dirk Hohndel <dirk at hohndel.org> wrote:

>>
> 
> so by enabling debug output for the read(), write(),
> characteristicWritten() and characteristcStateChanged() and i get
> this:
> 
> <snip>
> Found uuid: "{53544d54-4552-494f-5345-525631303030}"
> Found service "{53544d54-4552-494f-5345-525631303030}"
>   .. done discovering services
>   .. discovering details
>   .. enabling notifications
> BLE write completed
> BLE write completed
> characteristicWritten "{00000003-0000-1000-8000-008025000000}" "ff"
> INFO: dc_device_open error value of 0
> write "\xBB"
> [14.768589] ERROR: Failed to receive the echo. [in hw_ostc3.c:295
> (hw_ostc3_transfer)]
> [14.769031] ERROR: Failed to send the command. [in hw_ostc3.c:455
> (hw_ostc3_device_init_download)]

The 0xBB is the init communication command to the OSTC and as most 
(all?) commands in the OSTC protocol are echoed from the device, libdc 
expects a 0xBB in return. It simply does not get this and fails.

> 
> the OSTC+ itself says "Download mode enabled" right after the
> "Download button" is pressed.

This shows that the device sees the 0xBB command, so there is some 
(correct) data transferred to the device. so 1) the device responds with 
the echo which is lost (so the ssrf side does not see this) or 2) your 
test device is broken, which is unlikely when a classic BT transfer does 
work (its one chip, and half broken does not sound logical to me).

On 10-06-18 04:19, Lubomir I. Ivanov wrote:
 > one question from me:
 > how can upload a fake dive to the OSTC+?

I do not believe this is possible (other than putting it in a pressure 
tank and virtually dive it).

--jan



More information about the subsurface mailing list