Dat file saving

[rafi]

Hi

my problem is that i got two .dat files from some one .i know these are real time data but the problem is the person who saved that data into .dat file from which format is not known.i need to fine that format for example .xle or .doc .i tried every possible effort.unless and untill i do not know the saved dat file format i can read it in Lab view.so pls tell me someone complete labview code how to read that file or convert into readable format of labview 

thks and oblidge

[Bob_Schor]

If all you have are two data files of completely unknown format, it is almost impossible for anyone (other than the person who originated those data files) to tell you the format of the files, nor provide you with tools to read it.

If you had posted the files in question, we might have been able to use "editing tools" to examine the bits and bytes in the file and attempt guesses about the data contained in the file.  For example, if we saw a mixture of what appeared to be random bytes of data, and then all of a sudden Ascii Text appeared that was easy to read, we could "guess" that the Text represented String variables.  Numeric data could be examined to see if it appeared to represent 8-bit integers (unlikely), 16-bit integers, 32-bit integers, or floating point numbers of various formats (32-bit, 64-bit, or 128-bit).

Bob Schor

[rolfk]

128-bit floating point data are extremely rare. LabVIEWs extended format gets saved as 16 bytes, you  but only.contains 10 bytes of significant bits on x86 hardware. On all other hardware including x64 it is only having 8 bytes of significant data.the same as the double format.

Most other software never bothers.to support more than double format as the “double long” format is compiler and platform specific.

As to the original question. Binary data files are indeed pretty much impossible to decode without some good description of the format or at least the type and values it contains. 

[Bob_Schor]

---

@rolfk wrote:

128-bit floating point data are extremely rare.  I completely agree.

As to the original question. Binary data files are indeed pretty much impossible to decode without some good description of the format or at least the type and values it contains. 

---

We are saying the same thing -- a binary file is a "mess of bytes".  One can make educated "guesses" as to the file format (and, back in the day, I was able to take 9-track Mag Tape with data generated by Fortran/Macro data acquisition routines, and provides with a list of the names and an idea of what the data represented, I was able to write a (Fortran) routine that would read the Tape and generate Print Outs (on a "Line Printer", ka-thunk, ka-thunk) that did, in fact, correspond to the data, and allowed us to actually analyze these data.  But we had a good idea of the order and format of the data ...

Bob Schor

[LLindenbauer]

Have you tried running the file command on the file? You could also try a hex dump. Personally, I'd give it a 15% chance of being a regular zip file. However, your best bet is probably picking up the phone and calling the person who created the file for you.

[altenbach]

The good new is that you know the type of content ("real time data"). In a nutshell, any file is just a linear collection of bytes and extracting data requires some knowledge about the structure, but can also sometimes be done with some careful analysis and some best guesses based on the byte structure (symmetries, periodicities, some readable text sections, etc.) and some experimenting with byte order and plausible representations.

Do you know what was used to create these "dat" files? Another LabVIEW program? Some third party software?

Obviously "every possible effort" is impossible (sic) because this is an open-ended collection and there will always be possibilities you have not tried yet. As others have already said, we can provide a few more eyes if you care to attach an example, so please do!

Also provide as much as you know about the data: The instrument that recorded it, the software that wrote it, and the type of expected data (single channel, multiple channels, etc.)