> > > No; I thought I explained this before we started... > libdivecomputer has two reasonably distinct parts. > The communication with the dive computer and the > parsing of the data that was downloaded from the > dive computer. > My goal is to do the communication with Bluetooth > based dive computers from within Subsurface and > then pass the data buffers to libdivecomputer for > parsing. > > My concern is related to the fact that I have to communicate with the device using the Serial Port Profile and there is not a standard protocol for the communication. As you know, each member has its own implementation. Each vendor expects its own specific commands through the virtual COM port of the device. Because this is already implemented in *libdivecomputer*, I thought that it will be easier if I will find a way to integrate it.
> I don't think that's the right way to go. Of course, we have > our own branch of *libdivecomputer* and we could always > make changes, but that would move us further and further > away from upstream which is the opposite of what I'd want > > I don't intend to make changes in *libdivecomputer* branch. I want to find a way to initialize the *vtable* from Subsurface by faking the call of *dc_device_open* and return it with success. Then I want to change the *fd* from the serial port with my socket descriptor. As I said, I am not sure if it is possible or if it will work, but it will simplify my work. > I think you should consider just using the parser from > libdivecomputer and doing the downloading entirely > in Subsurface. > > Ok. Then I will implement the data transfer for HW OSTC family and try to use the *hw_ostc_parser* parser to interpret the data. If all works well, I will start to implement the communication for other families or I will go further with the implementation for Windows. Claudiu
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface