Using a AWG and a Scope -> using stairs to get to 1 mV accuracy

[HendriXML]

It is an zoom in on the glitches in this (or similar) graph.

So it should be a straight line down. The blue graph represents the slope at each time averaged point. Under/above most of the blue spikes there’s a glitch like the one I zoomed in on.

[joeqsmith]

I am not sure what this graph is.  I assumed it was a plot showing the slope computed for each discrete sample for the triangle wave.   I would expect the top and bottom to be flat as the slope over time should never change, not ramping as you show in the previous graph.  If this is what is happening, you have other problems besides the Arb.   Zooming into an area where you are calculating an average of the slope at discrete samples just muddies the waters.   

I'm sure you have heard the phrase "shit in equals shit out".   It's why I suggest you start with the basics and just make sure things work as expected before making the problem more complex than it needs to be.  A decent meter and manual stepping the Arb is a good start.  If the Arb appears to behave as expected, then maybe go back to a simple pulse and make sure you can capture the data reliably.   

Again, in my previous post, is that your Arb and can you run it stand alone?  Do they support Labview?  If so, maybe I can find a place that will sell one and see if I can help you sort out the root problems with your setup.

[Rerouter]

You can set the arb to DC mode and just increment it via scpi, that way you can stair step it vs averaging on a slope.

[joeqsmith]

You can set the arb to DC mode and just increment it via scpi, that way you can stair step it vs averaging on a slope.

Exactly what I am asking them to do!  Perhaps you can do a better job explaining this to them. 

[tautech]

I tried to look up the SAG1021 on Amazon and eBay but didn't turn anything up.  I found that part number on Siglent's site and am guessing this is the Arb you are using.   If it is, will it work standalone off a PC with Windows?  Labview interface?   

Here Joe:
https://www.siglentamerica.com/accessory/sag1021/

It's a USB device only and controlled entirely from the scope, be it with the scopes UI or remotely via the scope using SCPI. commands from the EasyWave AWG software.

[Rerouter]

Technically it could be initialised and controlled by a PC, but without listening in on it, its not yet possible, It enumerates just like the scope, but likely needs some special routine to pass commands to it.

[joeqsmith]

When I go to the documents, download, they don't list this device under the waveform generators.    I am not familiar with the Siglent products or how to control their DSOs.   It sounds like it would be a fair bit of effort to get it working as a stand alone device with LabView.  For running any sort of test like this, that would be the platform I would want to use.   Really, I would need to buy the same DSO and arb to really be of any help outside of just offering general comments and suggestions.   The arb seems like it may be more difficult to locate a distributor for in the USA. 

Sorry HendriXML, looks like you are on your own. 

[tautech]

When I go to the documents, download, they don't list this device under the waveform generators.

Yes because they are an accessory to a scope and their usage instruction is part of the scopes User manual.
P194 Arbitrary Waveform Generator(Option)
https://www.siglentamerica.com/wp-content/uploads/dlm_uploads/2017/10/SDS1000X-E_UserManul_UM0101E-E03A-1.pdf

The arb seems like it may be more difficult to locate a distributor for in the USA. 

Actually no, there are dozens of NA suppliers:
https://www.siglentamerica.com/how-to-buy/

Anyways, thanks Joe for your ideas and help thus far. 

[HendriXML]

Thank you all for giving your thoughts!

But there’s 2 separate things I’m trying to do. First exploring the method of using a ramp, this cannot be done by using dc steps  .

Secondly hunt down any problem that is in the way of getting the most precise results.

As a reference I created a dataset using dc steps and measure the outcome values with a MM. This will be the most precise, but also “more work”. If I had a SCPI MM, I would have used it to do automatic measurements. But I don’t, hence exploring the other method.

There seems to be nothing wrong with the method either. It shows great stuff, like that calculating values the way the documentation says is wrong.

But it also shows another structural problem. My awg has a unexpected jumps (2 mV) in the ramp that seems to have a digital cause. Probably in the DC stepping as well, but it would not have been noticed that way.
That problem cannot be blamed on the method. The method still gives excellent results, but when calculating slopes over small distances it shows that error. This is also because the jump does not restore it self. (It’s not a hill, but a higher plane.)

Maybe I have not been clear (writing these things down is sometimes a real struggle). But I won’t agree on the matter that there’s nothing wrong with AWG, and just use another approach that masks that problem.
For the device to get trustworthy, I now need to know what is happening. If it is a dac error this size, it will add something strange (high freq content) to every signal it generates! Or maybe the ramp is not “calculated” in a correct way in the firmware. That I would prefer, because a firmware update might correct it.
So my guess is that the problem is not understood. If it is, there’s a difference in opinion. But that’s ok too.

[Rerouter]

For a cross example, here is my own scope + awg using a 1V pk-pk with a 500mV offset at 1KHz, display scaled to 150mV/div and a -531mV offset,

The rounding of where the ramp direction reverses, looks off to me, the scope display on mine even when zoomed in does not seem to show it.

[HendriXML]

My error is not on the edges, but somewhere in the middle of the ramp. And I think it cannot be shown as a sudden jump if one does not take averages, because it would be masked by noise.

Using averages I found the issue. And then I zoomed in on the problem area, using a much higher sensitivity (10 mV/ div). so the scope measurement errors will be less.

Because I can shift the jump using the awg V offset, we again can rule out the scope as a source for this issue.

[Rerouter]

If you tell me exactly what settings your able to cause the jumps to appear, I can replicate the setup for you. this can give you some cross verification.

[HendriXML]

I am not sure what this graph is.  I assumed it was a plot showing the slope computed for each discrete sample for the triangle wave.   I would expect the top and bottom to be flat as the slope over time should never change, not ramping as you show in the previous graph.  If this is what is happening, you have other problems besides the Arb.   Zooming into an area where you are calculating an average of the slope at discrete samples just muddies the waters.   

The slope is not averaged. The values it is calculated with, are.

The slope graph should indead be flat. Maybe with some dips, that are compensated withs some ups. But those spikes show glitches that just shouldn’t be there. Also I made my graphs in such a resolution that zooming in is an option. Under/above the slope spikes, there’re issues to see in the ramp.

The same problem areas are repeatable..

Also there’s not shit comming in, but highly averaged values. That alone would clear most noise/rounding issues, but not shitty awg signals  those stand out!

[HendriXML]

If you tell me exactly what settings your able to cause the jumps to appear, I can replicate the setup for you. this can give you some cross verification.

That would be great!
Here's the portion of my script that set things up:

Code: [Select]

          <rep:Reporter.Information Text="SDS1104X.IDN"/>
          <Execute Statement="SDS1104X.CommHeader:= THeaderType.Off"/>
          <Execute Statement="SDS1104X.TriggerMode:= TTriggerMode.Normal"/>
          <Execute Statement="SDS1104X.TDiv:= 500*micro"/>
          <Execute Statement="SDS1104X.VDiv[TTraceType.CH1]:= 10 * milli"/>
          <Execute Statement="SDS1104X.VOffset[TTraceType.CH1]:= -435 * milli"/>
          <Execute Statement="SDS1104X.VDiv[TTraceType.CH2]:= 1"/>
          <Execute Statement="SDS1104X.VOffset[TTraceType.CH2]:= -2.5"/>
          <Execute Statement="SDS1104X.MemorySize:= TMemSize.ms70K"/>
          <Execute Statement="SDS1104X.SetTrigger(TTraceType.CH2, 2.5)"/>
          <Execute Statement="SDS1104X.TriggerDelay:= - 0.5 * SDS1104X.TDiv * micro"/>
          <Execute Statement="SDS1104X.SegmentCount:= 378"/>
          <Execute Statement="SDS1104X.SequenceMode:= True"/>
          <Variable Identifier="Freq" Type="Extended" Init="5 * 1 / (SDS1104X.TDiv * 14 * 2 * 1.1)"/>
          <Variable Identifier="AWGCommand" Type="string" Init="Format('C1:BSWV WVTP,RAMP,FRQ,%s,AMP,0.9,OFST,0.353,SYM,50', FloatTocode(Freq))"/>
          <Execute Statement="SDS1104X.RawWrite(AWGCommand)"/>
          <rep:Reporter.Information Text="AWGCommand"/>
          <Execute Statement="AWGCommand:= 'C1:OUTP ON'"/>
          <Execute Statement="SDS1104X.RawWrite(AWGCommand)"/>
          <rep:Reporter.Information Text="AWGCommand"/>
          <Execute Statement="AWGCommand:= 'C1:SYNC ON'"/>
          <Execute Statement="SDS1104X.RawWrite(AWGCommand)"/>
          <rep:Reporter.Information Text="AWGCommand"/>
           <Execute Statement="SDS1104X.Stop"/>
          <Execute Statement="SDS1104X.TriggerMode:= TTriggerMode.Single"/>
So 2 channels, ch1 for signal, ch2 for sync pulse triggering.

TDiv: 500us/div

CH1:
100mV/div
-400 mv offset

CH1 zooming in:
10mV/div
-435 mv offset

CH2:
1 V/div
-2.5V offset

Trigger delay (on screen dump): 0.00s

AWG frequency is calculated, but it says on a screen dump: 324.675
Type: Ramp
Amplitude: 900mV
Offset: 353mV
Sym: 50%

If not doing scriptbased averaging, averaging mode of 512x should be about the same.

I'm not sure you can take the same zoom in values.

[HendriXML]

I am not sure what this graph is.  I assumed it was a plot showing the slope computed for each discrete sample for the triangle wave.   I would expect the top and bottom to be flat as the slope over time should never change, not ramping as you show in the previous graph.  If this is what is happening, you have other problems besides the Arb.   Zooming into an area where you are calculating an average of the slope at discrete samples just muddies the waters.   

Maybe you missed the 2nd graph? It is drawn with a thin line to reveal details. But it can more easily be seen if you zoom in on the image. The glitches are easily been seen, even without the slope graph. Maybe that is what made it confusing?

[HendriXML]

Did some hunting on the scope and created some screendumps. These are all screen dumps of a 900mV amplitude ramp with a 381mV offset.

The problem is amazingly stable. It is on the screen for more than 15 minutes.

It is a 2 mV drop in 20ns of time.

If we zoom in enough on the time axis, our ramp becomes totally flat (except the sine on it...why?), and then this glitch kicks in, dropping 2 mV in an instance.

[HendriXML]

With 20M bandwidth limiting.

Will check this range with the DC offset wave type of the AWG!

[HendriXML]

It seems the area of the glitch has no dac errors!

Which is good news because calculating a decent ramp can be fixed in firmware!

Another possibility would be a time related issue (not before the dac: thus software, but after: thus electronics).

Another possibility would be that ramps use a different output than the DC offset.
* there is no sine wave in DC mode
* i can hear relais in dc mode, using relais while plotting a wave is not possible. So it might be an "auto ranging mode" and use the dac in more precise way?

Maybe a 100% ramp will be clear of this problem.

[HendriXML]

Here're the graphs of different symmetries: the time's are different, the Y values exactly the same.

I don't think its a dac issue anymore. It drops with a offset and I don't thnk the AWG has an extra dac for offsetting, but I might be wrong.

My guess would be that it is an "calculation error", however if the ramp was calculated at the AWG the vertical position was likely to change as well doing changes in the symmetry of it. I think it uses an arbitrary wave, which is scaled and has an offset, played at a certain sample rate(?). The wave sample data would then contain the glitch.

The error might well be that there a lot of samples are played double. Slopes up have namely a sudden drop, and slope downs have a sudden rise at the same level (at 50% symmetry). It might also be the same sample data but played in reverse for going down.

For me it is time to enter the territory of creating my own ramp and upload that and see what will happen.

However the documentation is sparse / non existing. I know of the wave editor that can be downloaded, but I'd like to create my own binary file. Trust is good control is better.

So does anybody know if there is some documentation on the file format?

[tautech]

However the documentation is sparse / non existing. I know of the wave editor that can be downloaded, but I'd like to create my own binary file. Trust is good control is better.

So does anybody know if there is some documentation on the file format?

Opened EasyWave and then went to Open File, the default format it expects is .csv.

[HendriXML]

Same sample but with 1800mV amplitude, thus twice as much.

The glitch is of the same height. So if it the error was some sample data, the error should have been doubled.

Looking at the grant picture it seems that the number of glitches seem to have increased. But getting them zoomed in on and in view using Excel take to much time.

Have to think about this. Are these ramps repeated pieces of the same sample "glued" together, but not seamless?

[HendriXML]

However the documentation is sparse / non existing. I know of the wave editor that can be downloaded, but I'd like to create my own binary file. Trust is good control is better.

So does anybody know if there is some documentation on the file format?

Opened EasyWave and then went to Open File, the default format it expects is .csv.

Thanks for replying, but can a CVS be uploaded also directly to the AWG?

Is suppose that it consists of values from 0-1. So these can be scaled, get an offset and get played at different frequencies.

Are they getting resampled while played or will the AWG chose it sampling frequency very precise. For accurate results these things matter .

I have read it is limited to 14kpt? (For my purpose that should be enough)

Will be busy for a few days, but will come back to this matter.   

[tautech]

However the documentation is sparse / non existing. I know of the wave editor that can be downloaded, but I'd like to create my own binary file. Trust is good control is better.

So does anybody know if there is some documentation on the file format?

Opened EasyWave and then went to Open File, the default format it expects is .csv.

Thanks for replying, but can a CVS be uploaded also directly to the AWG?

Is suppose that it consists of values from 0-1. So these can be scaled, get an offset and get played at different frequencies.

Are they getting resampled while played or will the AWG chose it sampling frequency very precise. For accurate results these things matter .

I have read it is limited to 14kpt? (For my purpose that should be enough)

Will be busy for a few days, but will come back to this matter.

The documentation indicates EasyWave files are uploaded via the scope to SAG.
I'd need to have a play with say grabbing a ramp csv from another AWG (sanity step check  ) and then uploading via EasyWave and the scope to the SAG. That alone might answer some questions about the SAG step and give Siglent a push to hopefully resolve the issue in firmware, I dunno.
Like you I also have a bit on so however the weather has turned here so I should have a change to look deeper in the next few days.
I'll try and document what I do so Siglent and others can easily follow and duplicate it.
Along with what you've displayed so far we should get a good picture of what's happening.

[HendriXML]

That would be great if this would lead to a solution. I’m new to AWG’s so I’ve yet to develop a model of how they work.
I’ve got a lot of answers to find. Like will they interpolate values between data samples if the period gets longer. If the outputting “HW engine” can do al that stuff than it would be tempting for a designer to just push samples to it, and not do any sample calculations on the device.
But if it calculates does it need to preprocess in a buffer or can it be done real-time?

Working with a binary file-format (and documentation of it) might give some extra info.

I hope someone can give some clues on this.

[tautech]

That would be great if this would lead to a solution. I’m new to AWG’s so I’ve yet to develop a model of how they work.
I’ve got a lot of answers to find. Like will they interpolate values between data samples if the period gets longer. If the outputting “HW engine” can do al that stuff than it would be tempting for a designer to just push samples to it, and not do any sample calculations on the device.
But if it calculates does it need to preprocess in a buffer or can it be done real-time?

Working with a binary file-format (and documentation of it) might give some extra info.

I hope someone can give some clues on this.

Via the SDS1104X-E web server .BIN is the default data format but for most they need to convert to .CSV using the scopes BIN to CSV conversion utility that you access from the web server. Works well.

The SAG spec from the scopes datasheet is mere: sample rate of 125 MHz, wave length of 16 kpts of which is the same spec as the standalone single channel SDG800 AWG series.
I have these plus the 1000X and 2000X models but their sample rates and mem spec is much higher.
Should make an interesting exercise.