[Qt-interest] Bluetooth SPP in Qt

[Jeffery MacEachern]

Hi Robert,

On Tue, Jun 28, 2011 at 01:11, Robert Wood <robert.wood at apostrophe.co.uk> wrote:
> On 27/06/11 22:16, Jeffery MacEachern wrote:
>>
>> That's sort of a multi-part question. The setup of the serial device
>> depends on your driver/platform. On Linux, you can use BlueZ directly
>> through QtDbus, or Qt Mobility classes, as I mentioned (they're
>> ostensibly cross-platform, but I don't know which platforms are
>> supported yet). I don't know anything about doing this manually on
>> Windows. Once you have created the serial device, you could use
>> QExtSerialPort[0] if you want a cross-platform way of accessing the
>> serial device. At this point, you can just shove bits across the link
>> like you would with a serial cable. Worst-case, it shouldn't be too
>> hard, just maybe a bit messy, code-wise.
>>
>> If this doesn't answer you question, could you clarify what your
>> concerns are, specifically? I have worked with exactly this situation
>> for a while, and could probably help you figure it out.
>
> Sorry if this is too much detail below, but thought I'd be as verbose as
> possible!

No worries, clarity is best!

> Currently, I do use QExtSerialPort to do all my communications. I use this
> thing called a Virtual Com Port (VCP) which is a USB communications class
> that mean you can send any number of bytes from one upwards from your
> program out via the USB port as if it were an old fashioned COM port/ttyS
> port you were sending the information out of/in to. On my embedded system I
> have this fantastic FTDI (they are the manufacturer of the device) IC that
> connects to the USB. This FTDI device strips out all of the USB overhead and
> spits out (and accepts in) the raw data the Qt GUI has sent out (or is to
> receive). This FTDI connects via the UART (COM port) of my eight bit
> embedded micro processor. Thus, as far as the Qt program is concerned, it is
> communicating via a UART, not USB.

Yes, I am familiar with FTDI's products. This is what I had assumed you meant.

> On Windows you have to install FTDI's VCP driver, on Linux the driver is in
> the kernel. These drivers then mean you can then access the VCPs easily. On
> Windows, I try to open all COM ports and if they can be opened, I give the
> user the choice of selecting one of them to communicate in a drop down box.
> In Linux I simply parse the /dev directory for devTTYUSB* and offer all of
> these as an option to communicate.
>
> I would have hoped that if you have a Bluetooth SPP then these would show up
> as com ports as well. If they do, then I assume "all" you have to do is get
> the user to pair up the PC and vending machine then the Qt application will
> be able to communicate as with the FTDI VCP?

That is essentially correct. Functionally, it works the same as the
VCPs you're already using. I think I may have added confusion with the
pairing process. I don't know what software the user will be using to
pair, but some that I have used do not automatically set up the serial
port for you (i.e. they "pair", but do not "connect"). The command do
so manually is quite simple ("rfcomm bind /dev/rfcommN
00:11:22:33:44:55 [channel]" on linux. If you want/need to do that bit
programmatically, the code can be a little bit messy, and that's where
the mentions of BlueZ' DBus API and Qt Mobility came in. However, they
may be entirely unnecessary with your setup.
Assuming your microcontroller is using a "serial cable
replacement"-style dongle such as those offered by RovingNetworks - or
something else configured similarly - then the computer should see the
SPP service during the scan. Try pairing them, and check if a
/dev/rfcommN device node is created. If so, then you just need to
proceed as you are now with the USB connection.
To clarify, the actual operation should be virtually identical to your
current code - the only difference is that the Bluetooth connection
itself needs to be set up first somehow; after you've "plugged in the
(wireless) cable", it should be transparent to your code, with the
exception that the port name will be different on Linux, as mentioned.

Does that help?

 - Jeffery MacEachern

> So, what I am trying to ascertain is if you use these SPPs, can you use
> these ports exactly as you would an old fashioned com port just as you do
> with the FTDI VCPs? If not, how do you get the Qt application to get data in
> and out of the SPP?
>
> Hope that's the right amount of detail and makes sense! :~)
>
> Rob
>
>
>