Raw hexadecimal string to real number with 2's complement

[VinnyAstro]

Hi!

I have a device giving me its orientation (X Y Z angles) in a hexadecimal string of 20 bytes as followed:

[Start of message] 2bytes

[X DATA (3bytes) | X Status (1bytes)]

[Y DATA (3bytes) | Y Status (1bytes)]

[Z DATA (3bytes) | Z Status (1bytes)]

[other data] 6 Bytes

All attached without spaces, that looks like : AAAAFF67BE02AFE3BD027F60BA02AABBCCDD

I'd like to convert for instance the X data (FF 67 BE 02, 02 being the status - ok/notok) into a real angle value : FF67BE into -38 978° (if conversion LSB/number is 1.)

So far I have done what you see below as an example, but I am not sure that I am not overdoing things a bit.

Especially, I am not sure when I should do the conversion to I32...

If I could have your honest opinion on wether what I'm doing is ok or not, that'd be great, thanks 🙂

 

Vinny.

[altenbach]

Your string has 40bytes and X is not a valid hex character. Please give an example with valid inputs!

There is no 3 byte datatype. What is the datatype of the angle? SGL? DBL? FXP? (FF67BE into -38 978°)

Are you sure you are getting a hex formatted plain string? Typically I would have expected a 20 character binary string. Can you link us to a website or manual that describes the format?

[Darin.K · Accepted solution]

Don't know if you are getting raw hex values or ascii values, either way I would probably not do what you are doing.

 

[crossrulz]

I think this is what you are trying to do.  Notice that I have "Display Style" and "Radix" visible for most of my constants and controls/indicators.  This is because I am showing the values in Hexidecimal.

EDIT: I really like Darin's idea of using the Fixed Point conversion.  That would be much simpler.

[altenbach]

Here's what I would probably do. Note that "scale by power of two" is an arithmetic shift, thus retaining the sign.

(And no, I probably would not cast a 3 byte string to a four byte datatype. Just does not feel right ;))

[altenbach]

And here's how you could expand it to get xyz.

• Take 20byte binary string
• Strip 2byte header (could inspect it for validity)
• unflatten to three I32
• Do a -8 arithmetic shift on the values
• deal with remaining string if needed.

You could even include the header (U16) and footer (U32) as cluster elements in the right order so you don't need to strip.

[altenbach · Accepted solution]

---

@altenbach wrote:

You could even include the header (U16) and footer (U32) as cluster elements in the right order so you don't need to strip.

---

Here's how that would look like:

[VinnyAstro]

Hi,

Thanks for all your quick answers.

• Uuuh No it does have 20Bytes (20 ASCII characters); The string input I give in my example was really just to work on the X data, as the rest will be the same//not relevant for the question 🙂
• I suppose I am getting ascii character and not raw hex data (picture below). That said, I am still extremely confused on something very basic: what would be the differrence exactly? Does Labview make any difference of the data inside this string?
  
  A very quick example to show you what I get when I dumbly trigger the device

I'll integrate Darin's idea tomorrow and see how it is doing, thanks 🙂

EDIT, the picture didn't upload for some reason:

[altenbach]

---

@VinnyAstro wrote:

• I suppose I am getting ascii character and not raw hex data (picture below). n:

---

You are getting a 20byte binary string  (independently on how you choose to display it! The display style does NOT change the data. Hex display is more suitable if you expect non-displayable characters to be part of the string. "Normal display" is useful if you only have printable characters, and you don't).

(ASCII is a not a datatype, just a convention to assign "meaning" to bytes, such as printable or control characters, e.g. which bit pattern should be displayed as the letter Q in normal display)

[altenbach]

Also note that your example string (AAAAFF67BE02AFE3BD027F60BA02AABBCCDD) only has 18 bytes. I assume that you are also counting two termination characters. If you use the 18byte string (i.e. without the termination characters), you can try to use my example, then use "unbundle by name" to get the desired values as needed. (You can expand the cluster to also include a field for the termination characters, etc.)

Unflatten from string even gives you error information, e.g. if the string is too short. (Note that typecast does not provide that luxury!)

Maybe you should configure your serial I/O to use defined termination characters instead of fixed size reads. I am not a "serial" expert, so others might have more specific advice here. (See below instead)