string to number conversion- a very interesting observation

[Mark H]

The bytes do not represent numeric ASCII characters (0,1,2....9,A,B,....F) so you cannot use the string to number conversion VIs.

There is no way that we can tell how to interpret your binary data without a proper description of what each byte represents - it would be futile to even guess.

Again - surely you must have a manual for the device you are workiing with? If not, I would suggest contacting the manufacturer/supplier.

I'm not sure it helps at all, but I've attached a short program with which you can load the data file into LabVIEW and display each byte element in different formats (string,hex,decimal,binary).

Mark.

[innovator81]

hello there,

Thanx for replying..well yes I am trying to change the data from binary to decimal format..

1>GPS system being used is SUPERSTAR-2 from Novatel
2>It is just a base unit being used right now.(not the differential set-up)
3>The baud rate settings(9600) and parity settings are all right as I have checked them with the manufacturer
4>The data that comes through the serial port is the binary data whose format I have posted already as a text file ...the range is 0-85 bytes at a time.
5>I need the data form 15-50 bytes (i.e the position and velocity data)

Right now the labview program goal is to convert this into decimal format using the given VIs.

[DavidJCrawford]

It sound like you have half an idea of whats in the binary data.

Do you have a protocol document that defines the information found in the binary data stream? If you do have that then please attach it if not too big.

[Mark H]

Firstly, your text file only appears to contain 38 bytes - this does not quite match up with your mention of bytes 0-85 (86 bytes) or bytes 15-50 (36 bytes).

You are still not telling us exactly how to interpet the bytes. I don't understand how you expect us to know about the data format of this "Superstar-2" device - unless someone else is very familiar with this particular device, or there is some cryptographic genius amongst us, then I don't think you aren't going to get any further here.

At this point I think I am going to bow out.

[innovator81]

well yes I have the protocol information and I am familiar with the range of bytes required..in fact I had already parsed the data into the required bytes but that was the hexadecimal string.which is the superficial data(as mentioned by 1 of u in the earlier queries)...as I said earlier I only need to know the conversion tool required to convert this binary data into decimal format(eg--6123021.09)..so can u guyz convert the 36 byte data into numerical format..if yes please le me know what conversion tool u used....

[Dennis_Knutson]

If you want someone to tell you how to do the conversion, post the details on the protocol. This has been requested several times. There is no single "binary" format so the protocol information has to be provided in order for the conversion to make sense.

If you want to do it yourself, use the typecast function. Feed a string into the input. Wire a numeric constant to the type input. Pick a data type (i.e. U8) for this constant. See what comes out. If it makes sense, you are done. If it doesn't, try another data type. You've got a lot of data types that may or may not work. Do you understand now why providing the protocol is important?

[Mark H]

For ther last time......

There is no standard function that you can just pass 36 bytes to and generate a decimal number.

Computers usually store floating point numbers in 4 bytes (single precision), 8 bytes (double precision) and 16 bytes extended precision, or 1,2,4 or 8 byte integers - none of these binary formats is 36 bytes long.

Even if your 36 bytes represented several numbers, 36 does not appear to be an exact multiple of 8, or 16, etc.

Message Edited by Mark H on 02-17-2006 03:32 PM

[Mark H]

Hi Dennis,

Just thought to mention - "protocol" is a term I would normally associate with comunication IO.

Data storage format, or representation, might be a better term, to avoid confusion?

Mark.

[Dennis_Knutson]

You're correct. I echoed back his comment on having protocol information and shouldn't have. l think the original poster  is much too confused already.

[innovator81]

this is the binary protocol file....