LabVIEW
UDP Parse
Solved!
Hi Folks
Looking to parse out some telemetry data from a UDP stream. I have the UDP packet (1237 in size) and i have a list of the struct that the UDP packet should be but falling short at the parsing end, can get numerics out but they dont make sense numerically (i.e. i know the index the gear should be but it's something stupid like 2.3E+6).
I have a cluster that i believe accounts for everything in the struct (i could be wrong & i am not sure about the entry CarUDPData m_car_data[20], i think this should be an array of clusters but this causes issues with the typecast).
Any thoughts would be much appreciated. Attached the VI (LV2017) with a sample of the data incoming which is currently set to display as hex. Also included the UDP packet struct which i am trying to get to on the right hand side of the BD. Again, i could have got the cluster wrong but a fresh pair of eyes is welcome!
Cheers
Jono
Have you tried unflatten from string using "little-endian"? (typecast is always big endian)
(It is really difficult to tell what the numbers should be. None of your cluster elements have names, for example. It would be orders of magnitude easier if you would give the element useful names! Also, the indicator is way too big for my screen to efficiently inspect the values.).
Hi Jono,
I used UnflattenFromString to read the first floats (=SGL!) and got reasonable values…
(Next time you should also state which values you do expect from this input data!)
Gerd & Altenbach
Firstly, thanks for the replies!
I had previously tried flatten to array of doubles by big endian network order which didn't work out so I saw a few threads talking about casting to cluster so i threw together a quick and dirty cluster (hence no names etc) to see if that'd get me anywhere, but to no avail.
As an indicator I'd be looking to ideally have an array or cluster which contains the floats and bytes detailed in the not on the block diagram. I think at this packet I was travelling around 30mph in 2nd/3rd gear, i'd expect (if they are in the correct order) these to be in index 7 & 24 for speed and gear respectively but the numbers indicate 13.0929 (which could be right actually as I've seen other C implementation always multiply this "raw" value by 2.23 which would give 29.19) & gear index shows 0.326. Also, index 55 should be 2017, scanning the array i see 2017 is at index 70, could this be due to some padding in the raw packet input?
I can try again tonight to get some data at known speeds and settings etc so it's not so much a stab in the dark!
Any thoughts in the mean time are always appreciated
Regards
Jono
Looks like i've been a bit dense in terms of what i expected for the array indexes, realised there are some "floats" that are actually [n] arrays! can pinpoint all the data, some (like times) will need some alteration but the floats looks good!
Any thoughts on how i can do the byte elements? tried unflattening the string to array of U8 little endian but don't think this is correct! thought it might also be the case of using the rest of the binary string from the Gerd's unflatten but this is empty string.
Again, any help is appreciated!
Regards
Jono
Hi Jono,
you can try to unflatten using the correct cluster type definition.
You could also split the string into parts and unflat each part alone.
tried unflattening the string to array of U8 little endian but don't think this is correct!
Which sense does the byte order have for an array of bytes? Byte order only makes sense for datatypes consisting of several bytes, like U16, SGL, DBL …
thought it might also be the case of using the rest of the binary string from the Gerd's unflatten but this is empty string.
The remaining string is empty because with my example the whole string is unflattened: I disabled the arrays size indication input!
Gerd
So i believe the correct cluster for the rest of the data should be (based upon the notes of the struct that i've included in the BD) a cluster of 30 U8s with 20x 9 SGL and 9 U8s on the end (for car data[20]). but again i am not sure if i am interpreting this wrong!?
Which sense does the byte order have for an array of bytes? Byte order only makes sense for datatypes consisting of several bytes, like U16, SGL, DBL …
Not sure i am following..
Cheers
Jono
Hi Jono,
why do I need to do the counting for you?
I found in UDPPacket:
- 61 floats
- 15 bytes
- 1 float
- 3 bytes
- 2 bytes
- 20 CARUDPData
Each CARUDPData seems to consist of
- 7 floats
- 9 bytes
This sums up to 61*4+15+4+5+20*7*4+20*9 bytes = 837 bytes, which is less than your packet size of 1237 bytes…
I'm not an expert in C data structures and AFAIK each compiler might use it's own data padding scheme. So I advise to recount all the numbers I gave here and then check with a known UDPPacket for any additional padding bytes!
Gerd
Not sure you've accounted for some floats having more than 1 value i.e. tyre pressure has [4] so it works out:
UDPPacket
76 Floats
24 Bytes
1 float
3 byte
2 byte
CarUDPData
9 Float
7 Byte
Makes 337 bytes for UDPPacket & 900 bytes for CarUDPData = 1237 Byte Packet
My thought is that if I split the string at bytes 338 - 1237 and i cast or flatten these to the correct cluster, i should have the correct data?
Cheers
Jono
Hi Jono,
Not sure you've accounted for some floats having more than 1 value i.e. tyre pressure has [4] so it works out:
Well, I wasn't sure either.
Makes 337 bytes for UDPPacket & 900 bytes for CarUDPData = 1237 Byte Packet
CarUDPData: 20*(9*4 + 7) = 860…
