Using a AWG and a Scope -> using stairs to get to 1 mV accuracy - Page 1
Forum section: electronics / testgear

author: HendriXML
author_rank: Super Contributor
timestamp: April 12, 2019, 08:19:55 pm
content: For the added overcurrent protection in this little project:https://www.eevblog.com/forum/projects/battery-voltage-to-5v-regulation/msg2280605/?all#lastPostI 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 theAWGin DC mode and measuring the output with aMM. 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 aDSOusing the 64x average mode.* At 50 deg (using a heatgun): The same as above.The data of the DSO was fetched usingSCPI. 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!

author: tautech
author_rank: Super Contributor
timestamp: April 12, 2019, 08:58:08 pm
content: Quote from: HendriXML on April 12, 2019, 08:19:55 pmFYI the displayed sampling rate and mem depth are clues to what happens when Averaging or E-Res modes are selected.

author: HendriXML
author_rank: Super Contributor
timestamp: April 12, 2019, 09:33:57 pm
content: Quote from: tautech on April 12, 2019, 08:58:08 pmThe 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 alsoPersonally 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!

author: tautech
author_rank: Super Contributor
timestamp: April 12, 2019, 09:44:23 pm
content: Try a full mem depthbeforeselecting 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 12, 2019, 09:52:02 pm
content: Quote from: tautech on April 12, 2019, 09:44:23 pmBut 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!

author: tautech
author_rank: Super Contributor
timestamp: April 12, 2019, 10:23:12 pm
content: Quote from: HendriXML on April 12, 2019, 09:52:02 pmDunno, past my level of knowledge.Others might know and help.

author: HendriXML
author_rank: Super Contributor
timestamp: April 12, 2019, 10:31:39 pm
content: Quote from: tautech on April 12, 2019, 10:23:12 pmDid 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

author: tautech
author_rank: Super Contributor
timestamp: April 12, 2019, 10:53:53 pm
content: Quote from: HendriXML on April 12, 2019, 10:31:39 pmYes 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)

author: HendriXML
author_rank: Super Contributor
timestamp: April 12, 2019, 11:09:07 pm
content: Quote from: tautech on April 12, 2019, 10:53:53 pmYes, 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.

author: tautech
author_rank: Super Contributor
timestamp: April 12, 2019, 11:17:22 pm
content: Quote from: HendriXML on April 12, 2019, 11:09:07 pmThe .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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 13, 2019, 10:40:56 pm
content: 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)

author: HendriXML
author_rank: Super Contributor
timestamp: April 14, 2019, 09:27:52 am
content: 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?

author: joeqsmith
author_rank: Super Contributor
timestamp: April 14, 2019, 12:42:07 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 14, 2019, 02:17:11 pm
content: Quote from: joeqsmith on April 14, 2019, 12:42:07 pmI 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?

author: joeqsmith
author_rank: Super Contributor
timestamp: April 14, 2019, 04:08:03 pm
content: Quote from: HendriXML on April 14, 2019, 02:17:11 pmObviously 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 14, 2019, 05:14:56 pm
content: Quote from: joeqsmith on April 14, 2019, 04:08:03 pmSo 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 14, 2019, 05:40:49 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 14, 2019, 06:10:21 pm
content: Quote from: joeqsmith on April 14, 2019, 05:40:49 pmWhat 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 14, 2019, 06:16:40 pm
content: 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!

author: joeqsmith
author_rank: Super Contributor
timestamp: April 14, 2019, 07:37:03 pm
content: Quote from: HendriXML on April 14, 2019, 06:10:21 pmIt 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 14, 2019, 07:40:49 pm
content: 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

author: HendriXML
author_rank: Super Contributor
timestamp: April 14, 2019, 08:06:25 pm
content: Quote from: joeqsmith on April 14, 2019, 07:40:49 pmNice 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 14, 2019, 09:13:26 pm
content: 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

author: tautech
author_rank: Super Contributor
timestamp: April 14, 2019, 10:43:36 pm
content: Quote from: joeqsmith on April 14, 2019, 09:13:26 pmThe manuals of interest are:SDS1000X-E Series User ManualProgramming Guide For Digital Oscilloscopes SeriesThey're down the list a bit here:https://www.siglentamerica.com/resources/documents/digital-oscilloscopes/#sds1000x-e-seriesSome 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/#msg1394796Also 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/

author: HendriXML
author_rank: Super Contributor
timestamp: April 14, 2019, 10:59:04 pm
content: Quote from: tautech on April 14, 2019, 10:43:36 pmThanks!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/sIt'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.

author: tautech
author_rank: Super Contributor
timestamp: April 14, 2019, 11:23:11 pm
content: Quote from: HendriXML on April 14, 2019, 10:59:04 pmHow 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:Quote

author: HendriXML
author_rank: Super Contributor
timestamp: April 14, 2019, 11:33:35 pm
content: Quote from: tautech on April 14, 2019, 11:23:11 pmI'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

author: tautech
author_rank: Super Contributor
timestamp: April 14, 2019, 11:43:51 pm
content: The NIVISARuntimepackage as a minimummustbe installed for EasyScope for USBorLAN connection.For USB just check the USB port's driver is set to ausbtmc.inf.

author: HendriXML
author_rank: Super Contributor
timestamp: April 15, 2019, 12:11:47 am
content: Quote from: tautech on April 14, 2019, 11:43:51 pmI’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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 15, 2019, 12:49:39 am
content: Quote from: HendriXML on April 14, 2019, 10:59:04 pmSeems 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?Quote from: HendriXML on April 15, 2019, 12:11:47 amWith 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?

author: HendriXML
author_rank: Super Contributor
timestamp: April 15, 2019, 01:21:43 am
content: Quote from: joeqsmith on April 15, 2019, 12:49:39 amThe scope.Quote from: joeqsmith on April 15, 2019, 12:49:39 amIt is about 1GB installation and gives access to some nice (debugging) tools.

author: tautech
author_rank: Super Contributor
timestamp: April 15, 2019, 01:26:40 am
content: Quote from: HendriXML on April 15, 2019, 12:11:47 amInteresting.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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 15, 2019, 01:29:17 am
content: I checked the USB driver, the module which gives the AV is some COM dll.

author: HendriXML
author_rank: Super Contributor
timestamp: April 15, 2019, 01:31:24 am
content: Quote from: tautech on April 15, 2019, 01:26:40 amI'm using my self created scripting language/interpreter, so it can't possibly be better

author: joeqsmith
author_rank: Super Contributor
timestamp: April 15, 2019, 02:32:02 am
content: Quote from: HendriXML on April 15, 2019, 01:21:43 amIt'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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 15, 2019, 08:27:07 pm
content: 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 resolutionFor 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 15, 2019, 10:08:45 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 16, 2019, 07:41:18 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 16, 2019, 11:00:18 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 16, 2019, 11:58:13 pm
content: 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)

author: HendriXML
author_rank: Super Contributor
timestamp: April 17, 2019, 12:19:35 am
content: When doing time-based averaging with larger steps, the slopes become more stable.This will be usable for some coarse answers.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 17, 2019, 11:39:24 am
content: Quote from: HendriXML on April 15, 2019, 08:27:07 pmHow 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

author: Rerouter
author_rank: Super Contributor
timestamp: April 17, 2019, 11:53:55 am
content: 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 readingSo 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 17, 2019, 05:57:58 pm
content: Quote from: joeqsmith on April 17, 2019, 11:39:24 amI didn't, but here the slope at some points on the averaged ramp.It should be a straight line of theoretically 580,64 V/sI 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 17, 2019, 06:03:48 pm
content: Quote from: Rerouter on April 17, 2019, 11:53:55 amThat 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.

author: Rerouter
author_rank: Super Contributor
timestamp: April 17, 2019, 08:34:46 pm
content: 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

author: joeqsmith
author_rank: Super Contributor
timestamp: April 18, 2019, 02:23:11 am
content: Quote from: HendriXML on April 17, 2019, 05:57:58 pmTriggers 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 18, 2019, 10:17:44 am
content: Quote from: joeqsmith on April 18, 2019, 02:23:11 amMy 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 18, 2019, 01:02:56 pm
content: Quote from: Rerouter on April 17, 2019, 08:34:46 pmNow 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 18, 2019, 01:38:24 pm
content: 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.

author: tautech
author_rank: Super Contributor
timestamp: April 18, 2019, 03:07:08 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 19, 2019, 10:36:21 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 19, 2019, 10:42:00 am
content: 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?

author: HendriXML
author_rank: Super Contributor
timestamp: April 19, 2019, 11:14:51 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 19, 2019, 08:49:30 pm
content: 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?

author: HendriXML
author_rank: Super Contributor
timestamp: April 19, 2019, 08:56:11 pm
content: I created a normal size image with only the glitches at 400 mV.

author: HendriXML
author_rank: Super Contributor
timestamp: April 19, 2019, 09:01:45 pm
content: 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)

author: genghisnico13
author_rank: Regular Contributor
timestamp: April 20, 2019, 02:51:49 pm
content: I don't know much about the subject, but have you tried adding white noise to your input signal with the generator?

author: HendriXML
author_rank: Super Contributor
timestamp: April 20, 2019, 02:53:51 pm
content: Quote from: HendriXML on April 19, 2019, 09:01:45 pmIn 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/#msg2355744The 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 20, 2019, 03:02:15 pm
content: Quote from: genghisnico13 on April 20, 2019, 02:51:49 pmVia 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 20, 2019, 04:44:56 pm
content: Quote from: HendriXML on April 19, 2019, 08:49:30 pmIf 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

author: HendriXML
author_rank: Super Contributor
timestamp: April 20, 2019, 05:27:00 pm
content: Quote from: joeqsmith on April 20, 2019, 04:44:56 pmHi, 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 20, 2019, 06:02:51 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 20, 2019, 06:33:38 pm
content: 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

author: HendriXML
author_rank: Super Contributor
timestamp: April 20, 2019, 06:39:18 pm
content: Quote from: joeqsmith on April 20, 2019, 06:02:51 pmIn 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 20, 2019, 08:47:18 pm
content: Quote from: joeqsmith on April 20, 2019, 06:02:51 pmIn 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)

author: joeqsmith
author_rank: Super Contributor
timestamp: April 20, 2019, 09:03:53 pm
content: Quote from: HendriXML on April 20, 2019, 06:39:18 pmThat 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 20, 2019, 09:20:44 pm
content: Quote from: joeqsmith on April 20, 2019, 09:03:53 pmBut 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 20, 2019, 09:37:53 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 20, 2019, 09:53:10 pm
content: Quote from: joeqsmith on April 20, 2019, 09:37:53 pmWhat 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”.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 20, 2019, 10:20:53 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 20, 2019, 10:39:07 pm
content: If there’s any need the resulting frames, can also be aligned by handBut 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 20, 2019, 10:45:09 pm
content: Quote from: HendriXML on April 20, 2019, 10:39:07 pmIt'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?

author: HendriXML
author_rank: Super Contributor
timestamp: April 20, 2019, 11:04:04 pm
content: 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/#msg2356566But 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?

author: joeqsmith
author_rank: Super Contributor
timestamp: April 21, 2019, 12:42:44 am
content: Quote from: HendriXML on April 20, 2019, 11:04:04 pmI 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

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 01:08:04 am
content: 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 21, 2019, 01:24:43 am
content: 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.

author: Rerouter
author_rank: Super Contributor
timestamp: April 21, 2019, 01:31:53 am
content: 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 21, 2019, 01:45:39 am
content: Quote from: Rerouter on April 21, 2019, 01:31:53 amExactly what I am asking them to do! Perhaps you can do a better job explaining this to them.

author: tautech
author_rank: Super Contributor
timestamp: April 21, 2019, 01:47:28 am
content: Quote from: joeqsmith on April 21, 2019, 12:42:44 amHere 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 usingSCPI.commands from the EasyWave AWG software.

author: Rerouter
author_rank: Super Contributor
timestamp: April 21, 2019, 01:53:02 am
content: 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 21, 2019, 03:56:47 am
content: 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.

author: tautech
author_rank: Super Contributor
timestamp: April 21, 2019, 04:39:27 am
content: Quote from: joeqsmith on April 21, 2019, 03:56:47 amYes 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.pdfQuoteActually no, there are dozens of NA suppliers:https://www.siglentamerica.com/how-to-buy/Anyways, thanks Joe for your ideas and help thus far.

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 08:49:14 am
content: 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.

author: Rerouter
author_rank: Super Contributor
timestamp: April 21, 2019, 09:50:35 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 10:13:03 am
content: 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.

author: Rerouter
author_rank: Super Contributor
timestamp: April 21, 2019, 10:19:00 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 10:25:10 am
content: Quote from: joeqsmith on April 21, 2019, 01:24:43 amThe 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 signalsthose stand out!

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 10:58:43 am
content: Quote from: Rerouter on April 21, 2019, 10:19:00 amThat would be great!Here's the portion of my script that set things up:Code:<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/divCH1:100mV/div-400 mv offsetCH1 zooming in:10mV/div-435 mv offsetCH2:1 V/div-2.5V offsetTrigger delay (on screen dump): 0.00sAWG frequency is calculated, but it says on a screen dump: 324.675Type: RampAmplitude: 900mVOffset: 353mVSym: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 01:41:52 pm
content: Quote from: joeqsmith on April 21, 2019, 01:24:43 amMaybe 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?

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 06:51:50 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 07:08:55 pm
content: With 20M bandwidth limiting.Will check this range with the DC offset wave type of the AWG!

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 07:30:35 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 08:54:27 pm
content: 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?

author: tautech
author_rank: Super Contributor
timestamp: April 21, 2019, 09:15:11 pm
content: Quote from: HendriXML on April 21, 2019, 08:54:27 pmOpened EasyWave and then went to Open File, the default format it expects is .csv.

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 09:21:13 pm
content: 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?

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 09:34:55 pm
content: Quote from: tautech on April 21, 2019, 09:15:11 pmThanks 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.

author: tautech
author_rank: Super Contributor
timestamp: April 21, 2019, 10:24:43 pm
content: Quote from: HendriXML on April 21, 2019, 09:34:55 pmThe 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 10:42:36 pm
content: 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.

author: tautech
author_rank: Super Contributor
timestamp: April 21, 2019, 10:58:40 pm
content: Quote from: HendriXML on April 21, 2019, 10:42:36 pmVia 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 kptsof 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.

author: Rerouter
author_rank: Super Contributor
timestamp: April 21, 2019, 10:58:58 pm
content: 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 playedAs 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

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 11:17:52 pm
content: Quote from: Rerouter on April 21, 2019, 10:58:58 pmI 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?

author: Rerouter
author_rank: Super Contributor
timestamp: April 21, 2019, 11:27:38 pm
content: 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

author: HendriXML
author_rank: Super Contributor
timestamp: April 21, 2019, 11:40:05 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 27, 2019, 09:43:54 am
content: 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: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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 27, 2019, 09:59:07 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 27, 2019, 10:34:37 am
content: Quote from: HendriXML on April 27, 2019, 09:59:07 amIt 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 27, 2019, 03:14:15 pm
content: 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)

author: HendriXML
author_rank: Super Contributor
timestamp: April 27, 2019, 08:34:50 pm
content: 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

author: Rerouter
author_rank: Super Contributor
timestamp: April 27, 2019, 09:25:27 pm
content: The scaling is fixed per attenuator step, so the scaling is indeed digital, likely a hardware multiply / divide in the FPGA,

author: HendriXML
author_rank: Super Contributor
timestamp: April 27, 2019, 10:03:39 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 27, 2019, 11:14:54 pm
content: 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.

author: Rerouter
author_rank: Super Contributor
timestamp: April 27, 2019, 11:48:08 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 28, 2019, 12:03:26 am
content: Quote from: Rerouter on April 27, 2019, 11:48:08 pmThe 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.

author: Rerouter
author_rank: Super Contributor
timestamp: April 28, 2019, 01:52:41 am
content: You have plenty of options than just frequency, you can also set by period, this gives many more cleaner divisionsLeft is the period, right is how many times each sample is repeated in that periodThere 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 250.0065536 500.0098304 750.016384 1250.032768 2500.049152 3750.065536 5000.08192 6250.098304 7500.16384 12500.24576 18750.32768 25000.4096 31250.49152 37500.57344 43750.65536 50000.73728 56250.8192 62500.90112 68750.98304 75001.2288 93751.6384 125002.048 156252.4576 187502.8672 218753.2768 25000

author: HendriXML
author_rank: Super Contributor
timestamp: April 28, 2019, 08:39:24 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 28, 2019, 09:57:44 am
content: Quote from: Rerouter on April 28, 2019, 01:52:41 amNice 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:C1:BSWV WVTP,ARB,PERI,0.0032768,AMP,1,OFST,0.5I 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).

author: Rerouter
author_rank: Super Contributor
timestamp: April 28, 2019, 10:08:14 am
content: I was suspicious it may be something else internally, as the resulting frequency had more then 7 significant digits after setting the period via SCPIas 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

author: HendriXML
author_rank: Super Contributor
timestamp: April 28, 2019, 10:30:36 am
content: 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?

author: Rerouter
author_rank: Super Contributor
timestamp: April 28, 2019, 10:49:36 am
content: 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?

author: HendriXML
author_rank: Super Contributor
timestamp: April 28, 2019, 11:04:30 am
content: Quote from: Rerouter on April 28, 2019, 10:49:36 amI 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.

author: Rerouter
author_rank: Super Contributor
timestamp: April 28, 2019, 11:14:08 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 28, 2019, 11:36:50 am
content: 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?

author: Rerouter
author_rank: Super Contributor
timestamp: April 28, 2019, 11:46:34 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 28, 2019, 12:47:03 pm
content: For those who would like to test their AWG...The attached CVS file should result into the2663 and 2664 value ramp when send by EasyWave.The values can be checked by NI I/O trace when copying the message.67 0A = 266368 0A = 2664It starts with a -0.5 and a 0.5 to have EasyWave force an amplitude of 1.0Code:72. viWrite (TCPIP0::192.168.2.73::INSTR (0x1157ACD8), "C1:WVDT WVNM,Glitchy,...", 32888, 32888)Process ID: 0x00002D1C Thread ID: 0x00002860Start Time: 14:26:42.166 Call Duration 00:00:00.007Status: 0 (VI_SUCCESS)Buffer Contents00000000: 43 31 3A 57 56 44 54 20 57 56 4E 4D 2C 47 6C 69 C1:WVDT WVNM,Gli00000010: 74 63 68 79 2C 54 59 50 45 2C 35 2C 4C 45 4E 47 tchy,TYPE,5,LENG00000020: 54 48 2C 33 32 4B 42 2C 46 52 45 51 2C 32 35 30 TH,32KB,FREQ,25000000030: 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,OFST00000050: 2C 30 2E 30 30 30 30 30 30 30 30 30 2C 50 48 41 ,0.000000000,PHA00000060: 53 45 2C 30 2E 30 30 30 30 30 30 30 30 30 2C 57 SE,0.000000000,W00000070: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 28, 2019, 07:51:29 pm
content: 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).

author: HendriXML
author_rank: Super Contributor
timestamp: April 29, 2019, 11:44:16 am
content: 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 29, 2019, 12:17:16 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 29, 2019, 12:33:07 pm
content: Quote from: joeqsmith on April 29, 2019, 12:17:16 pmHi 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.

author: tautech
author_rank: Super Contributor
timestamp: April 29, 2019, 10:10:01 pm
content: Quote from: HendriXML on April 29, 2019, 12:33:07 pmI 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.

author: HendriXML
author_rank: Super Contributor
timestamp: April 29, 2019, 10:35:47 pm
content: Quote from: tautech on April 29, 2019, 10:10:01 pmNice 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.

author: joeqsmith
author_rank: Super Contributor
timestamp: April 29, 2019, 11:01:39 pm
content: Quote from: HendriXML on April 29, 2019, 12:33:07 pmWow! Say no more.

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 10:16:49 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 10:33:52 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 11:22:33 am
content: With a amplitude of 1V the following values show a glitch when succeding to the next one. Notice the 2663Code:-32301-21373-14817-0389302663135912014731075The 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 11:35:57 am
content: 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:02663-000101001100111-00010100110100013591-011010100010111-01101010001100020147-100111010110011-10011101011010031075-111100101100011-111100101100100

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 11:46:12 am
content: These are the leaps to the next glitch:Code:-3230110928-213736556-1481710924-38936556266310928135916556201471092831075Something repeating can be seen. Which could maybe give us some clue!

author: Rerouter
author_rank: Super Contributor
timestamp: May 01, 2019, 12:15:31 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 12:48:00 pm
content: 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.

author: Rerouter
author_rank: Super Contributor
timestamp: May 01, 2019, 01:05:11 pm
content: 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

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 02:19:13 pm
content: Quote from: Rerouter on May 01, 2019, 01:05:11 pmThe 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 02:24:06 pm
content: 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...

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 02:27:27 pm
content: Just nice to know, how does the AWG's amplitude (6V pk-pk) go above the 5V usb connection? A boost converter?

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 04:53:57 pm
content: Quote from: Rerouter on May 01, 2019, 01:05:11 pmThe 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.Quote from: HendriXML on May 01, 2019, 02:27:27 pmThe 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?

author: Rerouter
author_rank: Super Contributor
timestamp: May 01, 2019, 09:00:45 pm
content: Main sample DAC:http://www.ti.com/jp/lit/ds/symlink/dac904.pdfOffset DAC (I think):http://www.ti.com/lit/ds/symlink/dac8580.pdfOutput Amplifier:https://www.renesas.com/sg/en/www/doc/datasheet/el5166-67.pdfOther Op Amp?http://www.szhuge.com/file/productpdf/945728698337600.pdfThe 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

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 11:04:23 pm
content: 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".

author: HendriXML
author_rank: Super Contributor
timestamp: May 01, 2019, 11:28:50 pm
content: Quote from: Rerouter on May 01, 2019, 09:00:45 pmIn 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 02, 2019, 09:46:10 am
content: 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".

author: tautech
author_rank: Super Contributor
timestamp: May 02, 2019, 09:49:56 am
content: Quote from: HendriXML on May 02, 2019, 09:46:10 amThis:Exceeds the channel voltage offset range as listed in the datasheet, that's all you're seeing.

author: Rerouter
author_rank: Super Contributor
timestamp: May 02, 2019, 10:01:13 am
content: 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 amplifierbefore the ADC is the channel VGA (Variable Gain Amplifier),https://www.analog.com/media/en/technical-documentation/data-sheets/ad8370.pdfyou 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 02, 2019, 10:27:17 am
content: Quote from: tautech on May 02, 2019, 09:49:56 amThere’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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 02, 2019, 10:31:08 am
content: Quote from: Rerouter on May 02, 2019, 10:01:13 amNice info!The practical consequences I will try to measure. As said before, I think it had its influence without me knowing about it.

author: HendriXML
author_rank: Super Contributor
timestamp: May 02, 2019, 11:21:28 am
content: I measured the following waves:Code:C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.60000000000000013,OFST,0.30000000000000006,DUTY,50C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.7,OFST,0.35,DUTY,50C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.8,OFST,0.4,DUTY,50C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1,OFST,0.5,DUTY,50C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.2000000000000002,OFST,0.60000000000000013,DUTY,50C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.3999999999999998,OFST,0.7,DUTY,50C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.6,OFST,0.8,DUTY,50The 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 02, 2019, 11:27:12 am
content: Different duty:Code:Siglent Technologies,SDS1204X-E,SDSMMDBQ2R3764,8.1.6.1.26C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.60000000000000013,OFST,0.30000000000000006,DUTY,1C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.7,OFST,0.35,DUTY,1C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.8,OFST,0.4,DUTY,1C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1,OFST,0.5,DUTY,1C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.2000000000000002,OFST,0.60000000000000013,DUTY,1C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.3999999999999998,OFST,0.7,DUTY,1C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.6,OFST,0.8,DUTY,1

author: HendriXML
author_rank: Super Contributor
timestamp: May 02, 2019, 11:42:10 am
content: 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-screenBut I don’t think with my/this scope one can say that there’re multiple screens of headroom.

author: Rerouter
author_rank: Super Contributor
timestamp: May 02, 2019, 11:48:46 am
content: 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,

author: HendriXML
author_rank: Super Contributor
timestamp: May 02, 2019, 12:05:03 pm
content: Quote from: Rerouter on May 02, 2019, 11:48:46 amTo 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 02, 2019, 01:59:20 pm
content: 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.

author: genghisnico13
author_rank: Regular Contributor
timestamp: May 02, 2019, 03:09:16 pm
content: I recently replicated some of rigol's comparisons about overload recovery in a RTB2000https://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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 02, 2019, 03:52:30 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 02, 2019, 09:50:32 pm
content: 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 mVB: 632mV >= Ampl < 633 mVC: 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 mV1x: 632mV >= Ampl < 633 mV10x: 6.32V >= Ampl < 6.33 VIt 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 12:49:46 am
content: I'm trying to restrict the number of samples via the SCPI command WAVEFORM_SETUP / WFSU in the form:WFSU SP,0,NP,1024if I query WAVEFORM_SETUP? it even returns: SP,0,NP,1024,FP,0But it does not limit the downloaded samples.Am I missing something?

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 10:54:03 am
content: 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)

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 11:54:39 am
content: 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!

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 12:12:38 pm
content: If I setup a wave, with an offset of 0 via SCPI cmd:Code:C1:BSWV WVTP,ARB,FRQ,300,AMP,1.3,OFST,0It'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!!

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 01:53:18 pm
content: 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) / 2Amplitude = High - LowThe valid valid range for aStart would be: MinSampleValue - Offset > 0.95 * 0.5 * AmplitudeHigh 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 * AmplitudeOr a bit more efficient in calculating stuff that does not change per sample.Start would be: MinSampleValue > 0.95 * 0.5 * Amplitude + OffsetHigh 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

author: Rerouter
author_rank: Super Contributor
timestamp: May 03, 2019, 08:09:37 pm
content: 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

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 08:40:56 pm
content: Quote from: Rerouter on May 03, 2019, 08:09:37 pmIf 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 10:13:54 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 10:35:43 pm
content: 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:<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"/>

author: Rerouter
author_rank: Super Contributor
timestamp: May 03, 2019, 10:49:09 pm
content: 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: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 clickskeys:0 - Menu Clear Button1 - Function 1 (left most key on bottom of screen)2 - Function 23 - Function 34 - Function 45 - Function 56 - Function 67 - Timebase (Decrease -1/ 0 Button / Increase 1)10 - Timebase Offset (Decrease -1/ 0 Button / Increase 1)11 - Autosetup Button12 - Run / Stop Button13 - Default Button15 - Intensity (Decrease -1/ 0 Button / Increase 1)16 - Trigger Level (Decrease -1/ 0 Button / Increase 1)17 - Auto Trigger Button18 - Trigger Button19 - Normal Trigger Button20 - Single Trigger Button22 - Cursors Button23 - Display / Persist button24 - Utility Button25 - Print Button26 - Measure Button27 - Aqcuire Button28 - Save/Recall Button29 - Decode Button30 - Digital Button31 - Math Button32 - Reference Button35 - 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 Button40 - Channel 2 Button41 - Channel 3 Button42 - Channel 4 Button43 - 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 Button48 - History Button49 - Roll Button50 - Search Button51 - Navigate Button52 - Left Navigation Button53 - Stop Navigate Button54 - Right Navigate Button

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 11:27:46 pm
content: Quote from: Rerouter on May 03, 2019, 10:49:09 pmThat’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.

author: Rerouter
author_rank: Super Contributor
timestamp: May 03, 2019, 11:36:16 pm
content: I can share what I have documented, but its mainly lifted from other manualsCode::WaveForm | :WFQuery Syntax<channel>:WaveForm?DescriptionA 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) blockThe 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.ParameterNameTypeRangeDefault<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 ExampleC1:WF? /*Returns the waveform data block of Channel 1*/Code:WaveForm_SetUp | WFSUCommand SyntaxWaveForm_SetUp FP, <first point>,NP,<num of points>,SP,<spacing>Query SyntaxWaveForm_SetUp?DescriptionThe 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.ParameterNameTypeRangeDefault<first point>NumericFirst Data Point<num of points>Numeric0 is all, above is maximum amount of points<spacing>Numeric0:1 is all, above sends only Nth pointCommand ExampleWFSU FP,200 /* Sets the first point to 200.*/Query ExampleWFSU? /* */

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 11:40:02 pm
content: Quote from: Rerouter on May 03, 2019, 10:49:09 pmThanks 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).PSI did test the BSWV? before, but there was no offset in it.

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 11:45:47 pm
content: Quote from: Rerouter on May 03, 2019, 11:36:16 pmI’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...

author: Rerouter
author_rank: Super Contributor
timestamp: May 03, 2019, 11:47:09 pm
content: There are also 3 related commands if you wish to navigate frames.FPAR Frame_PARamFRAM FRAMe_setFTIM Frame_TIMeset 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)

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 11:50:58 pm
content: Quote from: Rerouter on May 03, 2019, 11:47:09 pmThat 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 03, 2019, 11:58:01 pm
content: Quote from: Rerouter on May 03, 2019, 11:47:09 pmI 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.

author: Rerouter
author_rank: Super Contributor
timestamp: May 04, 2019, 12:03:42 am
content: these help?

author: HendriXML
author_rank: Super Contributor
timestamp: May 04, 2019, 12:06:47 am
content: Quote from: Rerouter on May 04, 2019, 12:03:42 amIf that’s not an offset on top of the zero adjustment offset, then it response depends on the route to this query.

author: Rerouter
author_rank: Super Contributor
timestamp: May 04, 2019, 12:11:43 am
content: 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,

author: HendriXML
author_rank: Super Contributor
timestamp: May 04, 2019, 12:21:57 am
content: Quote from: Rerouter on May 04, 2019, 12:11:43 amSo 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.

author: Rerouter
author_rank: Super Contributor
timestamp: May 04, 2019, 12:32:01 am
content: 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

author: HendriXML
author_rank: Super Contributor
timestamp: May 04, 2019, 12:45:56 am
content: 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...

author: Rerouter
author_rank: Super Contributor
timestamp: May 04, 2019, 01:15:04 am
content: "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

author: HendriXML
author_rank: Super Contributor
timestamp: May 04, 2019, 01:37:52 am
content: Quote from: Rerouter on May 04, 2019, 01:15:04 amFor another device I followed this guide:Support restart/shutdown through OctoPrint's system menuIn Settings > Commands, configure the following commands:Restart OctoPrint: sudo service octoprint restartRestart system: sudo shutdown -r nowShutdown system: sudo shutdown -h nowNoteIf 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

author: Rerouter
author_rank: Super Contributor
timestamp: May 04, 2019, 01:41:06 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 04, 2019, 08:54:40 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 04, 2019, 09:17:40 pm
content: It is still running but as can seen below it is very repetitive (Next glitch dist is 3384 or 2028).Code:InputValueDiff (V)Dif (mV)Next glitch dist-31645-0,0012-1,233384-28261-0,0011-1,152028-26233-0,0016-1,573384-22849-0,0013-1,342028-20821-0,0014-1,383384-17437-0,0011-1,112028-15409-0,0012-1,223384-12025-0,0013-1,252028-9997-0,0013-1,263384-6613-0,0012-1,222028-4585-0,0013-1,353384-1201-0,0013-1,342028827-0,0020-1,9933844211-0,0009-0,9220286239-0,0014-1,41The 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?)

author: HendriXML
author_rank: Super Contributor
timestamp: May 04, 2019, 10:14:19 pm
content: The more accurate values, where the relais clicks to switch to a different AWG ampl. attenuation are:Code:00.6324243787810.063242837Almost a factor 10...

author: HendriXML
author_rank: Super Contributor
timestamp: May 04, 2019, 10:41:23 pm
content: 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!

author: HendriXML
author_rank: Super Contributor
timestamp: May 04, 2019, 11:55:41 pm
content: It's glitching at the same input values... (these are almost the full lists, the same stuff continues )3000mVppCode:InputValueDiff (V)Dif (mV)Next glitch dist-31645-0,0012-1,233384-28261-0,0011-1,152028-26233-0,0016-1,573384-22849-0,0013-1,342028-20821-0,0014-1,383384-17437-0,0011-1,112028-15409-0,0012-1,223384-12025-0,0013-1,252028-9997-0,0013-1,263384-6613-0,0012-1,222028-4585-0,0013-1,353384-1201-0,0013-1,342028827-0,0020-1,9933844211-0,0009-0,9220286239-0,0014-1,41632.424378781 mVppCode:InputValueDifferenceNext glitch dist-31645-0,000153384-28261-0,000142028-26233-0,000173384-22849-0,000132028-20821-0,000173384-17437-0,000132028-15409-0,000183384-12025-0,000132028-9997-0,000163384-6613-0,000142028-4585-0,000173384-1201-0,000162028827-0,0002733844211-0,0001220286239-0,0001733849623-0,00016202811651-0,00016338415035-0,00013202817063-0,00017

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 12:07:40 am
content: 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:827=1100111011828=11001111004211=10000011100114212=1000001110100It 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 09:43:42 am
content: Binary conversion of the transition valuesCode:-31645/-3164410000100011000111000010001100100-28261/-2826010010001100110111001000110011100-26233/-2623210011001100001111001100110001000-22849/-2284810100110101111111010011011000000-20821/-2082010101110101010111010111010101100-17437/-1743610111011111000111011101111100100-15409/-1540811000011110011111100001111010000-12025/-1202411010001000001111101000100001000-9997/-999611011000111100111101100011110100-6613/-661211100110001010111110011000101100-4585/-458411101110000101111110111000011000-1201/-120011111011010011111111101101010000827/828000000110011101100000011001111004211/4212000100000111001100010000011101006239/6240000110000101111100011000011000009623/96240010010110010111001001011001100011651/116520010110110000011001011011000010015035/150360011101010111011001110101011110017063/170640100001010100111010000101010100020447/204480100111111011111010011111110000022475/224760101011111001011010101111100110025859/258600110010100000011011001010000010027887/278880110110011101111011011001111000031271/3127201111010001001110111101000101000

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 10:11:32 am
content: 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: 43mVWhat 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 10:57:07 am
content: Quote from: HendriXML on May 05, 2019, 09:43:42 amJust 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?

author: Rerouter
author_rank: Super Contributor
timestamp: May 05, 2019, 11:15:52 am
content: 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 downEqually if you had a USB analyser, the 4 pin header directly next to the USB port is all the USB pins

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 11:46:07 am
content: Quote from: Rerouter on May 05, 2019, 11:15:52 amI 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

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 11:51:33 am
content: 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?

author: Rerouter
author_rank: Super Contributor
timestamp: May 05, 2019, 11:55:43 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 12:06:24 pm
content: 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..

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 12:10:59 pm
content: Code:InputValueSumOutputValueSucceedingOutputValueDifferenceValueDiff-31645-320143-1,26E+00-1,26E+00-1,13E-033384-28261-532581-1,12E+00-1,12E+00-1,25E-032028-26233-442748-1,04E+00-1,04E+00-1,33E-033384-22849313497-9,01E-01-9,02E-01-1,14E-032028-20821388458-8,18E-01-8,20E-01-1,46E-033384-17437171607-6,79E-01-6,80E-01-1,20E-032028-15409224395-5,96E-01-5,97E-01-1,43E-033384-1202528208-4,57E-01-4,58E-01-1,20E-032028-999765218-3,75E-01-3,76E-01-1,10E-03More 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).

author: Rerouter
author_rank: Super Contributor
timestamp: May 05, 2019, 12:14:35 pm
content: If you have the bin file, likley going to be much easier to just load via USB

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 12:43:17 pm
content: Quote from: Rerouter on May 05, 2019, 12:14:35 pmIs not a doc, but a bin fileThe wave contains two values: 50% 827 and then 50% 828(it took some while, had to create and test one)

author: Rerouter
author_rank: Super Contributor
timestamp: May 05, 2019, 01:39:59 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 02:47:19 pm
content: 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 mVAt 1.99991 the average value is 52.1 mVThe very small positive change in amplitude gives a glitch and a drop of 29.2 mVI 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.

author: tinhead
author_rank: Super Contributor
timestamp: May 05, 2019, 05:12:51 pm
content: Quote from: HendriXML on May 05, 2019, 11:46:07 ami think this is the major problem, you device is bit wired from beginning, you should replace it and continue AWG work after that

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 05:40:21 pm
content: So at 1.99990V the other know glitch values come to live.These are only 8 valuesCode:-32301142770-1,67E-0310928-21373173773-1,35E-036556-14817269850-1,63E-0310924-3893200975-1,56E-0365562663-476178-2,69E-031092813591246249-1,28E-03655620147-407143-1,75E-031092831075245817-1,51E-03Bits and stuffCode:-32301/-3230010000001110100111000000111010100-21373/-2137210101100100000111010110010000100-14817/-1481611000110000111111100011000100000-3893/-3892111100001100101111110000110011002663/26640000101001100111000010100110100013591/135920011010100010111001101010001100020147/201480100111010110011010011101011010031075/3107601111001011000110111100101100100

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 05:54:15 pm
content: Quote from: tinhead on May 05, 2019, 05:12:51 pmI 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 05, 2019, 06:06:11 pm
content: The distance between glitches are at 1.9 compared to 2.0 are more wide (3.23x) and thus there less.6556/2028=3,23274161735710928/3384=3,22931442080378This 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* ScalingHere'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: VGARelay - analog scaling0.06V..0.6V: VGARelay - analog scaling0.6V..2V: VGADigital scaling (3.2x?)2V..6V: VGAIf someone can improve this, please do so. It's very possible that the low ranges are also subdivided, but I've not tested it.

author: HendriXML
author_rank: Super Contributor
timestamp: May 06, 2019, 11:06:25 am
content: 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 timeWhat 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 06, 2019, 12:29:25 pm
content: 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.

author: tinhead
author_rank: Super Contributor
timestamp: May 06, 2019, 01:16:23 pm
content: Quote from: HendriXML on May 06, 2019, 11:06:25 amas i do have SAG as well, send me all i need, so i can run it on my hardware

author: HendriXML
author_rank: Super Contributor
timestamp: May 06, 2019, 08:27:24 pm
content: Quote from: tinhead on May 06, 2019, 01:16:23 pmI 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/winAfter installing git, open a command line prompt and use a location of choice when executing the following:git clone --recurse-submoduleshttps://github.com/HendriXML/XMLScripts-Project-AWGStepTesting.gitC:\AWGStepTestingThis 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 usehttps://github.com/HendriXML/XMLScripts-Project-AWGStepTesting/issuesin 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.)

author: HendriXML
author_rank: Super Contributor
timestamp: May 07, 2019, 10:06:17 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 07, 2019, 12:57:33 pm
content: Quote from: Rerouter on May 03, 2019, 10:49:09 pmStill have no luck limiting the number of points. This is the response usingWAVEFORM_SETUP SP,0,NP,1000,FP,0C1:WAVEFORM? ALLEach time I get a different but repeating output value.Code:14089. viRead (TCPIP0::scope::inst0::INSTR (0x05981DB8), "ALL,#9000140346WAVEDE...", 1024000, 1363)Process ID: 0x000011F0 Thread ID: 0x00001110Start Time: 14:51:03.407 Call Duration 00:00:00.001Status: 0 (VI_SUCCESS)Buffer Contents00000000: 41 4C 4C 2C 23 39 30 30 30 31 34 30 33 34 36 57 ALL,#9000140346W00000010: 41 56 45 44 45 53 43 00 5A 1D 36 00 97 CB 00 57 AVEDESC.Z.6....W00000020: 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 ...........Sigle00000060: 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.%....t00000110: 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 ................

author: HendriXML
author_rank: Super Contributor
timestamp: May 10, 2019, 02:55:21 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 10, 2019, 05:35:07 pm
content: Quote from: HendriXML on May 06, 2019, 08:27:24 pmA 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/

author: HendriXML
author_rank: Super Contributor
timestamp: May 10, 2019, 08:54:09 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 10, 2019, 09:00:50 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 10, 2019, 09:27:54 pm
content: 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:Description: Global VISA COM I/O Resource ManagerSiglent 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

author: HendriXML
author_rank: Super Contributor
timestamp: May 11, 2019, 11:10:00 am
content: 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 offset3.0 V amplitude: 30,6mV offset (during measurement)6.0 V amplitude: 49.7mV offsetWith less then 2.0 V it jumps to a different range:1.9 V amplitude: 54.7mV offset0.7 V amplitude: 31.2mV offsetOff 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 amplitudeI 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 11, 2019, 02:15:47 pm
content: 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:DistCount6767135232 x 676202883 x 676270844 x 676 = 2704338485 x 676 = 3380I 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/1024I'll have to check if using that and the offset of 828 get "special bit" arrangements.

author: HendriXML
author_rank: Super Contributor
timestamp: May 11, 2019, 03:40:51 pm
content: When I substract 828 of the glitch values and multiply them by 676 these are the binary values:Code:01011000100001101100111110101100010000110110100000011001100111111000110111101100110011111100011100000110100111111010101111111011010011111101011000000001110100011100000101011110111010001110000010110000100001011110010001000111110000101111001000100100001001000001011001110111111100100000101100111100000010100001110011011100111111010000111001101110100000101011000100001101100111110101100010000110110100001011110110110111010101111101111011011011101011000011000100101100000110011111100010010110000011010000110010000010110011101111111001000001011001111000001101011000100100010101111110101100010010001011000011011001101000001101111111101100110100000111000000111001000001011001110111111100100000101100111100001110011110010010111111111111001111001001100000000011110101100010100110011111111010110001010011010000111110010000011011101111111111001000001101111000001111111111111111111111111000000000000000000000000000010001011100111110111110001000101110011111100000000110111110100110000111100011011111010011000100000010110101011101011101111001011010101110101111000000110000110110011111111110011000011011010000000000001101111101001100001111100110111110100110001000000100010111001010011101111010001011100101001111000001001001010001101111111110100100101000111000000000010100111011110010010111101010011101111001001100000110010100110000100001111011001010011000010001000001101111101001100001111110110111110100110001000000100000010001101000001111110000001000110100001000001000101110001111101001111100010111000111110101000010011101000000111001011111001110100000011100110000All 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 11, 2019, 05:19:34 pm
content: I think this is becoming more meaningful. A lot of the higher bits are about to overflow, or have overflowed.Code:Offset: 828Factor: 512Divider: 67611111111110011111111011011111111111001111111101110111111111101001111111000011111111110100111111100011111111111010100111110000111111111101010011111000111111111110101111111100001111111111010111111110001111111111101110011111010011111111110111001111101011111111111011111111110100111111111101111111111010111111111111001001111101111111111111100100111111000111111111110011111111011111111111111001111111110001111111111101100111111010111111111110110011111101111111111111011101111110101111111111101110111111011111111111110111111111101011111111111011111111110111111111111110011111111101111111111111001111111111011111111111101001111111011111111111110100111111110111111111111011111111110111111111111101111111111101111111111111000111111101111111111111100011111111011111111111111010000000001111111111111101000000001111111111111111000000000011111111111111100000000011111111111111111111111111000000000000000000000000000000000000001010000000100000000000000101000000011000000000000100000000001000000000000010000000000110000000000001101000000101000000000000110100000011000000000000011100000001010000000000001110000000110000000000001000000000010100000000000100000000001100000000000010100000001000000000000001010000000100100000000000101010000010000000000000010101000001001000000000001100000000100000000000000110000000010010000000000011101000001011000000000001110100000110000000000001000000000010110000000000100000000001100000000000010010100000111000000000001001010000011110000000000101000000001110000000000010100000000111100000000001011010000100010000000000101101000010010

author: HendriXML
author_rank: Super Contributor
timestamp: May 11, 2019, 11:25:53 pm
content: 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:Offset: 832, Factor: 12213, Divider: 1075711111111111011011111111101111111111101101111111111011111111111011110111111111111111111101111100000000811111111111011111101111111111111111101111111000000611111111111100001111111111111111111110001000000000911111111111100101101111111111111111110010111000000611111111111100111111111111111111111110100000000000111111111111110101110111111111111111111010111100000061111111111110110111111111111111111111011100000000091111111111111000110111111111111111111100011100000061111111111111001100111111111111111111100110100000061111111111111001111111111111111111111101000000000010111111111111101110000000011111111111110111000000010111111111111101111011111111111111111110111110000006111111111111110011111111111111111111111010000000009111111111111110101011111111111111111111010110000006111111111111111011100000011111111111111101110000010111111111111111100111111111111111111111110100000007111111111111111111111111100000000000000000000000003200000000000000011101111110000000000000001111000000600000000000000101111111100000000000000010111111111000000000000001001101111110000000000000100111000000600000000000001010011111110000000000000101010000000700000000000001011111111110000000000000110000000000100000000000000111011111111000000000000011110000000080000000000000111110111111000000000000011111100000060000000000001000111111111000000000000100100000000090000000000001010110111111000000000000101011100000060000000000001011111111111000000000000110000000000011000000000000110111011111100000000000011011110000006000000000000111011111111100000000000011110000000009000000000001000011011111100000000000100001110000006\

author: HendriXML
author_rank: Super Contributor
timestamp: May 12, 2019, 12:07:35 pm
content: 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:Offset: 831, Factor: 1065, Divider: 1407ValueNext valueBit cntSignificant bit10011111111111101000000000001112101001111111111010100000000091010101001111111101010100000007810101111111111101100000000001011101101100000001011011000000108101110011111111011101000000078101111111111111100000000000012131100101000000011001010000001081100111111111111010000000000101111010110000000110101100000010811011010000000110110100000010811011110000000110111100000010811011111111111111000000000001112111010000000001110100000000101011101010000000111010100000010811110000000000111100000000010111111001000000011110010000001081111011000000011110110000001081111101000000011111010000001081111110000000011111100000001091111111111111100000000000000151600001001111111000010100000007800001111111111000100000000001011000110011111110001101000000078000110111111110001110000000089000111111111110010000000000011120010011111111100101000000000910001010011111110010101000000078001011111111110011000000000010110011011000000000110110000001080011100111111100111010000000780011111111111101000000000000121301000110000000010001100000010801001010000000010010100000010801001111111111010100000000001011010101100000000101011000000108010110100000000101101000000108

author: HendriXML
author_rank: Super Contributor
timestamp: May 12, 2019, 05:42:28 pm
content: This is the very best match I can generate.Code:Offset: 836, Factor: 246, Divider: 325111001111111111111101000000000001112111010011111111111101010000000009101110101001111111111010101000000078111010111111111111101100000000001011111011010111111111101101100000007811101110011111111110111010000000781110111111111111111100000000000012131111001001111111111100101000000078111100111111111111110100000000001011111101010111111111110101100000007811110110011111111111011010000000781111011101111111111101111000000078111101111111111111111000000000001112111110011111111111111010000000009101111101001111111111110101000000078111110111111111111111100000000001011111111000111111111111100100000007811111101100000001111110110000001081111111010000000111111101000000108111111101111111111111111000000008911111111111111110000000000000000151600000010011111110000001010000000780000001111111110000000111111111101100000110011111110000011010000000780000011011111111000001110000000089000001111111111100001000000000001112000010011111111100001010000000009100000101001111111000010101000000078000010111111111100001100000000001011000011010111111100001101100000007800001110011111110000111010000000780000111111111111000100000000000012130001000101111111000100011000000078000100100111111100010010100000007800010011111111110001010000000000101100010101011111110001010110000000780001011001111111000101101000000078The 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

author: genghisnico13
author_rank: Regular Contributor
timestamp: May 12, 2019, 06:32:18 pm
content: Could be something as simple as not enough decoupling in the DAC when several bits change simultaneously?

author: HendriXML
author_rank: Super Contributor
timestamp: May 12, 2019, 07:09:56 pm
content: Quote from: genghisnico13 on May 12, 2019, 06:32:18 pmThe 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.

author: tautech
author_rank: Super Contributor
timestamp: May 13, 2019, 02:09:48 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 13, 2019, 12:32:25 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 13, 2019, 12:45:31 pm
content: Quote from: tautech on May 13, 2019, 02:09:48 amAt 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.

author: Rerouter
author_rank: Super Contributor
timestamp: May 13, 2019, 12:49:02 pm
content: 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?

author: HendriXML
author_rank: Super Contributor
timestamp: May 13, 2019, 12:53:16 pm
content: Quote from: Rerouter on May 13, 2019, 12:49:02 pmOnly 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 13, 2019, 03:40:12 pm
content: 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

author: HendriXML
author_rank: Super Contributor
timestamp: May 15, 2019, 08:45:56 am
content: I did a full test of the other unit (device B) I received.Here's the step size comparison between them.

author: HendriXML
author_rank: Super Contributor
timestamp: May 15, 2019, 08:52:44 am
content: 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.

author: tautech
author_rank: Super Contributor
timestamp: May 15, 2019, 08:54:04 am
content: Quote from: HendriXML on May 15, 2019, 08:45:56 amAnd you checked they are running the same firmware ?

author: HendriXML
author_rank: Super Contributor
timestamp: May 15, 2019, 09:19:21 am
content: 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).

author: HendriXML
author_rank: Super Contributor
timestamp: May 15, 2019, 09:54:25 am
content: 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:Offset: 316, Factor: 249, Divider: 329-321571001110000000110011100000001109-314811001111000000110011110000001108-3080510100000000001101000000000011012-301291010001000000010100010000000078-294491010010000000110100100000001109-287731010011000000110100110000001108-2809710101000000001101010000000011010-274211010101000000110101010000001108-267451010110000000110101100000001109-260691010111000000110101110000001108-2539310110000000001101100000000011011-247171011001000000010110010000000078-233611011011000000110110110000001108-2268510111000000001101110000000011010-220091011101000000110111010000001108-213331011110000000110111100000001109-206571011111000000110111110000001108-1998111000000000001110000000000011013-193051100001000000011000010000000078-186251100010000000111000100000001109-179491100011000000111000110000001108-1727311001000000001110010000000011010-167651100100110000111001001100001106-165971100101000000111001010000001108-159211100110000000111001100000001109-152451100111000000111001110000001108-147371100111110000111001111100001106-1456911010000000001110100000000011011-138931101001000000011010010000000078-125371101011000000111010110000001108-1186111011000000001110110000000011010-116931101100010000111011000100001106-111851101101000000111011010000001108-106771101101110000111011011100001106-105091101110000000111011100000001109-915711100000000001111000000000011012-84811110001000000011100010000000078-78011110010000000111100100000001109-71251110011000000111100110000001108-57731110101000000111101010000001108-50971110110000000111101100000001109-44211110111000000111101110000001108-42491110111010000111101110100001106-374511110000000001111100000000011011-23891111010000000111110100000001109-17131111011000000111110110000001108-103711111000000001111110000000011010-361111110100000011111101000000110848311111100011111111111001000005569911111110111111111111110000000778166711111111111111000000000000001414152343000000011111110000001000000077830230000001111111100000100000000889437500000111111111000010000000009910505100001001111111000010100000007785727000010111111110000110000000088964030000110111111100001110000000778707900001111111111000100000000001010117755000100011111110001001000000077886030001010001111100010100100000556911100010101111111000101100000007789787000101111111110001100000000099101046300011001111111000110100000007781113900011011111111000111000000008891181500011101111111000111100000007781198700011110011111000111101000005561249100011111111111001000000000001111121299900100001011111001000011000005561316700100001111111001000100000007781519900100111111111001010000000009910158750010100111111100101010000000778165510010101111111100101100000000889167190010110001111100101100100000556172270010110111111100101110000000778179030010111111111100110000000000101011185790011000111111100110010000000778199350011010111111100110110000000778206110011011111111100111000000000991021963001110111111110011110000000088922131001111000111110011110010000055622639001111011111110011111000000077823315001111111111110100000000000012121323991010000011111110100001000000077825347010001011111110100011000000077826023010001111111110100100000000099102669901001001111111010010100000007782720701001011011111010010111000005562737501001011111111010011000000008892788301001101011111010011011000005562805101001101111111010011100000007782872701001111111111010100000000001010112940301010001111111010100100000007782957501010010011111010100101000005562991101010011011111010100111000005563008301010011111111010101000000008893025101010100011111010101001000005563075901010101111111010101100000007783092701010110011111010101101000005563126701010111011111010101111000005563143501010111111111010110000000009910319430101100101111101011001100000556321110101100111111101011010000000778326190101101101111101011011100000556At 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 15, 2019, 11:26:51 am
content: 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.

author: Rerouter
author_rank: Super Contributor
timestamp: May 15, 2019, 12:13:57 pm
content: 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 replacementhttps://au.mouser.com/datasheet/2/609/AD9744-878112.pdfhttp://www.ti.com/lit/ds/symlink/dac904.pdf

author: HendriXML
author_rank: Super Contributor
timestamp: May 15, 2019, 12:49:43 pm
content: 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").

author: HendriXML
author_rank: Super Contributor
timestamp: May 15, 2019, 01:03:43 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 16, 2019, 10:30:04 am
content: 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 mV0,02%1,5,9,13..0,75 mV0,02%2,6,10,12,14-0,40 mV-0,01%3,7,11,12,153685,83 mV100,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 < 0The 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:Offset: 316, Factor: 249, Divider: 329-321571001101111111110011011111111809-314811001110111111110011101111111708-30805100111111111111001111111111111012-301291010000111111010100001111110018-294491010001111111110100011111111809-287731010010111111110100101111111708-2809710100111111111101001111111119010-274211010100111111110101001111111708-267451010101111111110101011111111809-260691010110111111110101101111111708-25393101011111111111010111111111110011-247171011000111111010110001111110018-233611011010111111110110101111111708-2268510110111111111101101111111119010-220091011100111111110111001111111708-213331011101111111110111011111111809-206571011110111111110111101111111708-19981101111111111111011111111111112013-193051100000111111011000001111110018-186251100001111111111000011111111809-179491100010111111111000101111111708-1727311000111111111110001111111119010-167651100100101111111001001011111506-165971100100111111111001001111111708-159211100101111111111001011111111809-152451100110111111111001101111111708-147371100111101111111001111011111506-14569110011111111111100111111111110011-138931101000111111011010001111110018-125371101010111111111010101111111708-1186111010111111111110101111111119010-116931101100001111111011000011111506-111851101100111111111011001111111708-106771101101101111111011011011111506-105091101101111111111011011111111809-9157110111111111111101111111111111012-84811110000111111011100001111110018-78011110001111111111100011111111809-71251110010111111111100101111111708-57731110100111111111101001111111708-50971110101111111111101011111111809-44211110110111111111101101111111708-42491110111001111111101110011111506-3745111011111111111110111111111110011-23891111001111111111110011111111809-17131111010111111111110101111111708-103711110111111111111101111111119010-361111110011111111111100111111170848311111100011111111111001000005569911111110111111111111110000000778166711111111111111000000000000001414152343000000011111110000001000000077830230000001111111100000100000000889437500000111111111000010000000009910505100001001111111000010100000007785727000010111111110000110000000088964030000110111111100001110000000778707900001111111111000100000000001010117755000100011111110001001000000077886030001010001111100010100100000556911100010101111111000101100000007789787000101111111110001100000000099101046300011001111111000110100000007781113900011011111111000111000000008891181500011101111111000111100000007781198700011110011111000111101000005561249100011111111111001000000000001111121299900100001011111001000011000005561316700100001111111001000100000007781519900100111111111001010000000009910158750010100111111100101010000000778165510010101111111100101100000000889167190010110001111100101100100000556172270010110111111100101110000000778179030010111111111100110000000000101011185790011000111111100110010000000778199350011010111111100110110000000778206110011011111111100111000000000991021963001110111111110011110000000088922131001111000111110011110010000055622639001111011111110011111000000077823315001111111111110100000000000012121323991010000011111110100001000000077825347010001011111110100011000000077826023010001111111110100100000000099102669901001001111111010010100000007782720701001011011111010010111000005562737501001011111111010011000000008892788301001101011111010011011000005562805101001101111111010011100000007782872701001111111111010100000000001010112940301010001111111010100100000007782957501010010011111010100101000005562991101010011011111010100111000005563008301010011111111010101000000008893025101010100011111010101001000005563075901010101111111010101100000007783092701010110011111010101101000005563126701010111011111010101111000005563143501010111111111010110000000009910319430101100101111101011001100000556321110101100111111101011010000000778326190101101101111101011011100000556

author: Rerouter
author_rank: Super Contributor
timestamp: May 16, 2019, 10:45:37 am
content: 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.00011011Any 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?

author: tautech
author_rank: Super Contributor
timestamp: May 16, 2019, 11:08:09 am
content: Possibly, I'll point them to this again.

author: HendriXML
author_rank: Super Contributor
timestamp: May 16, 2019, 02:23:39 pm
content: Quote from: Rerouter on May 16, 2019, 10:45:37 amWith 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:if (Value >= 0) = (Divider >= 0) thenResult:= (Value + Divider div 2) div DividerelseResult:= (Value - Divider div 2) div Divider

author: HendriXML
author_rank: Super Contributor
timestamp: May 16, 2019, 06:07:40 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 16, 2019, 06:21:07 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 18, 2019, 12:42:10 am
content: Quote from: HendriXML on May 16, 2019, 02:23:39 pmI think the problem has its origin in that there's some code like thisCode:Result:= Value div Dividerif (Value mod Divider) >= (Divider div 2) thenResult:= Result + 1Forgetting 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 18, 2019, 09:45:38 am
content: Quote from: HendriXML on May 18, 2019, 12:42:10 amMaybe 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 20, 2019, 12:19:25 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 20, 2019, 12:26:34 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 20, 2019, 12:54:14 pm
content: 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:-696 -> -696relay click-695 -> -704704 -> 701relay click705 -> 704Device B (mV)Code:-700 -> -698relay click-699 -> -700699 -> 699relay click700 -> 702So 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 20, 2019, 01:34:18 pm
content: 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 bandwidthIn 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.

author: Rerouter
author_rank: Super Contributor
timestamp: May 20, 2019, 02:24:59 pm
content: 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.pdfUnderneath 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.pdfIf 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 waveformsMy 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 20, 2019, 06:38:10 pm
content: 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 jobWould be nice if there was some kind of calibration process that users could run to optimize things a lot more.

author: HendriXML
author_rank: Super Contributor
timestamp: May 21, 2019, 03:38:00 pm
content: 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!

author: HendriXML
author_rank: Super Contributor
timestamp: May 21, 2019, 09:27:30 pm
content: 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 valuesHaving the 2 outputs in series might also give some extra possibilities to have more continuous values.

author: tautech
author_rank: Super Contributor
timestamp: May 23, 2019, 07:24:56 pm
content: 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

author: HendriXML
author_rank: Super Contributor
timestamp: May 23, 2019, 07:37:49 pm
content: Quote from: tautech on May 23, 2019, 07:24:56 pmAlways 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.

author: tautech
author_rank: Super Contributor
timestamp: May 23, 2019, 07:39:47 pm
content: Note, there is an updated programming guide too.

author: HendriXML
author_rank: Super Contributor
timestamp: May 23, 2019, 07:48:06 pm
content: Quote from: tautech on May 23, 2019, 07:39:47 pmYeh, 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!

author: HendriXML
author_rank: Super Contributor
timestamp: May 27, 2019, 08:52:14 pm
content: Quote from: HendriXML on May 23, 2019, 07:37:49 pm* 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 limitIt seems this problem is solved

author: HendriXML
author_rank: Super Contributor
timestamp: May 28, 2019, 12:53:41 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 28, 2019, 09:37:25 pm
content: 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:Coarse 0Voltage OUT:0,00 MM: mV: -500,00 mV SET: 0,00 mVVoltage OUT:1000,00 MM: mV: 500,00 mV SET: 1001,59 mVCoarse 1Voltage OUT:200,00 MM: mV: -300,00 mV SET: 200,30 mVVoltage OUT:400,00 MM: mV: -100,00 mV SET: 399,80 mVVoltage OUT:600,00 MM: mV: 100,00 mV SET: 600,10 mVVoltage OUT:800,00 MM: mV: 300,00 mV SET: 800,30 mVCoarse 2Voltage OUT:40,00 MM: mV: -460,00 mV SET: 40,30 mVVoltage OUT:80,00 MM: mV: -420,00 mV SET: 80,40 mVVoltage OUT:120,00 MM: mV: -380,00 mV SET: 119,90 mVVoltage OUT:160,00 MM: mV: -340,00 mV SET: 159,80 mVVoltage OUT:240,00 MM: mV: -260,00 mV SET: 240,60 mVVoltage OUT:280,00 MM: mV: -220,00 mV SET: 280,70 mVVoltage OUT:320,00 MM: mV: -180,00 mV SET: 320,40 mVVoltage OUT:360,00 MM: mV: -140,00 mV SET: 360,10 mVVoltage OUT:440,00 MM: mV: -60,00 mV SET: 439,90 mVVoltage OUT:480,00 MM: mV: -20,00 mV SET: 479,90 mVVoltage OUT:520,00 MM: mV: 20,00 mV SET: 520,00 mVVoltage OUT:560,00 MM: mV: 60,00 mV SET: 560,10 mVVoltage OUT:640,00 MM: mV: 140,00 mV SET: 640,40 mVVoltage OUT:680,00 MM: mV: 180,00 mV SET: 680,40 mVVoltage OUT:720,00 MM: mV: 220,00 mV SET: 719,00 mVVoltage OUT:760,00 MM: mV: 260,00 mV SET: 760,00 mVVoltage OUT:840,00 MM: mV: 340,00 mV SET: 840,20 mVVoltage OUT:880,00 MM: mV: 380,00 mV SET: 880,60 mVVoltage OUT:920,00 MM: mV: 420,00 mV SET: 920,90 mVVoltage OUT:960,00 MM: mV: 460,00 mV SET: 961,00 mVAs 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 29, 2019, 12:02:59 am
content: 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?)

author: HendriXML
author_rank: Super Contributor
timestamp: May 29, 2019, 01:12:55 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: May 30, 2019, 09:51:15 pm
content: 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 loadSo 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:Voltage OUT:0,0 mV; MM: 0,0 mV; SET: -0,3 mVVoltage OUT:40,0 mV; MM: 40,1 mV; SET: 40,4 mVVoltage OUT:80,0 mV; MM: 80,0 mV; SET: 79,9 mVVoltage OUT:120,0 mV; MM: 120,0 mV; SET: 120,5 mVVoltage OUT:160,0 mV; MM: 160,0 mV; SET: 160,4 mVVoltage OUT:200,0 mV; MM: 200,0 mV; SET: 199,8 mVVoltage OUT:240,0 mV; MM: 240,0 mV; SET: 239,7 mVVoltage OUT:280,0 mV; MM: 280,0 mV; SET: 280,0 mVVoltage OUT:320,0 mV; MM: 320,0 mV; SET: 320,2 mVVoltage OUT:360,0 mV; MM: 360,0 mV; SET: 360,4 mVVoltage OUT:400,0 mV; MM: 400,0 mV; SET: 400,5 mVVoltage OUT:440,0 mV; MM: 440,0 mV; SET: 440,8 mVVoltage OUT:480,0 mV; MM: 480,0 mV; SET: 481,0 mVVoltage OUT:520,0 mV; MM: 520,0 mV; SET: 521,3 mVVoltage OUT:560,0 mV; MM: 560,0 mV; SET: 561,9 mVVoltage OUT:600,0 mV; MM: 600,0 mV; SET: 602,1 mVVoltage OUT:640,0 mV; MM: 640,0 mV; SET: 641,9 mVVoltage OUT:680,0 mV; MM: 40,0 mV; SET: 681,8 mVVoltage OUT:720,0 mV; MM: 80,0 mV; SET: 722,3 mVVoltage OUT:760,0 mV; MM: 120,0 mV; SET: 761,9 mVVoltage OUT:800,0 mV; MM: 160,0 mV; SET: 801,8 mVVoltage OUT:840,0 mV; MM: 200,0 mV; SET: 842,1 mVVoltage OUT:880,0 mV; MM: 240,0 mV; SET: 881,7 mVVoltage OUT:920,0 mV; MM: 280,0 mV; SET: 921,4 mVVoltage OUT:960,0 mV; MM: 320,0 mV; SET: 961,4 mVVoltage OUT:1000,0 mV; MM: 360,5 mV; SET: 1002,3 mV

author: HendriXML
author_rank: Super Contributor
timestamp: June 02, 2019, 06:40:34 am
content: 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:Voltage OUT:0,0 mV; DSO: 0,0 mVVoltage OUT:40,0 mV; DSO: 40,2 mVVoltage OUT:80,0 mV; DSO: 80,1 mVVoltage OUT:120,0 mV; DSO: 120,2 mVVoltage OUT:160,0 mV; DSO: 160,2 mVVoltage OUT:200,0 mV; DSO: 200,3 mVVoltage OUT:240,0 mV; DSO: 240,4 mVVoltage OUT:280,0 mV; DSO: 280,4 mVVoltage OUT:320,0 mV; DSO: 320,5 mVVoltage OUT:360,0 mV; DSO: 360,5 mVVoltage OUT:400,0 mV; DSO: 400,6 mVVoltage OUT:440,0 mV; DSO: 440,6 mVVoltage OUT:480,0 mV; DSO: 480,7 mVVoltage OUT:520,0 mV; DSO: 520,7 mVVoltage OUT:560,0 mV; DSO: 560,8 mVVoltage OUT:600,0 mV; DSO: 600,8 mVVoltage OUT:640,0 mV; DSO: 640,8 mVVoltage OUT:680,0 mV; DSO: 680,9 mVVoltage OUT:720,0 mV; DSO: 721,0 mVVoltage OUT:760,0 mV; DSO: 761,1 mVVoltage OUT:800,0 mV; DSO: 801,1 mVVoltage OUT:840,0 mV; DSO: 841,2 mVVoltage OUT:880,0 mV; DSO: 881,3 mVVoltage OUT:920,0 mV; DSO: 921,4 mVVoltage OUT:960,0 mV; DSO: 961,4 mVVoltage OUT:1000,0 mV; DSO: 1001,9 mV

author: HendriXML
author_rank: Super Contributor
timestamp: June 02, 2019, 09:29:18 pm
content: 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:Voltage OUT:0,0 mV; DSO: -0,4 mVVoltage OUT:40,0 mV; DSO: 39,7 mVVoltage OUT:80,0 mV; DSO: 79,6 mVVoltage OUT:120,0 mV; DSO: 119,6 mVVoltage OUT:160,0 mV; DSO: 159,7 mVVoltage OUT:200,0 mV; DSO: 195,4 mVVoltage OUT:240,0 mV; DSO: 240,0 mVVoltage OUT:280,0 mV; DSO: 280,0 mVVoltage OUT:320,0 mV; DSO: 320,0 mVVoltage OUT:360,0 mV; DSO: 360,1 mVVoltage OUT:400,0 mV; DSO: 400,1 mVVoltage OUT:440,0 mV; DSO: 440,3 mVVoltage OUT:480,0 mV; DSO: 480,3 mVVoltage OUT:520,0 mV; DSO: 520,4 mVVoltage OUT:560,0 mV; DSO: 560,4 mVVoltage OUT:600,0 mV; DSO: 600,5 mVVoltage OUT:640,0 mV; DSO: 640,6 mVVoltage OUT:680,0 mV; DSO: 680,5 mVVoltage OUT:720,0 mV; DSO: 720,7 mVVoltage OUT:760,0 mV; DSO: 760,6 mVVoltage OUT:800,0 mV; DSO: 800,7 mVVoltage OUT:840,0 mV; DSO: 840,8 mVVoltage OUT:880,0 mV; DSO: 880,9 mVVoltage OUT:920,0 mV; DSO: 921,0 mVVoltage OUT:960,0 mV; DSO: 961,1 mVVoltage OUT:1000,0 mV; DSO: 1001,7 mVVoltage OUT:-45,0 mV; DAC: -44,0 mVVoltage OUT:-40,0 mV; DAC: -40,0 mVVoltage OUT:-30,0 mV; DAC: -30,3 mVVoltage OUT:-20,0 mV; DAC: -20,1 mVVoltage OUT:-10,0 mV; DAC: -10,0 mVVoltage OUT:0,0 mV; DAC: 0,0 mVVoltage OUT:10,0 mV; DAC: 10,2 mVVoltage OUT:20,0 mV; DAC: 20,4 mVVoltage OUT:30,0 mV; DAC: 30,6 mVVoltage OUT:40,0 mV; DAC: 40,4 mVVoltage OUT:45,0 mV; DAC: 44,4 mV

author: HendriXML
author_rank: Super Contributor
timestamp: June 02, 2019, 10:57:57 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: June 03, 2019, 09:54:44 pm
content: 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:Voltage TARGET: -23,0 mV; WVE: -30827; EXP: -23,5 mV; MM: -23,0 mVVoltage TARGET: -20,0 mV; WVE: -26868; EXP: -20,5 mV; MM: -20,0 mVVoltage TARGET: -10,0 mV; WVE: -13850; EXP: -10,6 mV; MM: -10,0 mVVoltage TARGET: 0,0 mV; WVE: -861; EXP: -0,7 mV; MM: 0,0 mVVoltage TARGET: 10,0 mV; WVE: 12068; EXP: 9,2 mV; MM: 10,0 mVVoltage TARGET: 20,0 mV; WVE: 25057; EXP: 19,1 mV; MM: 20,0 mVVoltage TARGET: 23,0 mV; WVE: 29028; EXP: 22,1 mV; MM: 23,0 mV

author: HendriXML
author_rank: Super Contributor
timestamp: June 03, 2019, 09:57:34 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: June 04, 2019, 08:55:31 pm
content: 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:Voltage TARGET: 0,0 mV; EXP: -0,3 mV; MM: 0,0 mVVoltage TARGET: 5,0 mV; EXP: 4,6 mV; MM: 5,0 mVVoltage TARGET: 10,0 mV; EXP: 9,6 mV; MM: 10,0 mVVoltage TARGET: 15,0 mV; EXP: 14,6 mV; MM: 15,0 mVVoltage TARGET: 20,0 mV; EXP: 20,5 mV; MM: 20,0 mVVoltage TARGET: 25,0 mV; EXP: 25,5 mV; MM: 25,0 mVVoltage TARGET: 30,0 mV; EXP: 30,4 mV; MM: 30,0 mVVoltage TARGET: 35,0 mV; EXP: 35,4 mV; MM: 35,0 mVVoltage TARGET: 40,0 mV; EXP: 40,4 mV; MM: 40,0 mVVoltage TARGET: 45,0 mV; EXP: 45,3 mV; MM: 45,0 mVVoltage TARGET: 50,0 mV; EXP: 50,3 mV; MM: 50,0 mVVoltage TARGET: 55,0 mV; EXP: 55,3 mV; MM: 55,0 mVVoltage TARGET: 60,0 mV; EXP: 60,0 mV; MM: 60,0 mVVoltage TARGET: 65,0 mV; EXP: 65,0 mV; MM: 65,0 mVVoltage TARGET: 70,0 mV; EXP: 69,9 mV; MM: 70,0 mVVoltage TARGET: 75,0 mV; EXP: 74,9 mV; MM: 75,0 mVVoltage TARGET: 80,0 mV; EXP: 79,9 mV; MM: 80,0 mVVoltage TARGET: 85,0 mV; EXP: 84,8 mV; MM: 85,0 mVVoltage TARGET: 90,0 mV; EXP: 89,8 mV; MM: 90,0 mVVoltage TARGET: 95,0 mV; EXP: 94,8 mV; MM: 95,0 mVVoltage TARGET: 100,0 mV; EXP: 100,5 mV; MM: 100,0 mVVoltage TARGET: 105,0 mV; EXP: 105,5 mV; MM: 105,0 mVVoltage TARGET: 110,0 mV; EXP: 110,4 mV; MM: 110,0 mVVoltage TARGET: 115,0 mV; EXP: 115,4 mV; MM: 115,0 mVVoltage TARGET: 120,0 mV; EXP: 120,4 mV; MM: 120,0 mVVoltage TARGET: 125,0 mV; EXP: 125,3 mV; MM: 125,0 mVVoltage TARGET: 130,0 mV; EXP: 130,3 mV; MM: 130,0 mVVoltage TARGET: 135,0 mV; EXP: 135,3 mV; MM: 135,0 mVVoltage TARGET: 140,0 mV; EXP: 140,5 mV; MM: 140,0 mVVoltage TARGET: 145,0 mV; EXP: 145,5 mV; MM: 145,0 mVVoltage TARGET: 150,0 mV; EXP: 150,4 mV; MM: 150,0 mVVoltage TARGET: 155,0 mV; EXP: 155,4 mV; MM: 155,0 mVVoltage TARGET: 160,0 mV; EXP: 160,4 mV; MM: 160,0 mVVoltage TARGET: 165,0 mV; EXP: 165,3 mV; MM: 165,0 mVVoltage TARGET: 170,0 mV; EXP: 170,3 mV; MM: 170,0 mVVoltage TARGET: 175,0 mV; EXP: 175,3 mV; MM: 175,0 mVVoltage TARGET: 180,0 mV; EXP: 179,9 mV; MM: 180,0 mVVoltage TARGET: 185,0 mV; EXP: 184,9 mV; MM: 185,0 mVVoltage TARGET: 190,0 mV; EXP: 189,8 mV; MM: 190,0 mVVoltage TARGET: 195,0 mV; EXP: 194,8 mV; MM: 195,0 mVVoltage TARGET: 200,0 mV; EXP: 199,8 mV; MM: 200,0 mVVoltage TARGET: 205,0 mV; EXP: 204,7 mV; MM: 205,0 mVVoltage TARGET: 210,0 mV; EXP: 209,7 mV; MM: 210,0 mVVoltage TARGET: 215,0 mV; EXP: 214,7 mV; MM: 215,0 mVVoltage TARGET: 220,0 mV; EXP: 219,8 mV; MM: 220,0 mVVoltage TARGET: 225,0 mV; EXP: 224,8 mV; MM: 225,0 mVVoltage TARGET: 230,0 mV; EXP: 229,7 mV; MM: 230,0 mVVoltage TARGET: 235,0 mV; EXP: 234,7 mV; MM: 235,0 mVVoltage TARGET: 240,0 mV; EXP: 239,7 mV; MM: 240,0 mVVoltage TARGET: 245,0 mV; EXP: 244,6 mV; MM: 245,0 mVVoltage TARGET: 250,0 mV; EXP: 249,6 mV; MM: 250,0 mVVoltage TARGET: 255,0 mV; EXP: 254,6 mV; MM: 255,0 mVVoltage TARGET: 260,0 mV; EXP: 260,1 mV; MM: 260,0 mVVoltage TARGET: 265,0 mV; EXP: 265,1 mV; MM: 265,0 mVVoltage TARGET: 270,0 mV; EXP: 270,0 mV; MM: 270,0 mVVoltage TARGET: 275,0 mV; EXP: 275,0 mV; MM: 275,0 mVVoltage TARGET: 280,0 mV; EXP: 280,0 mV; MM: 280,0 mVVoltage TARGET: 285,0 mV; EXP: 284,9 mV; MM: 285,0 mVVoltage TARGET: 290,0 mV; EXP: 289,9 mV; MM: 290,0 mVVoltage TARGET: 295,0 mV; EXP: 294,9 mV; MM: 295,0 mVVoltage TARGET: 300,0 mV; EXP: 300,3 mV; MM: 300,0 mVVoltage TARGET: 305,0 mV; EXP: 305,3 mV; MM: 305,0 mVVoltage TARGET: 310,0 mV; EXP: 310,2 mV; MM: 310,0 mVVoltage TARGET: 315,0 mV; EXP: 315,2 mV; MM: 315,0 mVVoltage TARGET: 320,0 mV; EXP: 320,2 mV; MM: 320,0 mVVoltage TARGET: 325,0 mV; EXP: 325,1 mV; MM: 325,0 mVVoltage TARGET: 330,0 mV; EXP: 330,1 mV; MM: 330,0 mVVoltage TARGET: 335,0 mV; EXP: 335,1 mV; MM: 335,0 mVVoltage TARGET: 340,0 mV; EXP: 340,5 mV; MM: 340,0 mVVoltage TARGET: 345,0 mV; EXP: 345,5 mV; MM: 345,0 mVVoltage TARGET: 350,0 mV; EXP: 350,4 mV; MM: 350,0 mVVoltage TARGET: 355,0 mV; EXP: 355,4 mV; MM: 355,0 mVVoltage TARGET: 360,0 mV; EXP: 360,4 mV; MM: 360,0 mVVoltage TARGET: 365,0 mV; EXP: 365,3 mV; MM: 365,0 mVVoltage TARGET: 370,0 mV; EXP: 370,3 mV; MM: 370,0 mVVoltage TARGET: 375,0 mV; EXP: 375,3 mV; MM: 375,0 mVVoltage TARGET: 380,0 mV; EXP: 380,6 mV; MM: 380,0 mVVoltage TARGET: 385,0 mV; EXP: 385,6 mV; MM: 385,0 mVVoltage TARGET: 390,0 mV; EXP: 390,5 mV; MM: 390,0 mVVoltage TARGET: 395,0 mV; EXP: 395,5 mV; MM: 395,0 mVVoltage TARGET: 400,0 mV; EXP: 400,5 mV; MM: 400,0 mVVoltage TARGET: 405,0 mV; EXP: 405,4 mV; MM: 405,0 mVVoltage TARGET: 410,0 mV; EXP: 410,4 mV; MM: 410,0 mVVoltage TARGET: 415,0 mV; EXP: 415,4 mV; MM: 415,0 mVVoltage TARGET: 420,0 mV; EXP: 420,9 mV; MM: 420,0 mVVoltage TARGET: 425,0 mV; EXP: 425,9 mV; MM: 425,0 mVVoltage TARGET: 430,0 mV; EXP: 430,8 mV; MM: 430,0 mVVoltage TARGET: 435,0 mV; EXP: 435,8 mV; MM: 435,0 mVVoltage TARGET: 440,0 mV; EXP: 440,8 mV; MM: 440,0 mVVoltage TARGET: 445,0 mV; EXP: 445,7 mV; MM: 445,0 mVVoltage TARGET: 450,0 mV; EXP: 450,7 mV; MM: 450,0 mVVoltage TARGET: 455,0 mV; EXP: 455,7 mV; MM: 455,0 mVVoltage TARGET: 460,0 mV; EXP: 461,1 mV; MM: 460,0 mVVoltage TARGET: 465,0 mV; EXP: 466,1 mV; MM: 465,0 mVVoltage TARGET: 470,0 mV; EXP: 471,0 mV; MM: 470,0 mVVoltage TARGET: 475,0 mV; EXP: 476,0 mV; MM: 475,0 mVVoltage TARGET: 480,0 mV; EXP: 481,0 mV; MM: 480,0 mVVoltage TARGET: 485,0 mV; EXP: 485,9 mV; MM: 485,0 mVVoltage TARGET: 490,0 mV; EXP: 490,9 mV; MM: 490,0 mVVoltage TARGET: 495,0 mV; EXP: 495,9 mV; MM: 495,0 mVVoltage TARGET: 500,0 mV; EXP: 501,3 mV; MM: 500,0 mVVoltage TARGET: 505,0 mV; EXP: 506,3 mV; MM: 505,0 mVVoltage TARGET: 510,0 mV; EXP: 511,2 mV; MM: 510,0 mVVoltage TARGET: 515,0 mV; EXP: 516,2 mV; MM: 515,0 mVVoltage TARGET: 520,0 mV; EXP: 521,2 mV; MM: 520,0 mVVoltage TARGET: 525,0 mV; EXP: 526,1 mV; MM: 525,0 mVVoltage TARGET: 530,0 mV; EXP: 531,1 mV; MM: 530,0 mVVoltage TARGET: 535,0 mV; EXP: 536,1 mV; MM: 535,0 mVVoltage TARGET: 540,0 mV; EXP: 541,9 mV; MM: 540,0 mVVoltage TARGET: 545,0 mV; EXP: 546,9 mV; MM: 545,0 mVVoltage TARGET: 550,0 mV; EXP: 551,8 mV; MM: 550,0 mVVoltage TARGET: 555,0 mV; EXP: 556,8 mV; MM: 555,0 mVVoltage TARGET: 560,0 mV; EXP: 561,8 mV; MM: 560,0 mVVoltage TARGET: 565,0 mV; EXP: 566,7 mV; MM: 565,0 mVVoltage TARGET: 570,0 mV; EXP: 571,7 mV; MM: 570,0 mVVoltage TARGET: 575,0 mV; EXP: 576,7 mV; MM: 575,0 mVVoltage TARGET: 580,0 mV; EXP: 582,2 mV; MM: 580,0 mVVoltage TARGET: 585,0 mV; EXP: 587,2 mV; MM: 585,0 mVVoltage TARGET: 590,0 mV; EXP: 592,1 mV; MM: 590,0 mVVoltage TARGET: 595,0 mV; EXP: 597,1 mV; MM: 595,0 mVVoltage TARGET: 600,0 mV; EXP: 602,1 mV; MM: 600,0 mVVoltage TARGET: 605,0 mV; EXP: 607,0 mV; MM: 605,0 mVVoltage TARGET: 610,0 mV; EXP: 612,0 mV; MM: 610,0 mVVoltage TARGET: 615,0 mV; EXP: 617,0 mV; MM: 615,0 mVVoltage TARGET: 620,0 mV; EXP: 622,0 mV; MM: 620,0 mVVoltage TARGET: 625,0 mV; EXP: 627,0 mV; MM: 625,0 mVVoltage TARGET: 630,0 mV; EXP: 631,9 mV; MM: 630,0 mVVoltage TARGET: 635,0 mV; EXP: 636,9 mV; MM: 635,0 mVVoltage TARGET: 640,0 mV; EXP: 641,9 mV; MM: 640,0 mVVoltage TARGET: 645,0 mV; EXP: 646,8 mV; MM: 645,0 mVVoltage TARGET: 650,0 mV; EXP: 651,8 mV; MM: 650,0 mVVoltage TARGET: 655,0 mV; EXP: 656,8 mV; MM: 655,0 mVVoltage TARGET: 660,0 mV; EXP: 662,0 mV; MM: 660,0 mVVoltage TARGET: 665,0 mV; EXP: 667,0 mV; MM: 665,0 mVVoltage TARGET: 670,0 mV; EXP: 671,9 mV; MM: 670,0 mVVoltage TARGET: 675,0 mV; EXP: 676,9 mV; MM: 675,0 mVVoltage TARGET: 680,0 mV; EXP: 681,9 mV; MM: 680,0 mVVoltage TARGET: 685,0 mV; EXP: 686,8 mV; MM: 685,0 mVVoltage TARGET: 690,0 mV; EXP: 691,8 mV; MM: 690,0 mVVoltage TARGET: 695,0 mV; EXP: 696,8 mV; MM: 695,0 mVVoltage TARGET: 700,0 mV; EXP: 702,4 mV; MM: 700,0 mVVoltage TARGET: 705,0 mV; EXP: 707,4 mV; MM: 705,0 mVVoltage TARGET: 710,0 mV; EXP: 712,3 mV; MM: 710,0 mVVoltage TARGET: 715,0 mV; EXP: 717,3 mV; MM: 715,0 mVVoltage TARGET: 720,0 mV; EXP: 722,3 mV; MM: 720,0 mVVoltage TARGET: 725,0 mV; EXP: 727,2 mV; MM: 725,0 mVVoltage TARGET: 730,0 mV; EXP: 732,2 mV; MM: 730,0 mVVoltage TARGET: 735,0 mV; EXP: 737,2 mV; MM: 735,0 mVVoltage TARGET: 740,0 mV; EXP: 742,0 mV; MM: 740,0 mVVoltage TARGET: 745,0 mV; EXP: 747,0 mV; MM: 745,0 mVVoltage TARGET: 750,0 mV; EXP: 751,9 mV; MM: 750,0 mVVoltage TARGET: 755,0 mV; EXP: 756,9 mV; MM: 755,0 mVVoltage TARGET: 760,0 mV; EXP: 761,9 mV; MM: 760,0 mVVoltage TARGET: 765,0 mV; EXP: 766,8 mV; MM: 765,0 mVVoltage TARGET: 770,0 mV; EXP: 771,8 mV; MM: 770,0 mVVoltage TARGET: 775,0 mV; EXP: 776,8 mV; MM: 775,0 mVVoltage TARGET: 780,0 mV; EXP: 782,0 mV; MM: 780,0 mVVoltage TARGET: 785,0 mV; EXP: 787,0 mV; MM: 785,0 mVVoltage TARGET: 790,0 mV; EXP: 791,9 mV; MM: 790,0 mVVoltage TARGET: 795,0 mV; EXP: 796,9 mV; MM: 795,0 mVVoltage TARGET: 800,0 mV; EXP: 801,9 mV; MM: 800,0 mVVoltage TARGET: 805,0 mV; EXP: 806,8 mV; MM: 805,0 mVVoltage TARGET: 810,0 mV; EXP: 811,8 mV; MM: 810,0 mVVoltage TARGET: 815,0 mV; EXP: 816,8 mV; MM: 815,0 mVVoltage TARGET: 820,0 mV; EXP: 822,2 mV; MM: 820,0 mVVoltage TARGET: 825,0 mV; EXP: 827,2 mV; MM: 825,0 mVVoltage TARGET: 830,0 mV; EXP: 832,1 mV; MM: 830,0 mVVoltage TARGET: 835,0 mV; EXP: 837,1 mV; MM: 835,0 mVVoltage TARGET: 840,0 mV; EXP: 842,1 mV; MM: 840,0 mVVoltage TARGET: 845,0 mV; EXP: 847,0 mV; MM: 845,0 mVVoltage TARGET: 850,0 mV; EXP: 852,0 mV; MM: 850,0 mVVoltage TARGET: 855,0 mV; EXP: 857,0 mV; MM: 855,0 mVVoltage TARGET: 860,0 mV; EXP: 861,8 mV; MM: 860,0 mVVoltage TARGET: 865,0 mV; EXP: 866,8 mV; MM: 865,0 mVVoltage TARGET: 870,0 mV; EXP: 871,7 mV; MM: 870,0 mVVoltage TARGET: 875,0 mV; EXP: 876,7 mV; MM: 875,0 mVVoltage TARGET: 880,0 mV; EXP: 881,7 mV; MM: 880,0 mVVoltage TARGET: 885,0 mV; EXP: 886,6 mV; MM: 885,0 mVVoltage TARGET: 890,0 mV; EXP: 891,6 mV; MM: 890,0 mVVoltage TARGET: 895,0 mV; EXP: 896,6 mV; MM: 895,0 mVVoltage TARGET: 900,0 mV; EXP: 901,5 mV; MM: 900,0 mVVoltage TARGET: 905,0 mV; EXP: 906,5 mV; MM: 905,0 mVVoltage TARGET: 910,0 mV; EXP: 911,4 mV; MM: 910,0 mVVoltage TARGET: 915,0 mV; EXP: 916,4 mV; MM: 915,0 mVVoltage TARGET: 920,0 mV; EXP: 921,4 mV; MM: 920,0 mVVoltage TARGET: 925,0 mV; EXP: 926,3 mV; MM: 925,0 mVVoltage TARGET: 930,0 mV; EXP: 931,3 mV; MM: 930,0 mVVoltage TARGET: 935,0 mV; EXP: 936,3 mV; MM: 935,0 mVVoltage TARGET: 940,0 mV; EXP: 941,5 mV; MM: 940,0 mVVoltage TARGET: 945,0 mV; EXP: 946,5 mV; MM: 945,0 mVVoltage TARGET: 950,0 mV; EXP: 951,4 mV; MM: 950,0 mVVoltage TARGET: 955,0 mV; EXP: 956,4 mV; MM: 955,0 mVVoltage TARGET: 960,0 mV; EXP: 961,4 mV; MM: 960,0 mVVoltage TARGET: 965,0 mV; EXP: 966,3 mV; MM: 965,0 mVVoltage TARGET: 970,0 mV; EXP: 971,3 mV; MM: 970,0 mVVoltage TARGET: 975,0 mV; EXP: 976,3 mV; MM: 975,0 mVVoltage TARGET: 980,0 mV; EXP: 982,4 mV; MM: 980,0 mVVoltage TARGET: 985,0 mV; EXP: 987,4 mV; MM: 985,0 mVVoltage TARGET: 990,0 mV; EXP: 992,3 mV; MM: 990,0 mVVoltage TARGET: 995,0 mV; EXP: 997,3 mV; MM: 995,0 mVVoltage TARGET: 1000,0 mV; EXP: 1002,3 mV; MM: 1000,0 mV

author: HendriXML
author_rank: Super Contributor
timestamp: June 06, 2019, 09:24:37 pm
content: 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).

author: HendriXML
author_rank: Super Contributor
timestamp: June 10, 2019, 08:58:23 pm
content: 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:0-0,11943,90587,841211,8381615,8822019,9252423,0372827,2573231,4813635,5794039,694443,5614847,4685251,4335655,4786059,5226463,2996867,4857271,6937675,7518079,8798483,8478887,729291,6049695,51110099,529104103,239108107,439112111,647116115,725120119,854124123,781128127,635132131,509136135,481140139,522144143,283148147,465152151,546156155,571160159,596164163,543168167,47172171,488176175,526180179,535184183,283188187,471192191,677196195,742200199,869204203,812208207,67212211,541216215,486220219,522224223,166228227,377232231,599236235,693240239,82244243,71248247,558252251,452256255,478260259,522264263,055268267,273272271,501276275,604280279,718284283,577288287,473292291,433296295,478300299,522304303,007308307,226312311,452316315,547320319,651324323,544328327,463332331,433336335,478340339,522344343,355348347,543352351,736356355,77360359,897364363,907368367,817372371,789376375,723380379,659384383,354388387,539392391,734396395,769400399,896404403,902408407,807412411,765416415,677420419,62424423,127428427,341432431,564436435,667440439,79444443,659448447,517452451,44456455,478460459,522464463,115468467,331472471,553476475,652480479,774484483,635488487,507492491,435496495,478500499,522504503,25508507,457512511,546516515,571520519,596524523,54528527,467532531,462536535,469540539,5544543,2548547,404552551,618556555,708560559,835564563,745568567,59572571,469576575,478580579,522584582,963588587,176592591,377596595,443600599,564604603,531608607,457612611,433616615,478620619,522624623,252628627,441632631,646636635,726640639,854644643,78648647,632652651,493656655,478660659,522664662,974668667,19672671,402676675,477680679,583684683,532688687,459692691,433696695,478700699,522704703,358708707,561712711,746716715,779720719,905724723,916728727,839732731,834736735,834740739,784744743,341748747,513752751,714756755,76760759,887764763,879768767,762772771,676776775,561780779,557784783,34788787,514792791,717796795,762800799,887804803,871808807,752812811,64816815,531820819,541824823,179828827,383832831,597836835,689840839,814844843,714848847,564852851,462856855,478860859,522864863,183868867,392872871,605876875,691880879,811884883,702888887,544892891,45896895,478900899,522904903,206908907,409912911,62916915,707920919,831924923,735928927,585932931,468936935,478940939,522944942,963948947,176952951,383956955,452960959,569964963,531968967,458972971,433976975,478980979,522984983,806988987,795992991,774996995,7511000999,776

author: HendriXML
author_rank: Super Contributor
timestamp: June 10, 2019, 11:25:46 pm
content: 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!!

author: HendriXML
author_rank: Super Contributor
timestamp: June 10, 2019, 11:55:48 pm
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: June 28, 2019, 09:38:48 am
content: 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.

author: HendriXML
author_rank: Super Contributor
timestamp: June 28, 2019, 10:17:41 am
content: The setup controlling the temperature is shown here:https://www.eevblog.com/forum/projects/very-stable-temperature-control/msg2514615/#msg2514615