Converting Binary To String (with out binary representation)

[Makra]

I am trying to convert binary data set that represents Hexadecimal values. I need to be able to convert this binary/hexadecimal string into a regular string so as to be used with the Hexadecimal string to Number.VI . If anyone has an Idea how to do this please advise. Thanks,
Joel

[ian_fung]

somthing like this? (see attached)

If you only need to convert hex/binary to hex string, then, "Type Cast" will do the job.

Cheers,
ian.f
-sg/my

[Makra]

Thank you Ian, this is a nice conversion program, but I am not sure how to interface it with the Binary code. I believe I am a bit new at dealing with data types. The Labview interprets this binary code in its Hex equivalents, which is what I display. It is this that I want to convert into a string.

I am attaching a example of my binary data displayed as hex. If you know how to get this to work with your program, please let me know, thank you greatly.

Joel

[ian_fung]

hi again,
Hope this is what you are looking for.
Let me know should you need more info. You may drop me an email, too.

Cheers
ian.f
sg/my

[Makra]

Thank you Greatly for you help, this allowed me to do what I needed. I was a little unsure about how to use type cast, but this clarified things. Thank you!

Joel

[Olivier Zimmermann]

You seem to be a little confused about encoding and representation of
data. Correctly converting data requires to understand what level of
representation you are working with. Then it will become the easiest
thing...


****
There are basically three level of representation that coexist when
using digital data: the "ideal" data (the abstract data itself), the
bit-level code (for the computer) and the displayed data (for you).

1) You should have a clear idea of what you are manipulating as an
"ideal" data: is it letters in a chain of characters ? is it a yes/no -
on/off - true/false boolean ? is it an integer number ? is it a real
number ?

2) To process the abstract data on a machine, it has been necessary to
choose a code. Bit-level code and pr
ocessing are coherent one to the
other on a given system, so that all you need to care of is which
"abstract" operation you want to do with your "abstract" data. But if
you want to make systems communicate (fortran to labview, unix to dos,
programmable instrument to pc...) you quickly find out it uses another
code/processing mechanism, so you need to understand exactly each code.

3) At last, you may have to eventually let the system communicate the
data to YOU. And according to your sensibility, you may prefer to have
integer numbers displayed or printed as bit fields, as hexadecimal
chains or in any other convention.


If you correctly differentiate and understand those three level of
representation of a data, you shall not be afraid to display in chinese
the unsigned integer numbers stored as octal digits in an ASCII string.
****

Mail me if you just can't &*$!! - oz

Makra wrote:

>I am trying to convert binary data set that represents Hexadecimal
>values. I need to be ab
le to convert this binary/hexadecimal string
>into a regular string so as to be used with the Hexadecimal string to
>Number.VI . If anyone has an Idea how to do this please advise.
>Thanks,
>Joel
>
>

[Makra]

Oliver,

Thank you for "the basics" lesson. I admit I am knew to this. The Abstract data are telemetry and values from a GPS receiver.
The it is the bit-level code that I am having trouble converting into the displayed data, to use your terminology. The device returns binary code (Motorola Binary Format) that I can display easily. The example I attached to ian.f's answer is an example of some of this data. The reason for me seperating it is that It is a long binary sequence which has a given format to it. So I am seperating the sequence and wish to convert each binary value(displayed in its Hex shorthand) into a string of that very Hex shorthand, so I can use the Hexadecimal to Number.VI

If you have any further suggestions, please let me know. Thank
you,
Joel

[Olivier Zimmermann]

Hi,

I quickly went over a few web-pages that deal with "Motorola Binary
Format". From what I understand, this is a digital I/O protocol used
over a serial RS-232 link to let a PC communicate with a Motorola GPS
receiver.

First of all, despite its name, this protocol is just not more binary
than any other digital protocol : all of them code bits ! And like the
huge majority of serial communication protocols, it sends the
information as a stream of ASCII bytes. This is the bit-level code.
Knowing this, the only thing you need to do for a perfect control of
these data, is write a "parser" that will recognize ASCII bytes paterns
and convert them to a data type that will fit your use.

You must use a function to read the ASCII bytes-stream from the GPS.
What is that function output type ? Is it a table of unsigned bytes ?


What you could do is send me a VI with a control on it representing a
piece of data read from your "GPS serial acquisition" function, and one
or more indicators, which represent the various values you would like to
extract from the raw data.
Fill both the control and the various indicators with the values they
should show when the stream is parsed correctly, and make these values
the default values.

I will send it back with code.

Maybe this can help - oz

By the way do you speak french ?...


Makra wrote:

> Oliver,
>
> Thank you for "the basics" lesson. I admit I am knew to this. The
> Abstract data are telemetry and values from a GPS receiver.
> The it is the bit-level code that I am having trouble converting into
> the displayed data, to use your terminology. The device returns
> binary code (Motorola Binary Format) that I can display easily. The
> example I attached to ian.f's answer is an example of some of this
> data. The reason for me seperating it is that It is a long binary
> sequence which has a given format to it. So I am seperating the
> sequence and wish to convert each binary value(displayed in its Hex
> shorthand) into a string of that very Hex shorthand, so I can use the
> Hexadecimal to Number.VI
>
> If you have any further suggestions, please let me know. Thank you,
> Joel
>
>