06-09-2020 11:17 AM
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
06-09-2020 12:17 PM
The data in your VI seems to be completely different than what you show in your wireshark capture.
06-09-2020 12:26 PM
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:34 PM
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?
06-10-2020 09:29 AM
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..
06-10-2020 09:53 AM
@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.
06-10-2020 12:15 PM - edited 06-10-2020 12:16 PM
@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.
06-10-2020 01:32 PM
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
06-10-2020 02:03 PM - edited 06-10-2020 02:05 PM
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
06-10-2020 02:07 PM
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.