> On Sep 27, 2018, at 11:22 AM, Linus Torvalds
> wrote:
>
> On Thu, Sep 27, 2018 at 10:27 AM Linus Torvalds
> wrote:
>>
>> But yes, limiting the packetsize to 128 bytes when using the BlueLink
>> Pro dongle really fixes things.
>>
>> And I also made the "split command" be conditional, and th
On Thu, Sep 27, 2018 at 10:27 AM Linus Torvalds
wrote:
>
> But yes, limiting the packetsize to 128 bytes when using the BlueLink
> Pro dongle really fixes things.
>
> And I also made the "split command" be conditional, and the "send as
> one" be triggered by just the bluetooth case.
Ok, pushed ou
On Thu, Sep 27, 2018 at 10:00 AM Linus Torvalds
wrote:
>
> And what may end up happening is that when the bluetooth side is slow,
> the buffer on the BlueLink fills up from the serial data and you have
> buffer overflows, and then things go sideways very quickly.
>
> Judging by the fact that we di
On Thu, Sep 27, 2018 at 9:30 AM Linus Torvalds
wrote:
>
> I wonder if bluetooth needs to lower the size of the maximum read packet.
Hmm. Again, the Mares app definitely does 256-byte reads too.
So once more, I'm thinking it's some oddity where the bluetooth side
is very slow (the timestamps seem
On Thu, Sep 27, 2018 at 8:39 AM Fabio Capriati wrote:
>
> Thanks to Dirk that provides me new version. Now it retrieved correctly Model
> and serial number but no new dives. There are dives inside in DC that I've
> already downloaded with another SW, I don't know if it flags them.
> Another stra
On Thu, Sep 27, 2018 at 6:38 AM Jef Driesen wrote:
>
> On 2018-09-27 02:37, Linus Torvalds wrote:
> >
> > Jef - I assume your "send first two bytes separately" model is because
> > that's what the Mares app does on a serial line too, and you just
> > followed suite?
>
> Unfortunately that's not th
On Wed, 26 Sep 2018, Linus Torvalds wrote:
>
> I think it will only speed things up (and make the BLE code work), but
> maybe I'm being overly optimistic.
Just noticed this blog post:
Reverse Engineering BLE Devices
https://sergioalberti.gitlab.io//gsoc/2018/09/24/reveng.html
ma
On Thu, Sep 27, 2018 at 6:26 AM Jef Driesen wrote:
>
> The semantics depends on the transport type, and not whether the actual
> parameter is NULL or not:
I hope you don't actually mind my commit e97886a994:
https://github.com/torvalds/libdc-for-dirk/commit/e97886a994c18844bdcb1e1832ce4475d
Hi
Thanks to Dirk that provides me new version. Now it retrieved correctly
Model and serial number but no new dives. There are dives inside in DC that
I've already downloaded with another SW, I don't know if it flags them.
Another strange thing is the led colour during download: it blinks green
but
> On Sep 27, 2018, at 6:38 AM, Jef Driesen wrote:
>
> On 2018-09-27 02:37, Linus Torvalds wrote:
>> So it turns out that "BLE is slow" is actually the *reason* for the problem.
>> There's some really odd timing thing, where when we send the read
>> command as two different packets (first the two
Il gio 27 set 2018, 15:57 Dirk Hohndel ha scritto:
> I saw Jef's responses, so this may need more iterations, but here is an
> APK for
> Fabio to test:
>
>
> http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.2.75-arm.apk
>
> /D
>
> > On Sep 26, 2018, at 5:48 PM, Linus Torvalds <
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
I saw Jef's responses, so this may need more iterations, but here is an APK for
Fabio to test:
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.2.75-arm.apk
/D
> On Sep 26, 2018, at 5:48 PM, Linus Torvalds
> wrote:
>
> On Wed, Sep 26, 2018 at 5:37 PM Linus Torvalds
> wrote:
On 2018-09-27 02:37, Linus Torvalds wrote:
So it turns out that "BLE is slow" is actually the *reason* for the
problem.
There's some really odd timing thing, where when we send the read
command as two different packets (first the two command bytes, then
the 8 bytes of offset/length), and wait f
On 2018-09-26 19:40, Linus Torvalds wrote:
Jef, what are the semantics for
ret = dc_iostream_read(iostream, buf, sizeof(buf), NULL);
meant to be when there is only a partial read? Right now it returns
DC_STATUS_SUCCESS and garbage in the end of "buf". Which really does
seem wrong. The c
15 matches
Mail list logo
