[GSoC] Week 3 (Native Bluetooth support)

Claudiu Olteanu olteanu.vasilica.claudiu at gmail.com
Sat Jun 13 14:43:35 PDT 2015


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/4b488606/attachment.html>


More information about the subsurface mailing list