using bluetooth write - hex data in

[Vickie]

I have a bluetooth adapter on my pc that I use to connect to my bluetooth device.

I can successfully do this in hyperterminal, issue my standard 2byte hex command and get the desired results.

When I use LabVIEW to do the same thing, I use the bluetooth write.vi with data in being my 2byte hex command. But the results are not the same as hyperterminal. When I do a bluetooth read to see the results of the write, I see skewed results and errors.

For example depending what I write, different values are read from my bluetooth device:

Write                      Read

0FFA                      2AA

FFF0                      0A

FFFF                      FA

FFFA                      AA

I see that the data in value of the bluetooth write.vi is pure ASCII, so this should transfer by hex value just fine.

I've tried using escape commands \r\n and the beginning and end of my write. This changes the Read value, but not to what I want.

I've also tried the hex escape command \x, but with the same results as above.

Thanks for any help.

Vickie

[jjgors]

Since you can use hyperterminal, I assume you are communicating over the virtual COM port??  If so, try using the VISA serial port read/write vi's instead of the bluetooth vi's.

[Vickie]

I just tried it using VISA serial write and read and I get the following results.

Write: \n0FFA\n

Read:
[H]-help >2AA sent
[H]-help >

Where I should be seeing....

Read:

[H]-help >0FFA sent

If I write without the escape characters I get:

Write:0FFA

Read:0 [illegal character entered]
[H]-help >

[jjgors]

I may be wrong, but it looks like you are mixing slash codes with hex data in your string control.  Try changing your string to a hex data type and then add in the new line constant.  (Or you can use 0A in hex for new line).  If you left it as ASCII, the data will not be what you expected.  You may need to change to hex on you read indicator also.

[Vickie]

I am mixing the slash codes with my hex; that's because I think I get "better" results that way, but not the right results either way. I'm assuming the hex string that you suggested is just a hex display, so it doesn't alter the ASCII string that is passed in. But I tried it anyway and got the same results.

Thanks for your suggestions.

[TreyB_NI]

Does your bluetooth device expect a termination character at the beginning of the string?

Do you read the expected hex values when you do a loopback test?

http://digital.ni.com/public.nsf/allkb/E22DA85E97818DE78625678C0069BFC9?OpenDocument#L


Here's a KB on hex communication with serial using VISA.

http://digital.ni.com/public.nsf/allkb/6C24F2F07BC23BB78625722800710865?OpenDocument

Trey B
Applications Engineering
National Instruments

[Vickie]

Hi Trey,

No, I don't expect any termination characters. Once my device receive 2 hex bytes an event is triggered without a termination character. 

I was playing around with the Serial Visa write and read in MAX last night and figured out how to get it working. I can only pass in 4bit hex at a time. If I try to pass in a full hex byte, some sort of translation happens and it skews the value. So to pass in 0FFA, I need to do 4 writes  with 0,F,F,A being written in separately.

When I send data this way, it is read correctly. I'm not sure why? But it works.