[GSoC] Week 3 (Native Bluetooth support)

[Claudiu Olteanu]

Hi,

As you can see I am having some troubles and I don't
know in which direction to go. If we want to implement
the data transfer using the Qt Bluetooth API, then we
should find a way to integrate it with the implementation
of the serial port communication from *libDC* project.

If this is not possible and we still want to use the
Qt Bluetooth API, then we need to do some specific
implementation for each dive computer vendor.
This implies a lot of useless work since it is already
implemented in *libDC* project.

I already tested the *serial_write* and *serial_read* methods
from *libDC*, using the *QtBluetoothSocket* descriptor and
they work. These are the basic methods used to
communicate with the device in *libDC*.

The only problem is that I need to call somehow the
initialization method to initialize the *vtable* of the
device which stores functions pointers to some device
specific implementation for read/write methods.
As I said, the initialization is done in the *open* method
and I don't know how to fake its call. I cannot manually
initialize the *vtable* because the methods are declared
static.

If I find a way to initialize the *vtable* and to replace
the serial port descriptor with my socket descriptor, then
I expect things to work.

Do you have any suggestions how to do that? Do you
believe that this is a bad idea? Should I give up with the
Qt Bluetooth API and move further?

Thanks,
Claudiu



On Sun, Jun 14, 2015 at 12:43 AM, Claudiu Olteanu <
olteanu.vasilica.claudiu at gmail.com> wrote:

> Hi there,
>
> This week I did some research about the *libdivecomputer*
> parser and its serial port implementation.
>
> I find out that each device has a virtual table which
> contains information about the device's family (*type*),
> a fingerprint and references to some operations
> (read/write/dump/close) needed for the serial
> communication. This table is initialized when the device
> is opened.
>
> In order to create a parser you need to provide the
> following information:
> - the device type (find out in the *vtable* or in our
>  *descriptorLookup* map)
> - some device information (the *model*, the *serial* and
>  the *firmware*) read from the device
> - some information about device's clock (*systime* and
>  *devtime*) read from the device
>
> Therefore all needed information can be obtained and we
> can create and use the *libdivecomputer* parser.
>
> The problem is that the devices expose only the Serial
> Port Profile and we can communicate with them only using
> the virtual COM port. Each device family has its own
> specific implementation and it requires a lot of work.
>
> Since the serial communication is already implemented in
> libdivecomputer I tried to find a way to use it along with
> the Qt Bluetooth API functionalities. I thought that if
> somehow I will replace the file descriptor of device's
> serial port from libdc with the socket descriptor obtained
> using the Qt Bluetooth API it should work. I am not sure
> if this is a good or a bad one. I didn't find a solution
> to do that anyway. We need to open the device in order to
> initialize its *vtable* and it will fail when it will try
> to open the serial port, since there is no port to open.
>
> I also tried to create a named pipe, to use it to simulate
> the virtual COM port and to pass its name to devname field
> from *device_data_t* structure (used when the port is opened).
> I didn't even believe that it would work but I said that I
> should give it a try. Apparently the *dc_device_open* method
> fails when it tries to call the *ioctl* or the *tcgetattr*
> method. I simulated the calls and both fail with an
> "*Inappropriate ioctl*" error. This is probably due the fact
> that it uses the TIOCEXCL command which is specific for
> terminals.
>
> Then I though that maybe a *pseudo-tty* can solve my problem,
> but I didn't have time to research. Do you believe that
> a pty could be a solution?
>
> Besides that I did some research about *QtSerialPort* and
> *QtSerialDevice* in order to see if I can emulate the virtual
> port and use it in my scenario. Unfortunately I didn't
> find anything useful.
>
> Now I am a little stuck and I don't know if I should give
> up with the Qt Bluetooth API and move further. Should I
> start to look over Jef's work and to finish his
> implementation?
>
> Another possible solution could be to implement the *bind*
> command from *rfcomm* tool. I looked over the implementation
> and I can do that with a simple *ioctl* call. I will use the
> Qt Bluetooth API for scanning, pairing and collecting
> information about remote devices. When the client wants
> to connect to the device, then I will create a RFCOMM
> device and use it in the *downloadfromdivecomputer*
> implementation. The inconvenient is that in order to
> create a RFCOMM device we need root privileges.
>
> Please let me know if you have other ideas or if I
> should concentrate my work in other direction.
>
> Best wishes,
> Claudiu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150614/71e17f11/attachment-0001.html>