Hexadecimal Reading does not match the reading of RealTerm Serial Capture

[SERDARSOYLU]

Hi 

I am reading the output of a serial device that spits out hexadecimal  characters. When I read its serial output with the VISA read block (using a string display with HexDisplay option on) I am getting hexadecimal characters. However, when I read the output of the device with a serial data capture program, such as RealTerm, the  captured data does not match with the ones that I read in my string display in LabVIEW. I know for sure that RealTerm spits out the correct hexadecomal characters since these characters are the same as the ones I am expecting. ( I am actually looking for  some specific header characters that I don't seem to get when I read with LabVIEW).

Is there anyone out there who has an idea what the problem could be?

Thank you very much.

Serdar 

[RavensFan]

Can you post some examples of the wrong data you are getting vs. the right data you are expecting?

Perhaps your LabVIEW VI and a corresponding screen shot of what shows up in RealTerm?

[SERDARSOYLU]

Hi;

Attached is the screenshot of RealTerm and the LabVIEW output. The hexadecimal character that I am  specifically looking for is 0X777F ( This indicates the beginning of the data whose format is 0x7FFF, 0x71DF, 0x0010, 0xFFF0, 0x0022, 0xFFA0, 0x0050, 0x0CCB, 0x0, 0x0, 0x0145). In the realterm screen shot, we can see  the characters 0XFF7F and the next 10 16-bits data words. Do you have any idea where I am making a mistake?

By the way, another question: I think 0XFF7F  reads as 777F.  is there any command that I can use in LabVIEW that allows me to read these as 777F right off the bat? 

Thank you very much for the response.

Serdar 

[Matthew_Kelton]

Why do you have your baud rate set to 11520 and not 115200 in LabVIEW?

[SERDARSOYLU]

It is embarrassing to admit that  it was the mistake:)) It solved the problem. Apparently, I send the baud rate wrong. By the way, as you can see, the data word 0xFFF7 is actually 0x7FFF. How can I read this value as 0X7FFF? Currently, I am swapping the string to do that but I am sure there is a better method to do this.. I think this has something to do with little-endian thing?  

Thank you so much!

Serdar 

[SERDARSOYLU]

This is the VI that I use to swap the string.

Thank you!

Serdar 

[RavensFan]

Serial data is just a string of bytes.  They'll look like 00 through FF or as their ASCII equivalent character depending on how you have your string display setup.

If you are getting 7FFF vs. FF7F, then it must be something else you are doing to the bytes after you receive them to turn a pair of bytes into something else such as a U16 or I16.  This doesn't show up in your screen shots  (Or are you using 4 bytes at a time to get a U32 or I32).  It all comes down to endianism.  If your device is sending pairs or 4bytes at a time that represent a piece of data and sends them in a different endian order then what your conversion code is using to convert two bytes into a U16 or I16, or 4 bytes into a U32 or I32.

Look in the Numeric >>  Data Manipulation palette for different functions to handle this such as swap bytes and swap words.  Also the Unflatten from String has an input that allows you to set the endianism of the data bytes.

[SERDARSOYLU]

Thank you for your answer!

Actually my serial device spits out  bytes that are little-endian(the least significant byte is output before the most significant byte). According to this, for instance, the data word comes in as 0x5249 and is read as 0x4952. Currently, I am doing this with my own swap function (attached to my previous post). I am wondering if there si nay better way of doing this using the data conversion blocks? By the way, my datat acquisition block is very simple as you can see in the attached file. 

Thank you so much.

Serdar 

[SERDARSOYLU]

here is the picture

[Matthew_Kelton]

If you are converting this string to a number, you can convert the 4 bytes to a number as they come in.  Then use Swap Bytes (under Numbers->Data Manipulation, or use Search). and the number will be correct.

If you want to leave it as a string, it may still be faster to do the above then convert it back into a string.