LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Packet data appearing in wrong field after flattening cluster to string

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

0 Kudos
Message 1 of 15
(2,393 Views)

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

0 Kudos
Message 2 of 15
(2,362 Views)

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.

0 Kudos
Message 3 of 15
(2,354 Views)

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?

0 Kudos
Message 4 of 15
(2,350 Views)

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..

0 Kudos
Message 5 of 15
(2,290 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 15
(2,286 Views)

@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.

 

altenbach_0-1591808777218.png

 

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

0 Kudos
Message 7 of 15
(2,273 Views)

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

 

 

0 Kudos
Message 8 of 15
(2,258 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 9 of 15
(2,253 Views)

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.

0 Kudos
Message 10 of 15
(2,249 Views)