Use of Typecast in Receiving Bluetooth Data

[baseball07]

Hi everyone, I am trying to establish communication between a Bluetooth transmitter (Server) and a Bluetooth receiver (client) located in a PDA, and display the result on the PDA.  I have already setup the PDA and am able to delpoy applications to it from LabVIEW, and successfully establish pairing between the transmitter (via server address of the transmitter) and reveiver inside the Bluetooth.  The only thing remaining is to capture the data on the receiving end.  The Bluetooth transmitter is sending the datain the folllowing way:

Header of FFFF followed by the actual 8-bit data, then a 1 second delay.  Then repeat.

I am looking at the Bluetooth Client example given in the LabVIEW examples folder  My main question is what exactly the use of the Typecast function is in this specific program (specifically what the interger "4" wired to type is used for).  I have a slight understanding of it, that it is used to convert between data types.  I am failing to see what it is used for in this application. 

My understanding is that the incoming data is binary, so I wrote a vi to look for the FFFF string, then capture the string after the FFFF header and extract that value.  I will then need to convert it to decimal which I know how to do, then display that value.  I will of course have to integrate it into the Bluetooth vi so the incoming string is real time   Would something like this work, or do I have to use the typecast function?

Any suggestions on my methodology and the use of typecast in this application would greatly be appricated.  Thank you.

[nathand]

The value "4" isn't important in that example for the Type Cast; the important part for the Type Cast function is the data type - it is a 32-bit signed integer value.  The 4 is important in that it reads 4 bytes(32-bits).  The output of Bluetooth Read is a string, and Type Cast converts that string to a 32-bit integer.  A string with length 4 is, of course, 4 bytes, so it can be easily converted to a 4-byte (32-bit) numeric value.  That integer is then used as the length input for the next Bluetooth Read, indicating how much data follows.  The typecast that follows that converts the string from the Bluetooth connection into an array of double-precision values.

I'm not sure what you mean by "the incoming stream is binary."  Of course it is - all data on a computer is binary.  That said, it's a string because that's an easy way to represent an arbitrary number of bytes in LabVIEW.  That string probably does not contain displayable ASCII text.  I can't understand what your "Logic Test.vi" is supposed to do.  You'll probably find typecast to be the easiest way to convert the data you read into usable numeric values.  Since it sounds like your protocol doesn't ever send you a length byte, you'll just need to try to read some excessively large number of bytes with a 1-second timeout.  If the format of your data allows it, you could typecast that to an array of I32 (or U32) and then use Search 1D Array to look for FFFF.

[baseball07]

Thank you for the suggestions, I am testing my program on my computer with the Bluetooth transmitter, Bluetooth dongle, and the LabVIEW program and I am seeing exactly what typecast is doing, however I have issues understanding the role of the 2nd "Bluetooth read".  Currently, I have my Bluetooth transmitter broadcasting "FF FF 22 33" then delaying 1 second before repeating, and I am able to read this through my LabVIEW program, so I know that the connection is ok.  After the first Bluetooth read, the data out shows what it should, it is two y's with the dots over them and " 3, and goes through the first typecast and displays the decimal value.  After this, it goes to a 2nd Bluetooth read which I am getting an error in.  I do not understand the function of this part and I cannot figure out what the error is.  There is a large decimal going into the "bytes to read pin".  Couldn't I just display the decimal after the first typecast?  Or send it to the 2nd typecast for plotting?  Thank you for your time.

[nathand]

The example code is set up for a protocol completely different than what you are doing, so you can't simply copy it and hope it works.  The example code expects that the other side will send a 4-byte header containing the number of data bytes that follow, then send the data.  The example code first reads that 4-byte header, casts it to an integer, and reads that number of bytes (the second Bluetooth Read).

When you run this with your device, the first read gets your 4 bytes - FF FF 22 33 - and converts that to an integer.  0xFFFF2233 is decimal 4294910515.  So you then try to read this huge number of bytes and you get an error - looks like error 1, an input parameter is invalid, because you can't read 4GB at once.  You can probably get your code working with a single Bluetooth Read, with a 1 second timeout (because you have a 1 second delay between packets).  You'll want to wire in some number of bytes to read that is at least the size of the largest packet you ever expect, but don't use a ridiculously huge number that generates an error.  LabVIEW will return as many bytes as are available when the timeout expires, even if it isn't as many as you asked to read (you might also get a timeout error, though, which you'll need to clear).  You can then do whatever you need to do with that data - search for FF FF, typecast anything after that to array of U16, display it. 

The output of the Bluetooth Read is a string, but it's not text - it's exactly the bytes that were sent.  The Y with the dots over it is the way ASCII 255 (0xFF) displays (at least in that font).  ASCII 34 (0x22) is ", and ASCII 51 (0x33) is the number 3.

[baseball07]

Thanks for all the feedback, I was able to get everything working great.