Subsurface-mobile with BT and BLE support [was Re: updates to libdc with ABI change]

[Linus Torvalds]

On Thu, Jun 29, 2017 at 3:31 PM, Anton Lundin <glance at acc.umu.se> wrote:
>
> I tested this to, against a OSTC4, and I actually got some data back.
> It looks scrambled, and haven't had the time to decipher what might
> be wrong.

Ok, good, getting anything back is a good step. Every time I got to
that point with any of the three dive computers I got working, I was
basically home free. At that point it's just about figuring out what's
different about the BLE side from the previously working protocol.

I have a few more suggestions for you to try.

 - one BLE GATT "feature" that I saw with the Perdix AI is that
depending on how the other end sends the data, it might either show up
as a plain data packet, or as a "descriptor value update" or whatever
the hell the GATT people call it.

And if it's a "value update", it seems to still have the notification
header on it, which is why our ::read() routine has this:

        if (device_is_shearwater(device))
                packet.remove(0,2);

which basically removes the two-byte GATT header. You'll note I do the
same for the writing side.

However, the fact that you only have one descriptor per characteristic
(unlike the Shearwater that puts everything into one characteristic)
and the fact that you don't seem to need this for the writing side
makes me suspect you're hitting a different thing entirely.

But to check, you might want to just literally print out the packet
you receive in characteristcStateChanged(). Which actually leads me to
my second suspicion:

 - the *other* suspect is that since we now presumably get notified
about the other end opening up their serial buffer, since that seems
to be how that terminal IO thing works, you may now be getting the
notification about the "receive credits" from the other side.

And right now that characteristcStateChanged() doesn't actually care
*which* characteristc it gets data for. It connects to the signal for
the whole service, so *any* characteristics under that services
sending notifications will just be counted as packet data.

So you might also want to add a debug printout about which
characteristic it is in there. So something like

    qDebug() << "characteristcStateChanged" << c.uuid().toString() <<
value.toHex();

in characteristcStateChanged() might be a good idea. You can put
something similar on the ::write() side just for completeness.

Also, if you run on Linux, doing

     btmon -w snoop.log

(as root) while doing this all will get you a nice packet trace that
you can then either send to me, or better yet just try to understand
yourself with

    wireshark -r snoop.log

which will force you to learn more about BT than you ever really
wanted to learn.

I speak from experience.

    "It builds character. Keep at it."
            - Calvin's dad

In fact, once you've gotten far enough to actually see data go back
and forth, you can ignore all the really nasty packets (that do the
connection setup and parse the characteristics etc), so just scroll to
the end, and look at the ATT write command "Value" stuff, and you can
see that data you wrote (and then same thing for the nofirications).

Have fun,

                  Linus