devel May 2014

devel@libdivecomputer.org

7 participants
4 discussions

Start a nNew thread

[PATCH] Minor error in serial_configure
by Venkatesh Shukla 28 May '14

28 May '14

I have attached a patch to a minute mistake that I noticed in the code. -- *Venkatesh Shukla*

3 5

Qt Bluetooth and maybee serial support
by Anton Lundin 22 May '14

22 May '14

Hi. I just saw that Qt 5.3 was released and that contains bluetooth support, and that includes android too: http://qt-project.org/doc/qt-5/qtbluetooth-index.html I think it would be awesome if we could add Qt Bluetooth support to libdivecomputer, and while where at it, maybe Qt Serial support to. We would probably build them as a default-off build option. Do you think it would be a patch you can accept Jef? At least one if the libdivecomputer based apps, Subsurface, is built with Qt and it would be a nice way to abstract it away. And it would probably help a bit in getting Subsurface more usable on Android. //Anton -- Anton Lundin +46702-161604

3 2

Native bluetooth communication
by Jef Driesen 07 May '14

07 May '14

Hi, The last few days, I received several questions related to the status of native bluetooth communication. In order to avoid having to repeat myself, let's give a small overview of the current status. A while ago, I have been prototyping a native bluetooth communication backend for libdivecomputer. The goal is to be able to replace the serial emulation in the future. The main reason behind this effort is that the current situation, where we rely on serial emulation, is less than ideal. It requires some setup by the end-user, and last but not least it doesn't appear to work very well on linux! I have arrived at a point where I have a functional implementation for windows and linux. With functional, I mean I'm able to connect to the dive computer and successfully download dives. What is still missing is device discovery, which means you have to figure out the bluetooth address of the device manually. Certainly not perfect yet, but it does work! I have attached the patches with my prototype code. These patches include the bluetooth communication code, together with the necessary changes to integrate it into the Shearwater Predator/Petrel backend (the same could be done for the Heinrichs Weikamp Frog too). The linux and windows implementations are very similar because they both provide a socket interface [1,2]. (I actually spend most of the time debugging a failure on Windows. In the end, the problem turned out to be caused by a bug in the mingw header files, and not my code. The bug was already fixed upstream [3], but not yet included in the packages I was using.) I'm now looking at Mac OS X support, but this appears to be much harder than I expected. The developer documentation [4] isn't very helpful. It contains lots of information, but appears to lack the info I'm looking after (e.g. how to connect to a device, send/receive data, etc). The fact that I don't have any experience with Objective-C code or the Mac framework doesn't really help either. So if anyone can provide some assistance here, that would be great! Ideally, I would like to avoid using Objective-C code completely and use the C api of the Mac framework instead. Of course help is not limited to the Mac OS X part only. If you have some knowledge about bluetooth in general, or have some experience with the Windows/Linux bluetooth api's, then any help in that area is appreciated too! [1] http://people.csail.mit.edu/albert/bluez-intro/ [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa362932%28v=vs.85%… [3] http://sourceforge.net/p/mingw-w64/code/6249/ [4] https://developer.apple.com/library/mac/#documentation/DeviceDrivers/Concep… Jef

2 1

setting aside SAMPLE_EVENT_xxx ranges for applications
by Dirk Hohndel 07 May '14

07 May '14

Hey Jef, chasing a bug in Subsurface today I realized that we are abusing existing event types internally since we don't have reserved event types that we know will not be used by libdivecomputer in the future. I guess there would be two solutions: a) we ask you to add events that you haven't seen in any dive computer, yet, so we can use them as synthetic events for our own purposes (so far this is only a "setpoint change" event that we use in the planner). b) you add a reserved range of numbers that we can simply redefine SAMPLE_EVENT_APP_RESERVED_1 ... SAMPLE_EVENT_APP_RESERVED_8 (or some reasonable number) Then we can do a #define SAMPLE_EVENT_SUBSURFACE_SP_CHANGE SAMPLE_EVENT_APP_RESERVED_1 and all is well. What do you think? /D

3 9

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel May 2014