[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