UDP data format

[mattbiegner22]

My apologizes if something similar to this question has been posted before.

I am an aerospace engineer who has been tasked with designing a small labview program to parse a text file with an aircraft's 6DOF position data and send it via UDP to a simulation at a specified run rate. I have the application working, however I am having a hard time constructing the UDP data that our simulation is looking for. Since I'm an AE I know enough about data types to get by, but I'm not familiar with UDP very much.

The problem that I am having is that the simulation is looking for a different data type than ASCII string. The proceeding image shows two separate packets that were grabbed when running wireshark on the simulation server. The top portion of the image is the packet that the sim is looking for. You can see that the hex yields invalid or strange ASCII characters, which leads me to believe that it does not want ASCII data. The bottom portion is the packet I'm sending it through labview, which is an ASCII string. The problem is that I don't know what kind of data the sim is looking for, and I can't get a hold of the guy who programmed it so I'm hoping someone here can shed some light on it. Would it maybe be looking for the data in the UDP packets to be a byte string?

And my second question is that since the sim is not looking for an ASCII string and since the UDP write block in labview will only send a string, how do I convert an ASCII string to a byte string or whatever data format my sim is looking for?

Thanks in advance!

[RavensFan]

If you don't know what type of data the application is looking for, how are we going to be able to help?

The data is you are snagging looks like it would all be valid data, but you need information to interpret it.  It could be a set of numbers transmitted it as any number of datatypes: sgl precision float (4 bytes) , double precision float (8 bytes), various signed or unsigned integer values ( 8 bit , 16 bit, or 32 bit).  All the zero bytes might be just space fillers to complete a packet, or the remaining unused portion of a data structure (e.g. only 10 elements were used out of a 32 element array, the remaining elements were padded with nulls. ....)

[mattbiegner22]

I'm looking at the plugin code and I think it's looking for a byte array, though I'm not sure. The code uses ioctlsocket calls and recvfrom calls to get the UDP data which I'm not at all familiar with, if that helps.

As for actual data types, it's varied. There are identifiers that are being passed as ints and the 6DOF position data is being passed as doubles.

Message Edited by mattbiegner22 on 06-12-2010 08:59 PM

[altenbach]

I agree with Ravens analysis. It looks like binary data and all you need to know is how to flatten/unflatten it. 

Could you attach the packet capture as a text file instead of an image?

Do you know what the data in that particular packet is? 

[mattbiegner22]

Yes, I should be able to attach it, it's on my other computer at the moment.

The data in the packet is essentially 6DOF position data and then some vehicle ID and status information. I think the correct order should be [Vehicle ID, Lat, Long, Alt, Phi, Theta, Psi, Status, Alive] and that is it. 

Is there an easy way in Labview to flatten it from an ASCII string to a binary string then?

[altenbach]

---

mattbiegner22 wrote: 

Is there an easy way in Labview to flatten it from an ASCII string to a binary string then?

---

From the LabVIEW perspective, there is no difference between as ASCII string and a binary string. Everything is just a string.  LabVIEW and UDP does not care if the characters are humanly readable or not.;)

So, yes, what you need to do will be trivial. 😄

All you need to do is flatten your raw data to a string and unflatten at the other end to get the data back as numerics.

If all fields are fixed, you would just create a matching cluster, then flatten to string (or vice versa at the other end).

(Here is a simple example of the cluster method, originally posted in this old thread. Of course you seem to be more concerned about the left side of the problem side, where you would simply form the cluster and flatten to string (not shown)). 

Often you can even use typecast. A simple explanation on how these operations work can be found here.

See how far you get. 😄 

[mattbiegner22]

Ok, so here's what I'm trying to do then, let me know if this makes sense:

I'm reading a text file line by line. For each line it reads, it gets passed to a spreadsheet string to array block to build an array of data that is delimited by commas. I then pass that array to a decimate array block to get each signal, which I then convert to it's respective data type. So, for example, all the status indicators would be converted to int8 and all the 6DOF position data would remain as double, since that is what the simulation reads. I then pass each signal to a typecast to convert it to binary, and then output that to a concatenate string block and then to the UDP write block.

I can post an example of the code that I have so far when I get to my other PC.

[altenbach]

---

mattbiegner22 wrote:

I can post an example of the code that I have so far when I get to my other PC.

---

 Yes, please do.

[mattbiegner22]

Ok so pretty much everything inside of that inner most case structure is the UDP data construction method I'm using. I'm giving the program the capability to output UDP to two different simulation servers, one which accepts an ASCII string as data and the other which requires the data to be typecast to binary.

I haven't hooked up the status indicators yet (the ints), but right now I'm just trying to get it to send data in the correct format.

 Also, when I run the labview with the typecasts I get a UDP data in the format "@AsÒ]«À]vÞ 3çŽ@„ì¥Xê|á"; is this indicative that it is binary?

[altenbach]

Can you run the VI so the indicator "Current Data (Long, Lat, Alt, Phi, Theta, Psi):" contains typical data, make the current value default, then save and reattach the VI?

You are doing some weird construtcs, firing the event structure from a timed loop. I would get rid of the event structure and run everything inside the timed loop. An event structure needs to be on the top diagram, and not buried inside inner loops and case structures, especially since you are remotely firing it every 100ms.

You also have some serious race conditions due to the abuse of local variables. In the section shown in the image, you are reading from the same local (i) in parallel and writing to it once. Since there is no data dependency, these operations can occur in any random order, so the "i" used to get the line might not be what is displayed and it could be the original or incremented value. Use an integer (blue!) shift register instead.

 

I did not really look at the rest of the code, but my comments are probably just the tip of the iceberg salad. 😉 

Message Edited by altenbach on 06-13-2010 04:21 PM