Hantek 1008C data type

[JDunne]

Hello, I'm currently trying to use a PC based USB Hantek oscilloscope to take voltage readings for a prolonged time (few days). I can record this data using the Hantek software, but to do any sort of meaningful analysis I need to convert the data from a .DRC data format to anything else (bin, txt, csv).

I'm finding it incredibly difficult to decode the information. If you have any suggestions I'm very happy to discuss, a typical file is attached with 8 channels being recorded, only channel-1 has a 1 kHz 2Vp-p square wave visible. I'm certain that its a Chinese char encoding but haven't found the tools to decode.

The only other solution I can envisage is developing a new LabVIEW VI to capture the data and write to a file type that I want. I have already asked Hantek for driver details, but here amongst the core of established NI users, can I get a few pointers in setting up such a program (interfacing with the USB device)?

Thanks for your time

JD

[Bob_Schor]

Well, I tried to go to Hantek to see if they had useful information, but they want me to log in ...

Do they provide you with details on their DRC data format?  Do they provide low-level calls to enable you to use it as a "smart A/D converter" and get the data streamed back to your PC over the USB line?

Looking at the data file you attached, it looks like it might be a Binary file -- if I had a clue to the file format, or to what you expect the contents to be, I might be able to decode it ...

If it is a binary file, you may be able to "break the code".  To do this, it would help to create several (small) files with known composition.  An example would be a square wave of known amplitude and known frequency, acquired with 2-4 channel Gain settings and 2-4 time bases.  If you have multiple channels, start with one channel at a time, then do both (or all) together.  It would help to know precisely how many samples you took -- one way to do this might be to save a single "sweep" of the scope.

With these data, you can probably figure out the encoding (if, as I'm guessing, it is binary).  If not, zip those data files up, along with a description of their acquisition settings, and we can take a crack at it ... (it may cost you a beer at some future meeting ...)

Bob Schor

[JDunne]

Hey Bob,

Contacted Hantek myself about protocols and file formats, I've herd good things about responses so I might get something back about that later.

More examples! An image capture of the waveform, a binary capture of the same waveform, and as short a real time recording as I could take, approximately 5 wavelengths. I did sift through the coded data to look for patterns, but there seems to be an abnormal character size which wouldn't be unusual if it were in Chinese!

I'll take a crack at it again tomorrow, good hunting!

Thanks for you time.

[mateh]

Just having some fun with this... I think I found your waveform in the repeating pattern that starts at byte 3227.

The data after this are grouped in blocks of 1008 bytes, with the first 8 bytes being some kind of header, followed by 500 U16 codes of AI data. These blocks are repeated for each channel to make one big block of 8064 bytes, and then that is repeated 240 times to store the whole waveform for each channel. I didn't bother trying to convert it to voltage. I don't think converting it to I16 is working either, since the negative numbers seem a little glitchy.

[mateh]

I messed around with it a little more and realized byte order of the U16 is reversed. Starting at byte 3228 and swapping the two joined arrays gives a plot that makes more sense.

[Bob_Schor]

Mateh,

     It looks like you have the data, but I can't make sense of your VI (it doesn't work for me).  I'm also assuming (but may be wrong) that the two Capture files represent the same thing, namely 1600 points from 1 channel, starting with four points at -0.0092 followed by three at 0.0005 etc.  I must confess I was having a very hard time "forcing" one form into the other ...

JD -- can you confirm that the two data files represent the same thing, 1600 points from a single channel, whose values are given in the Text file?  [Aha, now that I'm about to go home for dinner, I just had a flash of insight -- we'll see if it pans out ...].

BS

[mateh]

Hi Bob, both of the graphs show the data from the first drc file that JD posted. I zoomed in to show the square wave, but there's actually somewhere around 120,000 data points per channel. You can ignore the graph and VI in my first post since it was derived incorrectly. I hope I saved the correct default values in the 2nd VI that I posted.

Basically I read all of the binary data as U8, then truncate the first 3228 elements (this is where I saw the start of repeating patterns). Scrolling through the data after this point, it looked like a slowly changing (noisy) signal which abrubtly switched states every now and then, so I knew it was the AI data for the square wave. I joined each consecutive pair of bytes into a U16, then reshaped into a 2D array to make the repeating pattern easier to see. I put everything in a while loop so that I could play around with the 2D array dimension size and start index and see the updated results. I was able to get the headers to line up by setting the number of colums in the 2D array to 504. Looking at the 2D array at this point, it became obvious that each row represented a single channel (1-8), with the first 4 U16 elements in each row being some kind of header, followed by 500 samples. I guess the scope writes the data in blocks of 500 samples per channel all at once. I chop off the header columns, and use the for loop to iterate through every 8th row in the 2D array (the "channel 1" rows) and concatenate all the data to piece together the waveform from 500 sample blocks.

[Bob_Schor]

OK, inspired by Mateh's fine work, I took a look at the second DRC that JD posted (along with a text file).  There is a whole lot of stuff I don't understand about the header.  Here are some things, however, that can be deduced:

• The file is written using Little-Endian (shades of Matlab!)
• The beginning of the file may be an I32 header -- the 7th entry seems to be the number of channels.
• I called the first 760 I32's "Header", with another 3 I16's as "spacer" material that I just discarded.  I think this is unlikely, but means that I don't fully understand how the initial 760*2 + 3 = 1523 "words" are organized.
• The rest of the file are I16 arrays, with a 4-word "size" header.  I assume the A/D converter is ±10V, so I output an Array of Dbl.
• The plots look correct, and at the end of reading all of the Channels (from initial Header) and all points from each channel, we have read all the bytes in the file.

Here is the Code (as a Snippet) and the resulting Front Panel (showing plots and success indicator).

Bob Schor

[mateh]

Nicely done! I can see now why my VI was confusing since the two drc files are structured a little differently, as far as number of channels, points per block, etc.. these kinds of puzzles are fun

I think the conversion to voltage is going to depend on the scope's vertical offset and V/div setting. This information must be encoded somewhere in the file as well... The raw data could span a total of 4096 codes (12-bit ADC). Looking at the screenshot that JD posted, there's no vertical offset and the V/div is 0.5 V. So the range is +/-2048 codes, 512 codes per division, and an LSB weight of 0.5/512, or about 976 uV. Multiplying the raw data by the LSB weight results in a voltage that somewhat matches the text file. Maybe there's some slight adjustment for calibration going on.

[Bob_Schor]

Mateh,

     Yes, there's a lot we don't know, including resolution of the A/D converter, any additional amplification, etc.  I found it curious that most of the I16 numbers going into the plots are multiples of 10 (there may have been a 5 as the first number ...).  There is other information in the initial 760 I32 header -- it certainly isn't Ascii text (I checked), and once you are past the first few entries, is mostly 0.  I didn't try to convert to a float format ...

JD,

     Is any of this helpful to you?  Do you want to try our "Poke at the Hantek Data Files" routines with more data and see if our guesswork holds up?  You know the old saying, "The Proof of the Algorithm is In the Data ..." (??? or something like that ???).

Bob "Pudding" Schor