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

[HendriXML]

For the added overcurrent protection in this little project:
https://www.eevblog.com/forum/projects/battery-voltage-to-5v-regulation/msg2280605/?all#lastPost

I want to find out what the temperature sensitivity is when the zenerdiode would be replaced by a normal one.

First I simplified the schematic, so it is more easy to see what is measured in the experiment. The experiment uses the term input and output. The op amp feeds the subcircuit (input) which has an output on the non inverted input.

The subcircuits curve and the amplification determines when the positive feedback collapses.

In the experiment I've done 3 measurements:
* At room temperature: Non automated set of points by turning up the AWG in DC mode and measuring the output with a MM. This method is very precise and is the baseline to compare the next one to.
* At room temperature: A 50% triangle ramp with the AWG from 0 to 800 mV at 5 hz. Measuring the in and output many times with a DSO using the 64x average mode.
* At 50 deg (using a heatgun): The same as above.

The data of the DSO was fetched using SCPI. I manually removed data that wasn't in the ramp up. So it was known that all voltages should be rising (discarding noise). With this knowledge I took only the first voltage/time point of a certain voltage. Values in between are interpolated later on. In this way one can use the very high horizontal resolution to get very high vertical one. (Precision is another matter).

Also I used a 450 ohm resistor instead of a 500 ohm (R9) one, because of the 50,74 ohm output of the AWG. The voltage drop over the 450 ohm resistor is used to determine the drop over the extra 50,74 ohms.

Using the two datasets (Ramp and output) a new dataset for the use in Excel can be created. There the MM and DSO measurements can also be compared.

I think the DSO results are very usable! I did not even took out abnormal values, which would not be very difficult to spot.

I'm still not sure whether the fetched dataset is an averaged one or whether averaging is only used for the DSO screen.

The next step is to check for each temperature what amplification is needed to let the positive feedback collapse. If the difference is high, then a normal diode is not suited to be used in this circuit. (It may also that a Zener diode's curve at low currents also differs too much.) I will write a simulation script which will use the datasets I got to find the answers. There's even a slight possibility it won't collapse using the current component values.

BTW: The curves already tells me that temperature dependency is a bit too high to my likings. But these experiments are a good learning experience. So we shall continue!

[tautech]

I'm still not sure whether the fetched dataset is an averaged one or whether averaging is only used for the DSO screen.

FYI the displayed sampling rate and mem depth are clues to what happens when Averaging or E-Res modes are selected. 

[HendriXML]

I'm still not sure whether the fetched dataset is an averaged one or whether averaging is only used for the DSO screen.

FYI the displayed sampling rate and mem depth are clues to what happens when Averaging or E-Res modes are selected. 

The mem-depth I already manually turned down, so that's no clue to me . The sample rate does then also not need to be high anymore so I'm missing that clue also

Personally I would like to have the averaging in the dataset, but I don't think deep memory (?) can be used for that. I think there is some screen buffer where the averaging is happening, no? So it doesn't end up in the dataset.

Or is it "segmented" and are the segments averaged when retrieving the dataset (or outputting to the screen)? But then there're not enough segments.

There's prop. a 4 byte/Mpt deep memory buffer allocated where the summing is done.

Now I really like to know!

[tautech]

Try a full mem depth before selecting Average and then see the mem depth drop so the scope can process the averages quickly.
Both sampling rate and mem depth are timebase setting dependent so you can see what's going on.

[HendriXML]

Try a full mem depth before selecting Average and then see the mem depth drop so the scope can process the averages quickly.
Both sampling rate and mem depth are timebase setting dependent so you can see what's going on.

But is also needs memory to store the summing in, that alone could be a reason for not having the full memory to be available.

Also how does is implement FIFO? Has it got 2 or more summing buffers?

I did some testing, and averaging is in the dataset! (my scope was stored to leave from the livingroom to the e-lab, so I saved that investigation for later. Now that later has become soon)

I had an averaged sine wave of 6V ampl. and set it to 0V ampl. and then quickly retrieved a dataset. And indeed the ampl. hadn't dropped much. Nice to know!

[tautech]

Also how does is implement FIFO? Has it got 2 or more summing buffers?

Dunno, past my level of knowledge.
Others might know and help.

[HendriXML]

Also how does is implement FIFO? Has it got 2 or more summing buffers?

Dunno, past my level of knowledge.
Others might know and help.

Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution 

[tautech]

Also how does is implement FIFO? Has it got 2 or more summing buffers?

Dunno, past my level of knowledge.
Others might know and help.

Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution 

Yes I think that's correct.
4ch X-E right ?
Enter the webrowser and download the .bin to .csv file converter.
Use it to convert the default .bin data file to .csv then Copy/Paste the data into your program. (Excel etc)

[HendriXML]

Also how does is implement FIFO? Has it got 2 or more summing buffers?

Dunno, past my level of knowledge.
Others might know and help.

Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution 

Yes I think that's correct.
4ch X-E right ?
Enter the webrowser and download the .bin to .csv file converter.
Use it to convert the default .bin data file to .csv then Copy/Paste the data into your program. (Excel etc)

Yes, I went fancy with my post and on each glowing abrev. more details are shown. But here on the iPad it doesn’t work, so not worth the effort.

The way I get the samples is via SCPI in a byte per sample, so the extra bits are chopped off in that way. If the webbrowser does it otherwise it would pleasantly surprise me.  But I think that not many consumer level scope’s will support the extra bits feature.

[tautech]

Also how does is implement FIFO? Has it got 2 or more summing buffers?

Dunno, past my level of knowledge.
Others might know and help.

Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution 

Yes I think that's correct.
4ch X-E right ?
Enter the webrowser and download the .bin to .csv file converter.
Use it to convert the default .bin data file to .csv then Copy/Paste the data into your program. (Excel etc)

Yes, I went fancy with my post and on each glowing abrev. more details are shown. But here on the iPad it doesn’t work, so not worth the effort.

The way I get the samples is via SPCI in a byte per sample, so the extra bits are chopped off in that way. If the webbrowser does it otherwise it would pleasantly surprise me.  But I think that not many consumer level scope’s will support the extra bits feature.

The .bin/csv files can be pretty large but with use of a careful setup restricting mem depth, trigger level and Single shot you can keep the data sample size quite small and manageable.
Just try with some simple waveform to get some system that works for you sorted then migrate the settings into your test setup.

[HendriXML]

I did some testing with the AVG acquisition mode to find out how it functions and what the algorithm behind it might be.


First: it seems to work with a summing buff, which does not throw values out (no FIFO). The summing is weighted, new values are added with a greater weight. This means over time older values are loosing more and more their share. But that can take more time than one might think especially if the differences are great.
With this algorithm one summing buffer is enough. (When I was thinking about this stuff, I also thought of a way which discards values over time, and works more like you would expect. But that needs extra buffers. But to my understanding of the moment that wouldn't be a problem. )


How did I test this?


I ran a 140 hz square wave (fits the screen nice) which starts at 95% duty cycle.
Then its triggered.
Then imediately it goes to 90%.

Then it waits 10 seconds.
Then 5% less duty cycle.

The above is repeated until 5% duty cycle.

Then it waits 10 seconds.

Then it is stopped and a screendump is made.

So looking at the dumps, one can see how a high value decays over time. Left: “young low values”, right: older ones.

To use the AVG mode correctly this information might be of use. In this regard I find the "Averages 1024x" indication some what misleading. I mean after 18 x 140 samples/sec x 10 sec = 25200 samples later a value has still a lot of influence. And isn't "thrown out".

That is not a bad thing, but one should know that. (And maybe restart the triggering more often)

[HendriXML]

When the positieve feedback collapses can be shown by a graph, however it is depended on the slope of the Vi/Vout graph. I've put that slope against a second y-axis and come to the conclusion the data is not smooth enough to do anything meaningful with it.

The path I'll take then is to have a function fit of the points and take a differential of that (slope).

However it would also be nice to find a way to get smoother data, hence the exploration of averaging the samples. For me using the averaging acquisition mode has some drawbacks. One step better would be to have the separate sample sets and do the averaging myself. In this way every sample set is of equal influence and we would end up with a higher resolution as well.

Does someone now how to use SCPI to get the data from individual segments/frames when sequence mode enabled?

[joeqsmith]

Looking at the duty cycle average test.   Assuming I follow, which I am not sure I am,  at 140Hz or every 7.15ms the scope will see a trigger.   You wait 10 seconds except for the very first, to allow up to 1400 cycles to be captured.  Even with 32 averages, it should should be flushed but it's showing some residual.  The scope may not be collecting all the data.   

Send out a burst of 1400 cycles at the 140Hz and see how many trigger events the scope reports.   Maybe they provide you the retrace time.   Slow down the time between pulses (send a 356us pulse, wait for the scope retrace, then send the next pulse.)   You could even wait a second between.  Just use the lowest averages so you don't waste a lot of time.   

Basically, just curious if you made sure your test was valid before running it.

[HendriXML]

Looking at the duty cycle average test.   Assuming I follow, which I am not sure I am,  at 140Hz or every 7.15ms the scope will see a trigger.   You wait 10 seconds except for the very first, to allow up to 1400 cycles to be captured.  Even with 32 averages, it should should be flushed but it's showing some residual.  The scope may not be collecting all the data.   

Send out a burst of 1400 cycles at the 140Hz and see how many trigger events the scope reports.   Maybe they provide you the retrace time.   Slow down the time between pulses (send a 356us pulse, wait for the scope retrace, then send the next pulse.)   You could even wait a second between.  Just use the lowest averages so you don't waste a lot of time.   

Basically, just curious if you made sure your test was valid before running it.

I haven't seen a trigger counter anywhere, so I'm also not sure how many times it triggered.

But is should retrigger after 100ns. 140hz isn't even close to missing the next one. The period is also larger than what's in screen so it should have one trigger per period. But even if it had 2, the explanation still matches.

Also the after the first 95%->90% drop the script doesn't wait. So that average has very few high's in it.

The screenshots are static, but I off course saw an animated decay. Fast at first, than slowing down, so I know for sure it didn't trigger infrequent. (But I also would like to see how many)

Also I'm not surprised that it works like this, otherwise one needs more buffers. Which have to be shared by several frames. One buffer per frame x 1024 takes to much space: 4 buffers of 256 frames should however be possible. After 1024 frames one can than drop one buffer, and continue with 768 (3 full buffers) + 1 frame. Essentially doing a FIFO with buffers.

How I came to 4 buffers:
Going from 14M -> 1.4M gives 9 x 1.4M buffer space. A summing buffer needs 2 bytes/sample to handle overflows.

This however would have some artefacts like a few sudden drops in the average.

I cannot think of another way to really get rid of old values. Maybe someone else has a genius idea?

[joeqsmith]

Basically, just curious if you made sure your test was valid before running it.

I haven't seen a trigger counter anywhere, so I'm also not sure how many times it triggered.

But is should retrigger after 100ns. 140hz isn't even close to missing the next one. The period is also larger than what's in screen so it should have one trigger per period. But even if it had 2, the explanation still matches.

Also the after the first 95%->90% drop the script doesn't wait. So that average has very few high's in it.

The screenshots are static, but I off course saw an animated decay. Fast at first, than slowing down, so I know for sure it didn't trigger infrequent. (But I also would like to see how many)

Also I'm not surprised that it works like this, otherwise one needs more buffers. Which have to be shared by several frames. One buffer per frame x 1024 takes to much space: 4 buffers of 256 frames should however be possible. After 1024 frames one can than drop one buffer, and continue with 768 (3 full buffers) + 1 frame. Essentially doing a FIFO with buffers.

How I came to 4 buffers:
Going from 14M -> 1.4M gives 9 x 1.4M buffer space. A summing buffer needs 2 bytes/sample to handle overflows.

This however would have some artefacts like a few sudden drops in the average.

I cannot think of another way to really get rid of old values. Maybe someone else has a genius idea?

Obviously I don't know anything about the scope you are using.   Normally I will use Labview to collect and crunch the data.  Still, if you wrote you own software you would need to see how fast you could collect it first. 

[HendriXML]

Basically, just curious if you made sure your test was valid before running it.

I haven't seen a trigger counter anywhere, so I'm also not sure how many times it triggered.

But is should retrigger after 100ns. 140hz isn't even close to missing the next one. The period is also larger than what's in screen so it should have one trigger per period. But even if it had 2, the explanation still matches.

Also the after the first 95%->90% drop the script doesn't wait. So that average has very few high's in it.

The screenshots are static, but I off course saw an animated decay. Fast at first, than slowing down, so I know for sure it didn't trigger infrequent. (But I also would like to see how many)

Also I'm not surprised that it works like this, otherwise one needs more buffers. Which have to be shared by several frames. One buffer per frame x 1024 takes to much space: 4 buffers of 256 frames should however be possible. After 1024 frames one can than drop one buffer, and continue with 768 (3 full buffers) + 1 frame. Essentially doing a FIFO with buffers.

How I came to 4 buffers:
Going from 14M -> 1.4M gives 9 x 1.4M buffer space. A summing buffer needs 2 bytes/sample to handle overflows.

This however would have some artefacts like a few sudden drops in the average.

I cannot think of another way to really get rid of old values. Maybe someone else has a genius idea?

Obviously I don't know anything about the scope you are using.   Normally I will use Labview to collect and crunch the data.  Still, if you wrote you own software you would need to see how fast you could collect it first.

So I ran the script now using Sequence mode, and it clears up how fast it triggers. It can capture 1891 frames (buffers) of 14K in total The time it took was 27 sec. That makes 70 frames per sec. So 2 periods/cycles per frame.

In that mode we could get the 1891 buffers and calculate the average our selves. That does not need to be done realtime, because if we use the Single trigger mode it stops after 1891 frames/buffers.

The problem is, I haven't figured out how to get the data frame by frame via SCPI yet.

I've also searched for a Trigger counter but I don't think the scope has one.

[joeqsmith]

Odd they don't offer example code.   At these speeds, you may be able to grab it frame by frame.   There are some advantages to working this way, if you can pull it off.   All my vintage scopes allow creating your own scripts to control them.  I've never gone this route as the desktop PC's processing power can easily out pace the scopes I have.   You can take advantage of the GPU for example.     

Even if you can't collect individual frames without missing, the raw accumulated data sounds like it will work for you, assuming that is really what they send you.   I am envisioning a very sparse manual for your particular scope.   

[HendriXML]

Odd they don't offer example code.   At these speeds, you may be able to grab it frame by frame.   There are some advantages to working this way, if you can pull it off.   All my vintage scopes allow creating your own scripts to control them.  I've never gone this route as the desktop PC's processing power can easily out pace the scopes I have.   You can take advantage of the GPU for example.     

Even if you can't collect individual frames without missing, the raw accumulated data sounds like it will work for you, assuming that is really what they send you.   I am envisioning a very sparse manual for your particular scope.   

What you suppose is also doable for me to, frames don't need to adjacent to each other. (My mind was stuck on duplicating an averaging algorithm)
But it is also good to have a small timeframe at which all data is acquired. The fetching of data goes fast (for such small data blocks), like 5 MiB/s, so 14K frames could be downloaded at the speed of 35 frames/sec.

-Edit I have to correct the speed I usually get:
6 MB/sfor large blocks, but only 0,24 MB for 14K blocks.

[HendriXML]

With the command FRAME_SET the current frame can be set, that will probably the wavedata which is downloaded. That is something I will checkout later!

[joeqsmith]

Odd they don't offer example code.   At these speeds, you may be able to grab it frame by frame.   There are some advantages to working this way, if you can pull it off.   All my vintage scopes allow creating your own scripts to control them.  I've never gone this route as the desktop PC's processing power can easily out pace the scopes I have.   You can take advantage of the GPU for example.     

Even if you can't collect individual frames without missing, the raw accumulated data sounds like it will work for you, assuming that is really what they send you.   I am envisioning a very sparse manual for your particular scope.   

What you suppose is also doable for me to, frames don't need to adjacent to each other. (My mind was stuck on duplicating an averaging algorithm)
But it is also good to have a small timeframe at which all data is acquired. The fetching of data goes fast (for such small data blocks), like 5 MiB/s, so 14K frames could be downloaded at the speed of 35 frames/sec.

It seems like if you are capturing 5ms at 2Msamples/sec with no accumulation, and 8-bits/sample you need to send 10KBytes for each frame.  If your frame rate is 140Hz,  you need to send 1.4MBytes/sec or a 11.2Mbit.   This seems very doable if my basic math is correct.   

About 4 years ago,  I added a 1G Ethernet card to one of my old scopes.  Guessing all scopes will have their tricks depending what you are trying to do with them.  On this particular scope, I can move the frame into an internal memory buffer and then transfer that memory across the Ethernet to the PC while the scope grabs the next frame.   This allows me to achieve sustained data rates of well over 300Mbits.   I would imagine a modern scope would far out pace what my old scopes can do but again, I really have no idea about your particular setup.

If the data is unpacked on your scope (say they really send two bytes anytime you enable accumulation) the actual data rate you need would be much lower once you get past a one accumulation.     

[joeqsmith]

I doubt it will help you with the experiment you are trying to run but it should give you some idea how fast I can transfer data with my vintage scope. 

https://youtu.be/DlsBnumQaCA?list=PLZSS2ajxhiQA9yWh-hvVtv2ib-3ObOHGV&t=15

[HendriXML]

I doubt it will help you with the experiment you are trying to run but it should give you some idea how fast I can transfer data with my vintage scope. 

https://youtu.be/DlsBnumQaCA?list=PLZSS2ajxhiQA9yWh-hvVtv2ib-3ObOHGV&t=15

Nice to see and very fast  speeds! But think that also depends a lot on how fast chipset and cpu of the scope are. As far as I can see your data goes also through a VISA driver layer.
Which my software also directly communicates with. Also more pro scopes will prop. have better tuned software running on them.
I still find it amazing what my Siglent SDS1104X-E is capable of feature wise. Maybe if I ran jumbo packets on the network the speed goes up as well, I don’t know. To many network interrupts can slow things down. I don’t even know wether it is a Gib network interface.
For my experiment tons of data would also be overkill. With 14K frames I think a good dataset can be created. It is slowly rising so I can tune on that property and do heavy averaging.

[joeqsmith]

Many companies rolled their own VISA layer back then and I am using the custom one for this scope.   This DSO uses a P4 and was Windows 2000.   

I doubt jumbo will gain you much if anything.  The PC side should present no problem at these speeds, even with Labview.  As long as you have a large enough buffer setup, Windows should keep up with ease.   Someone here was asking about how fast the data could be transferred with the PC running an FFT on it.   It looks like I removed the video but the limiting factor is really updating the screen. 

I  looked up your scope on their site.  They show it has a LAN connection but details are sparse.  I couldn't locate a manual for it.  If you can post a link to the manual, I will have a look.     

Here you can see the time stamp of the data with Wireshark.  Keep in mind, the PC that I am using for these demos is fairly old.  My new PC will run circles around it.   
https://youtu.be/GhVQGPra9DQ?t=149

[tautech]

I  looked up your scope on their site.  They show it has a LAN connection but details are sparse.  I couldn't locate a manual for it.  If you can post a link to the manual, I will have a look.     

The manuals of interest are:
SDS1000X-E Series User Manual
Programming Guide For Digital Oscilloscopes Series

They're down the list a bit here:
https://www.siglentamerica.com/resources/documents/digital-oscilloscopes/#sds1000x-e-series

Some further data on LAN connection speeds is here:
https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/msg1394796/#msg1394796

Also there's some guidance about data collection in the Operation tips:
https://www.siglentamerica.com/operating-tips/sds1000x-e-series/
And videos:
https://www.siglentamerica.com/videos/sds1000x-e-series/

[HendriXML]

I  looked up your scope on their site.  They show it has a LAN connection but details are sparse.  I couldn't locate a manual for it.  If you can post a link to the manual, I will have a look.     

The manuals of interest are:
SDS1000X-E Series User Manual
Programming Guide For Digital Oscilloscopes Series

They're down the list a bit here:
https://www.siglentamerica.com/resources/documents/digital-oscilloscopes/#sds1000x-e-series

Some further data on LAN connection speeds is here:
https://www.eevblog.com/forum/testgear/open-source-lxi-tools-and-liblxi-v1-0-released-for-gnulinux/msg1394796/#msg1394796

Also there's some guidance about data collection in the Operation tips:
https://www.siglentamerica.com/operating-tips/sds1000x-e-series/
And videos:
https://www.siglentamerica.com/videos/sds1000x-e-series/

Thanks!

I checked the color of the led of the switch at the scopes connection: it is of amber color meaning a 100mbit connection.

I did a large 14M test, and it was fetched at 6MB/s
It's not 30MB/s but enough for a lot of applications.

Then I tried to use USB, but the VISA com interface crashed in that case so I cannot report any speeds on that.

[tautech]

Then I tried to use USB, but the VISA com interface crashed in that case so I cannot report any speeds on that.

How so ?
Is EasyScope working for you ?

If the install and connection to EasyScope is tried before installing the NIVISA package Windows will use some generic USB driver and then you need to venture into Device Manager to assign the correct NIVISA driver for operative scope USB connection.

From an old post:

The USB driver is being used for the connection to the Siglent scope....it should be something like: "C:\Program Files\IVI Foundation\VISA\IVI USB3 Staging\ausbtmc.inf"

[HendriXML]

Then I tried to use USB, but the VISA com interface crashed in that case so I cannot report any speeds on that.

How so ?

[/quote]
I'm quite sure this it has nothing to do with Siglent. The guys from VISA shared components (not National Instruments I think) did not a great job creating a COM interface for VISA. I don't think Easyscope uses the COM interface. Instead it propably talks directly to Visa.dll

[tautech]

The NIVISA Runtime package as a minimum must be installed for EasyScope for USB or LAN connection.
For USB just check the USB port's driver is set to ausbtmc.inf.

[HendriXML]

The NIVISA Runtime package as a minimum must be installed for EasyScope for USB or LAN connection.
For USB just check the USB port's driver is set to ausbtmc.inf.

I’ve installed the full package which deliver stuff with which the USB tests OK. With that pachage runtime or full comes an extra interface layer possibility. Namely COM. That is what is crashing. I had to try several versions to get LAN working. Today I tested USB for the first time, and it gives the usual access violation.
That just shouldn’t happen. And it is just when opening the device. I can even see that succeeding in the NI trace app. Which “watches” on the VISA.dll interface layer.

[joeqsmith]

...
I checked the color of the led of the switch at the scopes connection: it is of amber color meaning a 100mbit connection.

I did a large 14M test, and it was fetched at 6MB/s
It's not 30MB/s but enough for a lot of applications.
...

Seems reasonable and should easily cover what you are trying to do, assuming the scope can actually shuffle the data out.  I had a high end Arb that I was trying to use Ethernet with.  Their firmware was so poorly written, it was actually faster to use GPIB!  This was about a $70,000 USD unit.  Poorly written code has no bounds.    

Is the 100Mbit limit on your PC, scope or both? 

I’ve the full package ....

With you discussing NIVISA,  I am curious what the "full package" refers to?   Do you have the full package of Labview that you plan to use with this scope?   

[HendriXML]

Is the 100Mbit limit on your PC, scope or both? 

The scope.

With you discussing NIVISA,  I am curious what the "full package" refers to?   Do you have the full package of Labview that you plan to use with this scope?   

It is about 1GB installation and gives access to some nice (debugging) tools.

[tautech]

The NIVISA Runtime package as a minimum must be installed for EasyScope for USB or LAN connection.
For USB just check the USB port's driver is set to ausbtmc.inf.

I’ve installed the full package which deliver stuff with which the USB tests OK. With that pachage runtime or full comes an extra interface layer possibility. Namely COM. That is what is crashing. I had to try several versions to get LAN working. Today I tested USB for the first time, and it gives the usual access violation.
That just shouldn’t happen. And it is just when opening the device. I can even see that succeeding in the NI trace app. Which “watches” on the VISA.dll interface layer.

Interesting.
Ok then, is the inbuilt webservers SCPI panel better for what you're trying to do ?
No other SW is needed other than your browser and give it the scope's IP. 

[HendriXML]

I checked the USB driver, the module which gives the AV is some COM dll.

[HendriXML]

The NIVISA Runtime package as a minimum must be installed for EasyScope for USB or LAN connection.
For USB just check the USB port's driver is set to ausbtmc.inf.

I’ve installed the full package which deliver stuff with which the USB tests OK. With that pachage runtime or full comes an extra interface layer possibility. Namely COM. That is what is crashing. I had to try several versions to get LAN working. Today I tested USB for the first time, and it gives the usual access violation.
That just shouldn’t happen. And it is just when opening the device. I can even see that succeeding in the NI trace app. Which “watches” on the VISA.dll interface layer.

Interesting.
Ok then, is the inbuilt webservers SCPI panel better for what you're trying to do ?
No other SW is needed other than your browser and give it the scope's IP.

I'm using my self created scripting language/interpreter, so it can't possibly be better

[joeqsmith]

With you discussing NIVISA,  I am curious what the "full package" refers to?   Do you have the full package of Labview that you plan to use with this scope?   

It is about 1GB installation and gives access to some nice (debugging) tools.

It's far too small to be Labview.    They offer a Base, Full and Professional version is why I asked.    It will be interesting to see what you come up with for your own software.

[HendriXML]

I made a large graph PNG, to show the result of doing a segmented data acquisition and then averaging the 1891 (-> max, when 14K samples) frames.

No more 255 levels of resolution 

For a single temp dataset of my experiment I need two channels, which can be related by their timestamp.

But not taking the same time in each channel, because I will do some more averaging (But now using more the e-res approach) and will need to interpolate.

Because my traces will always be climbing (I'll choose the correct timings for that) this is easy and reliable. From start to finish, I'll group those values that have a minimal of 0.05V between the start of the group and its ending. Then I'll create a single point for each group which time is in the middle and it's value is an average of all the values.

This way I know for sure my curve will always rise and that there's enough vertical distance to have a reliable slope.

[HendriXML]

After some tweaking with timings and offsets: this is the ramp I'll feed my diode/resistor divider.

Starts at 10 mV up to 800 mV with only rising values.

Also done with averaging 1891 frames.

At some points the slope is not good enough to do calculations with, this will be fixed with the next averaging step.

[HendriXML]

I added the time averaged graph.

Behind the dashed lines one can see it follows the other curve nicely.

When I now take an interpolated value from the averaged curve, I am certain it is very accurate.

It's funny that a dataset of millions of measurements in just a few seconds can produce such usable curves. At least, if one has two of them and that will be the next step.

[HendriXML]

Got my two datasets.

Had to tune the time based averaging a bit to have more points. Because both are curved (input because of the 50 ohm output resistance of the AWG)
For the input curve it is now a difference of 0.01V which triggers the creation of a averaged point, but no more than 1000 values.
For the output curve it is a difference of 0.003V and also limited to 1000 values.

These two combined should give a nice input/output curve.

[HendriXML]

I've combined the two datasets to a Vout/Vin curve.

I also added a simple per point slope graph.

As can be seen the slope is much more stable (notice the different scale)!

But not good enough for directly using for analysis. So back to the function fitting and let the app Maxima do some algebra.

At least we ended up with a better dataset. (The results are however quite different than what I got with my MM a while back, so I'll have to redo them as well, for verification)

[HendriXML]

When doing time-based averaging with larger steps, the slopes become more stable.

This will be usable for some coarse answers.

[joeqsmith]

I made a large graph PNG, to show the result of doing a segmented data acquisition and then averaging the 1891 (-> max, when 14K samples) frames.

No more 255 levels of resolution 
....

How did you verify the scopes linearity?  Even the channel to channel on my scopes vary.  I was wanting to gain a bit more resolution with mine and modeled the channels.   Then used that to fit the data.

https://youtu.be/04I7nHA_HxM?t=161

[Rerouter]

I will say if your in full control of things with SCPI, use a smaller vdiv setting and trim the offset per segment. the offset dac is the root of trust as far as the scopes calibration goes, so the closer you can keep to the center division, the more you can trust the reading

So you just have a quite small time base so you can rip the data off as fast as possible (you can set things up so you only download every X sample to speed things up) and each time the data walks towards the top or bottom of the screen you adjust the channel offset.

[HendriXML]

I made a large graph PNG, to show the result of doing a segmented data acquisition and then averaging the 1891 (-> max, when 14K samples) frames.

No more 255 levels of resolution 
....

How did you verify the scopes linearity?  Even the channel to channel on my scopes vary.  I was wanting to gain a bit more resolution with mine and modeled the channels.   Then used that to fit the data.

https://youtu.be/04I7nHA_HxM?t=161

I didn't, but here the slope at some points on the averaged ramp.  It should be a straight line of theoretically 580,64 V/s

I had previously noted a dip around t=0, that certainly can be seen in the graph. The question is, what has the strongest influence on the errors: the DSO or the AWG.

One thing that needs improving is the triggering. While taking the data of each frame, I saw them one by one like an animation. And they shifted a bit to much to my opinion. But that should be averaged out.

What you did was very advanced, but for this experiment I leave it the way things are, because I will compare two datasets which will be fetched with the same (repeatable) errors, and can still be compared.

[HendriXML]

I will say if your in full control of things with SCPI, use a smaller vdiv setting and trim the offset per segment. the offset dac is the root of trust as far as the scopes calibration goes, so the closer you can keep to the center division, the more you can trust the reading

So you just have a quite small time base so you can rip the data off as fast as possible (you can set things up so you only download every X sample to speed things up) and each time the data walks towards the top or bottom of the screen you adjust the channel offset.

That would be a good idea to keep in mind. In the previous post I saw that things are not perfect in DSO measurement land. I'm happy that for answering the temperature dependency question it does not mind much.
Can you explain the dip I measured in the centre? It is one that bothers me.

[Rerouter]

My suspicion would be a rounding error, you can isolate which part is causing it by rerunning with an X10 probe connected, if it happens at the same point on the slope its the AWG, if it moves its the scope ADC

[joeqsmith]

I made a large graph PNG, to show the result of doing a segmented data acquisition and then averaging the 1891 (-> max, when 14K samples) frames.

No more 255 levels of resolution 
....

How did you verify the scopes linearity?  Even the channel to channel on my scopes vary.  I was wanting to gain a bit more resolution with mine and modeled the channels.   Then used that to fit the data.

https://youtu.be/04I7nHA_HxM?t=161

I didn't, but here the slope at some points on the averaged ramp.  It should be a straight line of theoretically 580,64 V/s

I had previously noted a dip around t=0, that certainly can be seen in the graph. The question is, what has the strongest influence on the errors: the DSO or the AWG.

One thing that needs improving is the triggering. While taking the data of each frame, I saw them one by one like an animation. And they shifted a bit to much to my opinion. But that should be averaged out.

What you did was very advanced, but for this experiment I leave it the way things are, because I will compare two datasets which will be fetched with the same (repeatable) errors, and can still be compared.

Triggers can pose some problems.   That Arb I mentioned samples the trigger asynchronous so I ended up with a large bit of jitter and had to synchronize the clocks.  The Arb required a minimum of a 5GHz clock so getting that working was a bit of effort.  Thank goodness for Mini-Circuits.       In the sub MHz, it seems like it would be far less of a problem.  I assume you are driving the scopes external trigger with one of the Arb's channels or it has an output trigger.  If not, maybe you can change your setup to improve it.   

[HendriXML]

I made a large graph PNG, to show the result of doing a segmented data acquisition and then averaging the 1891 (-> max, when 14K samples) frames.

No more 255 levels of resolution 
....

How did you verify the scopes linearity?  Even the channel to channel on my scopes vary.  I was wanting to gain a bit more resolution with mine and modeled the channels.   Then used that to fit the data.

https://youtu.be/04I7nHA_HxM?t=161

I didn't, but here the slope at some points on the averaged ramp.  It should be a straight line of theoretically 580,64 V/s

I had previously noted a dip around t=0, that certainly can be seen in the graph. The question is, what has the strongest influence on the errors: the DSO or the AWG.

One thing that needs improving is the triggering. While taking the data of each frame, I saw them one by one like an animation. And they shifted a bit to much to my opinion. But that should be averaged out.

What you did was very advanced, but for this experiment I leave it the way things are, because I will compare two datasets which will be fetched with the same (repeatable) errors, and can still be compared.

Triggers can pose some problems.   That Arb I mentioned samples the trigger asynchronous so I ended up with a large bit of jitter and had to synchronize the clocks.  The Arb required a minimum of a 5GHz clock so getting that working was a bit of effort.  Thank goodness for Mini-Circuits.       In the sub MHz, it seems like it would be far less of a problem.  I assume you are driving the scopes external trigger with one of the Arb's channels or it has an output trigger.  If not, maybe you can change your setup to improve it.

My scope does not have an external trigger. In the setup there’re 10 MSam/s (100 ns), but the sync puls is 50 ns wide so that would be tricky. I tried using it but, it didn’t trigger so I used the rampsignal instead. But when I think of it again, I must have forgotten to turn the sync pulse on.
A third probe does come at the cost of having half the memory buffer. It also increased the samples/s. (Meaning also less risk to miss. a trigger pulse) So now there’re much less samples to average. But of a higher quality (the signal seemed rock solid), and more samples to do time based averaging.

[HendriXML]

My suspicion would be a rounding error, you can isolate which part is causing it by rerunning with an X10 probe connected, if it happens at the same point on the slope its the AWG, if it moves its the scope ADC

Now I used the sync pulse from the AWG for the triggering.

Looking at these graphs it is very unlikely that the AWG causes the dips. Because they don't show up in both graphs the exact same time.

However I find them strange because they are averages of in this case more than 300 samples. It may be something that repeats itself. Or a single very high spike that is averaged down like this.

The circles are the time base averaged values.

[HendriXML]

I think that the sample based averaging needs to be done by sorting the values for each sample and discarding the lowest 25% and highest 25%. This will certainly filter out the spikes. The ones left over are closest to each other, so enough samples are left for propper averaging.

[tautech]

BTW, when using an external trigger source into one of the channels you can if you wish hide that channel.
The channel tab will still remain and show H. You can select Visible or Hidden on P2 in the channel menu.

[HendriXML]

So from the  70K x 378 samples I get, I discard 94 of the highest values and 94 of the lowest ones ending up with 190 for each of the 70K samples.

These 190 are normally averaged to a single "high resolution" value. Then the 70K high resolution samples are grouped and averaged: the circles.

These are the values used for the voltage based curves.

Taking this road even brings out the adc steps of the scope to light. But now much more stable than using a single frame.

Because of this I'm quite sure that the spikes (in the output B) are really there (ringing?). They turn up in every graph.

So I made the AWG output, which feeds the dividers less then 20 cm of coax, but it remains.

The question is whether the probe is causing this? Also the knee of the curve became a bit wobbly..., adc steps I guess.

[HendriXML]

Also I mentioned the animation of the 378 frames was rock solid, that is true regarding the triggering. But the traces seem to have "a wave" on them, which is probably noise. But maybe someone knows a technique to bring that down?

[HendriXML]

The technique I used to discard the lowest and the highest values was the following. (Because 70K x 378 values need to be sorted this better be a quick  and memory efficient algorithm  )

When the 378 values are added, they are divided in value bands of 32 values each. (Value div 32)  Because they are close to each other, most likely only 1 or 2 bands will be used.

In each band the separate values (value mod 32) are counted. (3x3, 2x7, 1x8, 13x17 etc.)

When doing the summing one loops through the bands (starting with the lowest) and the 32 counters in each. This is in sorted order, so the unwanted values can easily be discarded.

The fun part of this, is that thousands (64K) of samples could be summed, without any extra memory needed (or any dramatic loss in speed). And millions if the counters where made bigger.

[HendriXML]

In my graphs there seem reoccurring glitches (value going down for a few samples and the up again) around certain Y-values. This can be show by taking time based averages and showing the slope between them. At each larger peak there's probably a glitch.

I've tried different frequencies/probes/channels and calibrating. But the problem remains. I think the ADC or “firmware logic” has something to do with it.

The values in the graph are translated values I get from the scope (VOffset + VFactor * RawValue). Around the RawValue of 0 (-> 400mV), there's always such a glitch. However it seem to repeating at other values as well.

Can someone give a clue about what is happening and whether it is improvable?

[HendriXML]

I created a normal size image with only the glitches at 400 mV.

[HendriXML]

When I look at the above one thing strikes me, it seems that the value drops, but it never really jumps back. Like the whole positive (RawValue > 0) side should be lifted 1 step.
In the slope graph this can also be seen. A spike going down, doesn't have a spike going up. (The average slope is not restored)

[genghisnico13]

I don't know much about the subject, but have you tried adding white noise to your input signal with the generator?

[HendriXML]

When I look at the above one thing strikes me, it seems that the value drops, but it never really jumps back. Like the whole positive (RawValue > 0) side should be lifted 1 step.
In the slope graph this can also be seen. A spike going down, doesn't have a spike going up. (The average slope is not restored)

In this thread this problem is discussed, which lead to the cause.
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg2355744/#msg2355744

The documented way to translate raw sample values seems not to be correct. That's why every value below the center point is 1 step to high. When values get close to the centerpoint this results in a noticeable glitch.

[HendriXML]

I don't know much about the subject, but have you tried adding white noise to your input signal with the generator?

Via the UI I cannot add white noise, but maybe there's a SCPI way, I have to figure that out. But first I like to know the cause of the smaller glitches. I'm pretty confident that they are analogue issues (besides the centerpoint crossing error). But I may have to leave these issues it for a while: holidays are coming.

[joeqsmith]

In my graphs there seem reoccurring glitches (value going down for a few samples and the up again) around certain Y-values. This can be show by taking time based averages and showing the slope between them. At each larger peak there's probably a glitch.

I've tried different frequencies/probes/channels and calibrating. But the problem remains. I think the ADC or “firmware logic” has something to do with it.

The values in the graph are translated values I get from the scope (VOffset + VFactor * RawValue). Around the RawValue of 0 (-> 400mV), there's always such a glitch. However it seem to repeating at other values as well.

Can someone give a clue about what is happening and whether it is improvable?

If I have your setup, I would offer to try and replicate what ever test you are trying to run.  Because you are plotting the change in slope the sampling time is critical.  We know you were missing a lot of data early on.  To run this test, the sampling will need to be solid.  No missing data.  The trigger jigger will need to be VERY small.  on and on....   Once you have all the small details ironed out, it should be flat.  There should be no need to disguard data.   

I was attempting to use the scope to measure phase errors.  To get around problems like the trigger, I just let the scope record a large amount of data and realign it in software. 
https://youtu.be/Bg45FuoeHZk?list=PLZSS2ajxhiQA9yWh-hvVtv2ib-3ObOHGV&t=766

[HendriXML]

We know you were missing a lot of data early on.  To run this test, the sampling will need to be solid.  No missing data.  The trigger jigger will need to be VERY small.  on and on....   Once you have all the small details ironed out, it should be flat.  There should be no need to disguard data.

Hi, thanks for the response.
I think the triggering is OK now, using the sync pulse of 5 ns rise time at a cycle of ms, should do the trick.
Also because I have 2 simple ramps, I don’t think the timing can create the glitches I’m still seeing (1 I tackled).

Making the averaging more advanced, did not make it better. I’m seeing more of the true measurements now, thus the adc’s discrete values. But it is also an indication that the glitches are not single high spikes that where averaged down. They are in the signal of all the frames and go up and down with the AWG offset.

I’m not sure about what you mean by missing data. I turned away from scope averaging to do it in a script myself. So I know I get 378 frames of data.

My setup is way more simple (and slower) than yours. But still I seem to get some ringing. I purposely choose a ramp which was symmetrical and thus not having large change in voltages/currents.

Even in the most simple setup of having the AWG directly connected to the scope, they turn up.

Maybe I should suspect the AWG of acting strange. I could “zoom” on a glitch and see how that looks like.

If it’s in the signal than it will show up enlarged. Maybe showing dac issues.

[joeqsmith]

I was thinking you are plotting the slope of the change in values, not the values.  If I understand what you are doing (which is a pure guess on my part) then the time the data is sampled will have a dramatic effect on the amplitude, and hence the slope.   So timing is critical as well as the amplitude.   

Say you do something similar to what I show where I plot the time between samples.  Then fire up DOOM (or what ever games are now popular).      Does everything remain stable?   In  my case, Windows gets in the way of doing anything time critical.   This is why I let the scope capture lots of data and then I offload and process it.   

In your case, you may be able to run it at DC.  Step the Arb, let it settle, trigger the scope to grab a frame, download and average it and step the DAC.  Remove time from the setup.  Again, I am not really following along with what you are attempting to do and may be way off base in my suggestions.

[HendriXML]

The result of my zoom in are posted here:
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg2356566/#msg2356566

[HendriXML]

I was thinking you are plotting the slope of the change in values, not the values.  If I understand what you are doing (which is a pure guess on my part) then the time the data is sampled will have a dramatic effect on the amplitude, and hence the slope.   So timing is critical as well as the amplitude.

In case of a simple ramp/slow signal a change in time would mean it only goes up/down a bit, it would probably average the slope, but not have the reactive stuff I've got now (I guess).

I think I might have found a problem with the AWG signal.

[HendriXML]

In your case, you may be able to run it at DC.  Step the Arb, let it settle, trigger the scope to grab a frame, download and average it and step the DAC.  Remove time from the setup.  Again, I am not really following along with what you are attempting to do and may be way off base in my suggestions.

In my case 378 frames are held in the deep memory (i think its called like that). They’re placed there in succession and the acquisition is stopped after the last frame is acquired (the scope does this). After that the script has all the time in the world to download the data. So no real time issues.

Also in windows applications (processes or threads) can be run at high priority. Time critical software should use those possibilities. A multi core PC should be able to run a task almost real-time without any disturbances. (Not doing HDD stuff)

[joeqsmith]

I was thinking you are plotting the slope of the change in values, not the values.  If I understand what you are doing (which is a pure guess on my part) then the time the data is sampled will have a dramatic effect on the amplitude, and hence the slope.   So timing is critical as well as the amplitude.

In case of a simple ramp/slow signal a change in time would mean it only goes up/down a bit, it would probably average the slope, but not have the reactive stuff I've got now (I guess).

I think I might have found a problem with the AWG signal.

That would depend.  If the DSO is set to say 1mV / count.  Say the Arb slews at 1mV/ms.    Say the sample rate is 1KHz +/- 10ms.  That's +/-10 counts.  I'm not there and have no idea what your setup is.  This is why I was suggesting you run the system synchronously to remove these potential problems. 

[HendriXML]

I was thinking you are plotting the slope of the change in values, not the values.  If I understand what you are doing (which is a pure guess on my part) then the time the data is sampled will have a dramatic effect on the amplitude, and hence the slope.   So timing is critical as well as the amplitude.

In case of a simple ramp/slow signal a change in time would mean it only goes up/down a bit, it would probably average the slope, but not have the reactive stuff I've got now (I guess).

I think I might have found a problem with the AWG signal.

That would depend.  If the DSO is set to say 1mV / count.  Say the Arb slews at 1mV/ms.    Say the sample rate is 1KHz +/- 10ms.  That's +/-10 counts.  I'm not there and have no idea what your setup is.  This is why I was suggesting you run the system synchronously to remove these potential problems.

But almost the whole trace get the 10 counts, so the slope is not really affected, the absolute values are, but also not that much. Having a simple ramp has it benefits. That’s probably the reason I could not accept the roughness of my slopes.

[joeqsmith]

Again, hard to say without understand more about what you are doing.  Obviously with the example I provided, it could be off a fair amount.   If your trigger is not stable or Windows is still missing data.... I could see this level of error in the sampling depending how you are collecting the data.   

With you looking at the slope and not the raw averaged data, it could compound the problem.  I would start splitting up the problem until you understand where the causes of error come from. 

If your scope has a deep enough buffer to capture say 100 cycles of your triangle wave.  You could download that and then split and realign the data in software.  Then run your accumulation and division.  Basically the time error becomes the scope and arbs clocks.  You may be able to sync the two to minimize this error as well.  I am doing that using the GPS as a clock reference. 

[HendriXML]

If your scope has a deep enough buffer to capture say 100 cycles of your triangle wave.  You could download that and then split and realign the data in software.  Then run your accumulation and division. 

What you say here is good advice, and is exactly what the scope is doing for me. And the 2,3,4..378th trigger keeps the alignment intact. They call it segmenting mode resulting in frames. Otherwise it would be a great technique to apply by “hand”.

[joeqsmith]

If the scope is requiring more than one trigger, it's not what I am suggesting.   Let the Arb free run and the same for the scope.  One trigger to start the collection and just let it fill the scopes entire memory.   Maybe it can't work that way with your scope.  This will remove any trigger error, except what your alignment algorithm introduces. 

[HendriXML]

If there’s any need the resulting frames, can also be aligned by hand 

But the trigger accuracy is in my setup more than enough.

My setup is as far as I can see now pretty solid, but I’ve got an AWG that doesn’t create a good ramp.

Maybe iv’ve got to upload the ramp as an arbitrary wave. Never done that before and maybe the same glitch will arise.
However my data is good enough for the range I’m interested in. I could calculate directly with the slopes between (time averaged) points, or I could do a function fit between the point and use a derivative of it.

But what this exercise is about is learning, growing skills and getting some experience in this stuff. So I’m still glad the (single) ramp is a bit forgiving for all sorts of errors. But things that need improving, I’ll improve.

[joeqsmith]

My setup is as far as I can see now pretty solid, but I’ve got an AWG that doesn’t create a good ramp.

It's odd to me that your Arb wouldn't far exceed the scopes performance (noise, resolution).   I assume you have it terminated at 50 ohms.  What sort of Arb are you using?

[HendriXML]

The Awg seems to have this repeatable glitch.
It is discussed by me at:
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg2356566/#msg2356566

But it is not the first struggle I had with it:
https://www.eevblog.com/forum/testgear/sds1104x-e-and-sag1021-unwanted-dc-offset/

For the slow signals I did not terminate it with 50 ohms. Also in my original test setup is feeds a resistor/diode divider.

I’m quite sure it is not ringing or anything analogue. But maybe you’ve got an idea?

[joeqsmith]

The Awg seems to have this repeatable glitch.

I don't know what I am looking at.  It's a graph with some data.   If I knew for example that this is the Arb connected to your DSO showing a ramp and it's just raw data and your point is that the signal increased, then yes there is a major problem.   

If indeed this is what you are trying to show, single step the Arb's amplitude while watching the output with a DVM and make sure that it is linear.  I again expect the scope can't resolve it.  If the Arb is linear, start looking at your setup or code.   

Again, just split the problem.  Don't assume it's the Arb. Prove it. 

****

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?   

http://www.siglent.com/ENs/prodcut-fj.aspx?id=-1&tid=1&T=1
 

[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.

[Rerouter]

They work by directly piping the sample contents into the DAC, its at a fixed 125MHz sampling rate,

if you set the frequency faster than what is required to play at that rate, it will pick a value based on a division of the samples,
If you set a frequency slower than would play all the samples, they get doubled until the required number of clocks have been played

As such you will generally always have a jitter of about 125MHz unless you use a clean division of 125MHz,

The offset DAC is summed into the output op amp which is on a +-5V supply rail, this is why it tries to restrict you to +-4V, in reality the offset can be much higher if the op amp had a wider supply rail, but with only 5V it gets much less linear and begins clipping at about +-4.35V

[HendriXML]

The offset DAC is summed into the output op amp which is on a +-5V supply rail, this is why it tries to restrict you to +-4V, in reality the offset can be much higher if the op amp had a wider supply rail, but with only 5V it gets much less linear and begins clipping at about +-4.35V

I have the AWG on its own power supply, not USB. Would it be safe to give it some more voltage then? (For all the sub circuits?)

So it does have a offset DAC. 

But simply doubling the samples..that would be a nice test case for the ramp then.

Nice to know of the fixed sampling rate, will have to give that some thought to have it play nicely with the scope. And not measure in between values.

Some more questions that burn in my mind:
Any idea’s on why I can hear relais clicking? Is the DC mode just using the offset DAC?

[Rerouter]

To be clear, I am only talking about the output op amp and not the rest of the board, I believe it all ends up down regulated. but i cannot say what the margins are for the rest of the rest of the board,

That op amp itself is also a limiting factor, but unless you wish to replace it, I would not fiddle with its supply rails (this is from when i had a look at reversing the output chain)

https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg2189021/#msg2189021

[HendriXML]

The AWG is not ready to get fried so I won’t give it more juice.

I read about the square wave, one thing a saw repeatedly when looking at the ramps on the scope where square waves running over them.

At first I thought they where the issue, but they get averaged out, because they don’t repeat themselves at the same time. Maybe a frequency can be found where they stand still... causing another issue?

For now I won’t hunt at that one, but the beast has been seen lurking in the shadows.

[HendriXML]

I've started examining the possibilities to create my own wavedata.

First I downloaded EasyWave, I just took the most recent version I could find. But it might be that they're compiled model specific.

I created a Ramp, using a dedicated app. function for that. And did a fast first test (MeasuredWave).

It shows the same dips. After which I checked the Ramp I was feeding the AWG (InputWave).

For some reason it has 2 points of the same value in the middle of the ramp. Hence the dip. I don't think it should be there.

This and some other small bugs are a sign that it's better to completely create the WaveData ourselves. One thing I also do not like is that application works with comma separated value (CSV) files. With an XPos and a Y-Value. These are floating point values, which might contribute to rounding/truncate errors. Maybe it's good for editing, or to share wave data. It is not good in showing what is exactly uploaded to the AWG.

The uploading command for my wave was:

Code: [Select]

C1:WVDT WVNM,Ramp,TYPE,5,LENGTH,32KB,FREQ,324.674987793,AMPL,0.899999976,OFST,0.352999985,PHASE,0.000000000,WAVEDATA,
Where after the WAVEDATA 32KB of wave data is added. The wave data consists of 16 bit liitle-endian signed integers. Little-endian meaning that the least significant part of the integer is in front of the memory.
x86 processors are little endian, so while reading/writing values we shouldn't have any problems.
The full 16 bit range is used while transferring the data so from -32768 to 32767. So it is unscaled data, the scaling is done while "playing" the data. This is what one should expect.

[HendriXML]

Via SCPI I downloaded some internal wave data, and my own ramp.

Showing them in Excel is a good way to check the format assumptions I've made. The Y-values are the unscaled integer values.

As can be seen these also have some dips (except the M5). I think they also used the same EasyWave application to create those.

I don't think dips in the waves fully explain the glitches, but I'm not going to test and check with ramps having dips in them.

[HendriXML]

Choosing AMPL and FREQ values which should have no issues using even the most simple "scaling algorithms" would be a good starting point for further testing.

It is also important to know that the 16 bit integers will be scaled by /4 to 14 bit also in the most optimal situation. The question is than also whether this is done in one step or two.


Also with what accuracy can the AWG calculate / scale. If the intermediate value can be a 32 bit value, one could calculate the value the DAC more like this WaveValue * Factor div (Divider * 4) where I would go for (WaveValue * Factor + Divider * 2) div (Divider * 4) to do some proper rounding.
otherwise the division has to be done before the multiplication. Which leads to more rounding errors.

However I think rounding errors, should not lift the curve at a traject. It may create a local slope problem, but that would be counter balanced after that.

So I'm guessing it's a timing problem, maybe in combination with rounding errors.

[HendriXML]

As for the question where the scaling of the Y-values is happening.

I'm almost certain it is digital.

1/4 amplitude 1/1 resolution waves, look similar in step size to 1/1 amplitude 1/4 resolution waves.

However the way they look is different.
The 1/4 resolution wave takes smaller steps (and uses only 1/4 of the digital "bandwidth"), but these steps are with 1 granularity and not 4. And also seem to have some glitches, which the other one does not seem to have.

I guess the extra bits in the 16bit samples are used for calculation. I know for certain that they are read back ok, after writing them.

Will think about the differences some more. (For now it's also good to remember that if we want a smaller amplitude, we can also create a new wave. Maybe with the benefit of more control)

[HendriXML]

I've now zoomed in till 1mV/div.

Showing a scaled waveform and a normal output scaled one. Now they seem very similar.

No AWG DAC steps are visible in either case. Noise (and probably the sine on the ramp we've seen before) have an to huge impact on the signal to get more details by averaging.

Conclusion: the previous graphs cannot easily be explained by zooming in.

There're things that where different in this experiment:
* Scope channel offset
* AWG offset
* AWG amplitude

[Rerouter]

The scaling is fixed per attenuator step, so the scaling is indeed digital, likely a hardware multiply / divide in the FPGA,

[HendriXML]

Now I'm quite sure that rounding and/or imperfect wavedata should not be cause for the glitches. I can still see them and my ramps are simple and flawless. And we also examined different kinds of scaling. (With one still unexplained difference.)

The experiments will be moving towards timing to see the effects of that on the glitches.

We know the sample rate of the AWG is 125 Mhz. We know a play cycle contains 16384 samples. Whom either can be stretched by playing samples more than once, of be compacted by skipping samples.
I've played a 250 hz version of my ramp (with a good amount of glitches), which means 4096000 samples/s would ideally be played. Which the AWG cannot, but it can play each sample about 30,5 times on average.

I also played a 250 hz version of a new more steep ramp (16383  steps of +8 instead of +4), which has 50% zero values in it.

What we see then is that the glitches (seem to be less, but that does not need to mean much), are noticeable at the exact Y-position.

Surely need to think that one through. Putting an offset in the wavedata might be an idea.

[HendriXML]

Two new graphs, one with +3 steps, and one with +3 steps and +1000 offset.

The glitches appear exactly at the same Y-pos.

This means we should see something happening with a ramp just around the problem area, but with changing the wavedata. This way everything else stays the same.

When the Y-values change slowly and a glitch would appear, that would maybe give the exact value where things go wrong., and maybe an indication on why.

[Rerouter]

I should point out all the glitches in your output appear periodic, e.g. the last image i can see atleast 5 of them very evenly spaced, It could be a glitch in how samples are scaled, what if you generate a waveform and run it at a frequency that is a perfect division of 125MHz? while still allowing every sample to be used.

[HendriXML]

I should point out all the glitches in your output appear periodic, e.g. the last image i can see atleast 5 of them very evenly spaced, It could be a glitch in how samples are scaled, what if you generate a waveform and run it at a frequency that is a perfect division of 125MHz? while still allowing every sample to be used.

The problem is that 125 M is not dividable by 16384. If we took 254,313151041668 hz then each sample would be played about 30 times. I'll try that after searching for the (input!) glitch value(s).

I've got a clear graph of the glitch, but thousands of values are still candidate.... It's a process of trial and error.

[Rerouter]

You have plenty of options than just frequency, you can also set by period, this gives many more cleaner divisions
Left is the period, right is how many times each sample is repeated in that period

There are more if you want them, these where just up to 5 significant figures, even if it does use frequency internally (don't know which it uses), these are clean enough divisions that it should limit the possibility of glitches.

0.0032768   25
0.0065536   50
0.0098304   75
0.016384   125
0.032768   250
0.049152   375
0.065536   500
0.08192   625
0.098304   750
0.16384   1250
0.24576   1875
0.32768   2500
0.4096   3125
0.49152   3750
0.57344   4375
0.65536   5000
0.73728   5625
0.8192   6250
0.90112   6875
0.98304   7500
1.2288   9375
1.6384   12500
2.048   15625
2.4576   18750
2.8672   21875
3.2768   25000

[HendriXML]

Added is a "2 value" ramp up, which shows exactly one Y-value on the wave data side of things that lead to a glitch.

Thus when going up from 2663 to 2664 it drops in the output about 2 mV.

Each value is thus repeated 8K times.

[HendriXML]

You have plenty of options than just frequency, you can also set by period, this gives many more cleaner divisions
Left is the period, right is how many times each sample is repeated in that period

There are more if you want them, these where just up to 5 significant figures, even if it does use frequency internally (don't know which it uses), these are clean enough divisions that it should limit the possibility of glitches.

0.0032768   25

Nice table, good thinking to reverse it. I think it works "internally" by frequency, because it does not update the period value in the GUI. But that might just be sloppy programming.

Code: [Select]

C1:BSWV WVTP,ARB,PERI,0.0032768,AMP,1,OFST,0.5
I don't think there're less glitches. There must also be an perfect amplitude, but then we need to know to what output the input values are mapped (step size).

[Rerouter]

I was suspicious it may be something else internally, as the resulting frequency had more then 7 significant digits after setting the period via SCPI

as per you having a weird step between 2 values, perhaps try setting it to the lower attenuator setting, it may have some correction table inside that will move the quirk

[HendriXML]

The glitch can be seen at every freq. I tried between 250 and 300.
However at the perfect period something fascinating happens (a glitch in a glitch?). It should be noted all output values are averaged (190x).

It is probably the "sine wave" we saw earlier. (At least the scope made a sine out of it. But we don't know if it is.) I think it is a sign that the triggering is in sync with the sample rate of the AWG.


I don't think the horizontal stuff affect the glitching much, except that it may bring integer values forward that are troublesome.

The missing piece of information is the step size, that might give a clue why for instance 2664 acts weird. Also what is origin of the 2 mV? How many steps would that be?

[Rerouter]

Well at a minumum, looks like your the glitch is interesting, 6V pk-pk, it should be a 16 bit DAC, but your offset looks almost exactly like it behaving like a 12 bit, 4096 steps, which comes to about 1.5mV per step,

Could you share your ramp waveform?

[HendriXML]

Well at a minumum, looks like your the glitch is interesting, 6V pk-pk, it should be a 16 bit DAC, but your offset looks almost exactly like it behaving like a 12 bit, 4096 steps, which comes to about 1.5mV per step,

Could you share your ramp waveform?

I think it is advertised as being a 14 bit DAC. It should be mapped to 6V pk-pk at least, but with what exact value do they calculate. Everything that is only a slight bit of does not give answers.
Changing the offset slightly until a step "toggles" would give some clue. But that is another DAC.

Changing the amplitude until it toggles tells a lot less, because an amplitude will be scaled.

 

[Rerouter]

sorry, yep 14 bit,

There may be some kind of calibration routine, But I am suspicious, it defiantly has enough memory on board to store some kind of correction table, just doesn't make much sense to me why it would exist, (decent hardware)

Just using the built in generated ramp I do not see any such glitch, only thing of note, hooking up another BNC cable between my scope and the AWG IN/OUT pin gets rid of most the glitches due to the USB noise.

[HendriXML]

Averaging is the key to bring the dark creatures to light.

Also it drops at a certain value, but it is not “restored” near that value. So quite a range of values are off.

I hope the calculations are faulty, that is something that can be fixed.

Just to be sure, your Sag1021 shows similar glitches?

[Rerouter]

I have scrolled 0V - 1.8V and have not seen any glitches, if I only have one BNC lead connected I will see spiking, but no sudden discontinuities like your graphs are showing.

[HendriXML]

For those who would like to test their AWG...

The attached CVS file should result into the
2663 and 2664 value ramp when send by EasyWave.

The values can be checked by NI I/O trace when copying the message.
67 0A = 2663
68 0A = 2664

It starts with a -0.5 and a 0.5 to have EasyWave force an amplitude of 1.0

Code: [Select]

72.  viWrite (TCPIP0::192.168.2.73::INSTR (0x1157ACD8), "C1:WVDT WVNM,Glitchy,...", 32888, 32888)
Process ID: 0x00002D1C         Thread ID: 0x00002860
Start Time: 14:26:42.166       Call Duration 00:00:00.007
Status: 0 (VI_SUCCESS)
Buffer Contents
00000000:  43 31 3A 57 56 44 54 20 57 56 4E 4D 2C 47 6C 69  C1:WVDT WVNM,Gli
00000010:  74 63 68 79 2C 54 59 50 45 2C 35 2C 4C 45 4E 47  tchy,TYPE,5,LENG
00000020:  54 48 2C 33 32 4B 42 2C 46 52 45 51 2C 32 35 30  TH,32KB,FREQ,250
00000030:  2E 30 30 30 30 30 30 30 30 30 2C 41 4D 50 4C 2C  .000000000,AMPL,
00000040:  31 2E 30 30 30 30 30 30 30 30 30 2C 4F 46 53 54  1.000000000,OFST
00000050:  2C 30 2E 30 30 30 30 30 30 30 30 30 2C 50 48 41  ,0.000000000,PHA
00000060:  53 45 2C 30 2E 30 30 30 30 30 30 30 30 30 2C 57  SE,0.000000000,W
00000070:  41 56 45 44 41 54 41 2C 00 80 FE 7F 67 0A 67 0A  AVEDATA,....g.g.
00000080:  67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A  g.g.g.g.g.g.g.g.
00000090:  67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A  g.g.g.g.g.g.g.g.
000000A0:  67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A  g.g.g.g.g.g.g.g.
000000B0:  67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A  g.g.g.g.g.g.g.g.
000000C0:  67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A  g.g.g.g.g.g.g.g.
000000D0:  67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A 67 0A  g.g.g.g.g.g.g.g.

.......

00008050:  68 0A 68 0A 68 0A 68 0A 68 0A 68 0A 68 0A 68 0A  h.h.h.h.h.h.h.h.
00008060:  68 0A 68 0A 68 0A 68 0A 68 0A 68 0A 68 0A 68 0A  h.h.h.h.h.h.h.h.
00008070:  68 0A 68 0A 68 0A 68 0A                          h.h.h.h.


[HendriXML]

I did some browsing on whether these are known problems and I came across this webpage. Seems familiar.

https://gasstationwithoutpumps.wordpress.com/2015/07/16/fg085-function-generator-bugs/

It also possible that it is not a firmware related issue, but a badly functioning DAC of just my device.

So it would be helpful if users would report having the same issues or not. If it is just my AWG I would like to have it fixed (warranty).

[HendriXML]

In the name of testing methods, I’ll try to find not the 1 but all of the glitching input values in a automated way.
How to?

From every input value the output value needs to be checked against the output value of the succeeding input value.
This means checking 65K values. The measuring is done with a 8 bit/256 value DSO. So we know it has to measure in many batches. In each batch a different “input value band” and “output value band” can be measured. At the input things are controlled, but at the output we have to make a good guess about the matching measurement window. Which also means having some margin.
We need to see 1mV changes so the 10 mV/div is a decent sensitivity to measure glitches, it won’t be sensitive enough tho see each individual AWG step. But that’s ok.
With 256 values / 10 divisions that would give a window of 102 mV. In which we should catch the output. But better to take 2 margins of 20 mV and use a window of 60 mV. Which would mean at least 17 windows to see the whole 1 V ramp.
In each batch we need to identify the output of each input. This can be done by guessing the time location of each sample. I think this can be done with a good accuracy if we could identify the start and thus ending of each cycle. This can for instance be done by starting with a minimum, maximum value pair. In the output it is easy to scan for those, everything in between is where the input values are mapped to.
For each input value, I’d like to have at least 128 output samples, using the middle 64 samples to calculate a time based mean (the skipped ones are used as a margin). The DSO delivers 70 kpts, which would mean 540 blocks of 128. But that’s in the case of having exactly 1 cycle, which is not doable. I guess 500 blocks of 128 gives a safe margin to have 1 full cycle in view.
Giving that there’re 65K values, we need 132 batches. (In every batch the last value of the previous one will be the starting one).
Because this is much more than the 17 we needed to resolve enough details. I think we can turn down the Vdiv to 5 mV/div.
With 16K of input samples, we need to create 500 output samples. Which would mean 32 samples for each input value. Because this will leave 384 samples its good to have both a start and stop “signal” to be used for (time based) mapping. The first block will also be duplicated so when measuring the second, there will be no ringing measured in that one.
It would be nice if the whole test would run in less than 4hrs. Which would give about 109 secs per batch. In that time the following will happen:
* input wave constructed
* wave played and triggered
* 378 segments will be downloaded and averaged
* the cycle needs to be identified in the output
* the 500 x 128 value blocks need to be averaged (64 values in the middle)

I’ll be running the script through my DIY script interpreter, fast but certainly not compiled like speeds.

For me this exercise means discovering some new techniques, which is a good motivator. Getting more information on the glitches not so, now that I’m starting to understand that it is not really possible to work around them.

Edit:
In the script I won’t do the actual comparing. Outputting the input value, output voltage and voltage difference to the succeeding one gives some extra information which can be analyzed.

[joeqsmith]

Sorry, I didn't read all your updates but it looks like the Arb is still in question.   When you show these glitches, what is the dv/dt?  I'm not sure when looking at your graphs what the units are.   

Why not make a simple triangle generator in analog.  You could have it drive a nice edge to the scope for the trigger.  Basically, remove the Arb from the equation, cutting the problem in half.   

[HendriXML]

Sorry, I didn't read all your updates but it looks like the Arb is still in question.   When you show these glitches, what is the dv/dt?  I'm not sure when looking at your graphs what the units are.

Hi Joe, the problem with the AWG is that a single step transition from 2663 to 2664 it output drops 2mV instead of rising. I really dislike this, so I’ll be automatically investigating all the glitches on the same ramp to get an idea of what they have in common. So it seems side tracking on a side track. But because the thread is not really about the the diode and resistor divider, but more about using the AWG and DSO as tools to investigate, I’ll keep things bundled here.
I guess I could still use the AWG to do better measurements, because the output affects both curves the same way. Time based averages should then be done over the same time ranges for both curves. (So the glitches are also included in the same averages.)
Also the glitches are 2mV, over a very short period of time, so it affects the slope much more than absolute values. Using function fitting I could for instance work around that.

[tautech]

Sorry, I didn't read all your updates but it looks like the Arb is still in question.   When you show these glitches, what is the dv/dt?  I'm not sure when looking at your graphs what the units are.

Hi Joe, the problem with the AWG is the at a single step transition from 2663 to 2664 it output drops 2mV instead of rising. I really dislike this, so I’ll be automatically investigating all the glitches on the same ramp to get an idea of what they have in common. So it seems side tracking on a side track. But because the thread is not really about the the diode and resistor divider, but more about using the AWG and DSO as tools to investigate, I’ll keep things bundled here.
I guess I could still use the AWG to do better measurements, because the output affects both curves the same way. Time based averages should then be done over the same time ranges for both curves. (So the glitches are also included in the same averages.)
Also the glitches are 2mV, over a very short period of time, so it affects the slope much more than absolute values. Using function fitting I could for instance work around that.

I can tell you this is under investigation at the factory for ~1 week now.
Dunno about progress or outcome yet.

Thanks for all your work. 

[HendriXML]

Sorry, I didn't read all your updates but it looks like the Arb is still in question.   When you show these glitches, what is the dv/dt?  I'm not sure when looking at your graphs what the units are.

Hi Joe, the problem with the AWG is the at a single step transition from 2663 to 2664 it output drops 2mV instead of rising. I really dislike this, so I’ll be automatically investigating all the glitches on the same ramp to get an idea of what they have in common. So it seems side tracking on a side track. But because the thread is not really about the the diode and resistor divider, but more about using the AWG and DSO as tools to investigate, I’ll keep things bundled here.
I guess I could still use the AWG to do better measurements, because the output affects both curves the same way. Time based averages should then be done over the same time ranges for both curves. (So the glitches are also included in the same averages.)
Also the glitches are 2mV, over a very short period of time, so it affects the slope much more than absolute values. Using function fitting I could for instance work around that.

I can tell you this is under investigation at the factory for ~1 week now.
Dunno about progress or outcome yet.

Thanks for all your work. 

Nice to know it got Siglents attention. I'm glad to help.  When I get my automated testing script done, I'll see if I can get my hands on a second unit/replacement. Maybe the seller I bought it from can make some sort of an arrangement. They're nice affordable devices, so I hope this gets fixed if its structural.

[joeqsmith]

Hi Joe, the problem with the AWG is the at a single step transition from 2663 to 2664 it output drops 2mV instead of rising.

Wow!  Say no more. 

[HendriXML]

The script is running.

I made a graph of the values -32768 to -24286. Showing the full dataset this way would probably to much.

In the current state it shows one digital glitch, which is the highest peak down. This happens at exactly 1 value, and occurs at each of the averaged samples on the same X-pos.

The other dips, are not digital. Because they're spread over more samples, I get the suspicion that it might be the fall of the superimposed "moving" square wave. (But where is its rise?)

As said before, if there're would be a way to stop it "moving in time" (different frequency?) it's effect might even be more pronounced.

Another issue is that it's not easy to calculate the AWG output for a certain input value. I shifted the AWG -40mV get the output in view at the calculated V-center of -496,19 mV.

It output center is then  -7,18 mV off, so in reality a -33mV should have done the trick. But that is still a lot, having the drop-glitches might also result in this effect. The glitch can be seen as a sudden drop, but also as a correction of a positive invalid offset. The value after the glitch, might as well be the more correct one.

The script takes these nonlinearities in account, and adds or substracts an extra error offset each batch, otherwise the output would run out of the measurement window.

[HendriXML]

The previous graph did show on the Windows image view, but not on an iPad, so here's another one. But to see all of the spikes, one needs to zoom in.

[HendriXML]

With a amplitude of 1V the following values show a glitch when succeding to the next one. Notice the 2663

Code: [Select]

-32301
-21373
-14817
-03893
 02663
 13591
 20147
 31075
The full dataset cannot be shown in a graph using Excel and Visio, but what also can be seen is that the other negative spikes become less around 0 and then become positive spikes.

[HendriXML]

For the positive values and their succeeding ones I did a quick decimal to binary conversion.
It does not show anything obvious. But there's scaling done before it enters the DAC, so I did not really expect to see something in the bits. With this script however I can do a higher amplitude as well!! That'll be next. (It would be nice to have no scaling (or a magnitude of 2), but I don't thing it's as simple as using the highest value).

Code: [Select]

02663-000101001100111-000101001101000
13591-011010100010111-011010100011000
20147-100111010110011-100111010110100
31075-111100101100011-111100101100100


[HendriXML]

These are the leaps to the next glitch:

Code: [Select]

-32301 10928
-21373 6556
-14817 10924
-3893 6556
2663 10928
13591 6556
20147 10928
31075
Something repeating can be seen. Which could maybe give us some clue!

[Rerouter]

Seeing as its periodic, It leaves me wondering if its a scaling artifact,

Most scaling is done by multiplying first then dividing to maintain the information through the process, but unless its followed by a modulo to recover the truncated information, and rounded based on that modulo, it still leaves room for artifacts.

[HendriXML]

Doing the higher amplitude values I get issues and also get a pretty good idea about what should be solved first!

The waves I feed, are 16 bit. Just like the EasyWave app made them. (Here lies the danger of not having any documentation!) So I thought they would be scaled to 14 bit.

But I think it should be 14 bit values to begin with. 

I'll start testing right away!

Edit..
Nope, the above seems not be the case, wishful thinking. It still seems to need 16 bits. But the higher amplitude acts really strange. I need to investigate that.

[Rerouter]

At the higher amplitude, can you describe what about it is behaving weird? I'm curious what the min and max output range you are seeing is, It would be interesting if it was using both dac's to hybridise the output. or even if the output span was higher than 6V pk-pk

[HendriXML]

At the higher amplitude, can you describe what about it is behaving weird? I'm curious what the min and max output range you are seeing is, It would be interesting if it was using both dac's to hybridise the output. or even if the output span was higher than 6V pk-pk

The mV per input step are crazy high (310 mV / 80 instead of 80 * 3 / 65536 = 36 mV / 80). The wave is padded with zero values.

So I think I've got to sit on the thinking stone for a while.

The glitches where however in a non arbitrary wave as well. So this does not need to be related.

[HendriXML]

The values in the wave are very sensitive to the amplitude, but they differ very little in input. So I guess the wave is not uploaded the way I would like (or not handled in the correct way, but what would be the odds). Interesting...

[HendriXML]

Just nice to know, how does the AWG's amplitude (6V pk-pk) go above the 5V usb connection? A boost converter?

[HendriXML]

It would be interesting if it was using both dac's to hybridise the output. or even if the output span was higher than 6V pk-pk

The easy wave app, does make such choices. To move a static bottom of a curve to a wave offset.
But that’s off course for the whole wave.

Just nice to know, how does the AWG's amplitude (6V pk-pk) go above the 5V usb connection? A boost converter?

The offset DAC should not need to be high speed. And could be of a better precision. So it would surprise me, that they would work together in a cycle.

But the thought crossed also my mind as well. That certainly could lead to “alignment” problems as well. I’m just starting to understand a bit of all this, that makes it hard to troubleshoot.
Maybe they’re indeed two fast lower resolution DAC’s. One amplified, one not.
The (output) of glitches did move with the offset, but if it’s hybrid then a much higher/lower offset might change or make glitch go away. That’s one thing I’ll test later.

You’ve seen the internals, any ideas on what DAC’s are used?

[Rerouter]

Main sample DAC: http://www.ti.com/jp/lit/ds/symlink/dac904.pdf
Offset DAC (I think): http://www.ti.com/lit/ds/symlink/dac8580.pdf
Output Amplifier: https://www.renesas.com/sg/en/www/doc/datasheet/el5166-67.pdf

Other Op Amp? http://www.szhuge.com/file/productpdf/945728698337600.pdf

The DAC is single rail. likely 0 to 5V, have not measured yet, but likely, The output op amp has a 5V and a -5V rail, so that is where its wider range is coming from, it gets filtered, scaled and then summed with the offset DAC to give the 6V pk-pk, the op amp starts to clip around +-4V

[HendriXML]

Thanks for the info! Will look into it.

I now know what is happening with the higher amplitude testing, but was also affecting the other measurements (but mostly in absolute voltages).

To signal the start and the end of the value blocks, I write either a high or a low pulse to the wave. (Low in case of testing high values, High otherwise). It is then easy to test for saturated DSO values. And get precise locations of both start and end.

But what I did not know while vertically zooming in (using for instance a 100mV/div instead op 500mV/div and a new offset), is that the voltage that is out of the "zoom window" does affect the measurement if it is far off. This can be seen in the 2 screenshots. It's the same signal, but with more or less above the "zoom window". (Pulse and zero padding)

I'm quite sure that this is also the reason the measurement needed that 30mV offset.

I did not know of this scope behaviour. What are the practical limits of zooming in using a smaller vertical window, than the signals amplitude. Is there a rule of thumb?
(I'm also a bit disappointed that it cannot be done freely.)

For now I'll make more suitable waves with not pulses to the max/min, but to values that should just saturate the DSO measurements. And also will not do simple zero padding, but the repeating of the last value. In this way the whole wave is (almost) within the "vertical window".

[HendriXML]

Main sample DAC: http://www.ti.com/jp/lit/ds/symlink/dac904.pdf

In the typical INL graph it shows -4 SLBs, which to my understanding would mean 4 x the step value. (I find that quite high)
That would in optimal scaling be: 6V / Power(2,14) * 4 = 1.4mV.
Could this be the cause of the glitches? But I would then expect a (short) drop until succeeding to other higher values in a ramp, not a continued drop for a whole range of values.
Also according to the definition of INL, all those values in such a range should than have a high INL. As can be seen in the graph, that’s not typical.

[HendriXML]

Here's some more information on offscreen voltages.

At the examples I start zooming in from 1000 mV./Div until 100 mV/Div. At 100 mV/div it should go offscreen but it becomes in view again.

This something that happens when there's a larger "area" (duty of square changes the effect) of voltages are "above the screen".

[tautech]

Here's some more information on offscreen voltages.

At the examples I start zooming in from 1000 mV./Div until 100 mV/Div. At 100 mV/div it should go offscreen but it becomes in view again.

This something that happens when there's a larger "area" (duty of square changes the effect) of voltages are "above the screen".

This:



Exceeds the channel voltage offset range as listed in the datasheet, that's all you're seeing.

[Rerouter]

I suspect its gain stage saturation, as things are charged above the specified input range it takes some time to bleed off the parasitic capacitances in the amplifier

before the ADC is the channel VGA (Variable Gain Amplifier), https://www.analog.com/media/en/technical-documentation/data-sheets/ad8370.pdf

you would have to check what the VGAC code is, but you could probably work that back to figure out how close to the limits of the input range you are at,

Pretty sure the ADC has a 200mV input range.

[HendriXML]

Here's some more information on offscreen voltages.

At the examples I start zooming in from 1000 mV./Div until 100 mV/Div. At 100 mV/div it should go offscreen but it becomes in view again.

This something that happens when there's a larger "area" (duty of square changes the effect) of voltages are "above the screen".

This:



Exceeds the channel voltage offset range as listed in the datasheet, that's all you're seeing.

There’s more to it. I will do some test to show how much offscreen voltage is allowed, without getting the measurements wrong. To agagerate:
If we had a -1V to 10V square wave, there will probably be troubles zooming in (100mV/div) on the -1V bottom,  which is within offset range. I hope my AWG support the ranges needed to get an idea of the effects. I’m working on it.

[HendriXML]

I suspect its gain stage saturation, as things are charged above the specified input range it takes some time to bleed off the parasitic capacitances in the amplifier

before the ADC is the channel VGA (Variable Gain Amplifier), https://www.analog.com/media/en/technical-documentation/data-sheets/ad8370.pdf

you would have to check what the VGAC code is, but you could probably work that back to figure out how close to the limits of the input range you are at,

Pretty sure the ADC has a 200mV input range.

Nice info!

The practical consequences I will try to measure. As said before, I think it had its influence without me knowing about it.

[HendriXML]

I measured the following waves:

Code: [Select]

C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.60000000000000013,OFST,0.30000000000000006,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.7,OFST,0.35,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.8,OFST,0.4,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1,OFST,0.5,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.2000000000000002,OFST,0.60000000000000013,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.3999999999999998,OFST,0.7,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.6,OFST,0.8,DUTY,50
The bottoms should all be at the V-centre, but when having more voltage offscreen, the center voltage "rises". This happens with even small voltages like 300mv. 3 times the V/div. Because there is almost 1 division of digital margin offscreen it is almost nothing beyond that.
Maybe I made a mistake, so I posted the AWG commands.

[HendriXML]

Different duty:

Code: [Select]

Siglent Technologies,SDS1204X-E,SDSMMDBQ2R3764,8.1.6.1.26
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.60000000000000013,OFST,0.30000000000000006,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.7,OFST,0.35,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.8,OFST,0.4,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1,OFST,0.5,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.2000000000000002,OFST,0.60000000000000013,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.3999999999999998,OFST,0.7,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.6,OFST,0.8,DUTY,1


[HendriXML]

As can be seen, even small pulses (1%)  affect the quality of the signal and a non existing rise of voltage.

However because of the differences in duty %, I’m not putting the AWG under investigation regarding offsets and amplitudes. I’ve also seen similar behavior of the scopes with it’s test signal.

I’ve read this about it:
https://electronics.stackexchange.com/questions/287515/is-it-bad-to-let-an-oscilloscope-trace-go-off-screen

But I don’t think with my/this scope one can say that there’re multiple screens of headroom.

[Rerouter]

Its not always 1 division off screen, its more like 0.5, its mainly to eat up the steps between VGA codes to allow for ideal scaling, the measure UI gives a good idea of where this limit is, as it just works off the raw data points,

Equally yeah things will start misbehaving if you go a large amount outside the common mode range, you can use fine gain control to shift things in your favor, I suspect when you exceed the top of the ADC's true capture range it has some hardware protection, and by shunting current is causing your offset.

I suspect this protection is after the VGA, as there is no idiot proof way that it could not be set to a bad code and send a volt into the ADC,

[HendriXML]

Its not always 1 division off screen, its more like 0.5, its mainly to eat up the steps between VGA codes to allow for ideal scaling, the measure UI gives a good idea of where this limit is, as it just works off the raw data points,

Equally yeah things will start misbehaving if you go a large amount outside the common mode range, you can use fine gain control to shift things in your favor, I suspect when you exceed the top of the ADC's true capture range it has some hardware protection, and by shunting current is causing your offset.

I suspect this protection is after the VGA, as there is no idiot proof way that it could not be set to a bad code and send a volt into the ADC,

To my understanding 200 steps of the ADC are on screen, the other 56 steps are off. That’s why I thought there’s one division of digital headroom, below and above.
I don’t know how to compare the found analog headroom to other scopes, but reading the stackexchange answer, I’m a bit surprised that is so low.

Anyway it is a good thing to know about one’s scope.

My technique of creating signal samples is then also too disruptive, will use a calculated (time) range instead. But will first check how accurate that will be.

[HendriXML]

One technique I will test is having for instance 500 blocks of alternating values in a wave. And then getting those values measured in the DSO (without using signal values). When mapping is perfect all samples in the DSO could be used for that. But that is not doable. Because of inaccuracies of the trigger delay and difference between sample rates and stuff.
As the drawing shows I will create a test wave to examine the usability.
The start / end block can be identified separately for validating the start and end.
Each block in between also alternates. The question that will be answered is this:
How many DSO samples within each block can be used, without a single wrong value.
For instance, when a block has a width of 100 DSO samples and we take only the (calculated) middle one, the prediction could be 48 samples off and we still get a good value. But the more we try to use, to more accuracy is needed.
If we get a minimal of 70 correct middle ones for all blocks, then we know that taking just 50 middle ones is on the safe side and without any worries in a comparable situation.

[genghisnico13]

I recently replicated some of rigol's comparisons about overload recovery in a RTB2000 https://www.eevblog.com/forum/testgear/rigols-view-on-rtb2000/msg2378664/#msg2378664.
As you can see the signal gets distorted for 1-2ms after coming back to the screen, this distortion started to appear at 50mV/Div when the signal goes above +2.2V.

[HendriXML]

Seems like great scope, nice high res screenshots also.

(I will have to tune my gridlines colors in mine a bit better.)

Also nice to know after reading the thread I was a misuser of the vertical offset. 

Once I asked my self the question whether it would be ok to use it as a zoom centerer. Having had “good” results with it, it became something to do without further thinking about it. Sometimes even with a vague sense that is was magically handy.

Damn, another illusion gone. But better to know of it, so a bit of knowledge richer.

[HendriXML]

From Rerouter, I got to understand the AWG also has amplitude ranges (attenuator). From changing some values and hearing the relais clicking I know their max values are:
A: 63mV >= Ampl  < 64 mV
B: 632mV >= Ampl  < 633 mV
C: 6V >= Ampl  < ??

I may try more values to get an exact number, but this could be a way to guess/determine the unscaled step value of the highest range:
0.1x: 63.2mV >= Ampl  < 63.3 mV
1x: 632mV >= Ampl  < 633 mV
10x: 6.32V >= Ampl  < 6.33 V

It does not need to be this way, but sometimes verifying one value is easier than getting the right one. So I post it here as a reminder.

[HendriXML]

I'm trying to restrict the number of samples via the SCPI command WAVEFORM_SETUP / WFSU in the form:
WFSU SP,0,NP,1024

if I query WAVEFORM_SETUP? it even returns: SP,0,NP,1024,FP,0
But it does not limit the downloaded samples.

Am I missing something?

[HendriXML]

Did the limiting after downloading myself.

This graph shows (if one zooms in) 100 alternating input blocks at 300 hz acquired in 33333 samples x 378 frames by the DSO. The yellow line represents the averaged values (of 50%). The red dots the maximum value, the blue dots the minimal value of all the frames. (How well frames are aligned also determines the usefulness of centre samples.)

In this test a centre value would be considered valid is both the minimal and maximum value match the blocks expected value(range).

As can be seen the triggering delay might need a slight adjustment. But overall think this might give good results, but with 500 blocks things might get a bit tight. This partly because the DSO sample cannot be matched nicely with the freq. (Only 33% samples are used)

[HendriXML]

What can be seen on the first screen shots, is that the signal has an offset of around 56mV.

I did 2 offsets to check whether it is a scope measurement issue, or an AWG issue.

Both the lower and higher part of the square wave are off about that amount. So it is an AWG problem.

Yes, it was zero adjusted. But I think that is adjusting the offset DAC. It seems that the other DAC needs adjusting much more!

56 mV on a 1300 mV amplitude. (It's a build in square, so there should be troubles with the wave itself. Also other waves seem to have the same offset.)

The lesson that can be learned from this is: do the zero adjusting with an active wave in mind!

[HendriXML]

If I setup a wave, with an offset of 0 via SCPI cmd:

Code: [Select]

C1:BSWV WVTP,ARB,FRQ,300,AMP,1.3,OFST,0

It's offset gets added by -1.0 x zero balance offset!!

What could be a valid reason for that? Now the signal is still off!!

[HendriXML]

So the DSO value ranges cannot be accurately “predicted” because of the very high offset. But it can be determined by searching for the highest and lowest value. And than determining:
Offset = (High + Low) / 2
Amplitude = High - Low

The valid valid range for a
Start would be: MinSampleValue - Offset > 0.95 * 0.5 * Amplitude
High would be: (MinSampleValue - Offset > 0.45 * 0.5 * Amplitude) and (MaxSampleValue - Offset < 0.55 * 0.5 * Amplitude)
Low would be: (MinSampleValue - Offset > -0.55 * 0.5 * Amplitude) and (MaxSampleValue - Offset < -0.45 * 0.5 * Amplitude)
End would be: MaxSampleValue - Offset < -0.95 * 0.5 * Amplitude

Or a bit more efficient in calculating stuff that does not change per sample.

Start would be: MinSampleValue > 0.95 * 0.5 * Amplitude + Offset
High would be: (MinSampleValue > 0.45 * 0.5 * Amplitude + Offset) and (MaxSampleValue < 0.55 * 0.5 * Amplitude + Offset)
Low would be: (MinSampleValue  > -0.55 * 0.5 * Amplitude + Offset) and (MaxSampleValue  < -0.45 * 0.5 * Amplitude + Offset)
End would be: MaxSampleValue < -0.95 * 0.5 * Amplitude + Offset

[Rerouter]

I think the scpi offset does not have the awg offset applied to it. I will have a look today if there is any easy way to read that offset via command

[HendriXML]

I think the scpi offset does not have the awg offset applied to it. I will have a look today if there is any easy way to read that offset via command

If you can find it, great!

I looked for it for a short while. It is for example also missing in the WFSU? message.

In the UI it is "shown" in the Amplitude / Offset setting, but not in the LowLevel / HighLevel setting.

[HendriXML]

So here are my DSO values again, but now with the validation bands drawn as well. Red lines mean red dots (max value in all frames) may not cross, blue lines means blue dots (min value in all frames) may not cross.

So to remind:
This is a test to determine how well we can find blocks of AWG samples back as blocks in the DSO samples. And how much middle values within a DSO block should only have values of the same AWG block.
For now were have looked at the vertical part to determine a range to validate a DSO sample to.

The next step is to determine the DSO output blocks, by dividing the samples evenly (thus without using vertical data for that). And then to validate each DSO sample whether is has gotten in the correct DSO block.
We are only interested in continuous valid samples in the middle of each. Here's where we extract and average the data from each block in a real situation. The other samples are misalignment margins. The purpose of this test dataset is to determine how much margin is needed.
The margin is determined by the block with the least valid samples in the middle.
While it may all look nice in the graph, the determination of how much middle values can be used is very strict. In a real situation, we don't want to average "middle values" that belong to different input samples. So the usable values range may become a lot smaller when using more than 100 sample blocks.

[HendriXML]

Because it may be so that the AWG has scaling problems, which will be further tested, it might be informative to show how I calculated the range values without using floating point calculations, but with proper rounding. (It know it rounds a 1/2 down, but technically it is just as close to the below and above value, so I don't mind)
It's about moving divides to a single one and adding half of the divider before doing so.

Code: [Select]

            <Variable Identifier="SummedOffsetX2X100" Type="Int32" Init="(HighestValue + LowestValue) * 100"/>
            <Variable Identifier="SummedAmplitude" Type="Int32" Init="(HighestValue - LowestValue)"/>
            <Variable Identifier="Divider" Type="Int32" Init="100 * 2 * Count"/>
            <Variable Identifier="HalfXDivider" Type="Int32" Init="Divider div 2"/>
            <Execute Statement="StartRangeLow:= (95 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>
            <Execute Statement="HighRangeHigh:= (55 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>
            <Execute Statement="HighRangeLow:= (45 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>
            <Execute Statement="LowRangeHigh:= (-45 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>
            <Execute Statement="LowRangeLow:= (-55 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>
            <Execute Statement="EndRangeHigh:= (-95 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>


[Rerouter]

The waveform setup only applies when you use "<trace>:WF? ALL" for what ever reason its ignored for "<trace>:WF? DAT2"

for the channel calibration, the "PRINTCALI" command may interest you.

And finally for the AWG offset, I suspect your going to need to make use of manual button navigation to run the auto offset at startup, then when you read back with BSWV? it will then have the offset you will have to use, that or just run it manually before hand to grab the value. also you can use key "14" as a beep if you wish to have the script notify you.

Code: [Select]

Command syntax:
SY_FP <key>, <value>
For buttons, any integer is a press,
For knobs, a value of -1 is decrement, 0 is the button, 1 is increment, higher numbers correspond to moving that amount, e.g. 200 would be 200 clicks

keys:
0 - Menu Clear Button
1 - Function 1 (left most key on bottom of screen)
2 - Function 2
3 - Function 3
4 - Function 4
5 - Function 5
6 - Function 6
7 - Timebase (Decrease -1/ 0 Button / Increase 1)
10 - Timebase Offset (Decrease -1/ 0 Button / Increase 1)
11 - Autosetup Button
12 - Run / Stop Button
13 - Default Button
15 - Intensity (Decrease -1/ 0 Button / Increase 1)
16 - Trigger Level (Decrease -1/ 0 Button / Increase 1)
17 - Auto Trigger Button
18 - Trigger Button
19 - Normal Trigger Button
20 - Single Trigger Button
22 - Cursors Button
23 - Display / Persist button
24 - Utility Button
25 - Print Button
26 - Measure Button
27 - Aqcuire Button
28 - Save/Recall Button
29 - Decode Button
30 - Digital Button
31 - Math Button
32 - Reference Button
35 - Channel 1 VDIV (Decrease -1/ 0 Button / Increase 1)
36 - Channel 2 VDIV (Decrease -1/ 0 Button / Increase 1)
37 - Channel 3 VDIV (Decrease -1/ 0 Button / Increase 1)
38 - Channel 4 VDIV (Decrease -1/ 0 Button / Increase 1)
39 - Channel 1 Button
40 - Channel 2 Button
41 - Channel 3 Button
42 - Channel 4 Button
43 - Channel 1 Offset (Decrease -1/ 0 Button / Increase 1)
44 - Channel 2 Offset (Decrease -1/ 0 Button / Increase 1)
45 - Channel 3 Offset (Decrease -1/ 0 Button / Increase 1)
46 - Channel 4 Offset (Decrease -1/ 0 Button / Increase 1)
47 - Clear Sweeps Button
48 - History Button
49 - Roll Button
50 - Search Button
51 - Navigate Button
52 - Left Navigation Button
53 - Stop Navigate Button
54 - Right Navigate Button

[HendriXML]

The waveform setup only applies when you use "<trace>:WF? ALL" for what ever reason its ignored for "<trace>:WF? DAT2"

That’s good to know. Maybe it is also possible to grab one at a time segment/frame this way. I guess segment and frame are the same thing. This would be a step more robust then changing the active frame.
Using ALL I’ll need to do some more parsing. It would be nice if the documentation was better in this regard.

[Rerouter]

I can share what I have documented, but its mainly lifted from other manuals

Code: [Select]

:WaveForm | :WF
Query Syntax

<channel>:WaveForm?

Description

A WAVEFORM? Query transfers a waveform from the oscilloscope to the controller. A waveform consists of several distinct entities:
1. the descriptor (DESC)
2. the auxiliary data (DAT1) block3. the main data (DAT2) block
The WAVEFORM? Query instructs the oscilloscope to transmit a waveform to the controller. The entities may be queried independently. If the “ALL” parameter is specified,all four or five entities are transmitted in one block in the order enumerated above.
Note:1. The format of the waveform data depends on the current settings specified by the last WAVEFORM_SETUP command.
2.The format of the waveform data can be seen by the TEMPLATE? Query.

Parameter

Name

Type

Range

Default

 
<channel>

Discrete

{C1|C2|C3|C4|DI|D0|D1|D2|D3|D4|D5|D6|D7|D8|D9|D10|D11|D12|D13|D14|D15|MATH}

 
Query Example

C1:WF? /*Returns the waveform data block of Channel 1*/

Code: [Select]

WaveForm_SetUp | WFSU
Command Syntax

WaveForm_SetUp FP, <first point>,NP,<num of points>,SP,<spacing>

Query Syntax

WaveForm_SetUp?

Description

The WAVEFORM_SETUP command specifies the amount of data in a waveform to be transmitted to the controller. The command controls the settings of the parameters listed below.

Parameter

Name

Type

Range

Default

 
<first point>

Numeric

First Data Point

 
 
<num of points>

Numeric

0 is all, above is maximum amount of points

 
 
<spacing>

Numeric

0:1 is all, above sends only Nth point

 
Command Example

WFSU FP,200 /* Sets the first point to 200.*/

Query Example

WFSU?    /* */

[HendriXML]

And finally for the AWG offset, I suspect your going to need to make use of manual button navigation to run the auto offset at startup, then when you read back with BSWV? it will then have the offset you will have to use, that or just run it manually before hand to grab the value. also you can use key "14" as a beep if you wish to have the script notify you.

Thanks for the keys!

For this, I won’t use UI automation. These things can easily go wrong, if the UI is in a unexpected state, or something in it has changed. Also the offset I need cannot be created with the automatic zero function. Waves need a different offset value (a lot higher).
PS
I did test the BSWV? before, but there was no offset in it.

[HendriXML]

I can share what I have documented, but its mainly lifted from other manuals

I’m shopping out of other manuals too, thanks to Google. But a descent description of the returning data I’ve not yet seen. These things I don’t get. If one implements this stuff, it needs documentation as well, why not share it? That’s what you’re supposed to do with interfaces...

[Rerouter]

There are also 3 related commands if you wish to navigate frames.

FPAR Frame_PARam
FRAM FRAMe_set
FTIM Frame_TIMe

set lets you request the current frame number or set the frame on screen, and I suspect relates to its data,
Time gives you the interval time,
and par, well I'm not 100% clear what it gives,

As to your last reply, the "default" key puts the scope in a known menu state and you can update that default to whatever settings you wish, for me it puts it on utility menu page 1, but I have edited it from the original so less clear what it was (now wondering if I can use it to jump to hidden menus)

[HendriXML]

There are also 3 related commands if you wish to navigate frames.

FPAR Frame_PARam
FRAM FRAMe_set
FTIM Frame_TIMe

set lets you request the current frame number or set the frame on screen, and I suspect relates to its data,
Time gives you the interval time,
and par, well I'm not 100% clear what it gives,

As to your last reply, the "default" key puts the scope in a known menu state and you can update that default to whatever settings you wish, for me it puts it on utility menu page 1, but I have edited it from the original so less clear what it was (now wondering if I can use it to jump to hidden menus)

That what i use now. But I like my commands to be as independent of the UI state as possible.
That’s just a habbit. Writing multi user / multi threaded stuff requires taking that into account.

[HendriXML]

Img..

I think it show it it the DC mode, but not wave. But that can still be handy!
Parsing the answer shouldn’t be to hard.

[Rerouter]

these help?

[HendriXML]

these help?

If that’s not an offset on top of the zero adjustment offset, then it response depends on the route to this query. 

[Rerouter]

Like I said, the auto-zero offset does not get corrected for, so you will likely have to include it in your routine, and offset all values by that amount,

[HendriXML]

Like I said, the auto-zero offset does not get corrected for, so you will likely have to include it in your routine, and offset all values by that amount,

So that is the route dependency...(?)
But in my modded setup  it’s is only 1mV, and I want the 56mV of the needed wave offset in it. But using waves, that gets thrown out again by undoing it.
I could put 56mV in my scripts, but it would much nicer if it’s value was maintained, stored and accessible in the device.

[Rerouter]

the value is maintained, but just not for SCPI, if you power cycle the device then it defaults to that offset on the UI, but SCPI will still show the raw value its correcting for,

The offset is also maintained per SN if you where to use multiple units, in "usr\bin\siglent\usr\awg_zero_cal.txt" but short of telnet there are not any easy ways I am aware of to print this value, which is why I was suggesting to read the offset on SCPI after a "default" or restart

[HendriXML]

And I really appreciate the effort you’re putting in to this! Will check this when I’m in front of the scope again. I mainly work remote doing this kind of stuff.

It would be nice if it had a remote shutdown and a WOL functionality...

[Rerouter]

"SHELLCMD reboot" is a start, if your better at linux than me, you may have ideas for what else could be done to implement what your after

[HendriXML]

"SHELLCMD reboot" is a start, if your better at linux than me, you may have ideas for what else could be done to implement what your after

For another device I followed this guide:
Support restart/shutdown through OctoPrint's system menu
In Settings > Commands, configure the following commands:
Restart OctoPrint: sudo service octoprint restart
Restart system: sudo shutdown -r now
Shutdown system: sudo shutdown -h now
 Note
If you disabled Raspbian's default behaviour of allowing the pi user passwordless sudo for every command, you'll need to explicitly allow the pi user passwordless sudo access to the /sbin/shutdown program for the above to work. You'll have to add a sudo rule by creating a file /etc/sudoers.d/octoprint-shutdown (as root) with the following contents:
pi ALL=NOPASSWD: /sbin/shutdown

[Rerouter]

you don't need sudo, the command runs as root user, however "SHELLCMD shutdown" does not seem to work, only reboot, its equivilent to typing the command into a telnet session as root user.

[HendriXML]

I'm running a new glitch test at 3.0 V.

The scope measurements are now done without any offscreen (overdrive) voltages. This is quite an improvement in signal stability, which can be seen in the graph. The glitches are now even more recognisable.

The AWG and DSO sample block mapping is now done via an accurate trigger delay and time calculations. but first I did very strict test in how many center values of each block are certain to be mapped ok. With 500 blocks in the wave form this leads eventually to about 132 DSO samples per block, of which (at the very least) 118 are always mapped correctly. To be even more certain the script only takes 100 of them to do the extra averaging.

I find the mapping accuracy (118/132 in the very worst block) almost hard to believe, maybe there's a bug in the script. (This stuff is also hard to test.) But for now the results look promising.

[HendriXML]

It is still running but as can seen below it is very repetitive (Next glitch dist is 3384 or 2028).

Code: [Select]

InputValue Diff (V) Dif (mV) Next glitch dist
-31645 -0,0012 -1,23 3384
-28261 -0,0011 -1,15 2028
-26233 -0,0016 -1,57 3384
-22849 -0,0013 -1,34 2028
-20821 -0,0014 -1,38 3384
-17437 -0,0011 -1,11 2028
-15409 -0,0012 -1,22 3384
-12025 -0,0013 -1,25 2028
-9997 -0,0013 -1,26 3384
-6613 -0,0012 -1,22 2028
-4585 -0,0013 -1,35 3384
-1201 -0,0013 -1,34 2028
827 -0,0020 -1,99 3384
4211 -0,0009 -0,92 2028
6239 -0,0014 -1,41

The next test I will try to run at 632mV. Which might be without being mathematically scaled. But that give's very small steps and thus maybe hard to measure. (Are the glitches even a multitude of the step size?)

[HendriXML]

The more accurate values, where the relais clicks to switch to a different AWG ampl. attenuation are:

Code: [Select]

00.632424378781
0.063242837

Almost a factor 10...

[HendriXML]

The test is running, and the first glitch can be seen.

Whether you find glitches interesting or not, the method of making a 0.14mV spike so visible is a six on a stick!

[HendriXML]

It's glitching at the same input values... (these are almost the full lists, the same stuff continues )

3000mVpp

Code: [Select]

InputValue Diff (V) Dif (mV) Next glitch dist
-31645 -0,0012 -1,23 3384
-28261 -0,0011 -1,15 2028
-26233 -0,0016 -1,57 3384
-22849 -0,0013 -1,34 2028
-20821 -0,0014 -1,38 3384
-17437 -0,0011 -1,11 2028
-15409 -0,0012 -1,22 3384
-12025 -0,0013 -1,25 2028
-9997 -0,0013 -1,26 3384
-6613 -0,0012 -1,22 2028
-4585 -0,0013 -1,35 3384
-1201 -0,0013 -1,34 2028
827 -0,0020 -1,99 3384
4211 -0,0009 -0,92 2028
6239 -0,0014 -1,41

632.424378781 mVpp

Code: [Select]

InputValue Difference Next glitch dist
-31645 -0,00015 3384
-28261 -0,00014 2028
-26233 -0,00017 3384
-22849 -0,00013 2028
-20821 -0,00017 3384
-17437 -0,00013 2028
-15409 -0,00018 3384
-12025 -0,00013 2028
-9997 -0,00016 3384
-6613 -0,00014 2028
-4585 -0,00017 3384
-1201 -0,00016 2028
827 -0,00027 3384
4211 -0,00012 2028
6239 -0,00017 3384
9623 -0,00016 2028
11651 -0,00016 3384
15035 -0,00013 2028
17063 -0,00017


[HendriXML]

The question that might need answering is what is so special about going from 827 to 828. That glitch is both times relevantly lower (thus more glitchy) and is closest to 0.
Will do more of these experiments, to find out which factors change the outcome.

Code: [Select]

827=1100111011
828=1100111100

4211=1000001110011
4212=1000001110100

It may that we see raw (unscaled or transformed) DAC issues here which are of a weak third bit? Or the dacs first bit? (16 bit -> 14 bit) Not adding enough voltage?

But then it should happen much more often.. So maybe it is a combination with other bits as well.

At a later time I'll automate the conversion to bits for all glitch transitions, instead of using a webpage for it.

[HendriXML]

Binary conversion of the transition values

Code: [Select]

-31645/-31644
1000010001100011
1000010001100100

-28261/-28260
1001000110011011
1001000110011100

-26233/-26232
1001100110000111
1001100110001000

-22849/-22848
1010011010111111
1010011011000000

-20821/-20820
1010111010101011
1010111010101100

-17437/-17436
1011101111100011
1011101111100100

-15409/-15408
1100001111001111
1100001111010000

-12025/-12024
1101000100000111
1101000100001000

-9997/-9996
1101100011110011
1101100011110100

-6613/-6612
1110011000101011
1110011000101100

-4585/-4584
1110111000010111
1110111000011000

-1201/-1200
1111101101001111
1111101101010000

827/828
0000001100111011
0000001100111100

4211/4212
0001000001110011
0001000001110100

6239/6240
0001100001011111
0001100001100000

9623/9624
0010010110010111
0010010110011000

11651/11652
0010110110000011
0010110110000100

15035/15036
0011101010111011
0011101010111100

17063/17064
0100001010100111
0100001010101000

20447/20448
0100111111011111
0100111111100000

22475/22476
0101011111001011
0101011111001100

25859/25860
0110010100000011
0110010100000100

27887/27888
0110110011101111
0110110011110000

31271/31272
0111101000100111
0111101000101000


[HendriXML]

All the glitches (24x!) sum up to a total drop of -31mV (not very precise)
The extra offset I need to have the measurements in center is: 43mV

What if they are caused by the same error?

I haven't seen issues with the amplitude, though. So it is not as simple as that lower values output to high and that at the glitches it drops more to the expected output. If that was the case, the top of the amplitude wouldn't be raised as well.

[HendriXML]

Binary conversion of the transition values

Code: [Select]

-31645/-31644
1000010001100011
1000010001100100

-28261/-28260
1001000110011011
1001000110011100

-26233/-26232
1001100110000111
1001100110001000

-22849/-22848
1010011010111111
1010011011000000

-20821/-20820
1010111010101011
1010111010101100

-17437/-17436
1011101111100011
1011101111100100

-15409/-15408
1100001111001111
1100001111010000

-12025/-12024
1101000100000111
1101000100001000

-9997/-9996
1101100011110011
1101100011110100

-6613/-6612
1110011000101011
1110011000101100

-4585/-4584
1110111000010111
1110111000011000

-1201/-1200
1111101101001111
1111101101010000

827/828
0000001100111011
0000001100111100

4211/4212
0001000001110011
0001000001110100

6239/6240
0001100001011111
0001100001100000

9623/9624
0010010110010111
0010010110011000

11651/11652
0010110110000011
0010110110000100

15035/15036
0011101010111011
0011101010111100

17063/17064
0100001010100111
0100001010101000

20447/20448
0100111111011111
0100111111100000

22475/22476
0101011111001011
0101011111001100

25859/25860
0110010100000011
0110010100000100

27887/27888
0110110011101111
0110110011110000

31271/31272
0111101000100111
0111101000101000


Just some thinking out loud:
Looking at the bit's I don't any obvious similarities. Yes the first 2 bits overflow, but with 16 bit input values, using a 14 bit AWG that may not be very strange. At bit level the similarities are not obvious, but at integer level, the distances between them are very similar.
So I think a calculation/rounding error might then be more likely.

Off course these input values might also be scaled in such way, that the bits feeded to the DAC do have similarities. In that case the distances between glitch values might relate to ADC values that toggle the same bit of the DAC. What bit toggles 24 x times in this range? None but the closest would be bit 9 (32x). It also could be combinations of bits, but then there would be quite a few of them, because the toggling of different bits would also coincide in many case (bit 10 and 11 coincide 50% of the time).
Also it doesn't show any obvious up glitches, which should happen is a faulty bit would changed back.

Also why do they glitch at the same input values? Only one of the amplitudes was chosen with great accuracy. So the scaling should not be the same.
Edit - correction: most of the scaling is done by a VGA (Variable Gain Amplifier). So it is very likely that if there's even scaling involved, that it is the same for the tested amplitudes.
That brings us also to following the question: if it is a calculation/rounding error, what needs to be calculated?

[Rerouter]

You can probe the pins on the DAC to see what is going on, it looks like there all in a row, If you have an example waveform of it just jumping between 2 values, and the SCPI commands (the actual ones, not the psudocode out of your program) I can see what is happening, as mine is currently pulled down

Equally if you had a USB analyser, the 4 pin header directly next to the USB port is all the USB pins

[HendriXML]

You can probe the pins on the DAC to see what is going on, it looks like there all in a row, If you have an example waveform of it just jumping between 2 values, and the SCPI commands (the actual ones, not the psudocode out of your program) I can see what is happening, as mine is currently pulled down

Equally if you had a USB analyser, the 4 pin header directly next to the USB port is all the USB pins

I might need to claim warranty on the device, so I keep it closed.

But if you would like to do some measuring, I made a CSV file (usable for EasyWave) a few posts back that should give exactly 2 alternating values that glitch. However the SCPI output should be verified whether if they contain the values.

https://www.eevblog.com/forum/testgear/using-a-awg-and-a-scope-do-a-low-voltage-level-characterization-of-a-1n4005/msg2374044/#msg2374044

[HendriXML]

The SCPI commands I send to the AWG (scope) are partly binary. I could create a binary file, but it might be problematic for you to send it to the AWG. Do your tools support such a file?

[Rerouter]

Was more for the setup commands, to make sure I was running it exactly as you had, but for a laugh, here you go, compared to yours, looks like mine have something even weirder going on.

[HendriXML]

I forgot to mention it, for EasyWave not to do any scaling/transforming stuff, I had to put a max/min value in front of the wave. That is what we're looking at.
To find the glitch one needs to zoom in at the horizontal middle, and don't mind the overdrive..

[HendriXML]

Code: [Select]

InputValue Sum OutputValue SucceedingOutputValue Difference ValueDiff
-31645 -320143 -1,26E+00 -1,26E+00 -1,13E-03 3384
-28261 -532581 -1,12E+00 -1,12E+00 -1,25E-03 2028
-26233 -442748 -1,04E+00 -1,04E+00 -1,33E-03 3384
-22849 313497 -9,01E-01 -9,02E-01 -1,14E-03 2028
-20821 388458 -8,18E-01 -8,20E-01 -1,46E-03 3384
-17437 171607 -6,79E-01 -6,80E-01 -1,20E-03 2028
-15409 224395 -5,96E-01 -5,97E-01 -1,43E-03 3384
-12025 28208 -4,57E-01 -4,58E-01 -1,20E-03 2028
-9997 65218 -3,75E-01 -3,76E-01 -1,10E-03

More of exactly the same inputvalues, but now at 2.7 V amplitude.

Does this AWG even change amplitude by scaling values fed to the ADC?

That's probably where this comes in play as mentioned before: VGA (Variable Gain Amplifier).

[Rerouter]

If you have the bin file, likley going to be much easier to just load via USB

[HendriXML]

If you have the bin file, likley going to be much easier to just load via USB

Is not a doc, but a bin file 

The wave contains two values: 50% 827 and then 50% 828

(it took some while, had to create and test one)

[Rerouter]

fun for you, the amplitude limits are only enforced on the UI, if you go direct via SCPI, you can set the amplitude down to 2mV and up to 6.3243878V wonder if this could help with your glitches, Personally it looked OK for me, main issue is it would not allow scaling less than 4mV by default, with the SCPI trick that gets it to 2mV apart, but not representative of what your chasing, its weird how the bin files behave against how the .csv ones do.

[HendriXML]

Did some amplitude testing, the same 827 glitch can be seen until the amplitude of 1.99991, at 1.99990 it disappears.
At 1.99990 the average value is 80.3 mV
At 1.99991 the average value is 52.1 mV
The very small positive change in amplitude gives a glitch and a drop of 29.2 mV
I don't hear any relais clicking. This might be another useful peace of information.
I will now extract all the glitches at 1.9V and see at what values they're shown.

[tinhead]

I might need to claim warranty on the device, so I keep it closed.

i think this is the major problem, you device is bit wired from beginning, you should replace it and continue AWG work after that

[HendriXML]

So at 1.99990V the other know glitch values come to live.
These are only 8 values

Code: [Select]

-32301 142770 -1,67E-03 10928
-21373 173773 -1,35E-03 6556
-14817 269850 -1,63E-03 10924
-3893 200975 -1,56E-03 6556
2663 -476178 -2,69E-03 10928
13591 246249 -1,28E-03 6556
20147 -407143 -1,75E-03 10928
31075 245817 -1,51E-03

Bits and stuff

Code: [Select]

-32301/-32300
1000000111010011
1000000111010100

-21373/-21372
1010110010000011
1010110010000100

-14817/-14816
1100011000011111
1100011000100000

-3893/-3892
1111000011001011
1111000011001100

2663/2664
0000101001100111
0000101001101000

13591/13592
0011010100010111
0011010100011000

20147/20148
0100111010110011
0100111010110100

31075/31076
0111100101100011
0111100101100100


[HendriXML]

I might need to claim warranty on the device, so I keep it closed.

i think this is the major problem, you device is bit wired from beginning, you should replace it and continue AWG work after that

I think there's not much to be tested anymore and at least one other AWG does not have the same problem, so it is not a firmware kind of bug.

It's very likely a DAC problem, what bothers me that I cannot relate it to a single bit. (It's repeating thus that would make sense)

I'll contact the seller and hopefully get a better one and not worse.

I understand the device and technology behind it a bit better, and it seems to me that it should perform a lot better.

[HendriXML]

The distance between glitches are at 1.9 compared to 2.0 are more wide (3.23x) and thus there less.
6556/2028=3,232741617357
10928/3384=3,22931442080378
This could mean a smaller portion of the DAC input range is used.
Value 2663 has a record glitch of 2.69 mV which also indicates the amplification is more.

So there 3 ways of controlling the amplitude:
* VGA
* Attenuation with relays
* Scaling

Here's what I got to understand.
Between ranges there's a coarse way of scaling, within a range there's the VGA:

0V..0.06V: VGA
Relay - analog scaling
0.06V..0.6V: VGA
Relay - analog scaling
0.6V..2V: VGA
Digital scaling (3.2x?)
2V..6V: VGA

If someone can improve this, please do so. It's very possible that the low ranges are also subdivided, but I've not tested it.

[HendriXML]

Just to have some idea how DAC error show up, I made a little simulation script.

It simulates the complementary output currents DAC (dac904) to see what happens when certain bits don't contribute the way they're supposed to.

In the first graph only 1 bit is non perfect. In that case one gets step differences up and down. Up being even more visible.

But when another bit is also affected things show up very differently.

Similar effects can be seen in my AWG's DAC response.

In my AWG the effects are to too profound for what I like to do with it. But how do other's perform? Testing the same input values might not show any issues, but others may.

So for the sake of science I could fancy up my scripts, so that is more "user friendly" if others would like to do their own measurements.

What would be needed to perform the test:
* SAG1021
* NI VISA setup (It uses a COM interface that comes with it)
* Ethernet/Wifi connection on Scope (Using the above with USB fails)
* Interpreter executable (64 bit Windows, developed by me)
* Script + Script libraries
* XML editor to alter some values (for example an offset to get the first batch in view, scopes ip-adress). I really like the free Visual Studio Community for that.
* about 2 hours of executing time

What does it do?
For each of the 65536-1 (16 bit) values it determines the step size (V) to the next one. It does this in batches of 500 blocks. Each batch is centred in the DSO view and a segmented acquisition is done. Of that multi frame averages are calculated (after discarding the 50% extremes). Then these values are averaged per blocks (centre samples) before calculating the final value.
Because values are measured with high sensitivity (5mV/div) and there's plenty of averaging the results are very useful.

[HendriXML]

It would be nice to measure the true response of each bit. In that case it would be possible to determine a lookup table which delivers a better setting of bits (thus another value) for each value. Creating a very high precision DAC. Only usable for arbitrary wave forms, but those can do all the other waves (with limitations?). It wouldn’t surprise me if the others are (calculated) arbitrary waves.

The problem is that here’s still the unknown scaling or even offsetting of the input values. That makes setting (or toggling for generating AC voltage, losing the DC component) individual bit impossible.

[tinhead]

Just to have some idea how DAC error show up, I made a little simulation script.
...
What would be needed to perform the test:

as i do have SAG as well, send me all i need, so i can run it on my hardware

[HendriXML]

Just to have some idea how DAC error show up, I made a little simulation script.
...
What would be needed to perform the test:

as i do have SAG as well, send me all i need, so i can run it on my hardware

I hope that you're comfortable with git (Github) repositories. I've placed it there, when used well it can be quite handy.

Setup for git is over here:
https://www.git-scm.com/download/win

After installing git, open a command line prompt and use a location of choice when executing the following:


git clone --recurse-submodules https://github.com/HendriXML/XMLScripts-Project-AWGStepTesting.git C:\AWGStepTesting

This will get the submodules as well.

I have made the script a bit more user friendly, let's see how well it goes. Using git, it's easy to sync changes.

If there're any issues then please use
https://github.com/HendriXML/XMLScripts-Project-AWGStepTesting/issues

in that way all that stuff will be at one easy accessible location, beneficial to others - not participating this thread- as well.

The first run of the script will probably not have the waveform in view, because of the 5mV/div it needs a accurate DSO offset. Using the pause checkbox the script will stop making manual adjustments possible. Unchecking pause and resume will continue without further pausing. (But it can be checked at anytime, to set a pause request. The script will have a script element for that to check this.)

[HendriXML]

It would be great if other could post test results with the same parameters, so we could do a side by side comparison. Maybe use standard 3V amp, 300 hz for that.
Posting the results from the Output tab would be enough to have Excel make a nice graph.

[HendriXML]

The waveform setup only applies when you use "<trace>:WF? ALL" for what ever reason its ignored for "<trace>:WF? DAT2"

Still have no luck limiting the number of points. This is the response using

WAVEFORM_SETUP SP,0,NP,1000,FP,0

C1:WAVEFORM? ALL

Each time I get a different but repeating output value.

Code: [Select]

14089.  viRead (TCPIP0::scope::inst0::INSTR (0x05981DB8), "ALL,#9000140346WAVEDE...", 1024000, 1363)
Process ID: 0x000011F0         Thread ID: 0x00001110
Start Time: 14:51:03.407       Call Duration 00:00:00.001
Status: 0 (VI_SUCCESS)
Buffer Contents
00000000:  41 4C 4C 2C 23 39 30 30 30 31 34 30 33 34 36 57  ALL,#9000140346W
00000010:  41 56 45 44 45 53 43 00 5A 1D 36 00 97 CB 00 57  AVEDESC.Z.6....W
00000020:  41 56 45 41 43 45 00 E0 49 E2 25 10 00 E0 25 00  AVEACE..I.%...%.
00000030:  00 01 00 5A 01 00 00 00 00 00 00 00 00 00 00 00  ...Z............
00000040:  00 00 00 00 00 00 00 00 00 00 00 E0 22 02 00 00  ............"...
00000050:  00 00 00 00 00 00 00 00 00 00 00 53 69 67 6C 65  ...........Sigle
00000060:  6E 74 20 53 44 53 00 00 00 00 00 AB CD 00 00 00  nt SDS..........
00000070:  97 CB 00 F4 49 E2 25 F8 49 E2 25 F8 49 E2 25 E0  ....I.%.I.%.I.%.
00000080:  22 02 00 E0 22 02 00 DE 22 02 00 00 00 00 00 DF  "..."...".......
00000090:  22 02 00 00 00 00 00 00 00 00 00 01 00 00 00 E8  "...............
000000A0:  03 00 00 01 00 00 00 00 00 00 00 0A D7 A3 3B 0B  ..............;.
000000B0:  24 B8 3F 00 00 FE 42 00 00 00 C3 08 00 01 00 95  $.?...B.........
000000C0:  BF 56 33 79 E9 26 31 08 AC 6C 3F 79 E9 26 31 08  .V3y.&1..l?y.&1.
000000D0:  AC 6C 3F 56 00 B0 36 00 00 00 00 BC FE 01 00 00  .l?V..6.........
000000E0:  00 00 00 8C 7B CD 00 20 69 1D 36 F0 00 00 00 01  ....{.. i.6.....
000000F0:  00 00 00 C0 C5 F5 36 34 C4 F5 36 8C 7B CD 00 EC  ......64..6.{...
00000100:  5B 1D 36 53 00 00 00 84 4A E2 25 01 00 00 00 74  [.6S....J.%....t
00000110:  66 1D 36 00 00 00 00 00 00 00 00 3C F9 01 00 20  f.6........<...
00000120:  5C 1D 36 60 64 1D 36 EC 5B 1D 36 05 00 00 00 60  \.6`d.6.[.6....`
00000130:  64 1D 36 5F 70 89 30 00 00 00 00 00 00 00 00 00  d.6_p.0.........
00000140:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000150:  00 01 00 13 00 00 00 00 00 80 3F 03 00 01 00 00  ..........?.....
00000160:  00 80 3F 0B 24 B8 3F 00 00 1C 1C 1C 1C 1C 1C 1C  ..?.$.?.........
00000170:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000180:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000190:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001A0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001B0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001C0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001D0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001E0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001F0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000200:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000210:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000220:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000230:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000240:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000250:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000260:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000270:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000280:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000290:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000002A0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................


[HendriXML]

I did some further tuning on the script and measurement parameters.

This one is with 100 instead of 500 blocks per batch. Much less, because otherwise the values go out of the scope’s measurement window. This because it is now measured with 2mV/div (!).
Also the frequency has been lowered to 90 hz. Meaning more of the cycle is in view and there’s more time between frames. (Short time interferences and stuff are more averaged out).

The results are very nice. The first graph is a zoom in on the second overview graph. The DAC steps are now clearly visible (1/4) of the time, because of 16 -> 14 bit.
Also less pronounced glitches, (DAC errors) can be seen. This is not the whole range because these “special” measurements take a really long time.

One good thing:
The script determines whether the scope measurement was saturated. If that happens that value will be the start of a new batch with a better offset.
Because of this the script can now even start with a mismatching offset and find the right one.

No one responded yet, but has someone tried to run it?

I'll will push the new version of the script later on, so if there's something I should look at, tell me!

I started a warranty procedure for the AWG, but before returning it, it would be major fun if I got to know how the input values are translated to DAC values (Scale and offset). I'm convinced that with the right lookup table it is possible to have almost no glitches/drops at all.

[HendriXML]

Just to have some idea how DAC error show up, I made a little simulation script.
...
What would be needed to perform the test:

as i do have SAG as well, send me all i need, so i can run it on my hardware

I hope that you're comfortable with git (Github) repositories. I've placed it there, when used well it can be quite handy.

Setup for git is over here:
https://www.git-scm.com/download/win

After installing git, open a command line prompt and use a location of choice when executing the following:


git clone --recurse-submodules https://github.com/HendriXML/XMLScripts-Project-AWGStepTesting.git C:\AWGStepTesting

This will get the submodules as well.

I have made the script a bit more user friendly, let's see how well it goes. Using git, it's easy to sync changes.

If there're any issues then please use
https://github.com/HendriXML/XMLScripts-Project-AWGStepTesting/issues

in that way all that stuff will be at one easy accessible location, beneficial to others - not participating this thread- as well.

The first run of the script will probably not have the waveform in view, because of the 5mV/div it needs a accurate DSO offset. Using the pause checkbox the script will stop making manual adjustments possible. Unchecking pause and resume will continue without further pausing. (But it can be checked at anytime, to set a pause request. The script will have a script element for that to check this.)

A new version of the script and modules are pushed. It's easiest to pull them fresh using a different directory. It may that people dislike to execute a large unknown executable like this. But the big size is just because it's an all in one Delphi executable.
https://www.virustotal.com/nl/file/2badeb990bf2d17d659b28987dc146f3964a46dc0876ec8d8c9b96c7b11ebfe3/analysis/1557510442/

[HendriXML]

My more slow parameter (not in upload) script ran about 8h40.

I'll try to analyse it, and to guess what bits are toggling at what moment. After having played with this stuff for a while now I'm quite sure this is what is happening on a glitch (that is a common name for these kind of errors).
When a DAC binary value of 00111 turns into 001000, the voltages out of 3 current sources are replaced by the voltage of 1 (more significant) current source. If however the more significant bit, delivers less voltage than the previous ones combined than instead of increasing, the voltage drops. In my AWG this happens frequently, and with quite some voltage (one with 9.6x least significant bit steps).
That a DAC drops instead of climbs is normally a very unwanted situation, certainly in feedback loops. This is a high speed DAC so it usage is different, but for creating trustworthy signals I would like it to be much lower. These fast unwanted voltage transitions will be in all the signals it generates, creating unexpected "high frequencies" (not noise but regularly repeating).

The reason I did the precise measurement is to have more information to gaze at. For example the most significant bit, might have the greatest step error. This is at 828, the DAC will than change from 1111111111111 to 00000000000000. (-1 to 0).
This might be -for instance- an indication that there's a offset of 828.

[HendriXML]

I added a previous, lower quality measurement graph to have a side by side comparison to show what the extra averaging and time between acquisitions can mean.

[HendriXML]

I uploaded a new version of the script, the horizontal TDiv parameter was not set back to match the other parameters.
Now it runs smoothly, this is what to expect:

Code: [Select]

Description: Global VISA COM I/O Resource Manager
Siglent Technologies,SDS1204X-E,SDSMMDBQ2R3764,8.1.6.1.26

[2019-05-10 23:20:35] Setting up wave -32768..-32269
[2019-05-10 23:20:35] Setting up DSO Window, centered at -1432,58 mV
[2019-05-10 23:20:36] Getting 66667 DSO samples
[2019-05-10 23:21:16] Process single cycle samples
[2019-05-10 23:21:16] Off centre voltage: -25,00 mV
[2019-05-10 23:21:16] Setting up wave -32768..-32269
[2019-05-10 23:21:16] Setting up DSO Window, centered at -1457,58 mV
[2019-05-10 23:21:17] Getting 66667 DSO samples
[2019-05-10 23:21:54] Process single cycle samples
[2019-05-10 23:21:54] Off centre voltage: 9,20 mV
[2019-05-10 23:21:55] Setting up wave -32269..-31770
[2019-05-10 23:21:55] Setting up DSO Window, centered at -1425,54 mV
[2019-05-10 23:21:55] Getting 66667 DSO samples
[2019-05-10 23:22:35] Process single cycle samples
[2019-05-10 23:22:35] Off centre voltage: 0,20 mV
[2019-05-10 23:22:36] Setting up wave -31770..-31271
[2019-05-10 23:22:36] Setting up DSO Window, centered at -1402,49 mV
[2019-05-10 23:22:36] Getting 66667 DSO samples
[2019-05-10 23:23:17] Process single cycle samples
[2019-05-10 23:23:17] Off centre voltage: -0,50 mV



[HendriXML]

Besides measuring step voltages, I also measured absolute voltages. These are measured precisely and mostly by the using the ADC of the scope to get the wave in view. The few mV that are in the measurement are added to that.
It isn't a perfect straight line, because probably the offset of the AWG is not very steady.

I did some measurement and the offset is a bit depended on the amplitude as well:
2.0 V amplitude: 25.3mV offset
3.0 V amplitude: 30,6mV offset (during measurement)
6.0 V amplitude: 49.7mV offset

With less then 2.0 V it jumps to a different range:
1.9 V amplitude: 54.7mV offset
0.7 V amplitude: 31.2mV offset

Off course this offset shouldn't be there. I suspect however the device is "managing" it. I think that a part of the DAC range is used to control an offset needed for a following stage.

This offset is then (partly) amplified by the VGA.

I suspect that "0V" output of the DAC is at the wave value of 828, this value is transformed (scaled and offsetted) to DAC inputvalue of 0.
Beneath the 2.0V amplitude
I suspect that "0V" output of the DAC is at the wave value of 2664. (This is a difference of 3.2x, about the same factor the glitches get spread. Also there're about 3x less glitches. )

I made a drawing how I think the stages interact with each other. Looking at the glitches we get info on the digital side. (And start assuming things to move forward in the analysis)

The glitches are "special" values on the DAC stage, it should be possible to guess them. If these blanks are filled, then the scaling and offsetting can be determined.

[HendriXML]

Because more glitches could be measured a relation to all the glitches input values can be shown. Taking the distances between input values this table arises:

Code: [Select]

Dist Count
676 7
1352 3 2 x 676
2028 8 3 x 676
2708 4 4 x 676 = 2704
3384 8 5 x 676 = 3380
I think the 676 is a factor to some "binary base value", (256, 512, 1024). At the ADC-input value side glitches should repeat at such intervals.

Maybe values are scaled close to this factor/divider pair: 676/1024

I'll have to check if using that and the offset of 828 get "special bit" arrangements.

[HendriXML]

When I substract 828 of the glitch values and multiply them by 676 these are the binary values:

Code: [Select]

0101100010000110110011111 0101100010000110110100000
0110011001111110001101111 0110011001111110001110000
0110100111111010101111111 0110100111111010110000000
0111010001110000010101111 0111010001110000010110000
1000010111100100010001111 1000010111100100010010000
1001000001011001110111111 1001000001011001111000000
1010000111001101110011111 1010000111001101110100000
1010110001000011011001111 1010110001000011011010000
1011110110110111010101111 1011110110110111010110000
1100010010110000011001111 1100010010110000011010000
1100100000101100111011111 1100100000101100111100000
1101011000100100010101111 1101011000100100010110000
1101100110100000110111111 1101100110100000111000000
1110010000010110011101111 1110010000010110011110000
1110011110010010111111111 1110011110010011000000000
1111010110001010011001111 1111010110001010011010000
1111100100000110111011111 1111100100000110111100000
1111111111111111111111111 0000000000000000000000000
0001000101110011111011111 0001000101110011111100000
0001101111101001100001111 0001101111101001100010000
0010110101011101011101111 0010110101011101011110000
0011000011011001111111111 0011000011011010000000000
0011011111010011000011111 0011011111010011000100000
0100010111001010011101111 0100010111001010011110000
0100100101000110111111111 0100100101000111000000000
0101001110111100100101111 0101001110111100100110000
0110010100110000100001111 0110010100110000100010000
0110111110100110000111111 0110111110100110001000000
1000000100011010000011111 1000000100011010000100000
1000101110001111101001111 1000101110001111101010000
1001110100000011100101111 1001110100000011100110000

All of them have at least 4 bits replace by a more significant one. Duno if that means something yet, because the values are now to large... With every division (2,4,8,16) bits will right shift out.

[HendriXML]

I think this is becoming more meaningful. A lot of the higher bits are about to overflow, or have overflowed.

Code: [Select]

Offset: 828
Factor: 512
Divider: 676
1111111111001111111101101 1111111111001111111101110
1111111111010011111110000 1111111111010011111110001
1111111111010100111110000 1111111111010100111110001
1111111111010111111110000 1111111111010111111110001
1111111111011100111110100 1111111111011100111110101
1111111111011111111110100 1111111111011111111110101
1111111111100100111110111 1111111111100100111111000
1111111111100111111110111 1111111111100111111111000
1111111111101100111111010 1111111111101100111111011
1111111111101110111111010 1111111111101110111111011
1111111111101111111111010 1111111111101111111111011
1111111111110011111111101 1111111111110011111111110
1111111111110100111111101 1111111111110100111111110
1111111111110111111111101 1111111111110111111111110
1111111111111000111111101 1111111111111000111111110
1111111111111101000000000 1111111111111101000000001
1111111111111110000000000 1111111111111110000000001
1111111111111111111111111 0000000000000000000000000
0000000000000101000000010 0000000000000101000000011
0000000000001000000000010 0000000000001000000000011
0000000000001101000000101 0000000000001101000000110
0000000000001110000000101 0000000000001110000000110
0000000000010000000000101 0000000000010000000000110
0000000000010100000001000 0000000000010100000001001
0000000000010101000001000 0000000000010101000001001
0000000000011000000001000 0000000000011000000001001
0000000000011101000001011 0000000000011101000001100
0000000000100000000001011 0000000000100000000001100
0000000000100101000001110 0000000000100101000001111
0000000000101000000001110 0000000000101000000001111
0000000000101101000010001 0000000000101101000010010



[HendriXML]

For each input value that glitches it is now almost certain to say what bits are overflowed to a new active more significant bit.

To get to this table I'm simulating Offset/Factor/Divider values within a chosen range (speed). For each glitch the overflowable bits are counted. The settings with the best total overflowable bits are shown.

It's also hard to tell how the AWG calculates the DAC input value. Does it first do a 16 to 14 bit conversion, or at the end? Or combined with the divider (*4)? The latter would be best, but I don't think it does. Also the offset, is that done before scaling or after?

Code: [Select]

Offset: 832, Factor: 12213, Divider: 10757
1111111111101101111111110 1111111111101101111111111 0
1111111111101111011111111 1111111111101111100000000 8
1111111111101111110111111 1111111111101111111000000 6
1111111111110000111111111 1111111111110001000000000 9
1111111111110010110111111 1111111111110010111000000 6
1111111111110011111111111 1111111111110100000000000 11
1111111111110101110111111 1111111111110101111000000 6
1111111111110110111111111 1111111111110111000000000 9
1111111111111000110111111 1111111111111000111000000 6
1111111111111001100111111 1111111111111001101000000 6
1111111111111001111111111 1111111111111010000000000 10
1111111111111011100000000 1111111111111011100000001 0
1111111111111011110111111 1111111111111011111000000 6
1111111111111100111111111 1111111111111101000000000 9
1111111111111101010111111 1111111111111101011000000 6
1111111111111110111000000 1111111111111110111000001 0
1111111111111111001111111 1111111111111111010000000 7
1111111111111111111111111 0000000000000000000000000 32
0000000000000001110111111 0000000000000001111000000 6
0000000000000010111111110 0000000000000010111111111 0
0000000000000100110111111 0000000000000100111000000 6
0000000000000101001111111 0000000000000101010000000 7
0000000000000101111111111 0000000000000110000000000 10
0000000000000111011111111 0000000000000111100000000 8
0000000000000111110111111 0000000000000111111000000 6
0000000000001000111111111 0000000000001001000000000 9
0000000000001010110111111 0000000000001010111000000 6
0000000000001011111111111 0000000000001100000000000 11
0000000000001101110111111 0000000000001101111000000 6
0000000000001110111111111 0000000000001111000000000 9
0000000000010000110111111 0000000000010000111000000 6\


[HendriXML]

The previous table had a Divider larger than the Factor. That will not be the case in practice, so I ran the simulation taking care of that.

I changed the script to Sqr the overflow bit. So the best matches are the ones with high significant bits. Which bit was/would toggle is added to the table.

High significant bits toggling are probably responsible for the glitches. Now that I think about it, that only makes sense, but how much would be acceptable?
When is a DAC a rotten apple regarding this? For that we could take the datasheet of the DAC, but first I'll summarize stuff and make a new drawing.

Code: [Select]

Offset: 831, Factor: 1065, Divider: 1407
Value          Next value    Bit cnt Significant bit
10011111111111 10100000000000 11 12
10100111111111 10101000000000 9 10
10101001111111 10101010000000 7 8
10101111111111 10110000000000 10 11
10110110000000 10110110000001 0 8
10111001111111 10111010000000 7 8
10111111111111 11000000000000 12 13
11001010000000 11001010000001 0 8
11001111111111 11010000000000 10 11
11010110000000 11010110000001 0 8
11011010000000 11011010000001 0 8
11011110000000 11011110000001 0 8
11011111111111 11100000000000 11 12
11101000000000 11101000000001 0 10
11101010000000 11101010000001 0 8
11110000000000 11110000000001 0 11
11110010000000 11110010000001 0 8
11110110000000 11110110000001 0 8
11111010000000 11111010000001 0 8
11111100000000 11111100000001 0 9
11111111111111 00000000000000 15 16
00001001111111 00001010000000 7 8
00001111111111 00010000000000 10 11
00011001111111 00011010000000 7 8
00011011111111 00011100000000 8 9
00011111111111 00100000000000 11 12
00100111111111 00101000000000 9 10
00101001111111 00101010000000 7 8
00101111111111 00110000000000 10 11
00110110000000 00110110000001 0 8
00111001111111 00111010000000 7 8
00111111111111 01000000000000 12 13
01000110000000 01000110000001 0 8
01001010000000 01001010000001 0 8
01001111111111 01010000000000 10 11
01010110000000 01010110000001 0 8
01011010000000 01011010000001 0 8


[HendriXML]

This is the very best match I can generate.

Code: [Select]

Offset: 836, Factor: 246, Divider: 325
1110011111111111 1110100000000000 11 12
1110100111111111 1110101000000000 9 10
1110101001111111 1110101010000000 7 8
1110101111111111 1110110000000000 10 11
1110110101111111 1110110110000000 7 8
1110111001111111 1110111010000000 7 8
1110111111111111 1111000000000000 12 13
1111001001111111 1111001010000000 7 8
1111001111111111 1111010000000000 10 11
1111010101111111 1111010110000000 7 8
1111011001111111 1111011010000000 7 8
1111011101111111 1111011110000000 7 8
1111011111111111 1111100000000000 11 12
1111100111111111 1111101000000000 9 10
1111101001111111 1111101010000000 7 8
1111101111111111 1111110000000000 10 11
1111110001111111 1111110010000000 7 8
1111110110000000 1111110110000001 0 8
1111111010000000 1111111010000001 0 8
1111111011111111 1111111100000000 8 9
1111111111111111 0000000000000000 15 16
0000001001111111 0000001010000000 7 8
0000001111111110 0000001111111111 0 11
0000011001111111 0000011010000000 7 8
0000011011111111 0000011100000000 8 9
0000011111111111 0000100000000000 11 12
0000100111111111 0000101000000000 9 10
0000101001111111 0000101010000000 7 8
0000101111111111 0000110000000000 10 11
0000110101111111 0000110110000000 7 8
0000111001111111 0000111010000000 7 8
0000111111111111 0001000000000000 12 13
0001000101111111 0001000110000000 7 8
0001001001111111 0001001010000000 7 8
0001001111111111 0001010000000000 10 11
0001010101111111 0001010110000000 7 8
0001011001111111 0001011010000000 7 8
The formula to get to the ADC value is then the following:
ADC = ((WaveValue - Offset) * Factor + Divider * 2) div (Divider * 4)
In non integer calculus:
ADC = (123 * Value - 102503) / 650

[genghisnico13]

Could be something as simple as not enough decoupling in the DAC when several bits change simultaneously?

[HendriXML]

Could be something as simple as not enough decoupling in the DAC when several bits change simultaneously?

The output stays the same during long periods of holding a wave value. Also slight changes are expected. For instance the second highest significant bit determines 1/4 of the amplitude (0.9 V in the testing) if that value is of by 0.002 V it will lead to these glitches. That's still a tiny amount. A DAC bit handling needs thus to be very precise.

[tautech]

Following along as best I can as much is beyond my understanding, however been listening to an old Amp Hour podcast that might offer some understanding to what is going on, I dunno but I suggest you listen from 2hr 40min for just a few minutes for some ADC gems from EEVblog member free electron.
https://theamphour.com/169-an-interview-with-vincent-himpe-escaped-electron-elocution/

Hope it helps and flicks some thought switch ON. 

[HendriXML]

I made a graph how values are scaled between different stages.

I now know the offset (828) and digital scaling (1,3212), but I cannot figure out the exact way these values are calculated with. Thus I cannot manipulate the exact setting of bits on the DAC.

(That was what the previous posts where about. Matching at bit level.)

Otherwise it would  have been fun to measure the voltage change of each individual bit with a MM.

[HendriXML]

Following along as best I can as much is beyond my understanding, however been listening to an old Amp Hour podcast that might offer some understanding to what is going on, I dunno but I suggest you listen from 2hr 40min for just a few minutes for some ADC gems from EEVblog member free electron.
https://theamphour.com/169-an-interview-with-vincent-himpe-escaped-electron-elocution/

Hope it helps and flicks some thought switch ON. 

At the graph above wavevalues are translated to DAC values. If we did that for every glitching wavevalue, the corresponding DAC value would be "special". Special in the way that multiple less significant bits are traded with only one more significant bit (01111 -> 10000) in the next step. So the sum of all the less significant bit voltages are traded with only the voltage of one more significant bit. That voltage need to be very precise, otherwise we get a glitch at the output.

I used the glitches and the corresponding wave input values, to determine a relation between them (offset/scale). If that relation explains all the glitches, it is a good one.

[Rerouter]

If you manually set the waveform amplitude to 6.3243878V pk-pk after loading your waveform, does it alter this scaling issue and use up the remaining DAC range?

[HendriXML]

If you manually set the waveform amplitude to 6.3243878V pk-pk after loading your waveform, does it alter this scaling issue and use up the remaining DAC range?

Only below 2.0V the digital scaling changes. I suspect it than becomes much more: 3.2 x 1.3212 = 4.2. But I won't do any testing in that range.

So essentially there's no digital scaling done for changing amplitudes. Only the VGA is used.

Digitally offsetting the DAC enforces a analog output offset to the succeeding stage, but that also makes it impossible to use the full DAC range. I don’t why they have used that trick. Maybe it is an per device setting (the offset). That could be a reason you could not reproduce issues with my 828 value.

I’m quite certain running the script that checks the full range on another one will provide an answer to that.

Maybe they are willing to send me a second one, or a replacement. 

[HendriXML]

My seller responded quickly and has send me a second device to test. This will give some idea whether just mine is a bad apple, or whether the model has some (more) issues.

I really hope it is the first option 

[HendriXML]

I did a full test of the other unit (device B) I received.

Here's the step size comparison between them.

[HendriXML]

The highest peek transition on the new device is shown attached screenshot.

Unit now I showed relative (steps) voltages. Now I added 2 graphs of the difference at each wave value to the expected output. As can seen the offset is a major part, but my guess is that the offset is not entirely stable.

[tautech]

I did a full test of the other unit (device B) I received.

Here's the step size comparison between them.

And you checked they are running the same firmware ?

[HendriXML]

Same firmware, because of the bit matching, we can safely say the "step errors" are HW and caused by the DAC.

My "bit mapping" is almost perfect, read: I cannot in any way reproduce their (slight) calculation error.

I shall make a new mapping drawing that shows how some value are related. One question is answered, the 2 devices use 2 different digital offsets. That also means that glitches occur on different wave values.

I have to think about it some more, but second device's step errors are what one could expect reading the DAC datasheet. What I also like better is that they - except for on tiny negative one - are always positive errors. That makes the difference to the measured one and expected one also less (it supposed to do one stepvalue up).

[HendriXML]

About the calculation error, I'm taking a wild ques that the firmware developer made a mistake in converting a unsigned integer to a signed one. I found such an error in their scope documentation, so it would not surprise me. Here's the reason for my suspicion:

Code: [Select]

Offset: 316, Factor: 249, Divider: 329
-32157 10011100000001 10011100000001 1 0 9
-31481 10011110000001 10011110000001 1 0 8
-30805 10100000000001 10100000000001 1 0 12
-30129 10100010000000 10100010000000 0 7 8
-29449 10100100000001 10100100000001 1 0 9
-28773 10100110000001 10100110000001 1 0 8
-28097 10101000000001 10101000000001 1 0 10
-27421 10101010000001 10101010000001 1 0 8
-26745 10101100000001 10101100000001 1 0 9
-26069 10101110000001 10101110000001 1 0 8
-25393 10110000000001 10110000000001 1 0 11
-24717 10110010000000 10110010000000 0 7 8
-23361 10110110000001 10110110000001 1 0 8
-22685 10111000000001 10111000000001 1 0 10
-22009 10111010000001 10111010000001 1 0 8
-21333 10111100000001 10111100000001 1 0 9
-20657 10111110000001 10111110000001 1 0 8
-19981 11000000000001 11000000000001 1 0 13
-19305 11000010000000 11000010000000 0 7 8
-18625 11000100000001 11000100000001 1 0 9
-17949 11000110000001 11000110000001 1 0 8
-17273 11001000000001 11001000000001 1 0 10
-16765 11001001100001 11001001100001 1 0 6
-16597 11001010000001 11001010000001 1 0 8
-15921 11001100000001 11001100000001 1 0 9
-15245 11001110000001 11001110000001 1 0 8
-14737 11001111100001 11001111100001 1 0 6
-14569 11010000000001 11010000000001 1 0 11
-13893 11010010000000 11010010000000 0 7 8
-12537 11010110000001 11010110000001 1 0 8
-11861 11011000000001 11011000000001 1 0 10
-11693 11011000100001 11011000100001 1 0 6
-11185 11011010000001 11011010000001 1 0 8
-10677 11011011100001 11011011100001 1 0 6
-10509 11011100000001 11011100000001 1 0 9
-9157 11100000000001 11100000000001 1 0 12
-8481 11100010000000 11100010000000 0 7 8
-7801 11100100000001 11100100000001 1 0 9
-7125 11100110000001 11100110000001 1 0 8
-5773 11101010000001 11101010000001 1 0 8
-5097 11101100000001 11101100000001 1 0 9
-4421 11101110000001 11101110000001 1 0 8
-4249 11101110100001 11101110100001 1 0 6
-3745 11110000000001 11110000000001 1 0 11
-2389 11110100000001 11110100000001 1 0 9
-1713 11110110000001 11110110000001 1 0 8
-1037 11111000000001 11111000000001 1 0 10
-361 11111010000001 11111010000001 1 0 8
483 11111100011111 11111100100000 5 5 6
991 11111101111111 11111110000000 7 7 8
1667 11111111111111 00000000000000 14 14 15
2343 00000001111111 00000010000000 7 7 8
3023 00000011111111 00000100000000 8 8 9
4375 00000111111111 00001000000000 9 9 10
5051 00001001111111 00001010000000 7 7 8
5727 00001011111111 00001100000000 8 8 9
6403 00001101111111 00001110000000 7 7 8
7079 00001111111111 00010000000000 10 10 11
7755 00010001111111 00010010000000 7 7 8
8603 00010100011111 00010100100000 5 5 6
9111 00010101111111 00010110000000 7 7 8
9787 00010111111111 00011000000000 9 9 10
10463 00011001111111 00011010000000 7 7 8
11139 00011011111111 00011100000000 8 8 9
11815 00011101111111 00011110000000 7 7 8
11987 00011110011111 00011110100000 5 5 6
12491 00011111111111 00100000000000 11 11 12
12999 00100001011111 00100001100000 5 5 6
13167 00100001111111 00100010000000 7 7 8
15199 00100111111111 00101000000000 9 9 10
15875 00101001111111 00101010000000 7 7 8
16551 00101011111111 00101100000000 8 8 9
16719 00101100011111 00101100100000 5 5 6
17227 00101101111111 00101110000000 7 7 8
17903 00101111111111 00110000000000 10 10 11
18579 00110001111111 00110010000000 7 7 8
19935 00110101111111 00110110000000 7 7 8
20611 00110111111111 00111000000000 9 9 10
21963 00111011111111 00111100000000 8 8 9
22131 00111100011111 00111100100000 5 5 6
22639 00111101111111 00111110000000 7 7 8
23315 00111111111111 01000000000000 12 12 13
23991 01000001111111 01000010000000 7 7 8
25347 01000101111111 01000110000000 7 7 8
26023 01000111111111 01001000000000 9 9 10
26699 01001001111111 01001010000000 7 7 8
27207 01001011011111 01001011100000 5 5 6
27375 01001011111111 01001100000000 8 8 9
27883 01001101011111 01001101100000 5 5 6
28051 01001101111111 01001110000000 7 7 8
28727 01001111111111 01010000000000 10 10 11
29403 01010001111111 01010010000000 7 7 8
29575 01010010011111 01010010100000 5 5 6
29911 01010011011111 01010011100000 5 5 6
30083 01010011111111 01010100000000 8 8 9
30251 01010100011111 01010100100000 5 5 6
30759 01010101111111 01010110000000 7 7 8
30927 01010110011111 01010110100000 5 5 6
31267 01010111011111 01010111100000 5 5 6
31435 01010111111111 01011000000000 9 9 10
31943 01011001011111 01011001100000 5 5 6
32111 01011001111111 01011010000000 7 7 8
32619 01011011011111 01011011100000 5 5 6

At negative values, the bits don't match the glitches. I'll try to reproduce the "calculation error" later on.

As can de seen the digital offset is now at 1668 instead of 828. However because of the negative side not matching, there's very little difference in bit scoring in succeeding glitches. However at 1667-1668 there's a minor negative spike - which is the only one - so we can assume that is the transition at DAC -1 to 0.

[HendriXML]

Here's a comparison between the 2 devices in respect to the transformation of values.

Note that the output offset error is +31 mV vs -35 mV.

[Rerouter]

As some parts of this gets a little above what I am capable of fully parsing, is the delta you are seeing inline with what we would expect given the DAC and output OP amp specifications?

And how does it compare to the AD9744, as it seems to be a pin and package compatible replacement

https://au.mouser.com/datasheet/2/609/AD9744-878112.pdf
http://www.ti.com/lit/ds/symlink/dac904.pdf

[HendriXML]

I think the step errors are related to this datasheet info.

The DAC step is about (1779--1850)/(5883--6515)=0.293 mV: output range/used DAC range. (0.290 taking the requested 3600 mV amplitude).

So 1 mV is then about 3 LSBs (Least significant byte step).

My device has a 8 LSBs error, that's seems too much if one looks at the datasheet. The other device seems to be in spec. However the steps in the datasheet are calculated with the DAC output without AMP stuff in between. And these may also be compared to the expected voltage (and then could get summed after multiple step errors)  But I don't know what the datasheet calculations/definitions are.

The lower speed offset DAC should have much lower LSBs errors.

(What I know of this stuff, I learned from others (you as well) a little research and doing this "exercise").

[HendriXML]

The strange behaviour I saw in this graph is an explainable side effect of my testing.

In the waveform there's different amplitude than the one I test with. So selecting the wave form sets the VGA at 3.0V and setting the wave parameters changes it to 3.6V. It takes some time for the VGA to adjust and that can be seen as DC kind of error. In the results this stuff got averaged out.

I'm doing another run, now whit both the same voltages and a 3 sec waiting time for it to settle (always good  ). I already can see that it has a very positive influence.

The VGA is probably the one responsible for a DC error on the output. But if that's stable and predictable than that is not a mayor issue. The device has a offset capability.

[HendriXML]

Looking at the sum of the steps a the 4 interval we can probably assume, that the conversion from 16 to 14 bits (shifting 2 bits out, or div 4) is done as a first step. The bits that are "shifted out" don't do anything but create small noisy differences. (Checked it also with the sum of abs() values)

0,4,8,12..	0,55 mV	0,02%
1,5,9,13..	0,75 mV	0,02%
2,6,10,12,14	-0,40 mV	-0,01%
3,7,11,12,15	3685,83 mV	100,00%

Having an 14 bit DAC doesn't mean one needs to calculate with 14 bit input values, especially when they get scaled. Maybe there's a reason why, but it is not optimal.

Also there seems to be a discontinuity (?) after applying the offset (around the DAC value of -offset).  This is probably because of using a if .. then construct. But I cannot figure out what.
I saw that doing a -1 when DAC value + Offset < 0

The bits start matching the glitches almost perfectly for each value's resulting DAC code (the before overflow: 01111), but not the succeeding value's DAC code (the after overflow: 10000) one.

This discontinuity will have its affect on the output of a particular transition. Because I don't know the exact rule, I cannot say where.
 

Code: [Select]

Offset: 316, Factor: 249, Divider: 329
-32157 10011011111111 10011011111111 8 0 9
-31481 10011101111111 10011101111111 7 0 8
-30805 10011111111111 10011111111111 11 0 12
-30129 10100001111110 10100001111110 0 1 8
-29449 10100011111111 10100011111111 8 0 9
-28773 10100101111111 10100101111111 7 0 8
-28097 10100111111111 10100111111111 9 0 10
-27421 10101001111111 10101001111111 7 0 8
-26745 10101011111111 10101011111111 8 0 9
-26069 10101101111111 10101101111111 7 0 8
-25393 10101111111111 10101111111111 10 0 11
-24717 10110001111110 10110001111110 0 1 8
-23361 10110101111111 10110101111111 7 0 8
-22685 10110111111111 10110111111111 9 0 10
-22009 10111001111111 10111001111111 7 0 8
-21333 10111011111111 10111011111111 8 0 9
-20657 10111101111111 10111101111111 7 0 8
-19981 10111111111111 10111111111111 12 0 13
-19305 11000001111110 11000001111110 0 1 8
-18625 11000011111111 11000011111111 8 0 9
-17949 11000101111111 11000101111111 7 0 8
-17273 11000111111111 11000111111111 9 0 10
-16765 11001001011111 11001001011111 5 0 6
-16597 11001001111111 11001001111111 7 0 8
-15921 11001011111111 11001011111111 8 0 9
-15245 11001101111111 11001101111111 7 0 8
-14737 11001111011111 11001111011111 5 0 6
-14569 11001111111111 11001111111111 10 0 11
-13893 11010001111110 11010001111110 0 1 8
-12537 11010101111111 11010101111111 7 0 8
-11861 11010111111111 11010111111111 9 0 10
-11693 11011000011111 11011000011111 5 0 6
-11185 11011001111111 11011001111111 7 0 8
-10677 11011011011111 11011011011111 5 0 6
-10509 11011011111111 11011011111111 8 0 9
-9157 11011111111111 11011111111111 11 0 12
-8481 11100001111110 11100001111110 0 1 8
-7801 11100011111111 11100011111111 8 0 9
-7125 11100101111111 11100101111111 7 0 8
-5773 11101001111111 11101001111111 7 0 8
-5097 11101011111111 11101011111111 8 0 9
-4421 11101101111111 11101101111111 7 0 8
-4249 11101110011111 11101110011111 5 0 6
-3745 11101111111111 11101111111111 10 0 11
-2389 11110011111111 11110011111111 8 0 9
-1713 11110101111111 11110101111111 7 0 8
-1037 11110111111111 11110111111111 9 0 10
-361 11111001111111 11111001111111 7 0 8
483 11111100011111 11111100100000 5 5 6
991 11111101111111 11111110000000 7 7 8
1667 11111111111111 00000000000000 14 14 15
2343 00000001111111 00000010000000 7 7 8
3023 00000011111111 00000100000000 8 8 9
4375 00000111111111 00001000000000 9 9 10
5051 00001001111111 00001010000000 7 7 8
5727 00001011111111 00001100000000 8 8 9
6403 00001101111111 00001110000000 7 7 8
7079 00001111111111 00010000000000 10 10 11
7755 00010001111111 00010010000000 7 7 8
8603 00010100011111 00010100100000 5 5 6
9111 00010101111111 00010110000000 7 7 8
9787 00010111111111 00011000000000 9 9 10
10463 00011001111111 00011010000000 7 7 8
11139 00011011111111 00011100000000 8 8 9
11815 00011101111111 00011110000000 7 7 8
11987 00011110011111 00011110100000 5 5 6
12491 00011111111111 00100000000000 11 11 12
12999 00100001011111 00100001100000 5 5 6
13167 00100001111111 00100010000000 7 7 8
15199 00100111111111 00101000000000 9 9 10
15875 00101001111111 00101010000000 7 7 8
16551 00101011111111 00101100000000 8 8 9
16719 00101100011111 00101100100000 5 5 6
17227 00101101111111 00101110000000 7 7 8
17903 00101111111111 00110000000000 10 10 11
18579 00110001111111 00110010000000 7 7 8
19935 00110101111111 00110110000000 7 7 8
20611 00110111111111 00111000000000 9 9 10
21963 00111011111111 00111100000000 8 8 9
22131 00111100011111 00111100100000 5 5 6
22639 00111101111111 00111110000000 7 7 8
23315 00111111111111 01000000000000 12 12 13
23991 01000001111111 01000010000000 7 7 8
25347 01000101111111 01000110000000 7 7 8
26023 01000111111111 01001000000000 9 9 10
26699 01001001111111 01001010000000 7 7 8
27207 01001011011111 01001011100000 5 5 6
27375 01001011111111 01001100000000 8 8 9
27883 01001101011111 01001101100000 5 5 6
28051 01001101111111 01001110000000 7 7 8
28727 01001111111111 01010000000000 10 10 11
29403 01010001111111 01010010000000 7 7 8
29575 01010010011111 01010010100000 5 5 6
29911 01010011011111 01010011100000 5 5 6
30083 01010011111111 01010100000000 8 8 9
30251 01010100011111 01010100100000 5 5 6
30759 01010101111111 01010110000000 7 7 8
30927 01010110011111 01010110100000 5 5 6
31267 01010111011111 01010111100000 5 5 6
31435 01010111111111 01011000000000 9 9 10
31943 01011001011111 01011001100000 5 5 6
32111 01011001111111 01011010000000 7 7 8
32619 01011011011111 01011011100000 5 5 6


[Rerouter]

so at this point, thinking a truncation issue, If so that should not be a hard fix, do the math on 16 bit, truncate 1 bit, save the other and truncate that bit, then just sum the number with the saved bit, If its a 1, the number rounds up anyway, if its a 0, it doesn't change anything, and you get free rounding with just a summation. 

00
01
10
11

Any time that saved bit is 1, the number should round up,

Tautech, would we be able to get any developer insight into what approach they use, and where the scaling is stored?

[tautech]

Possibly, I'll point them to this again.

[HendriXML]

so at this point, thinking a truncation issue, If so that should not be a hard fix, do the math on 16 bit, truncate 1 bit, save the other and truncate that bit, then just sum the number with the saved bit, If its a 1, the number rounds up anyway, if its a 0, it doesn't change anything, and you get free rounding with just a summation. 

00
01
10
11

Any time that saved bit is 1, the number should round up,

Tautech, would we be able to get any developer insight into what approach they use, and where the scaling is stored?

With negative numbers we have to be cautious.

What gets really nice results, which also works with negative dividers is:
(It is like adding (or substracting) a 0.5 to let the value flip to the nearest when truncating.)

Code: [Select]

if (Value >= 0) = (Divider >= 0) then
  Result:= (Value + Divider div 2) div Divider
else
  Result:= (Value - Divider div 2) div Divider


[HendriXML]

This graph show the measured voltages against the expected ones (ramp from -1.8 to 1.8V) on one axis.
The difference between them are shown on another.
These measurements where done in 655 batches and in 3 sessions totalling about 9hrs of running time. Each batch has a different constructed wave (the partial ramp) and a scope channel offset that should put it into the middle.
Because this is done glueing measurement together I find the results quite decent. Okay there’s an offset and the amplification is not very precise. But that is all largely predictable (except for the error increase around 10000). Also the scope accuracy might also attribute to the errors. The measurements where done using 2mV/Div range. So the channel offset has the most importance in the accuracy of these absolute values.
The step measurement between values where always done in a single batch, so share channel offset and moment in time. They look similar the previous measurements, so no real harm was done measuring the AWG output too fast.

[HendriXML]

The last batch started at 6539, so that might explain why the error graph dips over there. Maybe the scope/AWG was not at the right temperature yet. Using these long test gives some idea on the stability/repeatability of the measurements.

[HendriXML]

so at this point, thinking a truncation issue, If so that should not be a hard fix, do the math on 16 bit, truncate 1 bit, save the other and truncate that bit, then just sum the number with the saved bit, If its a 1, the number rounds up anyway, if its a 0, it doesn't change anything, and you get free rounding with just a summation. 

00
01
10
11

Any time that saved bit is 1, the number should round up,

Tautech, would we be able to get any developer insight into what approach they use, and where the scaling is stored?

With negative numbers we have to be cautious.

What gets really nice results, which also works with negative dividers is:
(It is like adding (or substracting) a 0.5 to let the value flip to the nearest when truncating.)

Code: [Select]

if (Value >= 0) = (Divider >= 0) then
  Result:= (Value + Divider div 2) div Divider
else
  Result:= (Value - Divider div 2) div Divider


I think the problem has its origin in that there's some code like this

Code: [Select]

Result:= Value div Divider
if (Value mod Divider) >= (Divider div 2) then
  Result:= Result + 1
Forgetting the rounding down of negative values.
I've tried all kinds of programming errors, but only for 2 divisions max. I'm guessing this kind of error is repeated several times in the steps to get to a DAC value.
 

[HendriXML]

so at this point, thinking a truncation issue, If so that should not be a hard fix, do the math on 16 bit, truncate 1 bit, save the other and truncate that bit, then just sum the number with the saved bit, If its a 1, the number rounds up anyway, if its a 0, it doesn't change anything, and you get free rounding with just a summation. 

00
01
10
11

Any time that saved bit is 1, the number should round up,

Tautech, would we be able to get any developer insight into what approach they use, and where the scaling is stored?

With negative numbers we have to be cautious.

What gets really nice results, which also works with negative dividers is:
(It is like adding (or substracting) a 0.5 to let the value flip to the nearest when truncating.)

Code: [Select]

if (Value >= 0) = (Divider >= 0) then
  Result:= (Value + Divider div 2) div Divider
else
  Result:= (Value - Divider div 2) div Divider


I think the problem has its origin in that there's some code like this

Code: [Select]

Result:= Value div Divider
if (Value mod Divider) >= (Divider div 2) then
  Result:= Result + 1
Forgetting the rounding down of negative values.
I've tried all kinds of programming errors, but only for 2 divisions max. I'm guessing this kind of error is repeated several times in the steps to get to a DAC value.
 

Maybe I should clarify, I mean not the problem of the glitches, but of the discontinuity.

How do I know there's a discontinuity?

At certain wave values there're glitches. It is 99.9% sure that those glitches are related with special DAC values using a simple transformation DACcode = WaveValue * Factor / Divider - Offset.

However the resulting DAC values don't exactly match up the bit patterns which would cause a glitch. The DACcodes are off by a 1..2 (on a scale of 16K). Especially on the negative side.

So using the nearest DACcodes that should glitch and the WaveValues that belong to them one can try out different calculations (with errors) to get matching logic in all cases. This matching logic would then be the same as the logic applied in the AWG (for at least the 206 glitching values).
I can get close to 72% match, but not 100% using a combination of rounding error's.

The problem is, this matching should not be hard at all. There're should be a 100% match without simulating rounding errors.

Can this problem of discontinuity be seen in the output?

I thinks so, at some WaveValue value transitions (value -> value + 1), the DAC value will be off, thus the wrong "digital step" (dacvalue -> dacvalue - 2) will be taken. Thus it will be (only) one or two glitch on it self.

What would lead to a better solution?
* Calculate with as many bits as is possible through all the steps (32 bit, if that's possible).
* Do only one division as late as possible and with proper rounding.

There's also the slight possibility that there's something done on purpose, for example using 2 offsets: one for the most significant bit on and one for the most significant bit off. This trick could mitigate a DAC step error.
I already know different devices have different offsets, so it could be...
But the glitch at the 0 dac value should then not be the strongest in my device A.

[HendriXML]

I wanted to see how useful the method of doing multi window measurements would be using the SAG1021.

From -2.0 to 2.0 V, I did 20 partial and overlapping measurements (batches). Each batch climbing in voltage (DSO offset and AGW offset).

The AWG was loaded with a stairway ramp of 50 different value blocks evenly spread with an amplitude of 400 mV and thus a difference of 8 mV between them.  These value blocks where mapped to (multi segment) DSO acquisitions and then averaged. (Multiple frames and the block itself). For each batch a data file was written, containing the set/expected wave voltage, the measured one (DSO), and the difference between them.

These are shown in the graph against each other. Ideally it should be a straight line.

On a secondary axis the difference between the values are shown. This shows whether there's an offset, amplitude error etc for each batch.

The VDiv on the scope was 100 mV/div resulting in a 4 mV resolution.

[HendriXML]

What can be seen clearly in the graphs is that the offset error is much lower when the offset is in the -0.6 to 0.6 range. Outside this range it is quite high, which also happens when the wave amplitude is set higher than 0.6 V. (Why does it seem that these are linked to the same offset issue?)
I thought I could use this to do higher resolution measurements with the DSO. But is would take quite some effort to "calibrate" the measurements.. Also I'm not sure whether the offsets are stable/predictable.

It should also be said that also the DSO measurements imperfections may take part in the discontinuities. Also a perfect graph would not ensure that the devices are perfect (errors could cancel each other out). However in the graphs, the visible faults do give insight into things that might ruin the party.

[HendriXML]

Looking at the offset stuff, it is clear that the DC mode of the devices should be checked around -600 mV and 600 mV.

Having done that it turned out around -700 mV and 700 mV there's a change in range. (Relay clicks)

So it is nice to know what the offset voltage jump is before and after, so here're the results measured with a Fluke MM:
Device A (mV)

Code: [Select]

-696 -> -696
relay click
-695 -> -704

704 -> 701
relay click
705 -> 704

Device B (mV)

Code: [Select]

-700 -> -698
relay click
-699 -> -700

699 -> 699
relay click
700 -> 702

So no drops or rises of about 30 mV. This thus only seems to happen if there's a superimposed wave.

More reliable, but using only the DC mode of generating test voltages would be a lot slower. 1 value per "batch" instead of 50 (or many more).

Also the transition of +1 of device A from -696 to -695 results in an output transition of -696 to -704, which is -8. That's still an transition error of 9. That's 9x the step of what was requested.

[HendriXML]

I just realized that putting 2 of these AWG’s in series. One doing a DC offset, one doing only the wave, with the offset zero-ed would give much better results than using only one device.

That alone is some indication that a better design could lead to better results. But I don’t know how these SAG1021 perform in relation to others in the market.

One could say, yeh there’re not expensive, so what do you expect?

But the price difference could also justified by other things:
* extruded 3 piece alu case
* no screen/buttons/knobs
* no power supply
* depends on control through dso, which needs to be bought
* only one channel
* limited bandwidth

In my opinion there should be budget enough left over to have it perform well.

So my question would be, what should be expected from this device? I’d like to hear some opinions.

[Rerouter]

There are a few memories in these devices that the scaling factors could be stored,

right next to the FPGA we have a 25P40 SPI flash memory, 4 mb in size, probably for the fpga image, but it leaves a decent amount of free room.
https://www.micron.com/-/media/documents/products/data-sheet/nor-flash/serial-nor/m25p/m25p40.pdf

Underneath the USB controller we have a I2C memory, It is used for the memory controllers boot up settings such as VID PID etc, but there is room left over. 
https://www.promelec.ru/pdf/AT24C512C.pdf

If it exists, it will be in one of them, I would suspect the I2C memory more than the SPI one, as the free space of that adds up mostly to the size of all the default baked in waveforms

My suspicion is the device is fully self contained, and can work without the scope, more that we just don't know how to initialise it yet. would probably involve fun like forcing it into USB1.0 speed and hooking it up to a logic analyser. It does have the drivers in the scope files. But I am not yet able to interprit them.

[HendriXML]

What I’m curious about is why different units have different “tuning values”. The wave offset, and the values of switching to another range in the dc-mode. Is that done on factory and/or is it a calibration thing.
And if so, why does it not do a better job 
Would be nice if there was some kind of calibration process that users could run to optimize things a lot more.

[HendriXML]

I’ve been offered to switch to a another AWG by paying the difference:
https://www.eevblog.com/forum/testgear/sag1021-vs-sdg1032-what-to-expect/

But before doing so I’d like to know whether to expect a more precise performance.

Normally I would prefer to hack some issue away, but some of them are beyond my control.

So some advice would be nice!

[HendriXML]

In regard to doing precise measurements I think having two outputs in parallel and have a load (preferably known and static) on them should give the possibility to have different / special generated arbitrary waves correct the DAC issues of each other. In the other waves the issues are then somewhat averaged. For this one does not even need the know the underlying calculations to DAC values
Having the 2 outputs in series might also give some extra possibilities to have more continuous values.

[tautech]

Firmware updates that may or may not help with your results:
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg2431869/#msg2431869

[HendriXML]

Firmware updates that may or may not help with your results:
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg2431869/#msg2431869

Always nice that things get improved!

However the scope performed to my opinion very well, and I don’t think the fixes are related to my measurements done here.

I can mention a few things that I still miss:
* a way to acquire a certain single segment/frame using the (SCPI) wave setup command and a SN parameter.
* a fix that the number of points/samples can be limited by the using wave setup command, now it returns repeating values and is not usable when trying a limit
* a fix in the documentation: how to calculate a negative value in the wave data. It says doing minus 255, but I think it needs to be minus 256. But a lot of programming languages also can read it as a Int8. So no conversion is needed.

[tautech]

Note, there is an updated programming guide too. 

[HendriXML]

Note, there is an updated programming guide too. 

Yeh, I checked the calculation error right away. and it is still there.
For those using the wrong calculation the results are 1% off (at best) when using negative values. So this easy fix improves much with almost no effort!

[HendriXML]

Firmware updates that may or may not help with your results:
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg2431869/#msg2431869

Always nice that things get improved!

However the scope performed to my opinion very well, and I don’t think the fixes are related to my measurements done here.

I can mention a few things that I still miss:
* a way to acquire a certain single segment/frame using the (SCPI) wave setup command and a SN parameter.
* a fix that the number of points/samples can be limited by the using wave setup command, now it returns repeating values and is not usable when trying a limit
* a fix in the documentation: how to calculate a negative value in the wave data. It says doing minus 255, but I think it needs to be minus 256. But a lot of programming languages also can read it as a Int8. So no conversion is needed.

* a fix that the number of points/samples can be limited by the using wave setup command, now it returns repeating values and is not usable when trying a limit
It seems this problem is solved 

[HendriXML]

In another thread I’ve posted a comparison between the SAG1021 and a SDG1032X.
https://www.eevblog.com/forum/testgear/sag1021-vs-sdg1032-what-to-expect/

I’ll try to take the measurement method to a next level. Now using a SDG1032X.

The scope and the awg’s are decent devices for measuring relative voltages, especially when using more sensitive ranges. I’ll now try to use these strong points of those devices to get accurate absolute voltage measurements.

When doing so I’ll put all my trust in my Fluke MM, and take that as a reference. Because it is not programmable, a good first step would be to check whether the accuracy of the MM can be “transferred” to using the awg. In other words can we create reference voltages, that are spot on! If so these reference voltages can be used to automatically check the scope (offset dac and signal adc).

The range we’ll try to measure in is 0 to 1.0 volt. (The method could be used for other ranges as well off course). In that range we want to achieve a certain sensitivity / number of measure points.

0.5 mV resolution, will be fine I guess. This can be achieved by the 10 mV/div. (thus 0.4 mV reso).

This will give a window of 80 mV,. In such a window I would like to have 3 reference voltages, at low, mid and high. Thus we need reference voltages with a 40 mV step. It may that that at the edges the scope’s adc becomes less accurate but that is something I would like to investigate as well.

So we need to be able to generate 25 reference voltages of 40 mV to reach 1.0V.

These will be verified before doing scope tests and after. But I’ll find out how difficult getting accurate voltages will be and how stable they are.

[HendriXML]

So I did some measurements. I went from coarse to fine in 3 steps. In each step the values from the other step where used to interpolate, so there was already a close approximation.

That makes is easy to turn the value knop to get an spot on readout on the MM.

I used the -600 mV to 600mV range of the MM to get a 0.1 mV resolution. So I needed to offset channel 1 of the AWG, with channel 2 (-500). Because the readout of the multimeter should be different then the OUT voltage, that one is showed as well.

Each value was set via SCPI by a script, which pauses to add the mapping into the code. So the mapping didn't take very long to create.

Code: [Select]

Coarse 0
Voltage OUT:0,00 MM: mV: -500,00 mV SET: 0,00 mV
Voltage OUT:1000,00 MM: mV: 500,00 mV SET: 1001,59 mV
Coarse 1
Voltage OUT:200,00 MM: mV: -300,00 mV SET: 200,30 mV
Voltage OUT:400,00 MM: mV: -100,00 mV SET: 399,80 mV
Voltage OUT:600,00 MM: mV: 100,00 mV SET: 600,10 mV
Voltage OUT:800,00 MM: mV: 300,00 mV SET: 800,30 mV
Coarse 2
Voltage OUT:40,00 MM: mV: -460,00 mV SET: 40,30 mV
Voltage OUT:80,00 MM: mV: -420,00 mV SET: 80,40 mV
Voltage OUT:120,00 MM: mV: -380,00 mV SET: 119,90 mV
Voltage OUT:160,00 MM: mV: -340,00 mV SET: 159,80 mV
Voltage OUT:240,00 MM: mV: -260,00 mV SET: 240,60 mV
Voltage OUT:280,00 MM: mV: -220,00 mV SET: 280,70 mV
Voltage OUT:320,00 MM: mV: -180,00 mV SET: 320,40 mV
Voltage OUT:360,00 MM: mV: -140,00 mV SET: 360,10 mV
Voltage OUT:440,00 MM: mV: -60,00 mV SET: 439,90 mV
Voltage OUT:480,00 MM: mV: -20,00 mV SET: 479,90 mV
Voltage OUT:520,00 MM: mV: 20,00 mV SET: 520,00 mV
Voltage OUT:560,00 MM: mV: 60,00 mV SET: 560,10 mV
Voltage OUT:640,00 MM: mV: 140,00 mV SET: 640,40 mV
Voltage OUT:680,00 MM: mV: 180,00 mV SET: 680,40 mV
Voltage OUT:720,00 MM: mV: 220,00 mV SET: 719,00 mV
Voltage OUT:760,00 MM: mV: 260,00 mV SET: 760,00 mV
Voltage OUT:840,00 MM: mV: 340,00 mV SET: 840,20 mV
Voltage OUT:880,00 MM: mV: 380,00 mV SET: 880,60 mV
Voltage OUT:920,00 MM: mV: 420,00 mV SET: 920,90 mV
Voltage OUT:960,00 MM: mV: 460,00 mV SET: 961,00 mV

As can be seen the AWG is accurate to +/- 2 mV (but most of the time the values are much closer) by itself. This mapping will make it accurate to about +/- 0.2mV.

I know my MM will also its own measurement errors, but in my lab it is the best reference for now.

[HendriXML]

I changed the way I measure. First I check and map the values until 640 mV, then I do combine of a negative offset to get the last value from 640 mV to 0 (looking at the MM). When I check the output at channel 2 with the MM, then it is -643.0 mV and not -640 mV. So there's 3 mV lost...


In this case that is a bit much, also I'd like to know what is happening. And what the mechanics of this combining are. (Does it do a polarity change digitally? Is the output impedance doubled?)

[HendriXML]

The combining function works digitally, stuff before the dacs. So there is no analog offset.
https://www.siglentamerica.com/operating-tip/generating-complex-waveforms-using-siglents-combine-function-x-series-dual-channel-generators/

Not hearing relays was somewhat a clue in this conclusion.

[HendriXML]

I made a new mapping, now not using the combine functionality. But using 2 channels and measure between the non-ground BNC wires. Starting with a zero offset on channel 2, until 640 mV. Then dialing until zero (thus about 640 mV at channel 2). And then continue measuring.

Roughly the max difference between the MM and the AWG values are about 0.25%

Siglent specifies the DC  Characteristics  as:
Accuracy ±(1%+3 mV) HiZ load

So its better than the specs (at the range 0-1.0V). By using the mapping I can get voltages close to the accuracy of my MM. (0.09%).
But because the MM is taken as the reference, the deviation to that reference is as close as 1 digit (0,01%).

Code: [Select]

Voltage OUT:0,0 mV; MM: 0,0 mV; SET: -0,3 mV
Voltage OUT:40,0 mV; MM: 40,1 mV; SET: 40,4 mV
Voltage OUT:80,0 mV; MM: 80,0 mV; SET: 79,9 mV
Voltage OUT:120,0 mV; MM: 120,0 mV; SET: 120,5 mV
Voltage OUT:160,0 mV; MM: 160,0 mV; SET: 160,4 mV
Voltage OUT:200,0 mV; MM: 200,0 mV; SET: 199,8 mV
Voltage OUT:240,0 mV; MM: 240,0 mV; SET: 239,7 mV
Voltage OUT:280,0 mV; MM: 280,0 mV; SET: 280,0 mV
Voltage OUT:320,0 mV; MM: 320,0 mV; SET: 320,2 mV
Voltage OUT:360,0 mV; MM: 360,0 mV; SET: 360,4 mV
Voltage OUT:400,0 mV; MM: 400,0 mV; SET: 400,5 mV
Voltage OUT:440,0 mV; MM: 440,0 mV; SET: 440,8 mV
Voltage OUT:480,0 mV; MM: 480,0 mV; SET: 481,0 mV
Voltage OUT:520,0 mV; MM: 520,0 mV; SET: 521,3 mV
Voltage OUT:560,0 mV; MM: 560,0 mV; SET: 561,9 mV
Voltage OUT:600,0 mV; MM: 600,0 mV; SET: 602,1 mV
Voltage OUT:640,0 mV; MM: 640,0 mV; SET: 641,9 mV
Voltage OUT:680,0 mV; MM: 40,0 mV; SET: 681,8 mV
Voltage OUT:720,0 mV; MM: 80,0 mV; SET: 722,3 mV
Voltage OUT:760,0 mV; MM: 120,0 mV; SET: 761,9 mV
Voltage OUT:800,0 mV; MM: 160,0 mV; SET: 801,8 mV
Voltage OUT:840,0 mV; MM: 200,0 mV; SET: 842,1 mV
Voltage OUT:880,0 mV; MM: 240,0 mV; SET: 881,7 mV
Voltage OUT:920,0 mV; MM: 280,0 mV; SET: 921,4 mV
Voltage OUT:960,0 mV; MM: 320,0 mV; SET: 961,4 mV
Voltage OUT:1000,0 mV; MM: 360,5 mV; SET: 1002,3 mV


[HendriXML]

For each of the reference voltages, I let a script center that voltage, thus tuning the DSO offset so the DSO adc would measure less than 0.1 mV.

So in the upcoming measurements the offset will be set to a more calibrated value.

As can be seen the offset dac (channel 1) is very close to the MM value. From the 4 channels 2 are even significantly closer.

The next step will be to measure high/low (+40mV / -40mV) reference voltages at about + 4 div and -4 div, to get an idea of how much the adc of the scope deviates.

Code: [Select]

Voltage OUT:0,0 mV; DSO: 0,0 mV
Voltage OUT:40,0 mV; DSO: 40,2 mV
Voltage OUT:80,0 mV; DSO: 80,1 mV
Voltage OUT:120,0 mV; DSO: 120,2 mV
Voltage OUT:160,0 mV; DSO: 160,2 mV
Voltage OUT:200,0 mV; DSO: 200,3 mV
Voltage OUT:240,0 mV; DSO: 240,4 mV
Voltage OUT:280,0 mV; DSO: 280,4 mV
Voltage OUT:320,0 mV; DSO: 320,5 mV
Voltage OUT:360,0 mV; DSO: 360,5 mV
Voltage OUT:400,0 mV; DSO: 400,6 mV
Voltage OUT:440,0 mV; DSO: 440,6 mV
Voltage OUT:480,0 mV; DSO: 480,7 mV
Voltage OUT:520,0 mV; DSO: 520,7 mV
Voltage OUT:560,0 mV; DSO: 560,8 mV
Voltage OUT:600,0 mV; DSO: 600,8 mV
Voltage OUT:640,0 mV; DSO: 640,8 mV
Voltage OUT:680,0 mV; DSO: 680,9 mV
Voltage OUT:720,0 mV; DSO: 721,0 mV
Voltage OUT:760,0 mV; DSO: 761,1 mV
Voltage OUT:800,0 mV; DSO: 801,1 mV
Voltage OUT:840,0 mV; DSO: 841,2 mV
Voltage OUT:880,0 mV; DSO: 881,3 mV
Voltage OUT:920,0 mV; DSO: 921,4 mV
Voltage OUT:960,0 mV; DSO: 961,4 mV
Voltage OUT:1000,0 mV; DSO: 1001,9 mV


[HendriXML]

It was quite hotter than normal at the lab so I ran the auto calibration of the scope. And the manual determination of AWG offset mapping.

I added the values -45, -40, -30, -20, -20, -10, 0, 10, 20, 30, 40, 45 so that they also can be set very precisely. I used those voltages to measure the DSO adc response.

This makes it possible to translate/map DSO wave values to precise voltages.


The combination of setting a precise DSO offset combined with precise adc measurement and measurement window shifting will hopefully give the possibility to use the scope as a high precision tool. (At least for some duration). I'll continue under the assumption that the offset and adc measurement are independent of each other regarding errors.


The next and final step is to ensure we can superimpose precise voltages on the offset using arbitrary wave data.

If that is done, we should be able to create and measure a very accurate staircase ramp (lineair/continuous in voltage generation and measurement) from 0 to 1.0 V using 25 shifting windows.

Code: [Select]

Voltage OUT:0,0 mV; DSO: -0,4 mV
Voltage OUT:40,0 mV; DSO: 39,7 mV
Voltage OUT:80,0 mV; DSO: 79,6 mV
Voltage OUT:120,0 mV; DSO: 119,6 mV
Voltage OUT:160,0 mV; DSO: 159,7 mV
Voltage OUT:200,0 mV; DSO: 195,4 mV
Voltage OUT:240,0 mV; DSO: 240,0 mV
Voltage OUT:280,0 mV; DSO: 280,0 mV
Voltage OUT:320,0 mV; DSO: 320,0 mV
Voltage OUT:360,0 mV; DSO: 360,1 mV
Voltage OUT:400,0 mV; DSO: 400,1 mV
Voltage OUT:440,0 mV; DSO: 440,3 mV
Voltage OUT:480,0 mV; DSO: 480,3 mV
Voltage OUT:520,0 mV; DSO: 520,4 mV
Voltage OUT:560,0 mV; DSO: 560,4 mV
Voltage OUT:600,0 mV; DSO: 600,5 mV
Voltage OUT:640,0 mV; DSO: 640,6 mV
Voltage OUT:680,0 mV; DSO: 680,5 mV
Voltage OUT:720,0 mV; DSO: 720,7 mV
Voltage OUT:760,0 mV; DSO: 760,6 mV
Voltage OUT:800,0 mV; DSO: 800,7 mV
Voltage OUT:840,0 mV; DSO: 840,8 mV
Voltage OUT:880,0 mV; DSO: 880,9 mV
Voltage OUT:920,0 mV; DSO: 921,0 mV
Voltage OUT:960,0 mV; DSO: 961,1 mV
Voltage OUT:1000,0 mV; DSO: 1001,7 mV

Voltage OUT:-45,0 mV; DAC: -44,0 mV
Voltage OUT:-40,0 mV; DAC: -40,0 mV
Voltage OUT:-30,0 mV; DAC: -30,3 mV
Voltage OUT:-20,0 mV; DAC: -20,1 mV
Voltage OUT:-10,0 mV; DAC: -10,0 mV
Voltage OUT:0,0 mV; DAC: 0,0 mV
Voltage OUT:10,0 mV; DAC: 10,2 mV
Voltage OUT:20,0 mV; DAC: 20,4 mV
Voltage OUT:30,0 mV; DAC: 30,6 mV
Voltage OUT:40,0 mV; DAC: 40,4 mV
Voltage OUT:45,0 mV; DAC: 44,4 mV



[HendriXML]

I think the measurement part will be around 1 mV accurate in the range of 0-1.0 V. Thus some 0.1% error (+MM errors).  In that range a thousand precise voltages can be generated and measured in a few minutes. A second scope channel will be “calibrated” as well to do the divider measurements.

[HendriXML]

For the wave voltages I did some iterative measurements, each time updating the interpolator values. This way we know wat 16 bit dac value (WVE) is needed to create a certain voltage (TARGET).

I took a 50 mV amplitude with a enough margin for errors, to be certain that a -20 mV to 20 mV range can be generated within the dac range.

The EXP (expected) voltage is the voltage that should be outputted at a certain dac value (WVE) (repeated in a single value wave).

As can be seen there is some offset, and amplification that needs correcting. But if that is consistent at different offset voltages, then superimposing precise voltages (accurate to 0.1 mV) would not be any problem.

Code: [Select]

Voltage TARGET: -23,0 mV; WVE: -30827; EXP: -23,5 mV; MM: -23,0 mV
Voltage TARGET: -20,0 mV; WVE: -26868; EXP: -20,5 mV; MM: -20,0 mV
Voltage TARGET: -10,0 mV; WVE: -13850; EXP: -10,6 mV; MM: -10,0 mV
Voltage TARGET: 0,0 mV; WVE: -861; EXP: -0,7 mV; MM: 0,0 mV
Voltage TARGET: 10,0 mV; WVE: 12068; EXP: 9,2 mV; MM: 10,0 mV
Voltage TARGET: 20,0 mV; WVE: 25057; EXP: 19,1 mV; MM: 20,0 mV
Voltage TARGET: 23,0 mV; WVE: 29028; EXP: 22,1 mV; MM: 23,0 mV


[HendriXML]

The next step will be to test whether a combination of offsets and a single value superimposed wave can indeed generate precise voltages, verified by the MM.

[HendriXML]

The voltages in the following table where checked. These voltages are generate using offsets n x 40 mV and wave voltages from -20 mV to 20 mV.

All voltages below 660 mV had +/- 1 digit accuracy, thus maximal 0.1 mV off. I did not enter the true MM values, because that would take a lot of time, and going better than 1 digit off would not be worth the efford.

Voltages above 660 mV where measured in a different range, but I'm convinced that they'll be as accurate as well, because it seems that the wave and offset errors are independent of each other. So the error correction will continue in the same manner. (I could measure this with an channel 2 offset as well, but an accuracy that is in par with my Fluke is OK to me)

the EXP is again the voltage that "should" be outputted by the AWG using the requested parameters. Although the standard accuracy seems OK most of the time, the worse deviations are improved by more than 10x.

Code: [Select]

Voltage TARGET: 0,0 mV; EXP: -0,3 mV; MM: 0,0 mV
Voltage TARGET: 5,0 mV; EXP: 4,6 mV; MM: 5,0 mV
Voltage TARGET: 10,0 mV; EXP: 9,6 mV; MM: 10,0 mV
Voltage TARGET: 15,0 mV; EXP: 14,6 mV; MM: 15,0 mV
Voltage TARGET: 20,0 mV; EXP: 20,5 mV; MM: 20,0 mV
Voltage TARGET: 25,0 mV; EXP: 25,5 mV; MM: 25,0 mV
Voltage TARGET: 30,0 mV; EXP: 30,4 mV; MM: 30,0 mV
Voltage TARGET: 35,0 mV; EXP: 35,4 mV; MM: 35,0 mV
Voltage TARGET: 40,0 mV; EXP: 40,4 mV; MM: 40,0 mV
Voltage TARGET: 45,0 mV; EXP: 45,3 mV; MM: 45,0 mV
Voltage TARGET: 50,0 mV; EXP: 50,3 mV; MM: 50,0 mV
Voltage TARGET: 55,0 mV; EXP: 55,3 mV; MM: 55,0 mV
Voltage TARGET: 60,0 mV; EXP: 60,0 mV; MM: 60,0 mV
Voltage TARGET: 65,0 mV; EXP: 65,0 mV; MM: 65,0 mV
Voltage TARGET: 70,0 mV; EXP: 69,9 mV; MM: 70,0 mV
Voltage TARGET: 75,0 mV; EXP: 74,9 mV; MM: 75,0 mV
Voltage TARGET: 80,0 mV; EXP: 79,9 mV; MM: 80,0 mV
Voltage TARGET: 85,0 mV; EXP: 84,8 mV; MM: 85,0 mV
Voltage TARGET: 90,0 mV; EXP: 89,8 mV; MM: 90,0 mV
Voltage TARGET: 95,0 mV; EXP: 94,8 mV; MM: 95,0 mV
Voltage TARGET: 100,0 mV; EXP: 100,5 mV; MM: 100,0 mV
Voltage TARGET: 105,0 mV; EXP: 105,5 mV; MM: 105,0 mV
Voltage TARGET: 110,0 mV; EXP: 110,4 mV; MM: 110,0 mV
Voltage TARGET: 115,0 mV; EXP: 115,4 mV; MM: 115,0 mV
Voltage TARGET: 120,0 mV; EXP: 120,4 mV; MM: 120,0 mV
Voltage TARGET: 125,0 mV; EXP: 125,3 mV; MM: 125,0 mV
Voltage TARGET: 130,0 mV; EXP: 130,3 mV; MM: 130,0 mV
Voltage TARGET: 135,0 mV; EXP: 135,3 mV; MM: 135,0 mV
Voltage TARGET: 140,0 mV; EXP: 140,5 mV; MM: 140,0 mV
Voltage TARGET: 145,0 mV; EXP: 145,5 mV; MM: 145,0 mV
Voltage TARGET: 150,0 mV; EXP: 150,4 mV; MM: 150,0 mV
Voltage TARGET: 155,0 mV; EXP: 155,4 mV; MM: 155,0 mV
Voltage TARGET: 160,0 mV; EXP: 160,4 mV; MM: 160,0 mV
Voltage TARGET: 165,0 mV; EXP: 165,3 mV; MM: 165,0 mV
Voltage TARGET: 170,0 mV; EXP: 170,3 mV; MM: 170,0 mV
Voltage TARGET: 175,0 mV; EXP: 175,3 mV; MM: 175,0 mV
Voltage TARGET: 180,0 mV; EXP: 179,9 mV; MM: 180,0 mV
Voltage TARGET: 185,0 mV; EXP: 184,9 mV; MM: 185,0 mV
Voltage TARGET: 190,0 mV; EXP: 189,8 mV; MM: 190,0 mV
Voltage TARGET: 195,0 mV; EXP: 194,8 mV; MM: 195,0 mV
Voltage TARGET: 200,0 mV; EXP: 199,8 mV; MM: 200,0 mV
Voltage TARGET: 205,0 mV; EXP: 204,7 mV; MM: 205,0 mV
Voltage TARGET: 210,0 mV; EXP: 209,7 mV; MM: 210,0 mV
Voltage TARGET: 215,0 mV; EXP: 214,7 mV; MM: 215,0 mV
Voltage TARGET: 220,0 mV; EXP: 219,8 mV; MM: 220,0 mV
Voltage TARGET: 225,0 mV; EXP: 224,8 mV; MM: 225,0 mV
Voltage TARGET: 230,0 mV; EXP: 229,7 mV; MM: 230,0 mV
Voltage TARGET: 235,0 mV; EXP: 234,7 mV; MM: 235,0 mV
Voltage TARGET: 240,0 mV; EXP: 239,7 mV; MM: 240,0 mV
Voltage TARGET: 245,0 mV; EXP: 244,6 mV; MM: 245,0 mV
Voltage TARGET: 250,0 mV; EXP: 249,6 mV; MM: 250,0 mV
Voltage TARGET: 255,0 mV; EXP: 254,6 mV; MM: 255,0 mV
Voltage TARGET: 260,0 mV; EXP: 260,1 mV; MM: 260,0 mV
Voltage TARGET: 265,0 mV; EXP: 265,1 mV; MM: 265,0 mV
Voltage TARGET: 270,0 mV; EXP: 270,0 mV; MM: 270,0 mV
Voltage TARGET: 275,0 mV; EXP: 275,0 mV; MM: 275,0 mV
Voltage TARGET: 280,0 mV; EXP: 280,0 mV; MM: 280,0 mV
Voltage TARGET: 285,0 mV; EXP: 284,9 mV; MM: 285,0 mV
Voltage TARGET: 290,0 mV; EXP: 289,9 mV; MM: 290,0 mV
Voltage TARGET: 295,0 mV; EXP: 294,9 mV; MM: 295,0 mV
Voltage TARGET: 300,0 mV; EXP: 300,3 mV; MM: 300,0 mV
Voltage TARGET: 305,0 mV; EXP: 305,3 mV; MM: 305,0 mV
Voltage TARGET: 310,0 mV; EXP: 310,2 mV; MM: 310,0 mV
Voltage TARGET: 315,0 mV; EXP: 315,2 mV; MM: 315,0 mV
Voltage TARGET: 320,0 mV; EXP: 320,2 mV; MM: 320,0 mV
Voltage TARGET: 325,0 mV; EXP: 325,1 mV; MM: 325,0 mV
Voltage TARGET: 330,0 mV; EXP: 330,1 mV; MM: 330,0 mV
Voltage TARGET: 335,0 mV; EXP: 335,1 mV; MM: 335,0 mV
Voltage TARGET: 340,0 mV; EXP: 340,5 mV; MM: 340,0 mV
Voltage TARGET: 345,0 mV; EXP: 345,5 mV; MM: 345,0 mV
Voltage TARGET: 350,0 mV; EXP: 350,4 mV; MM: 350,0 mV
Voltage TARGET: 355,0 mV; EXP: 355,4 mV; MM: 355,0 mV
Voltage TARGET: 360,0 mV; EXP: 360,4 mV; MM: 360,0 mV
Voltage TARGET: 365,0 mV; EXP: 365,3 mV; MM: 365,0 mV
Voltage TARGET: 370,0 mV; EXP: 370,3 mV; MM: 370,0 mV
Voltage TARGET: 375,0 mV; EXP: 375,3 mV; MM: 375,0 mV
Voltage TARGET: 380,0 mV; EXP: 380,6 mV; MM: 380,0 mV
Voltage TARGET: 385,0 mV; EXP: 385,6 mV; MM: 385,0 mV
Voltage TARGET: 390,0 mV; EXP: 390,5 mV; MM: 390,0 mV
Voltage TARGET: 395,0 mV; EXP: 395,5 mV; MM: 395,0 mV
Voltage TARGET: 400,0 mV; EXP: 400,5 mV; MM: 400,0 mV
Voltage TARGET: 405,0 mV; EXP: 405,4 mV; MM: 405,0 mV
Voltage TARGET: 410,0 mV; EXP: 410,4 mV; MM: 410,0 mV
Voltage TARGET: 415,0 mV; EXP: 415,4 mV; MM: 415,0 mV
Voltage TARGET: 420,0 mV; EXP: 420,9 mV; MM: 420,0 mV
Voltage TARGET: 425,0 mV; EXP: 425,9 mV; MM: 425,0 mV
Voltage TARGET: 430,0 mV; EXP: 430,8 mV; MM: 430,0 mV
Voltage TARGET: 435,0 mV; EXP: 435,8 mV; MM: 435,0 mV
Voltage TARGET: 440,0 mV; EXP: 440,8 mV; MM: 440,0 mV
Voltage TARGET: 445,0 mV; EXP: 445,7 mV; MM: 445,0 mV
Voltage TARGET: 450,0 mV; EXP: 450,7 mV; MM: 450,0 mV
Voltage TARGET: 455,0 mV; EXP: 455,7 mV; MM: 455,0 mV
Voltage TARGET: 460,0 mV; EXP: 461,1 mV; MM: 460,0 mV
Voltage TARGET: 465,0 mV; EXP: 466,1 mV; MM: 465,0 mV
Voltage TARGET: 470,0 mV; EXP: 471,0 mV; MM: 470,0 mV
Voltage TARGET: 475,0 mV; EXP: 476,0 mV; MM: 475,0 mV
Voltage TARGET: 480,0 mV; EXP: 481,0 mV; MM: 480,0 mV
Voltage TARGET: 485,0 mV; EXP: 485,9 mV; MM: 485,0 mV
Voltage TARGET: 490,0 mV; EXP: 490,9 mV; MM: 490,0 mV
Voltage TARGET: 495,0 mV; EXP: 495,9 mV; MM: 495,0 mV
Voltage TARGET: 500,0 mV; EXP: 501,3 mV; MM: 500,0 mV
Voltage TARGET: 505,0 mV; EXP: 506,3 mV; MM: 505,0 mV
Voltage TARGET: 510,0 mV; EXP: 511,2 mV; MM: 510,0 mV
Voltage TARGET: 515,0 mV; EXP: 516,2 mV; MM: 515,0 mV
Voltage TARGET: 520,0 mV; EXP: 521,2 mV; MM: 520,0 mV
Voltage TARGET: 525,0 mV; EXP: 526,1 mV; MM: 525,0 mV
Voltage TARGET: 530,0 mV; EXP: 531,1 mV; MM: 530,0 mV
Voltage TARGET: 535,0 mV; EXP: 536,1 mV; MM: 535,0 mV
Voltage TARGET: 540,0 mV; EXP: 541,9 mV; MM: 540,0 mV
Voltage TARGET: 545,0 mV; EXP: 546,9 mV; MM: 545,0 mV
Voltage TARGET: 550,0 mV; EXP: 551,8 mV; MM: 550,0 mV
Voltage TARGET: 555,0 mV; EXP: 556,8 mV; MM: 555,0 mV
Voltage TARGET: 560,0 mV; EXP: 561,8 mV; MM: 560,0 mV
Voltage TARGET: 565,0 mV; EXP: 566,7 mV; MM: 565,0 mV
Voltage TARGET: 570,0 mV; EXP: 571,7 mV; MM: 570,0 mV
Voltage TARGET: 575,0 mV; EXP: 576,7 mV; MM: 575,0 mV
Voltage TARGET: 580,0 mV; EXP: 582,2 mV; MM: 580,0 mV
Voltage TARGET: 585,0 mV; EXP: 587,2 mV; MM: 585,0 mV
Voltage TARGET: 590,0 mV; EXP: 592,1 mV; MM: 590,0 mV
Voltage TARGET: 595,0 mV; EXP: 597,1 mV; MM: 595,0 mV
Voltage TARGET: 600,0 mV; EXP: 602,1 mV; MM: 600,0 mV
Voltage TARGET: 605,0 mV; EXP: 607,0 mV; MM: 605,0 mV
Voltage TARGET: 610,0 mV; EXP: 612,0 mV; MM: 610,0 mV
Voltage TARGET: 615,0 mV; EXP: 617,0 mV; MM: 615,0 mV
Voltage TARGET: 620,0 mV; EXP: 622,0 mV; MM: 620,0 mV
Voltage TARGET: 625,0 mV; EXP: 627,0 mV; MM: 625,0 mV
Voltage TARGET: 630,0 mV; EXP: 631,9 mV; MM: 630,0 mV
Voltage TARGET: 635,0 mV; EXP: 636,9 mV; MM: 635,0 mV
Voltage TARGET: 640,0 mV; EXP: 641,9 mV; MM: 640,0 mV
Voltage TARGET: 645,0 mV; EXP: 646,8 mV; MM: 645,0 mV
Voltage TARGET: 650,0 mV; EXP: 651,8 mV; MM: 650,0 mV
Voltage TARGET: 655,0 mV; EXP: 656,8 mV; MM: 655,0 mV
Voltage TARGET: 660,0 mV; EXP: 662,0 mV; MM: 660,0 mV
Voltage TARGET: 665,0 mV; EXP: 667,0 mV; MM: 665,0 mV
Voltage TARGET: 670,0 mV; EXP: 671,9 mV; MM: 670,0 mV
Voltage TARGET: 675,0 mV; EXP: 676,9 mV; MM: 675,0 mV
Voltage TARGET: 680,0 mV; EXP: 681,9 mV; MM: 680,0 mV
Voltage TARGET: 685,0 mV; EXP: 686,8 mV; MM: 685,0 mV
Voltage TARGET: 690,0 mV; EXP: 691,8 mV; MM: 690,0 mV
Voltage TARGET: 695,0 mV; EXP: 696,8 mV; MM: 695,0 mV
Voltage TARGET: 700,0 mV; EXP: 702,4 mV; MM: 700,0 mV
Voltage TARGET: 705,0 mV; EXP: 707,4 mV; MM: 705,0 mV
Voltage TARGET: 710,0 mV; EXP: 712,3 mV; MM: 710,0 mV
Voltage TARGET: 715,0 mV; EXP: 717,3 mV; MM: 715,0 mV
Voltage TARGET: 720,0 mV; EXP: 722,3 mV; MM: 720,0 mV
Voltage TARGET: 725,0 mV; EXP: 727,2 mV; MM: 725,0 mV
Voltage TARGET: 730,0 mV; EXP: 732,2 mV; MM: 730,0 mV
Voltage TARGET: 735,0 mV; EXP: 737,2 mV; MM: 735,0 mV
Voltage TARGET: 740,0 mV; EXP: 742,0 mV; MM: 740,0 mV
Voltage TARGET: 745,0 mV; EXP: 747,0 mV; MM: 745,0 mV
Voltage TARGET: 750,0 mV; EXP: 751,9 mV; MM: 750,0 mV
Voltage TARGET: 755,0 mV; EXP: 756,9 mV; MM: 755,0 mV
Voltage TARGET: 760,0 mV; EXP: 761,9 mV; MM: 760,0 mV
Voltage TARGET: 765,0 mV; EXP: 766,8 mV; MM: 765,0 mV
Voltage TARGET: 770,0 mV; EXP: 771,8 mV; MM: 770,0 mV
Voltage TARGET: 775,0 mV; EXP: 776,8 mV; MM: 775,0 mV
Voltage TARGET: 780,0 mV; EXP: 782,0 mV; MM: 780,0 mV
Voltage TARGET: 785,0 mV; EXP: 787,0 mV; MM: 785,0 mV
Voltage TARGET: 790,0 mV; EXP: 791,9 mV; MM: 790,0 mV
Voltage TARGET: 795,0 mV; EXP: 796,9 mV; MM: 795,0 mV
Voltage TARGET: 800,0 mV; EXP: 801,9 mV; MM: 800,0 mV
Voltage TARGET: 805,0 mV; EXP: 806,8 mV; MM: 805,0 mV
Voltage TARGET: 810,0 mV; EXP: 811,8 mV; MM: 810,0 mV
Voltage TARGET: 815,0 mV; EXP: 816,8 mV; MM: 815,0 mV
Voltage TARGET: 820,0 mV; EXP: 822,2 mV; MM: 820,0 mV
Voltage TARGET: 825,0 mV; EXP: 827,2 mV; MM: 825,0 mV
Voltage TARGET: 830,0 mV; EXP: 832,1 mV; MM: 830,0 mV
Voltage TARGET: 835,0 mV; EXP: 837,1 mV; MM: 835,0 mV
Voltage TARGET: 840,0 mV; EXP: 842,1 mV; MM: 840,0 mV
Voltage TARGET: 845,0 mV; EXP: 847,0 mV; MM: 845,0 mV
Voltage TARGET: 850,0 mV; EXP: 852,0 mV; MM: 850,0 mV
Voltage TARGET: 855,0 mV; EXP: 857,0 mV; MM: 855,0 mV
Voltage TARGET: 860,0 mV; EXP: 861,8 mV; MM: 860,0 mV
Voltage TARGET: 865,0 mV; EXP: 866,8 mV; MM: 865,0 mV
Voltage TARGET: 870,0 mV; EXP: 871,7 mV; MM: 870,0 mV
Voltage TARGET: 875,0 mV; EXP: 876,7 mV; MM: 875,0 mV
Voltage TARGET: 880,0 mV; EXP: 881,7 mV; MM: 880,0 mV
Voltage TARGET: 885,0 mV; EXP: 886,6 mV; MM: 885,0 mV
Voltage TARGET: 890,0 mV; EXP: 891,6 mV; MM: 890,0 mV
Voltage TARGET: 895,0 mV; EXP: 896,6 mV; MM: 895,0 mV
Voltage TARGET: 900,0 mV; EXP: 901,5 mV; MM: 900,0 mV
Voltage TARGET: 905,0 mV; EXP: 906,5 mV; MM: 905,0 mV
Voltage TARGET: 910,0 mV; EXP: 911,4 mV; MM: 910,0 mV
Voltage TARGET: 915,0 mV; EXP: 916,4 mV; MM: 915,0 mV
Voltage TARGET: 920,0 mV; EXP: 921,4 mV; MM: 920,0 mV
Voltage TARGET: 925,0 mV; EXP: 926,3 mV; MM: 925,0 mV
Voltage TARGET: 930,0 mV; EXP: 931,3 mV; MM: 930,0 mV
Voltage TARGET: 935,0 mV; EXP: 936,3 mV; MM: 935,0 mV
Voltage TARGET: 940,0 mV; EXP: 941,5 mV; MM: 940,0 mV
Voltage TARGET: 945,0 mV; EXP: 946,5 mV; MM: 945,0 mV
Voltage TARGET: 950,0 mV; EXP: 951,4 mV; MM: 950,0 mV
Voltage TARGET: 955,0 mV; EXP: 956,4 mV; MM: 955,0 mV
Voltage TARGET: 960,0 mV; EXP: 961,4 mV; MM: 960,0 mV
Voltage TARGET: 965,0 mV; EXP: 966,3 mV; MM: 965,0 mV
Voltage TARGET: 970,0 mV; EXP: 971,3 mV; MM: 970,0 mV
Voltage TARGET: 975,0 mV; EXP: 976,3 mV; MM: 975,0 mV
Voltage TARGET: 980,0 mV; EXP: 982,4 mV; MM: 980,0 mV
Voltage TARGET: 985,0 mV; EXP: 987,4 mV; MM: 985,0 mV
Voltage TARGET: 990,0 mV; EXP: 992,3 mV; MM: 990,0 mV
Voltage TARGET: 995,0 mV; EXP: 997,3 mV; MM: 995,0 mV
Voltage TARGET: 1000,0 mV; EXP: 1002,3 mV; MM: 1000,0 mV


[HendriXML]

I'm now working towards the actual measurements on the diode/resistor divider. (I'm btw not really interested in the results anymore, but more in checking the method).

Formally I used 2 channels of the scope one to measure the applied voltage (minus the AWG impedance drop), and one measuring the voltage drop over the resistor.

Because in the new situation the voltage of the AWG is calibrated there is no need for measuring the applied voltage anymore. Only one probe will be fine. (Calibrated with the AWG)

During the multi window measurement it is important that the DSO measurements have a matching offset and range. It is possible to adjust doing batches when measurements get saturated, but I want to take another approach. (Also the scope is very sensitive to out of range (overdrive?) voltages ) The idea is to approximate the expected dso voltages for each test voltage, by using a coarse range. And using that approximation to iteratively do a finer measurement (smaller window) until the target range has been reached.

Then a final, multi segment measurement will be done.

But what range should be used and what voltage steps?

The calibrated way of generating voltages has a better accuracy than 0.5 mV that is certainly good enough to create steps of 4 mV. At the 10 mV/div this means 10 adc steps with a resolution of 0.4 mV. Creating smaller test steps will only enhance quantisation effects.
Using 4 mV test steps mean there will be a maximum of 20 measurements per "measurement window". However because we also have "voltage generation windows" (AWG offset and superimposed wave) and that those 2 won't always align it is possible that fewer measurements in a certain window take place.

Generating and measuring is done in batches. A batch will control only one measurement window and only one voltage generation window. The measurement points are divided over batches by the following logic:
Start with the lowest voltage test point and find the highest (calibrated) usable DSO offset for the expected voltage of that point. Find the highest (calibrated) usable AWG offset and wave value. The offsets (and corresponding range) are now bound to that batch. If succeeding test points go beyond that, a new batch will be defined (etc.).

So an (expected) out of range measurement and a out of range voltage generation can both trigger a new batch. If more probes would be added, a greater number of batches would be needed, depending on how well the different windows would align. But for now having only one probe makes life easy.

The expected voltage for each point will be determined by the same logic, except for the coarsest DSO range. That one needs to be chosen in a way that generated voltages cannot go out of range.

I'll need to implement this in a script and then test with a simple "awg out = dso in" test. That test will then also tell whether DSO offset / adc measurement errors are also independent of each other or not. Plotting a graph of the 250 measurements a near perfect straight line should be shown from (0, 0) to (1.0, 1.0).

[HendriXML]

The script is finally complete.

It allows the definition of testvoltages, in this case 0 mV, 4 mV, 8 mV .. 1000 mV, thus 251 testsamples.

These voltages are generated using a AWG offset and WaveValues (max 12) in an arbitrary wave. The actual (calibrated) offset and wave values are determined by a lookup table (interpolated), which is created using a MM. (A bench one would be handy...)

The voltage response is measured by a DSO, using an offset and ADC values.

Which offset is needed to have each samples response in the scopes measurement window is determined by first measuring the voltage at the 200 mV/div range and a -200  mV offset, so we're certain no sample is out of view. However the response voltages will not be very precise. The next iteration uses the 50 mV/div range, with some extra margin. The response voltage for each sample is now more accurate. The next resolution will be the 10 mV/div range. This is the same range as the final measurement, but just as the prior measurements it uses only 2 sequences. Its purpose is to get accurate response voltages, so very little margin is needed for the final step which uses 202 sequences.

Each sequence (or frame) contains about 4600 adc samples, thus each final response voltage is an average of about 460000 adc samples. (The script discards 50% of the extremes)
The scopes offsets are set using a lookup table (which was determined automatically using calibrated awg values). The ADC values are also read using a lookup table (also automatically generated).

The following table is what we get when just measuring the AWG's output. This a good check whether the assumption on which the calibrations are based are true (the independencies between awg offset and wave value and scope offset and adc values). And whether measurements (and counterbalanced errors) are consistent.

(Keep in mind that at 10 mV/div the adc steps are 0.4 mV! Averaging can give a bit more precision, but also has its limits.)

Code: [Select]

0 -0,119
4 3,905
8 7,84
12 11,838
16 15,882
20 19,925
24 23,037
28 27,257
32 31,481
36 35,579
40 39,69
44 43,561
48 47,468
52 51,433
56 55,478
60 59,522
64 63,299
68 67,485
72 71,693
76 75,751
80 79,879
84 83,847
88 87,72
92 91,604
96 95,511
100 99,529
104 103,239
108 107,439
112 111,647
116 115,725
120 119,854
124 123,781
128 127,635
132 131,509
136 135,481
140 139,522
144 143,283
148 147,465
152 151,546
156 155,571
160 159,596
164 163,543
168 167,47
172 171,488
176 175,526
180 179,535
184 183,283
188 187,471
192 191,677
196 195,742
200 199,869
204 203,812
208 207,67
212 211,541
216 215,486
220 219,522
224 223,166
228 227,377
232 231,599
236 235,693
240 239,82
244 243,71
248 247,558
252 251,452
256 255,478
260 259,522
264 263,055
268 267,273
272 271,501
276 275,604
280 279,718
284 283,577
288 287,473
292 291,433
296 295,478
300 299,522
304 303,007
308 307,226
312 311,452
316 315,547
320 319,651
324 323,544
328 327,463
332 331,433
336 335,478
340 339,522
344 343,355
348 347,543
352 351,736
356 355,77
360 359,897
364 363,907
368 367,817
372 371,789
376 375,723
380 379,659
384 383,354
388 387,539
392 391,734
396 395,769
400 399,896
404 403,902
408 407,807
412 411,765
416 415,677
420 419,62
424 423,127
428 427,341
432 431,564
436 435,667
440 439,79
444 443,659
448 447,517
452 451,44
456 455,478
460 459,522
464 463,115
468 467,331
472 471,553
476 475,652
480 479,774
484 483,635
488 487,507
492 491,435
496 495,478
500 499,522
504 503,25
508 507,457
512 511,546
516 515,571
520 519,596
524 523,54
528 527,467
532 531,462
536 535,469
540 539,5
544 543,2
548 547,404
552 551,618
556 555,708
560 559,835
564 563,745
568 567,59
572 571,469
576 575,478
580 579,522
584 582,963
588 587,176
592 591,377
596 595,443
600 599,564
604 603,531
608 607,457
612 611,433
616 615,478
620 619,522
624 623,252
628 627,441
632 631,646
636 635,726
640 639,854
644 643,78
648 647,632
652 651,493
656 655,478
660 659,522
664 662,974
668 667,19
672 671,402
676 675,477
680 679,583
684 683,532
688 687,459
692 691,433
696 695,478
700 699,522
704 703,358
708 707,561
712 711,746
716 715,779
720 719,905
724 723,916
728 727,839
732 731,834
736 735,834
740 739,784
744 743,341
748 747,513
752 751,714
756 755,76
760 759,887
764 763,879
768 767,762
772 771,676
776 775,561
780 779,557
784 783,34
788 787,514
792 791,717
796 795,762
800 799,887
804 803,871
808 807,752
812 811,64
816 815,531
820 819,541
824 823,179
828 827,383
832 831,597
836 835,689
840 839,814
844 843,714
848 847,564
852 851,462
856 855,478
860 859,522
864 863,183
868 867,392
872 871,605
876 875,691
880 879,811
884 883,702
888 887,544
892 891,45
896 895,478
900 899,522
904 903,206
908 907,409
912 911,62
916 915,707
920 919,831
924 923,735
928 927,585
932 931,468
936 935,478
940 939,522
944 942,963
948 947,176
952 951,383
956 955,452
960 959,569
964 963,531
968 967,458
972 971,433
976 975,478
980 979,522
984 983,806
988 987,795
992 991,774
996 995,751
1000 999,776


[HendriXML]

Here are all the testsamples in a graph. The reddish line shows the error voltage between what was measured and what was expected. Both the AWG and the DSO can contribute to that error voltage.

Having more calibration points might get the error voltage even lower, but I think around 1 mV accuracy (about 0.1% of full scale) is just fine!!

[HendriXML]

Here’s the graph of the diode/resistor divider. I also added a slope curve.

As can be seen it gives better results than a previous method, which was using a single ramp and capture that with one dso window (but with averaging multiple cycles/frames). Also the older graphs data was not calibrated in the same way so the accuracy is not nearly as good.

[HendriXML]

After creating a temperature control apparatus. I did a second measurement on 60 deg Celcius.

With the found data I'll try to simulate the effects on the electronic fuse circuit. I already know it is too temperature depended, and the knee of the curve is not "sharp" enough to use it in a reliable way. But it is a nice exercise for me to see how to determine that for certain.

[HendriXML]

The setup controlling the temperature is shown here:
https://www.eevblog.com/forum/projects/very-stable-temperature-control/msg2514615/#msg2514615