Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Highlighted

06-09-2020 11:17 AM

Options

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Hi

I'm using udp to transmit data and then observing the traffic with wireshark to make sure the message is transmitted correctly.

I have a cluster of data comprising different numeric data types which I flatten to string before transmission. The issue I'm having is that

the data shows up in the wrong field. The fixed point data field shows all zeros while the actual value appears in the u32 data field.

I've attached a screenshot of a sample message cluster and the wireshark screenshot. Any ideas what could be going here?

Thanks

Highlighted
Options

06-09-2020 12:17 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

The data in your VI seems to be completely different than what you show in your wireshark capture.

Highlighted
Options
Sorry about that I was trying different things. You can replace the VI inputs with wireshark data. I will try to post more detailed data with another VI.

06-09-2020 12:26 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Highlighted
Options

** LabVIEW Champion. It all comes together in GCentral **

**What does "Engineering Redefined" mean??**

06-09-2020 12:34 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

A better test would be to look at the received string at the other end. flattened FXP data is always 8 bytes as you data string already shows. (Not sure why you are using FXP for a 15bit integer.).

It is useless for us to look at a highly truncated image of a wireshark capture. Is this the payload field? What were the cluster values for this particular capture?

Highlighted
Options

06-10-2020 09:29 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Hi Altenbach,

Yes, the wireshark image is in the payload field. I was able to partially fix the problem and I could see the correct data in the first fixed point data field. I had to configure the fixed point control for 32 bit word length and 15bit integer length and then use the Fixed point to integer cast function to convert to unsigned integer before flattening to string. I repeated this process for the other fixed point data and configured the word length and integer lengths for the each specific fixed point control. The problem now is that the wireshark data does not match the input of the cluster for the other fixed point data except for the first one. I've attached a sample vi and the wireshark screenshot. Any suggestions are welcome. Thanks..

Highlighted
Options

There are only two ways to tell somebody thanks: Kudos and Marked Solutions

Unofficial Forum Rules and Guidelines

06-10-2020 09:53 AM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

@SolPS wrote:

The problem now is that the wireshark data does not match the input of the cluster for the other fixed point data except for the first one.

Looking at the hex values, only the first Fixed Point value is wrong.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions

Unofficial Forum Rules and Guidelines

Highlighted
Options

** LabVIEW Champion. It all comes together in GCentral **

**What does "Engineering Redefined" mean??**

06-10-2020 12:15 PM - edited 06-10-2020 12:16 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

@SolPS wrote:Yes, the wireshark image is in the payload field. I was able to partially fix the problem and I could see the correct data in the first fixed point data field. I had to configure the fixed point control for 32 bit word length and 15bit integer length and then use the Fixed point to integer cast function to convert to unsigned integer before flattening to string. I repeated this process for the other fixed point data and configured the word length and integer lengths for the each specific fixed point control. The problem now is that the wireshark data does not match the input of the cluster for the other fixed point data except for the first one. I've attached a sample vi and the wireshark screenshot. Any suggestions are welcome. Thanks..

__None__ of your FXP numbers have a 15 bit integer length. (Some are unsigned 17:32, i.e. 15 bit fractional length), some are (signed 0:32, i.e. zero integer length)

You are really not making a lot of sense. First, can you configure wireshark to only show the raw hex data instead of trying to interpret it according to some rules. (Are you using any well known port so wireshark interprets it in terms of a certain packet communication format? That only confuses!)

Then also set your string to hex format in the VI and compare the two.

What is the reason for your fxp cast function? Unless you know what it did in terms of shifting, it's irreversible.

The smallest unit is a byte, so "15bits" needs to be padded to an integer multiple of 8bits, of course.

Highlighted
Options

06-10-2020 01:32 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

Hi Altenbach,

Sorry about the confusion. I think I need to understand whether or not my approach is correct in the first place so I will start at the beginning. Perhaps, I might have gone down the wrong path.

I'm trying to work from a spec sheet that looks something like this:

Data Bit ct Data type Range

data1 32 Unsigned Integer

data2 32 Unsigned scaled Integer 0-32767

data3 32 Unsigned Integer

data4 32 Unsigned scaled Integer 0-80000

data5 32 Signed scaled Integer -0.5 to +0.5

The 3 unsigned scaled integers I interpreted as having to be implemented as a fixed point data. I may be wrong but that was my understanding as the values must be strictly within the specified range so I decided to use fixed point representation for those. The reason for the different integer lengths was that I was configuring each fixed point control to match or be as close to enough to the specified range.

I only tried the fxp cast function to see if I could get the same data input. The wireshark data was different from my input so that was why I used it.

Is my approach wrong here? What is the best path forward? Thanks in advance

Highlighted
Options

06-10-2020 02:03 PM - edited 06-10-2020 02:05 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

I don't know the right way to interpret the info you presented from the spec sheet. Let's consider data4 as an example. It's called an unsigned scaled integer, it has 32 bits, and is said to have a Range of 0-80000.

That might mean that the device will only ever report values from 0-80000 (which never uses more than 17 of the 32 bits).

It also might be that you're supposed to scale the integer you get to map it from all 32-bits worth of values to the restricted range 0-80000. So you'd take the value you get an multiply it by 80000/U32Max, where U32Max is the maximum possible unsigned integer you can express with 32 bits = 2^32 - 1.

The signed integer with the -0.5 to +0.5 range seems more likely to fit the latter option.

I think fixed point would be pretty unlikely unless there was also a lot more info about what to do with it.

-Kevin P

Highlighted
Options

06-10-2020 02:07 PM

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report to a Moderator

You have 4 U32's and 1 I32. Don't make up a fixed point data type to "force" a range. You are causing the bits to be interpreted differently.

What is the source of the data? For the 4 U32's, all of the data can fit in the range of the datatype. If you want to prevent the values from being outside a tighter range, then you enforce that at the source. If it is coming from a control, you can set data range limits on the control. If it is coming from somewhere else, then you can programmatically enforce the limits, (e.g. In Range and Coerce), but also decide how to handle a value that comes in that is outside of that range.

For your last value, you say it is a signed 32 bit integer, but a range of -0.5 to +0.5. That makes no sense. That would require a floating point value. Though it is possible that you can use and integer if you scale the value by 10 or 100 or something. So -0.5 would show up as -500. +0.42 would show up as +420. But that kind of scaling is something both ends need to agree upon.

I would double check your instruction manuals again, particular for that last element.