Rigol DS1054Z CSV Increment value???....... - Page 1
Forum section: electronics / testgear

author: Smokey
author_rank: Super Contributor
timestamp: October 18, 2015, 02:57:06 am
content: Anyone know what is going on with the "Increment" value in the DS1054Z CSV file header generated from memory? It doesn't appear to directly represent the sample rate.The only reference I could find was this other thread which said you need to manually change the increment. That seems silly. That is such a simple thing to fix I would think if it was a bug it would have been picked up at this point.https://www.eevblog.com/forum/projects/rigol-ds1000z-csv-to-ltspice-%28pwl%29-parser-%28testers-welcomed-!%29/What's the deal?

author: Smokey
author_rank: Super Contributor
timestamp: October 18, 2015, 03:38:53 am
content: Here are some examples of the CSV header and the associated CSV data summary file:1:CH1,Start,Increment,Volt,-3.00000e-03,5.00000e-06DSO Acquire SystemAcquire Mode:NormalMemory Depth:12000ptsAverage Num:1024Sampling Rate:2000000Sa/s2:CH1,Start,Increment,Volt,-1.20000e-01,2.00000e-04DSO Acquire SystemAcquire Mode:NormalMemory Depth:12000ptsAverage Num:1024Sampling Rate:50000Sa/s3:CH1,CH2,Start,Increment,Volt,Volt,-5.00000e-01,5.00000e-03DSO Acquire SystemAcquire Mode:NormalMemory Depth:6000000ptsAverage Num:1024Sampling Rate:1000000Sa/s

author: Smokey
author_rank: Super Contributor
timestamp: October 18, 2015, 04:54:06 am
content: Just to throw more data into the mix..I put a 1khz sine wave into the scope and saved a CSV with 12K points and 200uS horizontal. That ended up being 5MSa/s on the screen. I then sucked the data into excel, used the "Increment" from the CSV header to fill in the sample time column, then pulled out one cycle of the sine wave, which should have taken 0.001 seconds for 1khz, but based on the increment value it came up as 0.01 seconds (100hz).EDIT to say, it's not always just a x10 problem. It's a different ratio for different sample rates, and it appears to change with number of sample points even at the same sample rate.The one cycle of 1khz sine wave took 4997 samples. That lines right up with the 5Msa/s of the actual sample rate.Here are the header and data summary info.CH1,Start,Increment,Volt,-1.20000e-03,2.00000e-06DSO Acquire SystemAcquire Mode:NormalMemory Depth:12000ptsAverage Num:2Sampling Rate:5000000Sa/s

author: Karel
author_rank: Super Contributor
timestamp: October 18, 2015, 08:38:58 am
content: Why would you want to use csv files? They are way too big & slow.Just download the data in byte format and you'll be fine.For example, there's a program called DSRemote that allows you to download display dataor memory data and stores it into a file with the extension ".edf".Those files can be opened with Scilab, Octave, Matlab, EDFbrowser, etc.There's no good reason for it but if you really insist to use excel, use the built-in edf to ascii (csv) converter of EDFbrowser.It's a kind of a de-tour but you'll be sure that your csv files will be correct.Edit:Never use csv files if it's not strictly necessary.Csv files are a kind of "last resort" solution to overcome the barrier of different file formats when a converter is not available.

author: Warhawk
author_rank: Frequent Contributor
timestamp: October 18, 2015, 09:00:02 am
content: Quote from: Smokey on October 18, 2015, 02:57:06 amHi, this might help you:https://www.eevblog.com/forum/projects/rigol-ds1000z-csv-to-ltspice-(pwl)-parser-(testers-welcomed-!)/I think it is a bug.edit: I did not read the thread carefully...

author: Smokey
author_rank: Super Contributor
timestamp: October 19, 2015, 12:51:51 am
content: That link really doesn't like to be copied and pasted. What a stupid bug, if that's a bug. So far I've tested a bunch of sample rate/data points/channel count combinations and none of them are right for the increment. It's not like I'm working with one special case the QC engineers missed. It's just wrong across the board.Except for being less efficient, I'm not sure why you have so much CSV hate. It's trivial to write an analysis script to interpret CSV formatted data, which it what I'm looking to do. At least it should be if it had accurate data, which is a fault with Rigol, not CSV.

author: Warhawk
author_rank: Frequent Contributor
timestamp: October 19, 2015, 06:09:44 am
content: Quote from: Smokey on October 19, 2015, 12:51:51 amI apologize, I did not read your thread carefully and missed that you are refereeing to the same topic. Stupid meAnyone else can use the link in my signature. That one should work.Long story short: It is really bug when you have the source data parameter set to "from memory" and not "from the screen". I reported it to the DS1000z "buglist" thread, however it seems that the community does not care much.

author: Smokey
author_rank: Super Contributor
timestamp: November 30, 2015, 07:37:04 am
content: Hey guys,I've been working on downloading the sample memory over Ethernet using the ds1054z python library and I found some interesting things.https://github.com/pklaus/ds1054zThe ":WAVeform:PREamble?" command to get waveform paramaters , which includes "xincrement", returns incorrect data. It's not just xincrement either, "points" is also screwy. Whatever is feeding the ":WAVeform:PREamble?" command is probably also feeding the CSV increment value.The odd thing is that the sample rate command, ":ACQuire:SRATe?" always seems to return the correct value, so the scope is doing something funny with the data internally for the Preamble command.Not that it makes a lot of sense, but my first guess was some sort of buffer update access conflict or something. Dunno.