Raw hexadecimal string to real number with 2's complement

[crossrulz]

---

@altenbach wrote:

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.

---

Not when the data is hex/raw/binary.  The termination character can easily be found in the data.  But there is typically a set protocol for the messages.  So follow the protocol.  In this case, you can read 1 byte at a time until you find the first start byte, then read another byte and verify it matches the second byte.  From there, read the rest of the 18 bytes in the message.

For more details: VIWeek 2020/Proper way to communicate over serial

[VinnyAstro]

Thanks a lot Altenbach, that's really helpful and informative.

So as far as I understood of the documentation for now, there is no end character as the device is in trigger mode:

You send anything (in my example I just send "1" as a string and the device answer with those 20bytes. 

In my example I just happened to miss one 😄

It's an interesting idea to get this error handling possibility, but then it shouldn't appear.

However, while it is not meant to work at high speed (technically a trigger every half a second or even every seconds should be enough) I did notice that if I trigger it too fast (20ms or so), it tends to sometimes send more than 20 bytes. I haven't investigated it yet, but my guess is that one message didn't have the time to get created by the device, the answer was then empty ans so the next message is then the answer of the previous trigger + the new one.

When I noticed this, I was reading one byte at a time in a while loop and exiting on timeout.

[VinnyAstro]

After coming back to it, here is what I believe would be a good working solution for me.

As I still need to analyse the status of each axis (1byte for each), I came up with the idea of simply "shrinking" the i32 into a U8 to get only the LSB.

I "just" need to analyze those status bytes now.

Thanks again, have a great day and weekend.

[altenbach]

---

@VinnyAstro wrote:

After coming back to it, here is what I believe would be a good working solution for me.

.

---

Have you even tried that? This will not work because the fields in the string don't correspond to the cluster order.

To look at the LSB, simply AND with 255 and convert to U8. Wrap the entire thing into a subVI that receives the string and outputs the scaled values and an error status.

[VinnyAstro]

---

@altenbach  a écrit : Have you even tried that? This will not work because the fields in the string don't correspond to the cluster order.

To look at the LSB, simply AND with 255 and convert to U8. Wrap the entire thing into a subVI that receives the string and outputs the scaled values and an error status.

---

I did, and I was getting the expected results. here is a try with an example frame easily identifiable

The fields in the string are:

Identifier (2B) | X data (4B - MSB:DATA1 | DATA2 | DATA3 | LSB:Status) | Y Data (4B) | Z data (4B) | Gyro Status (2B) | Counter (2B) | CRC (2B)
 0000 | AA|AA|AA|11 | BBBB BB22 | CCCC CC33 | DDDD | EEEE | FFFF

Now I don't really need the identifier in my setup (only one device) thus reading only from the 3byte on.

So it should be fine that way no? But I've tried as well with the AND with 255, it gives me the same results 🙂

 conversion

EDIT: I forgot that in between I also inserted a U8 conversion as I don't like leaving the automatic conversion to labview 🙂

[altenbach]

A picture of the front panel is not helpful. Attach your latest Vi containing useful default data in all controls).

I did not notice that you now remove the first two bytes from the string first instead of parsing them. Shouldn't they be part of the data structure?

[VinnyAstro]

---

@altenbach  a écrit :

I did not notice that you now remove the first two bytes from the string first instead of parsing them. Shouldn't they be part of the data structure?

---

Not really, at least for now. The identifier is just if I'm communicating with multiple devices, which for now isn't the case. I am just running a few tests to see if it is performant enough.... and also to prepare/train for a bigger code.

Here is my VI. I still need to process the Status values. I'm reading a log file 20B by 20B for now, so my input is an array of 20B string. I've run a 10min test with a 1s triggertime (1 measurement every seconds.)

[billko]

---

@VinnyAstro wrote:

---

@altenbach  a écrit :

I did not notice that you now remove the first two bytes from the string first instead of parsing them. Shouldn't they be part of the data structure?

---

Not really, at least for now. The identifier is just if I'm communicating with multiple devices, which for now isn't the case. I am just running a few tests to see if it is performant enough.... and also to prepare/train for a bigger code.

Here is my VI. I still need to process the Status values. I'm reading a log file 20B by 20B for now, so my input is an array of 20B string. I've run a 10min test with a 1s triggertime (1 measurement every seconds.)

---

This is a decidedly anti-scalable, anti-maintainable path you are going down here.  Better to decode it correctly and not do anything with a few fields now, than try to add them in later.  Especially if you are "preparing/training for a bigger code".

[altenbach]

I agree that your data structures are not very intuitive, but it really depends on how they are used later.

Note that placing your error indicator inside a fast  loop will make you miss most errors. For example you string at index 32 will give you an error (It's too short!), but you'll never know about it in the current code!

[VinnyAstro]

Ah yes I'm aware that this is definitely not the most scalabale way to deal with it, especially I will still need to deal with all status and errors.

But it was a perf test on this device to see if we're going with it or not, and then I got intrigued into understanding and learning this whole 2's complement thingy.

The FOR loop will not even exist if we go for it, I was given some log files acquired by a terminal software and had to analyze them 🙂

Thanks again for all the help and advices, really appreciate it.