06-25-2007 06:20 PM
06-25-2007 06:54 PM
06-26-2007 12:12 AM
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
06-26-2007 06:24 PM
06-27-2007 12:18 AM
Just try to change the Channel input in Open Bluetooth Connection.vi from 0 to 1.
Rumcajs.
06-27-2007 01:17 PM
06-27-2007 04:59 PM
06-27-2007 07:08 PM
07-06-2007 10:44 AM
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
08-08-2007 05:31 PM
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.