Different results when unflattening string to single point precision or double point precision

[marlonpodd]

Hello,

I want to unflatten an 8-character string to a double, but when I do I get a very large or small number. When I unflatten the same string to the single point precision number, I get the actual value I expected. The only thing I changed is the type that goes into the Unflatten From String VI, and I'm unsure how to get a correct double value with high precision. I have images attached below.

Thanks,

Marlon

[Martin_Henz]

Pictures are pictures are pictures and useless pictures.

I'm willing to help, but I'm never look at pictures when it comes to LabVIEW code. Post a real labview VI and don't forget do convert it down to an earlier labview version.

Your problem sounds like a typical big/little endian problem. If you don't know which conversion is correct, then try conversion with big endian and little endian - one of them should work.

[rolfk]

Where did you get those 8 bytes from? You can unflatten all kind of data to all kind of other data, but without knowing where it comes from, who created it and what it originally meant, any unflattening is purely speculative.

[rolfk]

---

@Martin_Henz wrote:

Your problem sounds like a typical big/little endian problem. If you don't know which conversion is correct, then try conversion with big endian and little endian - one of them should work.

---

It might, but the bit patterns looks very suspicious, like made up. Real floating point numbers seldom give such symmetric byte patterns. But if I use Big Endian it would result in 2,26163E+6, which might or might not be a reasonable value.

[marlonpodd]

---

@Martin_Henz wrote:

Pictures are pictures are pictures and useless pictures.

I'm willing to help, but I'm never look at pictures when it comes to LabVIEW code. Post a real labview VI and don't forget do convert it down to an earlier labview version.

Your problem sounds like a typical big/little endian problem. If you don't know which conversion is correct, then try conversion with big endian and little endian - one of them should work.

---

Sorry I should have sent the VI I'm working with, the screenshots I sent were from a test VI just to figure out why I'm getting varying values.

I tried changing the endianness for the Unflatten From String VI but still did not get the correct conversion to a double value.

Essentially, in another VI I'm receiving floating point values from XPlane over UDP and I need to unflatten the output string in order to get doubles that I can actually use.

[marlonpodd]

---

@rolfk wrote:

Where did you get those 8 bytes from? You can unflatten all kind of data to all kind of other data, but without knowing where it comes from, who created it and what it originally meant, any unflattening is purely speculative.

---

Mentioned in another comment, but I want to receive aircraft parameters from XPlane over UDP in Labview, and to get those values as useable doubles I need to unflatten the output string from XPlane. Doubles are important since some parameters like longitude and latitude require many digits of precision to be effective.

[marlonpodd]

---

@rolfk wrote:

---

@Martin_Henz wrote:

Your problem sounds like a typical big/little endian problem. If you don't know which conversion is correct, then try conversion with big endian and little endian - one of them should work.

---

It might, but the bit patterns looks very suspicious, like made up. Real floating point numbers seldom give such symmetric byte patterns. But if I use Big Endian it would result in 2,26163E+6, which might or might not be a reasonable value.

---

You're correct, that bit pattern of AAAA is made up for testing purposes, but as mentioned in my other comments XPlane outputs a flattened string and I want to convert that to a double value. For example, the string ß‘ŒB     (8 characters) which represents airspeed in knots should equal about 70.2849, but if I convert it to a double it reads as 4.485E-308.

[rolfk]

---

@marlonpodd wrote:

---

---

You're correct, that bit pattern of AAAA is made up for testing purposes, but as mentioned in my other comments XPlane outputs a flattened string and I want to convert that to a double value. For example, the string ß‘ŒB     (8 characters) which represents airspeed in knots should equal about 70.2849, but if I convert it to a double it reads as 4.485E-308.

---

It's pretty useless to represent binary data in text. It all depends on the encoding what "strange" characters you will see (and some characters are unprintable). Much better is to show the actual binary values in Hex form, such as 0x34456788.

Also your VI shows what you think you have to do to convert the data, but unfortunately misses any example data string at all. Resave it with representative data in the control and after having right clicked on the control and selecting "Make current data default". And tell us what you think that data should represent.

[altenbach]

---

@marlonpodd wrote:

---

@Martin_Henz wrote:

Pictures are pictures are pictures and useless pictures.

I'm willing to help, but I'm never look at pictures when it comes to LabVIEW code. Post a real labview VI and don't forget do convert it down to an earlier labview version.

• Your problem sounds like a typical big/little endian problem. If you don't know which conversion is correct, then try conversion with big endian and little endian - one of them should work.
•  
•  

---

Sorry I should have sent the VI I'm working with, the screenshots I sent were from a test VI just to figure out why I'm getting varying values..

---

This is just plain silly!

If you attach an example, make sure the input string has typical data so we have something to play with.

It is very unlikely that the eight byte that represent the DBL value always end in x20 (space character).

Please:

- reattach the VI after the input string contains a typical received string as default.

- tell us what kind of values you expect.

- if unflattening to SGL gives the correct result, maybe they are!

[Yamaeda]

12.07 as double type cast to a string is "@($" (4028 2404 0000 0000) (or as \s "@($\04\00\00\00\00")

You can't just change "AAAA    " to "AA  " and expect the same result, the bit patterns between SGL and DBL differs more than that.

Double-precision floating-point format - Wikipedia