Bluetooth serial connection
Trey
device called a BAM module. The BAM module provides a SPP service and
simply relays the information it receives directly to a physical
serial connection.
In Linux, I can use the "rfcomm" command to set up a virtual serial
port and use the Java Comm library to communicate with the BAM just
like a wired serial connection; however, I want to do this in Windows,
be able to scan for devices, select one and communicate with it like a
wired serial connection... all with Java.
I understand the basics of the JSR 82 process (finding devices,
searching for services) but I think I need to know how to connect to a
particular service and send serial messages in a particular way (baud,
stop bits, parity, etc).
I've spent many hours searching the web for a solution to this
problem, and at this point I'm desperate. Any sort of help would be
much appreciated.
Vlad Skarzhevskyy
JSR-82 even more RFCOMM layer does not exposes baud settings. RFCOMM
provides the emulated serial port and will deliver the highest
possible data rate.
You can read more about RFCOMM here:
http://www.palowireless.com/infotooth/tutorial/rfcomm.asp
and here
http://www.bluetooth.com/NR/rdonlyres/1483FFFD-7A5C-49A8-9AFE-1156DA1D96C3/916/rfcomm1.pdf
In your case the "BAM module" is what is called type 2 RFCOMM device
the RS-232 port it has has different setting than Bluetooth
connection.
--
Vlad
Trey
RFCOMM always uses the highest data rate, is 57600 Bd possible?
Perhaps a better question: Is what I'm trying to do possible with
JSR-82 (specifically BlueCove) or should I find another way?
On Jul 7, 12:07 pm, "Vlad Skarzhevskyy" <skarzhevs...@gmail.com>
wrote:
> JSR-82 even more RFCOMM layer does not exposes baud settings. RFCOMM
> provides the emulated serial port and will deliver the highest
> possible data rate.
>
> You can read more about RFCOMM here:http://www.palowireless.com/infotooth/tutorial/rfcomm.asp
> In your case the "BAM module" is what is called type 2 RFCOMM device
> the RS-232 port it has has different setting than Bluetooth
> connection.
>
Vlad Skarzhevskyy
As far as I know when you have used rfcomm command on linux to create
port and then changed the bitrate while connecting to the virtual port
on linux created by rfcomm this had no affect on device connected on
the other end of Bluetooth.
On 7/7/08, Trey <yert...@gmail.com> wrote:
>
--
Vlad
Trey
Type 2 RFCOMM device for normal serial communications)?
BTW, thank you for helping me.
On Jul 7, 3:39 pm, "Vlad Skarzhevskyy" <skarzhevs...@gmail.com> wrote:
> It is possible.
> As far as I know when you have used rfcomm command on linux to create
> port and then changed the bitrate while connecting to the virtual port
> on linux created by rfcomm this had no affect on device connected on
> the other end of Bluetooth.
>
Manuel Naranjo
> How would I go about doing what I'm talking about (connecting to a
> Type 2 RFCOMM device for normal serial communications)?
>
> BTW, thank you for helping me.
>
http://www.acroname.com/robotics/parts/I19-10542.html
According to the specs this one doesn't allow you to setup the port
settings.
What you need is a bit more advanced device. For example the company I
work for sells this one: http://aircable.net/serial.html
Which allows you to configure the serial port. SPP allows you to send
modem control signals (DTR etc), the Serial3 implements this part. Take
a look at the specs according to the sig:
https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=8700
(you will need a bluetooth sig memebership, you get this for free).
But anyway, rfcomm and SPP doesn't define a way to setup baud rates. As
bluetooth wasn't thought that way, but you can define the baud rate on
the device, if you want more information about our devices contact me
privately.
Thanks,
Manuel
Trey
Windows...)
I can actually send data to the BAM, however it only works less than
25% of the time. Here is my code:
StreamConnection connection= (StreamConnection)
Connector.open("btspp://" + address + ":
1;authenticate=false;encrypt=false;master=true");
OutputStream out = connection.openOutputStream();
out.write((byte)128);
Thread.sleep(15);
out.write((byte)131);
out.flush();
connection.close();
I find that waiting between the two bytes increases the chances that
it will work (not entirely sure about that though).
On Jul 7, 6:04 pm, Manuel Naranjo <naranjo.man...@gmail.com> wrote:
> Trey,> How would I go about doing what I'm talking about (connecting to a
> > Type 2 RFCOMM device for normal serial communications)?
>
> > BTW, thank you for helping me.
>
Manuel Naranjo
> StreamConnection connection= (StreamConnection)
> Connector.open("btspp://" + address + ":
> 1;authenticate=false;encrypt=false;master=true");
> OutputStream out = connection.openOutputStream();
> out.write((byte)128);
>
> Thread.sleep(15);
> out.write((byte)131);
> out.flush();
> connection.close();
>
> I find that waiting between the two bytes increases the chances that
> it will work (not entirely sure about that though).
>
the rfcomm channel is busy.
Have you tried with plain windows? Just to make sure your stack is not a
problem? Adding a virtual port, then connecting. If this works, then
there shouldn't be any limitation in bluecove for you to make this work.
Except for the 8 bits/16 bits thing which is kind of tricky.
Trey
and communicating to the BAM through it. I understand Windows'
Bluetooth drivers are notoriously wonky.
As I said before the command "128 131" has the desired effect maybe
15% of the time. How could this be? Where is my problem and how do I
resolve this issue?
Manuel Naranjo
> I've been unsuccessful at setting up a virtual serial port in Windows
> and communicating to the BAM through it. I understand Windows'
> Bluetooth drivers are notoriously wonky.
>
consider a stack. Bluecove is ok so is widcomm, never tried with toshiba....
> As I said before the command "128 131" has the desired effect maybe
> 15% of the time. How could this be? Where is my problem and how do I
> resolve this issue?
>
Thin is that in java a data type byte is actually 16 bits or something
like that, so data conversions aren't so easy to do. If you do byte A =
128 && 0x00FF you some how can be sure that the upper part of A is null.
I would say you better start debuggin what's going on. Eclipse is pretty
good for this tasks. Make sure bluecove is getting exactly the same that
you wanna transfer.
Trey
> consider a stack. Bluecove is ok so is widcomm, never tried with toshiba....
Windows way. So I guess I was using the Windows XP SP2 stack.
I tried using "& 0x00FF" but it doesn't change my results. I'm pretty
sure the "byte" type in Java is 8 bits. The "char" type however, is 16
bits.
I'm not sure if any amount of debugging is going to solve this
problem. The fact that it works some times, but not all, is a
disturbing result when working with computers. It should work or not
work.
I suspect baud rate issues. Is there any reason BlueCove (or the
underlying Windows stuff) would change settings from run to run?
Thanks for your help
Manuel Naranjo
> I was unsucessful at setting up a virtual COM port the standard
> Windows way. So I guess I was using the Windows XP SP2 stack.
>
> I tried using "& 0x00FF" but it doesn't change my results. I'm pretty
> sure the "byte" type in Java is 8 bits. The "char" type however, is 16
> bits.
>
> I'm not sure if any amount of debugging is going to solve this
> problem. The fact that it works some times, but not all, is a
> disturbing result when working with computers. It should work or not
> work.
>
> I suspect baud rate issues. Is there any reason BlueCove (or the
> underlying Windows stuff) would change settings from run to run?
>
why bluecove will make any difference with this. You said you were able
to make this run on linux right? Ok why not first trying to get this
working with bluecove for linux. This works pretty well. If your app
works then it might be a problem related to the stack, and I suggest you
try getting another stack.
Cheers,
Manuel}
>
Trey
you told me it wasn't).
The message "128 131" was being sent rarely because it wasn't given
enough time to complete the transfer. After adding a longer
Thread.sleep *after* sending the data, the connection stayed open long
enough to transfer the data successfully.
Basically I was closing the connection before the data could be sent.
It works perfectly now!
Manuel Naranjo
> I finally figured it out. The problem was not with the baud (I know...
> you told me it wasn't).
>
> The message "128 131" was being sent rarely because it wasn't given
> enough time to complete the transfer. After adding a longer
> Thread.sleep *after* sending the data, the connection stayed open long
> enough to transfer the data successfully.
>
Ouch!, bluetooth connections tends to be asynchronous this means you
know when you tell the rfcomm connection to send the data, but you don't
really know when that happens.
A suggestion, making a connection takes no less than 1 sec (it might
take less, but in general), it's a safe value to tell if a connection
was successful or not 7 secs, this is related to bluetooth page windows
sizes.