LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Bluetooth

I'm trying to use a D-Link DBT-120 USB adaptor and an RFCOMM device with LabVIEW 8.0 evaluation - so far with limited success.
I can use the RFCOMM Discover to find the D-Link Adaptor, and then discover the devices around the room.
I know which device is "mine" by the address that is reported.  But if I try to send a message or connect to the "server" (the D-Link) all I get is errors.  The "Creating a Bluetooth Server Application" section of "Developing Bluetooth Applications with LabVIEW" doesn't help.  Is there anything else?
 
Thanks,
 
Les Hammer
0 Kudos
Message 1 of 22
(5,736 Views)
First, what are the errors that you're getting?

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 22
(5,729 Views)

I'm getting error 1 when I set up everything the way I think it should be.

Other times I get error 56 or 59.

The directions say to give the "server address" as the input.  None of them ever ask for the address of the device I'm trying to connect to.  That's confusing too.  Is there a generic example that says "if you know the address of the bluetooth on your computer and the address of the remote bluetooth device, here's how to send a string of bytes and listen/receive a string of bytes in response"?  This isn't some bt headset that folows a standard protocol.  (Well, it *does* follow a standard protocol - it's just that it is IEEE 1451.0, not an audio device.)  My remote device does not have any "services", but if you send it the right bytes it will respond.  And I know my remote device works because someone else was able to connect to it with a Lynix program.

Thanks,

Les Hammer 

0 Kudos
Message 3 of 22
(5,718 Views)
Typically, the server address is the device you're trying to connect to.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 4 of 22
(5,695 Views)

Just try to change the Channel input in Open Bluetooth Connection.vi  from 0 to 1.

Rumcajs.

0 Kudos
Message 5 of 22
(5,681 Views)
> Typically, the server address is the device you're trying to connect to.

Hi Mike,
 
When I use the address of the remote device I get error 54 "Ill formed Address"  when I try to do a Create Listener (even though this is generated automatically from the list of addresses returned from "Discover."
 
BTW, is the UUID a random number or is there a method to choose these.  IEEE-1451.0 has a "UUID" but it's a different length than what is suggested by "help", and you can't find that UUID until you talk to the device - which you can't do without knowing the uuid that labview wants...
 
Thanks,
 
Les Hammer
0 Kudos
Message 6 of 22
(5,650 Views)
> Just try to change the Channel input in Open Bluetooth Connection.vi  from 0 to 1.
OK.  That plus Mike's suggestion of using the remote device's address for the "server" allows me to write to the device.  At least the debugger shows a string of bytes coming in that look like what I'm sending.  🙂
 
Still having trouble with the Create listener though...
 
Thanks,
 
Les Hammer
0 Kudos
Message 7 of 22
(5,639 Views)
Whoo Whoo! Good progress!

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 8 of 22
(5,624 Views)

Hi it's me again.  I'm still having problems reading my Bluetooth device.

I'm using LabVIEW 8.0 (eval) and a D-Link RFCOMM DBT-120.
I have several .vi that all get compiled into one .dll.
I have a global .vi to store the address string, connect ID etc.
The network (remote) device is primative and doesn't have "services" or a uuid, but responds to an octet array input with an octet array output.  (octet array == bunch of char)

What works:
My init vi BT Discover finds both locally installed (the D-Link) and the network (remote) device.  This vi saves the remote device address to the global.

My writeMsg.vi takes the remote address and does a BT Open connection -- BT Write and saves the connection ID.  The message makes it to the remote device (as verified by the remote's debugger).  The remote's debugger is happy and says it is sending a response.

As a side note here, if I do the BT Open connection in the init vi and save the connect ID to the global, and then skip the BT Open in the writeMsg.vi -- just doing the BT write, the BT write is not happy with  that connect ID.  Does LabVIEW 8.0 have a problem with putting a connect ID into the global?

What doesn't work:
My readResponse.vi is suppose to take the connect ID to the BT Read.  It gets error 1 - invalid input.  Apparently it's not happy with the connect ID.  On the other hand, If I change the previous writeMsg.vi to close the connection and open a new connection in readRepnse.vi (using the address string rather than the connect ID), then I get a timeout.

Any suggestions?

Thanks,

Les Hammer

0 Kudos
Message 9 of 22
(5,563 Views)

I finally got all of this to work.  Here are a few hints for anyone else trying to get Bluetooth to work in a dll:

1)  Bluetooth Discover does not work in LabVIEW 7.1.  You need at least 8.0

2)  If there is only one address for both send and receive you cannot do the write to device and read from device in separate .vi!  You need one operate.vi that handles all the I/O in a state machine -- during idle time it just listens for incoming bytes and stores them in a circular buffer.  Of course, since this operate.vi should never return until the end of the program, you need to spawn a thread in your C++ program -- otherwise your program will hang on the call.  The "write.vi" doesn't write to the device - it writes to a global and sets a flag/semaphore to trigger the operate.vi to jump out of the listen/read loop and go to the write loop.  (If you try to write to the device from the write.vi you won't be able to get the ConnectId.)   Similarly, your "read.vi" doesn't read directly from the device -- it reads from the (global) circular buffer that operate.vi has been writing to.  Be sure not to go past the "end" marker.  You may also want a Close.vi which sets a flag to tell operate.vi to go to the CloseBluetooth section and turn off.

3)  Unlike my BNEP code (not written in LabVIEW, different transceiver, etc), the RFCOMM code with a D-Link dongle has a 124 byte limit.  If you have messages larger than that it will either break them up into 124 byte chunks or loose it altogether.  (This was mainly a problem seen on my device side - which doesn't have LabVIEW code.)  It's unknown whether the D-Link, the device RFCOMM code, or something else causes this limit.  It's just something to be aware of.  You may have to stitch smaller device-incoming messages together, or break up outgoing messages.  (LabVIEW seems very capable of reassembling these device-outgoing, computer-LabVIEW-incoming messages into one big stream.)

That should be enough to get anyone going on a Bluetooth dll.

0 Kudos
Message 10 of 22
(5,433 Views)