Converting Hexadecimal Data to a Physical Representation

[CoffeeCakess]

Hello All,

This is my first attempt in trying to convert hexadecimal data to anything, so I may be missing something obvious.  

Essentially I have an accelerometer which outputs serial data (which I am using VISA to capture).  I don't seem to have any issues in capturing the data but more so handeling it properly so I get the intended output.  I have attached an image showing the expected data packet from the accelerometer and a VI showing how I am attempting to handle the data (which just handles a single data packet).  The numbers don't make sense relative to what the accelerometer is experincing.  I have also noticed regardless of the number, the way I am calculating the values cannot account for negative numbers.  Considering this, I do not think I am properly executing the logical left shift and the bitwise OR operation.

Any help or suggestions would be appreciated.

Thank You,

Tyler

[altenbach]

Your documentation describes 11 bytes, your VI has a string of 32 bytes. (containing letters, numbers and spaces)

Can you attach a VI that contains an actual string received from the instrument instead? Just capture it in an indicator, then right-click the indicator terminal and "create constant". Copy that constant to your VI and attach it again. Lost of your code makes no sense at all. Shifting a U8 by 8 will leave you nothing. Why is there a FOR loop? A series of divisions and multiplications can be replaced by a single multiplication.

[RavensFan]

You have a problem in that you defined all of those as U8 integers.  So when you go and do an 8 bit shift on the high bytes, you wind up shifting out all the bits and filling it with zeroes.

If you used an I16 integer as the constant in your current code, you'll get better results.

If it was me, I'd used Join Numbers and typecast them to an I16.  Join numbers does the work that the 8 bit shift and OR are doing all in a single node.

I'd recommend encapsulating that math in a small subVI since it is repeated a number of times.

EDIT:   Altenbach is correct that your documenation is based on 11 bytes, and not a string of ASCII hex digits, 0-9,A-F plus spaces.

The point about shifting a U8 still applies.  Whether you are dealing with a human readable string, or a string of 11 bytes of raw binary data, only affects the first part of the code.

[cbutcher]

Hi Coffee,

Could you give the accelerometer manual/datasheet, or failing that a link to the part/manufacturer link/store page etc?

I don't see how you'd get the negative values with the image you've supplied, but one thing to note is that you're probably expecting/ed to use the AxH and AxL to get the high and low bytes of a 16 bit number. The bit shift you're carrying out is only outputting an 8 bit value, which when you take the OR is not giving the behaviour you'd expect.

Try using Join Numbers instead.

It may then be that you need to interpret this as an I16, rather than a U16. You can use the To I16 node for this - but check carefully the behaviour vs what you expect. In your case, I get -78 as the value, which then translates to -0.373242 ms^-2. Is that what you wanted?

Modified with Join Numbers and To I16, for the X Accel output.

[CoffeeCakess]

Thank you all for the help and feedback.  I have already learned alot on how I can clean up my code.  Again I apologize as I am very new to dealing with serial data so I imagine I am making some very fundamental mistakes.

I have attached a constant with data directly from the serial read in normal and hex view as well as the data sheet for the accelerometer.

[RavensFan]

Based on that you are getting binary data, try this.  This uses an unflatten from string to convert the packet of 11 bytes to a defined cluster.

The key points are setting the parameters in the cluster to have the right data types, and using unflatten from string since it lets you define the byte order and that you don't have any size information for the cluster embedded in the data.

[cbutcher]

The datasheet confirms that an I16 is the expected data type (signed short) so that should work out better for you!

[altenbach]

In the meantime, I go the same as Ravens, starting with the formatted string, converting it to the binary string, and unflattening the same way. 🙂 (You guys are fast for a Saturday morning 😄 )

In the real code, you would delete the left part and convert the "raw string" into a control and do a few minor tweaks. 😄 You might even want to verify the value of the first two bytes (not shown).

[altenbach]

---

@altenbach wrote:

You might even want to verify the value of the first two bytes (not shown).

---

Here's how that could look like.