How do you interpret what the 8bit digitizer is putting out?

[FueL30]

I am trying to collect data from a signal. All I am getting is ASCII, which is what the computer is interpreting the binary bin file as. I am looking to put this data in a spread sheet so I can make sense of it. Unfortunately I don't know how the 8bit digitzer interprets or records the data other than it is decimal. I would like to know how this 8bit data correlates to the signal. I am using a NI 5112. Thanks

[TimmTheEnchanter]

Hi FueL30,

A digitizer does not interpret or record data in either of these file formats, it simply returns data (for instance, from the Fetch or Read functions).  Returning data from the digitizer in I8 or I16 format does not necessarily mean the data must be written to a file in a binary format (you can use scaling coefficients before writing the values to a file, or you could write the I8 or I16 values along with the scaling coefficients to a text file).  

If you are viewing a binary file in a program like Notepad, it is expected that when you open up a binary file and see a lot of ASCII characters. This is because Notepad assumes the data in the file is ASCII, not binary.  If you are using the Write to Binary File LabVIEW function, then you should be able to use the Read from Binary File LabVIEW function to get the data back in the same order it was written.  From there you can plot it to a graph just as if the data were coming straight from the Fetch function.  

What functions or VIs are you using to store the data to a file?  Are you using Write to Binary File?

Alternatively, if you are just trying to write to a spreadsheet, you could use the Write to Spreadsheet File VI instead.   If you are trying to save space or increase file write speed by using binary files, you may consider the TDMS file format.

As a side note, how the data is then stored to a hard drive a lower level gets into the topic of whether MSBs or LSBs are stored first (endianness), which isn't something you typically need to be concerned about as long as you are reading/writing on the same kind of system (Windows OR Mac, not both).

-Andrew

[FueL30]

Sorry, I do not know what functions are being used to record the data. I did not know there were more than one function. I was just handed the data on a USB stick that was acquired by the 5112. On this USB stick was a .bin file. I do not have a program that can read this so I created the program myself. Now that I have a program that can read the data, I don't know what any of the binary numbers represent comparing it to the waveform on the scopes. I need to create a program that automatically analyze the data to search for anomalies. This would be simple if I knew how this 8 bit sampler saves data. If there is already a program that does this in labview then I should be going back to them for the appropriate tools/functions. Thanks for your help.

I am currently just guessing that the right most binary number is used to differentiate pos to neg.

eg FE at the top, 00 in the mid,  FF at the bottom.

[DFGray]

 A .bin file could be the output of the NI-SCOPE Soft Front Panel.  In this case, the data is from a single channel and is a flat file consisting of an array of one of the following datatypes - signed 8-bit, IEEE 32-bit float, or IEEE 64-bit float.  Floating point will be little-endian byte ordered.  If the file was created by the SFP, the default is to save a text header file with channel information in addition to the binary file.  Ask your data source if they have this.  Or just try to read the data in all the formats above and see which one makes sense.  If you need help with this, let us know.

Note that you can use the SFP to read and display the binary data file.  It has options for all the different data types.  The SFP is free with the NI-SCOPE driver.

[FueL30]

There was an issue with the data I had received. We were having memory issues while trying to sample at the maximum rate. There was a bug with the software trigger. It was not working. It only seemed to do it while they were attempting to fetch the data as it filled up, I am guessing. This could be a reason why I couldn't make sense of the data. We had to stop this and try another solution by either streaming (which we didn't have a fast enough method for) or lowering our sample rate. We had no choice, and did that. We brought it back down to half of its capabilities. Another issue is the software I am using to make the program, is having trouble with the large 100 meg files. Although we reduced the sample rate our files are still massive. Time is not on our side to solve this issue, and will have to make due with what we have.

Thank you for your help.

[TimmTheEnchanter]

FueL30,

Can you be more specific on these points?

1. Which digitizer are you using?

2. What "maximum rate" were you trying to achieve?

3. What specific "memory issues" did you receive while running at the maximum rate?

4. Can you provide screenshots that show what the issue is with the data you received?

It sounds like you may be receiving a very common memory overflow error.  If this is the case, your data should never be corrupted.  In the case of this kind of error, the digitizer simply stops acquiring and returns as much data as it has.

-Andrew