Two ASCII characters into decimal value

[altenbach]

---

@josborne wrote:

I am wondering if your technique could save me some time.

---

Of course it would!

Sorry, I no longer have access to LabVIEW 7.0, so I can only give you a picture. Bascially, you would create a cluster diagram constant of 13 bytes containing the correctly named fields in the correct order and representation. Put it into an array container.

Now typecast the raw string to this array and you get an array of clusters containing all your numbers. No joining needed. Now use an autoindexing FOR loop and manipulate the values.

Here is code that does exactly the same as your code! I do not know the other fields so I just used some padding values to make sure the fields add up to the correct number of bytes. Makes sense? Try it! (I am not sure if your data is signed or unsigned, so adjust the datatypes accordingly)

No spitting strings, no joining bytes, etc.! 😄

Now, why do you get stairsteps? I haven't had time to study your data, but most likely your not scaling something right. Do you have a link to the original document the describes the data structure in detail?

[josborne]

Thanks, altenbach.

I wish I had learned that technique 3 weeks ago.  Could saved me a lot of time.  🙂

[PawelG]

Wow! this is really great! It's so much easier way do get data from string.

Single pages from documentation to radar are available here: https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B8dlp0EyY6VPMTQzYTY0NTYtMzJiMC00N...

On page 53 there is description of one complete protocol but it's really poor.

[PawelG]

Any ideas how to get right distance values?

[RavensFan]

Doesn't Altenbach's code work for you?

If you give a typical data string and what you expect the numbers to be, then it would be easier to help.  Only you really know if a number is right or wrong since it is your application.

[altenbach]

---

@Ravens Fan wrote:

Doesn't Altenbach's code work for you?

---

My code exactly duplicates his code and he gets stairsteps in the second graph. Most likely one of the scaling constants if off, but I haven't had time to look into it.

[PawelG]

Altenbach really helped me, but still values of distance are incorrect. Distance from bits responsible for meter counter varies from 0m to 1000m. Distance from bits responsible for kilometer counter have increment of 0,1km. I tried to add them in many different ways but still something goes wrong. Here is sample graph with values from both distance counters added. Amplitude is meters.

[PawelG]

---

@altenbach wrote:

My code exactly duplicates his code and he gets stairsteps in the second graph. Most likely one of the scaling constants if off, but I haven't had time to look into it.

---

Exactly,

I think that something is incorrect in manual. I tried to set those constants on many different values and still distance curve doesn't look as it should

[altenbach]

I think the two distance scales are not aligned with repect to each other, but independent measures of the same thing, just with different resolution and different initial offset.

Since they are an incrementing counter, we can "unwrap" the fine scale, adding 1000 whenever there is a large negative step.

As you can see they now both show the same curve, one just with higher resolution. Modify as needed.

[altenbach]

If we remove the random initial offset and scale both to meters and graph them on a shared x and y axis, it is clear what is happening. Here's a modification that shows this.

Note that the graph is zoomed inteo the end of the data.