Author Topic: Using a AWG and a Scope -> using stairs to get to 1 mV accuracy  (Read 12413 times)

0 Members and 1 Guest are viewing this topic.

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
For the added overcurrent protection in this little project:
https://www.eevblog.com/forum/projects/battery-voltage-to-5v-regulation/msg2280605/?all#lastPost

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

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

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

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

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

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

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

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

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

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

BTW: The curves already tells me that temperature dependency is a bit too high to my likings. But these experiments are a good learning experience. So we shall continue!
« Last Edit: June 10, 2019, 11:22:12 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
I'm still not sure whether the fetched dataset is an averaged one or whether averaging is only used for the DSO screen.
FYI the displayed sampling rate and mem depth are clues to what happens when Averaging or E-Res modes are selected.  ;)
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
I'm still not sure whether the fetched dataset is an averaged one or whether averaging is only used for the DSO screen.
FYI the displayed sampling rate and mem depth are clues to what happens when Averaging or E-Res modes are selected.  ;)
The mem-depth I already manually turned down, so that's no clue to me ;). The sample rate does then also not need to be high anymore so I'm missing that clue also :-//

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

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

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

Now I really like to know!

“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Try a full mem depth before selecting Average and then see the mem depth drop so the scope can process the averages quickly.
Both sampling rate and mem depth are timebase setting dependent so you can see what's going on.
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Try a full mem depth before selecting Average and then see the mem depth drop so the scope can process the averages quickly.
Both sampling rate and mem depth are timebase setting dependent so you can see what's going on.
But is also needs memory to store the summing in, that alone could be a reason for not having the full memory to be available.

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

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

I had an averaged sine wave of 6V ampl. and set it to 0V ampl. and then quickly retrieved a dataset. And indeed the ampl. hadn't dropped much. Nice to know!
« Last Edit: April 12, 2019, 10:13:08 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Also how does is implement FIFO? Has it got 2 or more summing buffers?
Dunno, past my level of knowledge.
Others might know and help.
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Also how does is implement FIFO? Has it got 2 or more summing buffers?
Dunno, past my level of knowledge.
Others might know and help.
Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution  :-+
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Also how does is implement FIFO? Has it got 2 or more summing buffers?
Dunno, past my level of knowledge.
Others might know and help.
Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution  :-+
Yes I think that's correct.
4ch X-E right ?
Enter the webrowser and download the .bin to .csv file converter.
Use it to convert the default .bin data file to .csv then Copy/Paste the data into your program. (Excel etc)
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Also how does is implement FIFO? Has it got 2 or more summing buffers?
Dunno, past my level of knowledge.
Others might know and help.
Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution  :-+
Yes I think that's correct.
4ch X-E right ?
Enter the webrowser and download the .bin to .csv file converter.
Use it to convert the default .bin data file to .csv then Copy/Paste the data into your program. (Excel etc)
Yes, I went fancy with my post and on each glowing abrev. more details are shown. But here on the iPad it doesn’t work, so not worth the effort.

The way I get the samples is via SCPI in a byte per sample, so the extra bits are chopped off in that way. If the webbrowser does it otherwise it would pleasantly surprise me.  But I think that not many consumer level scope’s will support the extra bits feature.
« Last Edit: April 17, 2019, 11:15:02 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Also how does is implement FIFO? Has it got 2 or more summing buffers?
Dunno, past my level of knowledge.
Others might know and help.
Did some googling, and found no answer yet, so that's not easy obtained knowledge. A more practical question would be: can one retrieve the summed values, because they've got a higher resolution  :-+
Yes I think that's correct.
4ch X-E right ?
Enter the webrowser and download the .bin to .csv file converter.
Use it to convert the default .bin data file to .csv then Copy/Paste the data into your program. (Excel etc)
Yes, I went fancy with my post and on each glowing abrev. more details are shown. But here on the iPad it doesn’t work, so not worth the effort.

The way I get the samples is via SPCI in a byte per sample, so the extra bits are chopped off in that way. If the webbrowser does it otherwise it would pleasantly surprise me.  But I think that not many consumer level scope’s will support the extra bits feature.
The .bin/csv files can be pretty large but with use of a careful setup restricting mem depth, trigger level and Single shot you can keep the data sample size quite small and manageable.
Just try with some simple waveform to get some system that works for you sorted then migrate the settings into your test setup.
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
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)
« Last Edit: April 14, 2019, 07:33:20 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... scope averaging mode tested
« Reply #11 on: April 14, 2019, 09:27:52 am »
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?
« Last Edit: April 17, 2019, 11:16:18 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #12 on: April 14, 2019, 12:42:07 pm »
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.
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #13 on: April 14, 2019, 02:17:11 pm »
Looking at the duty cycle average test.   Assuming I follow, which I am not sure I am,  at 140Hz or every 7.15ms the scope will see a trigger.   You wait 10 seconds except for the very first, to allow up to 1400 cycles to be captured.  Even with 32 averages, it should should be flushed but it's showing some residual.  The scope may not be collecting all the data.   

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

Basically, just curious if you made sure your test was valid before running it.
I haven't seen a trigger counter anywhere, so I'm also not sure how many times it triggered.

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

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

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

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

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

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

I cannot think of another way to really get rid of old values. Maybe someone else has a genius idea?
« Last Edit: April 14, 2019, 03:22:57 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #14 on: April 14, 2019, 04:08:03 pm »
Basically, just curious if you made sure your test was valid before running it.
I haven't seen a trigger counter anywhere, so I'm also not sure how many times it triggered.

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

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

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

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

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

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

I cannot think of another way to really get rid of old values. Maybe someone else has a genius idea?
Obviously I don't know anything about the scope you are using.   Normally I will use Labview to collect and crunch the data.  Still, if you wrote you own software you would need to see how fast you could collect it first. 
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #15 on: April 14, 2019, 05:14:56 pm »
Basically, just curious if you made sure your test was valid before running it.
I haven't seen a trigger counter anywhere, so I'm also not sure how many times it triggered.

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

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

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

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

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

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

I cannot think of another way to really get rid of old values. Maybe someone else has a genius idea?
Obviously I don't know anything about the scope you are using.   Normally I will use Labview to collect and crunch the data.  Still, if you wrote you own software you would need to see how fast you could collect it first.

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

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

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

I've also searched for a Trigger counter but I don't think the scope has one.
« Last Edit: April 20, 2019, 11:39:44 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #16 on: April 14, 2019, 05:40:49 pm »
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.   
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #17 on: April 14, 2019, 06:10:21 pm »
Odd they don't offer example code.   At these speeds, you may be able to grab it frame by frame.   There are some advantages to working this way, if you can pull it off.   All my vintage scopes allow creating your own scripts to control them.  I've never gone this route as the desktop PC's processing power can easily out pace the scopes I have.   You can take advantage of the GPU for example.     

Even if you can't collect individual frames without missing, the raw accumulated data sounds like it will work for you, assuming that is really what they send you.   I am envisioning a very sparse manual for your particular scope.   
What you suppose is also doable for me to, frames don't need to adjacent to each other. :-+ (My mind was stuck on duplicating an averaging algorithm)
But it is also good to have a small timeframe at which all data is acquired. The fetching of data goes fast (for such small data blocks), like 5 MiB/s, so 14K frames could be downloaded at the speed of 35 frames/sec.

-Edit I have to correct the speed I usually get:
6 MB/sfor large blocks, but only 0,24 MB for 14K blocks.
« Last Edit: April 16, 2019, 10:22:08 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #18 on: April 14, 2019, 06:16:40 pm »
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!
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual segements?
« Reply #19 on: April 14, 2019, 07:37:03 pm »
Odd they don't offer example code.   At these speeds, you may be able to grab it frame by frame.   There are some advantages to working this way, if you can pull it off.   All my vintage scopes allow creating your own scripts to control them.  I've never gone this route as the desktop PC's processing power can easily out pace the scopes I have.   You can take advantage of the GPU for example.     

Even if you can't collect individual frames without missing, the raw accumulated data sounds like it will work for you, assuming that is really what they send you.   I am envisioning a very sparse manual for your particular scope.   
What you suppose is also doable for me to, frames don't need to adjacent to each other. :-+ (My mind was stuck on duplicating an averaging algorithm)
But it is also good to have a small timeframe at which all data is acquired. The fetching of data goes fast (for such small data blocks), like 5 MiB/s, so 14K frames could be downloaded at the speed of 35 frames/sec.

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

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

If the data is unpacked on your scope (say they really send two bytes anytime you enable accumulation) the actual data rate you need would be much lower once you get past a one accumulation.     
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #20 on: April 14, 2019, 07:40:49 pm »
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
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #21 on: April 14, 2019, 08:06:25 pm »
I doubt it will help you with the experiment you are trying to run but it should give you some idea how fast I can transfer data with my vintage scope. 

https://youtu.be/DlsBnumQaCA?list=PLZSS2ajxhiQA9yWh-hvVtv2ib-3ObOHGV&t=15
Nice to see and very fast  speeds! But think that also depends a lot on how fast chipset and cpu of the scope are. As far as I can see your data goes also through a VISA driver layer.
Which my software also directly communicates with. Also more pro scopes will prop. have better tuned software running on them.
I still find it amazing what my Siglent SDS1104X-E is capable of feature wise. Maybe if I ran jumbo packets on the network the speed goes up as well, I don’t know. To many network interrupts can slow things down. I don’t even know wether it is a Gib network interface.
For my experiment tons of data would also be overkill. With 14K frames I think a good dataset can be created. It is slowly rising so I can tune on that property and do heavy averaging.
« Last Edit: April 14, 2019, 08:41:07 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #22 on: April 14, 2019, 09:13:26 pm »
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
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #23 on: April 14, 2019, 10:43:36 pm »
I  looked up your scope on their site.  They show it has a LAN connection but details are sparse.  I couldn't locate a manual for it.  If you can post a link to the manual, I will have a look.     
The manuals of interest are:
SDS1000X-E Series User Manual
Programming Guide For Digital Oscilloscopes Series

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

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

Also there's some guidance about data collection in the Operation tips:
https://www.siglentamerica.com/operating-tips/sds1000x-e-series/
And videos:
https://www.siglentamerica.com/videos/sds1000x-e-series/
Avid Rabid Hobbyist
 
The following users thanked this post: joeqsmith

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #24 on: April 14, 2019, 10:59:04 pm »
I  looked up your scope on their site.  They show it has a LAN connection but details are sparse.  I couldn't locate a manual for it.  If you can post a link to the manual, I will have a look.     
The manuals of interest are:
SDS1000X-E Series User Manual
Programming Guide For Digital Oscilloscopes Series

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

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

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

Thanks!

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

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

Then I tried to use USB, but the VISA com interface crashed in that case so I cannot report any speeds on that.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #25 on: April 14, 2019, 11:23:11 pm »
Then I tried to use USB, but the VISA com interface crashed in that case so I cannot report any speeds on that.
How so ?
Is EasyScope working for you ?

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

From an old post:
Quote
The USB driver is being used for the connection to the Siglent scope....it should be something like: "C:\Program Files\IVI Foundation\VISA\IVI USB3 Staging\ausbtmc.inf"
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #26 on: April 14, 2019, 11:33:35 pm »
Then I tried to use USB, but the VISA com interface crashed in that case so I cannot report any speeds on that.
How so ?
[/quote]
I'm quite sure this it has nothing to do with Siglent. The guys from VISA shared components (not National Instruments I think) did not a great job creating a COM interface for VISA. I don't think Easyscope uses the COM interface. Instead it propably talks directly to Visa.dll
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #27 on: April 14, 2019, 11:43:51 pm »
The NIVISA Runtime package as a minimum must be installed for EasyScope for USB or LAN connection.
For USB just check the USB port's driver is set to ausbtmc.inf.
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #28 on: April 15, 2019, 12:11:47 am »
The NIVISA Runtime package as a minimum must be installed for EasyScope for USB or LAN connection.
For USB just check the USB port's driver is set to ausbtmc.inf.
I’ve installed the full package which deliver stuff with which the USB tests OK. With that pachage runtime or full comes an extra interface layer possibility. Namely COM. That is what is crashing. I had to try several versions to get LAN working. Today I tested USB for the first time, and it gives the usual access violation.
That just shouldn’t happen. And it is just when opening the device. I can even see that succeeding in the NI trace app. Which “watches” on the VISA.dll interface layer.
« Last Edit: April 15, 2019, 12:47:32 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #29 on: April 15, 2019, 12:49:39 am »
...
I checked the color of the led of the switch at the scopes connection: it is of amber color meaning a 100mbit connection.

I did a large 14M test, and it was fetched at 6MB/s
It's not 30MB/s but enough for a lot of applications.
...
Seems reasonable and should easily cover what you are trying to do, assuming the scope can actually shuffle the data out.  I had a high end Arb that I was trying to use Ethernet with.  Their firmware was so poorly written, it was actually faster to use GPIB!  This was about a $70,000 USD unit.  Poorly written code has no bounds.   :-DD 

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

I’ve the full package ....

With you discussing NIVISA,  I am curious what the "full package" refers to?   Do you have the full package of Labview that you plan to use with this scope?   
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #30 on: April 15, 2019, 01:21:43 am »
Is the 100Mbit limit on your PC, scope or both? 

The scope.

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

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

“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #31 on: April 15, 2019, 01:26:40 am »
The NIVISA Runtime package as a minimum must be installed for EasyScope for USB or LAN connection.
For USB just check the USB port's driver is set to ausbtmc.inf.
I’ve installed the full package which deliver stuff with which the USB tests OK. With that pachage runtime or full comes an extra interface layer possibility. Namely COM. That is what is crashing. I had to try several versions to get LAN working. Today I tested USB for the first time, and it gives the usual access violation.
That just shouldn’t happen. And it is just when opening the device. I can even see that succeeding in the NI trace app. Which “watches” on the VISA.dll interface layer.
Interesting.
Ok then, is the inbuilt webservers SCPI panel better for what you're trying to do ?
No other SW is needed other than your browser and give it the scope's IP. 
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #32 on: April 15, 2019, 01:29:17 am »
I checked the USB driver, the module which gives the AV is some COM dll.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #33 on: April 15, 2019, 01:31:24 am »
The NIVISA Runtime package as a minimum must be installed for EasyScope for USB or LAN connection.
For USB just check the USB port's driver is set to ausbtmc.inf.
I’ve installed the full package which deliver stuff with which the USB tests OK. With that pachage runtime or full comes an extra interface layer possibility. Namely COM. That is what is crashing. I had to try several versions to get LAN working. Today I tested USB for the first time, and it gives the usual access violation.
That just shouldn’t happen. And it is just when opening the device. I can even see that succeeding in the NI trace app. Which “watches” on the VISA.dll interface layer.
Interesting.
Ok then, is the inbuilt webservers SCPI panel better for what you're trying to do ?
No other SW is needed other than your browser and give it the scope's IP.
I'm using my self created scripting language/interpreter, so it can't possibly be better ;)
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... SPCI individual frames?
« Reply #34 on: April 15, 2019, 02:32:02 am »
With you discussing NIVISA,  I am curious what the "full package" refers to?   Do you have the full package of Labview that you plan to use with this scope?   
It is about 1GB installation and gives access to some nice (debugging) tools.
It's far too small to be Labview.  :-DD  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.
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #35 on: April 15, 2019, 08:27:07 pm »
I made a large graph PNG, to show the result of doing a segmented data acquisition and then averaging the 1891 (-> max, when 14K samples) frames.

No more 255 levels of resolution  :-+

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

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

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

This way I know for sure my curve will always rise and that there's enough vertical distance to have a reliable slope.
« Last Edit: April 17, 2019, 11:21:42 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #36 on: April 15, 2019, 10:08:45 pm »
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.
« Last Edit: April 15, 2019, 11:37:24 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #37 on: April 16, 2019, 07:41:18 pm »
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.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #38 on: April 16, 2019, 11:00:18 pm »
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.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #39 on: April 16, 2019, 11:58:13 pm »
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)
« Last Edit: April 17, 2019, 12:01:14 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #40 on: April 17, 2019, 12:19:35 am »
When doing time-based averaging with larger steps, the slopes become more stable.

This will be usable for some coarse answers.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #41 on: April 17, 2019, 11:39:24 am »
I made a large graph PNG, to show the result of doing a segmented data acquisition and then averaging the 1891 (-> max, when 14K samples) frames.

No more 255 levels of resolution  :-+
....

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

https://youtu.be/04I7nHA_HxM?t=161
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #42 on: April 17, 2019, 11:53:55 am »
I will say if your in full control of things with SCPI, use a smaller vdiv setting and trim the offset per segment. the offset dac is the root of trust as far as the scopes calibration goes, so the closer you can keep to the center division, the more you can trust the reading

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

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #43 on: April 17, 2019, 05:57:58 pm »
I made a large graph PNG, to show the result of doing a segmented data acquisition and then averaging the 1891 (-> max, when 14K samples) frames.

No more 255 levels of resolution  :-+
....

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

https://youtu.be/04I7nHA_HxM?t=161
I didn't, but here the slope at some points on the averaged ramp.  :-+ It should be a straight line of theoretically 580,64 V/s

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

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

What you did was very advanced, but for this experiment I leave it the way things are, because I will compare two datasets which will be fetched with the same (repeatable) errors, and can still be compared.
« Last Edit: April 17, 2019, 06:13:12 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #44 on: April 17, 2019, 06:03:48 pm »
I will say if your in full control of things with SCPI, use a smaller vdiv setting and trim the offset per segment. the offset dac is the root of trust as far as the scopes calibration goes, so the closer you can keep to the center division, the more you can trust the reading

So you just have a quite small time base so you can rip the data off as fast as possible (you can set things up so you only download every X sample to speed things up) and each time the data walks towards the top or bottom of the screen you adjust the channel offset.
That would be a good idea to keep in mind. In the previous post I saw that things are not perfect in DSO measurement land. I'm happy that for answering the temperature dependency question it does not mind much.
Can you explain the dip I measured in the centre? It is one that bothers me.
« Last Edit: April 17, 2019, 06:23:36 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #45 on: April 17, 2019, 08:34:46 pm »
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
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #46 on: April 18, 2019, 02:23:11 am »
I made a large graph PNG, to show the result of doing a segmented data acquisition and then averaging the 1891 (-> max, when 14K samples) frames.

No more 255 levels of resolution  :-+
....

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

https://youtu.be/04I7nHA_HxM?t=161
I didn't, but here the slope at some points on the averaged ramp.  :-+ It should be a straight line of theoretically 580,64 V/s

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

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

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

Triggers can pose some problems.   That Arb I mentioned samples the trigger asynchronous so I ended up with a large bit of jitter and had to synchronize the clocks.  The Arb required a minimum of a 5GHz clock so getting that working was a bit of effort.  Thank goodness for Mini-Circuits.   :-DD    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.   
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #47 on: April 18, 2019, 10:17:44 am »
I made a large graph PNG, to show the result of doing a segmented data acquisition and then averaging the 1891 (-> max, when 14K samples) frames.

No more 255 levels of resolution  :-+
....

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

https://youtu.be/04I7nHA_HxM?t=161
I didn't, but here the slope at some points on the averaged ramp.  :-+ It should be a straight line of theoretically 580,64 V/s

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

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

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

Triggers can pose some problems.   That Arb I mentioned samples the trigger asynchronous so I ended up with a large bit of jitter and had to synchronize the clocks.  The Arb required a minimum of a 5GHz clock so getting that working was a bit of effort.  Thank goodness for Mini-Circuits.   :-DD    In the sub MHz, it seems like it would be far less of a problem.  I assume you are driving the scopes external trigger with one of the Arb's channels or it has an output trigger.  If not, maybe you can change your setup to improve it.
My scope does not have an external trigger. In the setup there’re 10 MSam/s (100 ns), but the sync puls is 50 ns wide so that would be tricky. I tried using it but, it didn’t trigger so I used the rampsignal instead. But when I think of it again, I must have forgotten to turn the sync pulse on.
A third probe does come at the cost of having half the memory buffer. It also increased the samples/s. (Meaning also less risk to miss. a trigger pulse) So now there’re much less samples to average. But of a higher quality (the signal seemed rock solid), and more samples to do time based averaging.
« Last Edit: April 18, 2019, 10:20:29 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #48 on: April 18, 2019, 01:02:56 pm »
My suspicion would be a rounding error, you can isolate which part is causing it by rerunning with an X10 probe connected, if it happens at the same point on the slope its the AWG, if it moves its the scope ADC
Now I used the sync pulse from the AWG for the triggering.

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

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

The circles are the time base averaged values.
« Last Edit: April 18, 2019, 01:05:20 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #49 on: April 18, 2019, 01:38:24 pm »
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.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #50 on: April 18, 2019, 03:07:08 pm »
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.
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #51 on: April 19, 2019, 10:36:21 am »
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.
« Last Edit: April 20, 2019, 11:49:56 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #52 on: April 19, 2019, 10:42:00 am »
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?
« Last Edit: April 19, 2019, 10:57:32 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> sidetrack... Averaging 1891 frames by script
« Reply #53 on: April 19, 2019, 11:14:51 am »
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.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #54 on: April 19, 2019, 08:49:30 pm »
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?
« Last Edit: April 19, 2019, 09:52:19 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #55 on: April 19, 2019, 08:56:11 pm »
I created a normal size image with only the glitches at 400 mV.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #56 on: April 19, 2019, 09:01:45 pm »
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)
« Last Edit: April 19, 2019, 09:06:58 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline genghisnico13

  • Regular Contributor
  • *
  • Posts: 54
  • Country: cl
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #57 on: April 20, 2019, 02:51:49 pm »
I don't know much about the subject, but have you tried adding white noise to your input signal with the generator?
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #58 on: April 20, 2019, 02:53:51 pm »
When I look at the above one thing strikes me, it seems that the value drops, but it never really jumps back. Like the whole positive (RawValue > 0) side should be lifted 1 step.
In the slope graph this can also be seen. A spike going down, doesn't have a spike going up. (The average slope is not restored)
In this thread this problem is discussed, which lead to the cause.
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg2355744/#msg2355744

The documented way to translate raw sample values seems not to be correct. That's why every value below the center point is 1 step to high. When values get close to the centerpoint this results in a noticeable glitch.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #59 on: April 20, 2019, 03:02:15 pm »
I don't know much about the subject, but have you tried adding white noise to your input signal with the generator?
Via the UI I cannot add white noise, but maybe there's a SCPI way, I have to figure that out. But first I like to know the cause of the smaller glitches. I'm pretty confident that they are analogue issues (besides the centerpoint crossing error). But I may have to leave these issues it for a while: holidays are coming.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #60 on: April 20, 2019, 04:44:56 pm »
In my graphs there seem reoccurring glitches (value going down for a few samples and the up again) around certain Y-values. This can be show by taking time based averages and showing the slope between them. At each larger peak there's probably a glitch.

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

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

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

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

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

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #61 on: April 20, 2019, 05:27:00 pm »

We know you were missing a lot of data early on.  To run this test, the sampling will need to be solid.  No missing data.  The trigger jigger will need to be VERY small.  on and on....   Once you have all the small details ironed out, it should be flat.  There should be no need to disguard data.
Hi, thanks for the response.
I think the triggering is OK now, using the sync pulse of 5 ns rise time at a cycle of ms, should do the trick.
Also because I have 2 simple ramps, I don’t think the timing can create the glitches I’m still seeing (1 I tackled).

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

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

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

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

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

If it’s in the signal than it will show up enlarged. Maybe showing dac issues.
« Last Edit: April 20, 2019, 05:35:14 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #62 on: April 20, 2019, 06:02:51 pm »
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).   :-DD   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.
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #64 on: April 20, 2019, 06:39:18 pm »
I was thinking you are plotting the slope of the change in values, not the values.  If I understand what you are doing (which is a pure guess on my part) then the time the data is sampled will have a dramatic effect on the amplitude, and hence the slope.   So timing is critical as well as the amplitude.
In case of a simple ramp/slow signal a change in time would mean it only goes up/down a bit, it would probably average the slope, but not have the reactive stuff I've got now (I guess).

I think I might have found a problem with the AWG signal.
« Last Edit: April 20, 2019, 08:22:48 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #65 on: April 20, 2019, 08:47:18 pm »
In your case, you may be able to run it at DC.  Step the Arb, let it settle, trigger the scope to grab a frame, download and average it and step the DAC.  Remove time from the setup.  Again, I am not really following along with what you are attempting to do and may be way off base in my suggestions.
In my case 378 frames are held in the deep memory (i think its called like that). They’re placed there in succession and the acquisition is stopped after the last frame is acquired (the scope does this). After that the script has all the time in the world to download the data. So no real time issues.

Also in windows applications (processes or threads) can be run at high priority. Time critical software should use those possibilities. A multi core PC should be able to run a task almost real-time without any disturbances. (Not doing HDD stuff)
« Last Edit: April 20, 2019, 08:57:43 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #66 on: April 20, 2019, 09:03:53 pm »
I was thinking you are plotting the slope of the change in values, not the values.  If I understand what you are doing (which is a pure guess on my part) then the time the data is sampled will have a dramatic effect on the amplitude, and hence the slope.   So timing is critical as well as the amplitude.
In case of a simple ramp/slow signal a change in time would mean it only goes up/down a bit, it would probably average the slope, but not have the reactive stuff I've got now (I guess).

I think I might have found a problem with the AWG signal.
That would depend.  If the DSO is set to say 1mV / count.  Say the Arb slews at 1mV/ms.    Say the sample rate is 1KHz +/- 10ms.  That's +/-10 counts.  I'm not there and have no idea what your setup is.  This is why I was suggesting you run the system synchronously to remove these potential problems. 
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #67 on: April 20, 2019, 09:20:44 pm »
I was thinking you are plotting the slope of the change in values, not the values.  If I understand what you are doing (which is a pure guess on my part) then the time the data is sampled will have a dramatic effect on the amplitude, and hence the slope.   So timing is critical as well as the amplitude.
In case of a simple ramp/slow signal a change in time would mean it only goes up/down a bit, it would probably average the slope, but not have the reactive stuff I've got now (I guess).

I think I might have found a problem with the AWG signal.
That would depend.  If the DSO is set to say 1mV / count.  Say the Arb slews at 1mV/ms.    Say the sample rate is 1KHz +/- 10ms.  That's +/-10 counts.  I'm not there and have no idea what your setup is.  This is why I was suggesting you run the system synchronously to remove these potential problems.
But almost the whole trace get the 10 counts, so the slope is not really affected, the absolute values are, but also not that much. Having a simple ramp has it benefits. That’s probably the reason I could not accept the roughness of my slopes.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #68 on: April 20, 2019, 09:37:53 pm »
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. 
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #69 on: April 20, 2019, 09:53:10 pm »
If your scope has a deep enough buffer to capture say 100 cycles of your triangle wave.  You could download that and then split and realign the data in software.  Then run your accumulation and division. 
What you say here is good advice, and is exactly what the scope is doing for me. And the 2,3,4..378th trigger keeps the alignment intact. They call it segmenting mode resulting in frames. Otherwise it would be a great technique to apply by “hand”.
« Last Edit: April 20, 2019, 09:55:36 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #70 on: April 20, 2019, 10:20:53 pm »
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. 
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #71 on: April 20, 2019, 10:39:07 pm »
If there’s any need the resulting frames, can also be aligned by hand  :popcorn:

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

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

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

But what this exercise is about is learning, growing skills and getting some experience in this stuff. So I’m still glad the (single) ramp is a bit forgiving for all sorts of errors. But things that need improving, I’ll improve.
« Last Edit: April 20, 2019, 10:41:15 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #72 on: April 20, 2019, 10:45:09 pm »
My setup is as far as I can see now pretty solid, but I’ve got an AWG that doesn’t create a good ramp.

It's odd to me that your Arb wouldn't far exceed the scopes performance (noise, resolution).   I assume you have it terminated at 50 ohms.  What sort of Arb are you using?
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #73 on: April 20, 2019, 11:04:04 pm »
The Awg seems to have this repeatable glitch.
It is discussed by me at:
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg2356566/#msg2356566

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

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

I’m quite sure it is not ringing or anything analogue. But maybe you’ve got an idea?
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #74 on: April 21, 2019, 12:42:44 am »
The Awg seems to have this repeatable glitch.

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

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

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

****

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

http://www.siglent.com/ENs/prodcut-fj.aspx?id=-1&tid=1&T=1
 
« Last Edit: April 21, 2019, 12:57:52 am by joeqsmith »
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #75 on: April 21, 2019, 01:08:04 am »
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.
« Last Edit: April 21, 2019, 08:02:58 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #76 on: April 21, 2019, 01:24:43 am »
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.
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #77 on: April 21, 2019, 01:31:53 am »
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.
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #78 on: April 21, 2019, 01:45:39 am »
You can set the arb to DC mode and just increment it via scpi, that way you can stair step it vs averaging on a slope.
Exactly what I am asking them to do!  Perhaps you can do a better job explaining this to them. 
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #79 on: April 21, 2019, 01:47:28 am »
I tried to look up the SAG1021 on Amazon and eBay but didn't turn anything up.  I found that part number on Siglent's site and am guessing this is the Arb you are using.   If it is, will it work standalone off a PC with Windows?  Labview interface?   
Here Joe:
https://www.siglentamerica.com/accessory/sag1021/

It's a USB device only and controlled entirely from the scope, be it with the scopes UI or remotely via the scope using SCPI. commands from the EasyWave AWG software.
« Last Edit: April 21, 2019, 01:59:34 am by tautech »
Avid Rabid Hobbyist
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #80 on: April 21, 2019, 01:53:02 am »
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.
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #81 on: April 21, 2019, 03:56:47 am »
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. 
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #82 on: April 21, 2019, 04:39:27 am »
When I go to the documents, download, they don't list this device under the waveform generators.
Yes because they are an accessory to a scope and their usage instruction is part of the scopes User manual.
P194 Arbitrary Waveform Generator(Option)
https://www.siglentamerica.com/wp-content/uploads/dlm_uploads/2017/10/SDS1000X-E_UserManul_UM0101E-E03A-1.pdf

Quote
The arb seems like it may be more difficult to locate a distributor for in the USA. 
Actually no, there are dozens of NA suppliers:
https://www.siglentamerica.com/how-to-buy/

Anyways, thanks Joe for your ideas and help thus far.  :-+
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #83 on: April 21, 2019, 08:49:14 am »
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.
« Last Edit: April 21, 2019, 10:00:20 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #84 on: April 21, 2019, 09:50:35 am »
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.
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #85 on: April 21, 2019, 10:13:03 am »
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.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #86 on: April 21, 2019, 10:19:00 am »
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.
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #87 on: April 21, 2019, 10:25:10 am »
I am not sure what this graph is.  I assumed it was a plot showing the slope computed for each discrete sample for the triangle wave.   I would expect the top and bottom to be flat as the slope over time should never change, not ramping as you show in the previous graph.  If this is what is happening, you have other problems besides the Arb.   Zooming into an area where you are calculating an average of the slope at discrete samples just muddies the waters.   
The slope is not averaged. The values it is calculated with, are.

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

The same problem areas are repeatable..

Also there’s not shit comming in, but highly averaged values. That alone would clear most noise/rounding issues, but not shitty awg signals  :-+ those stand out!
« Last Edit: April 21, 2019, 01:35:09 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #88 on: April 21, 2019, 10:58:43 am »
If you tell me exactly what settings your able to cause the jumps to appear, I can replicate the setup for you. this can give you some cross verification.
That would be great!
Here's the portion of my script that set things up:
Code: [Select]
          <rep:Reporter.Information Text="SDS1104X.IDN"/>
          <Execute Statement="SDS1104X.CommHeader:= THeaderType.Off"/>
          <Execute Statement="SDS1104X.TriggerMode:= TTriggerMode.Normal"/>
          <Execute Statement="SDS1104X.TDiv:= 500*micro"/>
          <Execute Statement="SDS1104X.VDiv[TTraceType.CH1]:= 10 * milli"/>
          <Execute Statement="SDS1104X.VOffset[TTraceType.CH1]:= -435 * milli"/>
          <Execute Statement="SDS1104X.VDiv[TTraceType.CH2]:= 1"/>
          <Execute Statement="SDS1104X.VOffset[TTraceType.CH2]:= -2.5"/>
          <Execute Statement="SDS1104X.MemorySize:= TMemSize.ms70K"/>
          <Execute Statement="SDS1104X.SetTrigger(TTraceType.CH2, 2.5)"/>
          <Execute Statement="SDS1104X.TriggerDelay:= - 0.5 * SDS1104X.TDiv * micro"/>
          <Execute Statement="SDS1104X.SegmentCount:= 378"/>
          <Execute Statement="SDS1104X.SequenceMode:= True"/>
          <Variable Identifier="Freq" Type="Extended" Init="5 * 1 / (SDS1104X.TDiv * 14 * 2 * 1.1)"/>
          <Variable Identifier="AWGCommand" Type="string" Init="Format('C1:BSWV WVTP,RAMP,FRQ,%s,AMP,0.9,OFST,0.353,SYM,50', FloatTocode(Freq))"/>
          <Execute Statement="SDS1104X.RawWrite(AWGCommand)"/>
          <rep:Reporter.Information Text="AWGCommand"/>
          <Execute Statement="AWGCommand:= 'C1:OUTP ON'"/>
          <Execute Statement="SDS1104X.RawWrite(AWGCommand)"/>
          <rep:Reporter.Information Text="AWGCommand"/>
          <Execute Statement="AWGCommand:= 'C1:SYNC ON'"/>
          <Execute Statement="SDS1104X.RawWrite(AWGCommand)"/>
          <rep:Reporter.Information Text="AWGCommand"/>
           <Execute Statement="SDS1104X.Stop"/>
          <Execute Statement="SDS1104X.TriggerMode:= TTriggerMode.Single"/>
So 2 channels, ch1 for signal, ch2 for sync pulse triggering.

TDiv: 500us/div

CH1:
100mV/div
-400 mv offset

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

CH2:
1 V/div
-2.5V offset

Trigger delay (on screen dump): 0.00s

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

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

I'm not sure you can take the same zoom in values.
« Last Edit: April 29, 2019, 11:49:15 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #89 on: April 21, 2019, 01:41:52 pm »
I am not sure what this graph is.  I assumed it was a plot showing the slope computed for each discrete sample for the triangle wave.   I would expect the top and bottom to be flat as the slope over time should never change, not ramping as you show in the previous graph.  If this is what is happening, you have other problems besides the Arb.   Zooming into an area where you are calculating an average of the slope at discrete samples just muddies the waters.   
Maybe you missed the 2nd graph? It is drawn with a thin line to reveal details. But it can more easily be seen if you zoom in on the image. The glitches are easily been seen, even without the slope graph. Maybe that is what made it confusing?
« Last Edit: April 21, 2019, 01:43:44 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #90 on: April 21, 2019, 06:51:50 pm »
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.
« Last Edit: April 21, 2019, 06:54:53 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #91 on: April 21, 2019, 07:08:55 pm »
With 20M bandwidth limiting.

Will check this range with the DC offset wave type of the AWG!
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #92 on: April 21, 2019, 07:30:35 pm »
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.
« Last Edit: April 21, 2019, 07:37:47 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #93 on: April 21, 2019, 08:54:27 pm »
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?
« Last Edit: April 21, 2019, 10:11:53 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #94 on: April 21, 2019, 09:15:11 pm »
However the documentation is sparse / non existing. I know of the wave editor that can be downloaded, but I'd like to create my own binary file. Trust is good control is better.

So does anybody know if there is some documentation on the file format?
Opened EasyWave and then went to Open File, the default format it expects is .csv.
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #95 on: April 21, 2019, 09:21:13 pm »
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?
« Last Edit: April 21, 2019, 09:36:54 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #96 on: April 21, 2019, 09:34:55 pm »
However the documentation is sparse / non existing. I know of the wave editor that can be downloaded, but I'd like to create my own binary file. Trust is good control is better.

So does anybody know if there is some documentation on the file format?
Opened EasyWave and then went to Open File, the default format it expects is .csv.
Thanks for replying, but can a CVS be uploaded also directly to the AWG?

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

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

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

Will be busy for a few days, but will come back to this matter.   
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #97 on: April 21, 2019, 10:24:43 pm »
However the documentation is sparse / non existing. I know of the wave editor that can be downloaded, but I'd like to create my own binary file. Trust is good control is better.

So does anybody know if there is some documentation on the file format?
Opened EasyWave and then went to Open File, the default format it expects is .csv.
Thanks for replying, but can a CVS be uploaded also directly to the AWG?

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

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

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

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

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #98 on: April 21, 2019, 10:42:36 pm »
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.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #99 on: April 21, 2019, 10:58:40 pm »
That would be great if this would lead to a solution. I’m new to AWG’s so I’ve yet to develop a model of how they work.
I’ve got a lot of answers to find. Like will they interpolate values between data samples if the period gets longer. If the outputting “HW engine” can do al that stuff than it would be tempting for a designer to just push samples to it, and not do any sample calculations on the device.
But if it calculates does it need to preprocess in a buffer or can it be done real-time?

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

I hope someone can give some clues on this.
Via the SDS1104X-E web server .BIN is the default data format but for most they need to convert to .CSV using the scopes BIN to CSV conversion utility that you access from the web server. Works well.

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

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #100 on: April 21, 2019, 10:58:58 pm »
They work by directly piping the sample contents into the DAC, its at a fixed 125MHz sampling rate,

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

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

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

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #101 on: April 21, 2019, 11:17:52 pm »
The offset DAC is summed into the output op amp which is on a +-5V supply rail, this is why it tries to restrict you to +-4V, in reality the offset can be much higher if the op amp had a wider supply rail, but with only 5V it gets much less linear and begins clipping at about +-4.35V
I have the AWG on its own power supply, not USB. Would it be safe to give it some more voltage then? (For all the sub circuits?)

So it does have a offset DAC.  :-+

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

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

Some more questions that burn in my mind:
Any idea’s on why I can hear relais clicking? Is the DC mode just using the offset DAC?
« Last Edit: April 21, 2019, 11:21:56 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #102 on: April 21, 2019, 11:27:38 pm »
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
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> ADC inaccuracy?
« Reply #103 on: April 21, 2019, 11:40:05 pm »
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.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Exploring the wavedata
« Reply #104 on: April 27, 2019, 09:43:54 am »
I've started examining the possibilities to create my own wavedata.

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

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

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

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

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

The uploading command for my wave was:
Code: [Select]
C1:WVDT WVNM,Ramp,TYPE,5,LENGTH,32KB,FREQ,324.674987793,AMPL,0.899999976,OFST,0.352999985,PHASE,0.000000000,WAVEDATA,
Where after the WAVEDATA 32KB of wave data is added. The wave data consists of 16 bit liitle-endian signed integers. Little-endian meaning that the least significant part of the integer is in front of the memory.
x86 processors are little endian, so while reading/writing values we shouldn't have any problems.
The full 16 bit range is used while transferring the data so from -32768 to 32767. So it is unscaled data, the scaling is done while "playing" the data. This is what one should expect.
« Last Edit: April 27, 2019, 09:47:55 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Exploring the wavedata
« Reply #105 on: April 27, 2019, 09:59:07 am »
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.
« Last Edit: April 27, 2019, 10:34:55 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Exploring the wavedata
« Reply #106 on: April 27, 2019, 10:34:37 am »
Choosing AMPL and FREQ values which should have no issues using even the most simple "scaling algorithms" would be a good starting point for further testing.
It is also important to know that the 16 bit integers will be scaled by /4 to 14 bit also in the most optimal situation. The question is than also whether this is done in one step or two.


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

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

So I'm guessing it's a timing problem, maybe in combination with rounding errors.
« Last Edit: May 01, 2019, 08:02:33 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #107 on: April 27, 2019, 03:14:15 pm »
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)

« Last Edit: April 27, 2019, 08:00:38 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #108 on: April 27, 2019, 08:34:50 pm »
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

« Last Edit: April 27, 2019, 08:44:29 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #109 on: April 27, 2019, 09:25:27 pm »
The scaling is fixed per attenuator step, so the scaling is indeed digital, likely a hardware multiply / divide in the FPGA,
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #110 on: April 27, 2019, 10:03:39 pm »
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.
« Last Edit: April 27, 2019, 10:08:22 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #111 on: April 27, 2019, 11:14:54 pm »
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.
« Last Edit: April 27, 2019, 11:17:37 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #112 on: April 27, 2019, 11:48:08 pm »
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.
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #113 on: April 28, 2019, 12:03:26 am »
I should point out all the glitches in your output appear periodic, e.g. the last image i can see atleast 5 of them very evenly spaced, It could be a glitch in how samples are scaled, what if you generate a waveform and run it at a frequency that is a perfect division of 125MHz? while still allowing every sample to be used.
The problem is that 125 M is not dividable by 16384. If we took 254,313151041668 hz then each sample would be played about 30 times. I'll try that after searching for the (input!) glitch value(s).

I've got a clear graph of the glitch, but thousands of values are still candidate.... It's a process of trial and error.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #114 on: April 28, 2019, 01:52:41 am »
You have plenty of options than just frequency, you can also set by period, this gives many more cleaner divisions
Left is the period, right is how many times each sample is repeated in that period

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

0.0032768   25
0.0065536   50
0.0098304   75
0.016384   125
0.032768   250
0.049152   375
0.065536   500
0.08192   625
0.098304   750
0.16384   1250
0.24576   1875
0.32768   2500
0.4096   3125
0.49152   3750
0.57344   4375
0.65536   5000
0.73728   5625
0.8192   6250
0.90112   6875
0.98304   7500
1.2288   9375
1.6384   12500
2.048   15625
2.4576   18750
2.8672   21875
3.2768   25000
« Last Edit: April 28, 2019, 02:02:14 am by Rerouter »
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #115 on: April 28, 2019, 08:39:24 am »
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.
« Last Edit: April 28, 2019, 08:49:06 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #116 on: April 28, 2019, 09:57:44 am »
You have plenty of options than just frequency, you can also set by period, this gives many more cleaner divisions
Left is the period, right is how many times each sample is repeated in that period

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

0.0032768   25
Nice table, good thinking to reverse it. I think it works "internally" by frequency, because it does not update the period value in the GUI. But that might just be sloppy programming.
Code: [Select]
C1:BSWV WVTP,ARB,PERI,0.0032768,AMP,1,OFST,0.5
I don't think there're less glitches. There must also be an perfect amplitude, but then we need to know to what output the input values are mapped (step size).
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #117 on: April 28, 2019, 10:08:14 am »
I was suspicious it may be something else internally, as the resulting frequency had more then 7 significant digits after setting the period via SCPI

as per you having a weird step between 2 values, perhaps try setting it to the lower attenuator setting, it may have some correction table inside that will move the quirk
« Last Edit: April 28, 2019, 10:21:26 am by Rerouter »
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #118 on: April 28, 2019, 10:30:36 am »
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?
« Last Edit: April 28, 2019, 10:51:02 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #119 on: April 28, 2019, 10:49:36 am »
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?
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #120 on: April 28, 2019, 11:04:30 am »
Well at a minumum, looks like your the glitch is interesting, 6V pk-pk, it should be a 16 bit DAC, but your offset looks almost exactly like it behaving like a 12 bit, 4096 steps, which comes to about 1.5mV per step,

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

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

 :-//
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #121 on: April 28, 2019, 11:14:08 am »
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.
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #122 on: April 28, 2019, 11:36:50 am »
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?
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #123 on: April 28, 2019, 11:46:34 am »
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.
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #124 on: April 28, 2019, 12:47:03 pm »
For those who would like to test their AWG...

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

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

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

.......

00008050:  68 0A 68 0A 68 0A 68 0A 68 0A 68 0A 68 0A 68 0A  h.h.h.h.h.h.h.h.
00008060:  68 0A 68 0A 68 0A 68 0A 68 0A 68 0A 68 0A 68 0A  h.h.h.h.h.h.h.h.
00008070:  68 0A 68 0A 68 0A 68 0A                          h.h.h.h.
« Last Edit: April 28, 2019, 04:50:02 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #125 on: April 28, 2019, 07:51:29 pm »
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).
« Last Edit: April 28, 2019, 09:53:35 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Exploring the wavedata
« Reply #126 on: April 29, 2019, 11:44:16 am »
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.
« Last Edit: April 29, 2019, 03:05:14 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #127 on: April 29, 2019, 12:17:16 pm »
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.   
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #128 on: April 29, 2019, 12:33:07 pm »
Sorry, I didn't read all your updates but it looks like the Arb is still in question.   When you show these glitches, what is the dv/dt?  I'm not sure when looking at your graphs what the units are.
Hi Joe, the problem with the AWG is that a single step transition from 2663 to 2664 it output drops 2mV instead of rising. I really dislike this, so I’ll be automatically investigating all the glitches on the same ramp to get an idea of what they have in common. So it seems side tracking on a side track. But because the thread is not really about the the diode and resistor divider, but more about using the AWG and DSO as tools to investigate, I’ll keep things bundled here.
I guess I could still use the AWG to do better measurements, because the output affects both curves the same way. Time based averages should then be done over the same time ranges for both curves. (So the glitches are also included in the same averages.)
Also the glitches are 2mV, over a very short period of time, so it affects the slope much more than absolute values. Using function fitting I could for instance work around that.
« Last Edit: April 29, 2019, 11:15:16 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #129 on: April 29, 2019, 10:10:01 pm »
Sorry, I didn't read all your updates but it looks like the Arb is still in question.   When you show these glitches, what is the dv/dt?  I'm not sure when looking at your graphs what the units are.
Hi Joe, the problem with the AWG is the at a single step transition from 2663 to 2664 it output drops 2mV instead of rising. I really dislike this, so I’ll be automatically investigating all the glitches on the same ramp to get an idea of what they have in common. So it seems side tracking on a side track. But because the thread is not really about the the diode and resistor divider, but more about using the AWG and DSO as tools to investigate, I’ll keep things bundled here.
I guess I could still use the AWG to do better measurements, because the output affects both curves the same way. Time based averages should then be done over the same time ranges for both curves. (So the glitches are also included in the same averages.)
Also the glitches are 2mV, over a very short period of time, so it affects the slope much more than absolute values. Using function fitting I could for instance work around that.
I can tell you this is under investigation at the factory for ~1 week now.
Dunno about progress or outcome yet.

Thanks for all your work.  :)
Avid Rabid Hobbyist
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #130 on: April 29, 2019, 10:35:47 pm »
Sorry, I didn't read all your updates but it looks like the Arb is still in question.   When you show these glitches, what is the dv/dt?  I'm not sure when looking at your graphs what the units are.
Hi Joe, the problem with the AWG is the at a single step transition from 2663 to 2664 it output drops 2mV instead of rising. I really dislike this, so I’ll be automatically investigating all the glitches on the same ramp to get an idea of what they have in common. So it seems side tracking on a side track. But because the thread is not really about the the diode and resistor divider, but more about using the AWG and DSO as tools to investigate, I’ll keep things bundled here.
I guess I could still use the AWG to do better measurements, because the output affects both curves the same way. Time based averages should then be done over the same time ranges for both curves. (So the glitches are also included in the same averages.)
Also the glitches are 2mV, over a very short period of time, so it affects the slope much more than absolute values. Using function fitting I could for instance work around that.
I can tell you this is under investigation at the factory for ~1 week now.
Dunno about progress or outcome yet.

Thanks for all your work.  :)
Nice to know it got Siglents attention. I'm glad to help.  When I get my automated testing script done, I'll see if I can get my hands on a second unit/replacement. Maybe the seller I bought it from can make some sort of an arrangement. They're nice affordable devices, so I hope this gets fixed if its structural.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 6558
  • Country: us
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #131 on: April 29, 2019, 11:01:39 pm »
Hi Joe, the problem with the AWG is the at a single step transition from 2663 to 2664 it output drops 2mV instead of rising.

Wow!  Say no more. 
How electrically robust is your meter?? https://www.youtube.com/channel/UCsK99WXk9VhcghnAauTBsbg
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #132 on: May 01, 2019, 10:16:49 am »
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.



“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #133 on: May 01, 2019, 10:33:52 am »
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.
« Last Edit: May 01, 2019, 10:37:11 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #134 on: May 01, 2019, 11:22:33 am »
With a amplitude of 1V the following values show a glitch when succeding to the next one. Notice the 2663 :-+
Code: [Select]
-32301
-21373
-14817
-03893
 02663
 13591
 20147
 31075
The full dataset cannot be shown in a graph using Excel and Visio, but what also can be seen is that the other negative spikes become less around 0 and then become positive spikes.

“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #135 on: May 01, 2019, 11:35:57 am »
For the positive values and their succeeding ones I did a quick decimal to binary conversion.
It does not show anything obvious. But there's scaling done before it enters the DAC, so I did not really expect to see something in the bits. With this script however I can do a higher amplitude as well!! That'll be next. (It would be nice to have no scaling (or a magnitude of 2), but I don't thing it's as simple as using the highest value).
Code: [Select]
02663-000101001100111-000101001101000
13591-011010100010111-011010100011000
20147-100111010110011-100111010110100
31075-111100101100011-111100101100100
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #136 on: May 01, 2019, 11:46:12 am »
These are the leaps to the next glitch:
Code: [Select]
-32301 10928
-21373 6556
-14817 10924
-3893 6556
2663 10928
13591 6556
20147 10928
31075
Something repeating can be seen. Which could maybe give us some clue!
« Last Edit: May 01, 2019, 11:48:16 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #137 on: May 01, 2019, 12:15:31 pm »
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.

 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #138 on: May 01, 2019, 12:48:00 pm »
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.  |O

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.
« Last Edit: May 01, 2019, 04:25:44 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #139 on: May 01, 2019, 01:05:11 pm »
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
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #140 on: May 01, 2019, 02:19:13 pm »
At the higher amplitude, can you describe what about it is behaving weird? I'm curious what the min and max output range you are seeing is, It would be interesting if it was using both dac's to hybridise the output. or even if the output span was higher than 6V pk-pk

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

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

The glitches where however in a non arbitrary wave as well. So this does not need to be related.
« Last Edit: May 01, 2019, 02:25:10 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #141 on: May 01, 2019, 02:24:06 pm »
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...
« Last Edit: May 01, 2019, 07:38:55 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #142 on: May 01, 2019, 02:27:27 pm »
Just nice to know, how does the AWG's amplitude (6V pk-pk) go above the 5V usb connection? A boost converter?
« Last Edit: May 01, 2019, 02:29:23 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #143 on: May 01, 2019, 04:53:57 pm »
It would be interesting if it was using both dac's to hybridise the output. or even if the output span was higher than 6V pk-pk
The easy wave app, does make such choices. To move a static bottom of a curve to a wave offset.
But that’s off course for the whole wave.
Just nice to know, how does the AWG's amplitude (6V pk-pk) go above the 5V usb connection? A boost converter?

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

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

You’ve seen the internals, any ideas on what DAC’s are used?
« Last Edit: May 01, 2019, 07:47:50 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #144 on: May 01, 2019, 09:00:45 pm »
Main sample DAC: http://www.ti.com/jp/lit/ds/symlink/dac904.pdf
Offset DAC (I think): http://www.ti.com/lit/ds/symlink/dac8580.pdf
Output Amplifier: https://www.renesas.com/sg/en/www/doc/datasheet/el5166-67.pdf

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

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

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #145 on: May 01, 2019, 11:04:23 pm »
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".

« Last Edit: May 01, 2019, 11:06:49 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #146 on: May 01, 2019, 11:28:50 pm »
Main sample DAC: http://www.ti.com/jp/lit/ds/symlink/dac904.pdf
In the typical INL graph it shows -4 SLBs, which to my understanding would mean 4 x the step value. (I find that quite high)
That would in optimal scaling be: 6V / Power(2,14) * 4 = 1.4mV.
Could this be the cause of the glitches? But I would then expect a (short) drop until succeeding to other higher values in a ramp, not a continued drop for a whole range of values.
Also according to the definition of INL, all those values in such a range should than have a high INL. As can be seen in the graph, that’s not typical.
« Last Edit: May 02, 2019, 12:14:36 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #147 on: May 02, 2019, 09:46:10 am »
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".
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 18440
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #148 on: May 02, 2019, 09:49:56 am »
Here's some more information on offscreen voltages.

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

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



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

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #149 on: May 02, 2019, 10:01:13 am »
I suspect its gain stage saturation, as things are charged above the specified input range it takes some time to bleed off the parasitic capacitances in the amplifier

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

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

Pretty sure the ADC has a 200mV input range.
« Last Edit: May 02, 2019, 10:13:24 am by Rerouter »
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #150 on: May 02, 2019, 10:27:17 am »
Here's some more information on offscreen voltages.

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

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



Exceeds the channel voltage offset range as listed in the datasheet, that's all you're seeing.
There’s more to it. I will do some test to show how much offscreen voltage is allowed, without getting the measurements wrong. To agagerate:
If we had a -1V to 10V square wave, there will probably be troubles zooming in (100mV/div) on the -1V bottom,  which is within offset range. I hope my AWG support the ranges needed to get an idea of the effects. I’m working on it.
« Last Edit: May 02, 2019, 10:34:33 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #151 on: May 02, 2019, 10:31:08 am »
I suspect its gain stage saturation, as things are charged above the specified input range it takes some time to bleed off the parasitic capacitances in the amplifier

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

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

Pretty sure the ADC has a 200mV input range.
Nice info!

The practical consequences I will try to measure. As said before, I think it had its influence without me knowing about it.
« Last Edit: May 02, 2019, 10:35:38 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #152 on: May 02, 2019, 11:21:28 am »
I measured the following waves:
Code: [Select]
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.60000000000000013,OFST,0.30000000000000006,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.7,OFST,0.35,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.8,OFST,0.4,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1,OFST,0.5,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.2000000000000002,OFST,0.60000000000000013,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.3999999999999998,OFST,0.7,DUTY,50
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.6,OFST,0.8,DUTY,50
The bottoms should all be at the V-centre, but when having more voltage offscreen, the center voltage "rises". This happens with even small voltages like 300mv. 3 times the V/div. Because there is almost 1 division of digital margin offscreen it is almost nothing beyond that.
Maybe I made a mistake, so I posted the AWG commands.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #153 on: May 02, 2019, 11:27:12 am »
Different duty:
Code: [Select]
Siglent Technologies,SDS1204X-E,SDSMMDBQ2R3764,8.1.6.1.26
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.60000000000000013,OFST,0.30000000000000006,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.7,OFST,0.35,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,0.8,OFST,0.4,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1,OFST,0.5,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.2000000000000002,OFST,0.60000000000000013,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.3999999999999998,OFST,0.7,DUTY,1
C1:BSWV WVTP,SQUARE,FRQ,500,AMP,1.6,OFST,0.8,DUTY,1
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #154 on: May 02, 2019, 11:42:10 am »
As can be seen, even small pulses (1%)  affect the quality of the signal and a non existing rise of voltage.

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

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

But I don’t think with my/this scope one can say that there’re multiple screens of headroom.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #155 on: May 02, 2019, 11:48:46 am »
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,
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #156 on: May 02, 2019, 12:05:03 pm »
Its not always 1 division off screen, its more like 0.5, its mainly to eat up the steps between VGA codes to allow for ideal scaling, the measure UI gives a good idea of where this limit is, as it just works off the raw data points,

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

I suspect this protection is after the VGA, as there is no idiot proof way that it could not be set to a bad code and send a volt into the ADC,
To my understanding 200 steps of the ADC are on screen, the other 56 steps are off. That’s why I thought there’s one division of digital headroom, below and above.
I don’t know how to compare the found analog headroom to other scopes, but reading the stackexchange answer, I’m a bit surprised that is so low.

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

My technique of creating signal samples is then also too disruptive, will use a calculated (time) range instead. But will first check how accurate that will be.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #157 on: May 02, 2019, 01:59:20 pm »
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.
« Last Edit: May 02, 2019, 02:35:57 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline genghisnico13

  • Regular Contributor
  • *
  • Posts: 54
  • Country: cl
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #158 on: May 02, 2019, 03:09:16 pm »
I recently replicated some of rigol's comparisons about overload recovery in a RTB2000 https://www.eevblog.com/forum/testgear/rigols-view-on-rtb2000/msg2378664/#msg2378664.
As you can see the signal gets distorted for 1-2ms after coming back to the screen, this distortion started to appear at 50mV/Div when the signal goes above +2.2V.
 
The following users thanked this post: HendriXML

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #159 on: May 02, 2019, 03:52:30 pm »
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.
« Last Edit: May 02, 2019, 06:22:37 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #160 on: May 02, 2019, 09:50:32 pm »
From Rerouter, I got to understand the AWG also has amplitude ranges (attenuator). From changing some values and hearing the relais clicking I know their max values are:
A: 63mV >= Ampl  < 64 mV
B: 632mV >= Ampl  < 633 mV
C: 6V >= Ampl  < ??

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

It does not need to be this way, but sometimes verifying one value is easier than getting the right one. So I post it here as a reminder.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #161 on: May 03, 2019, 12:49:46 am »
I'm trying to restrict the number of samples via the SCPI command WAVEFORM_SETUP / WFSU in the form:
WFSU SP,0,NP,1024

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

Am I missing something?
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #162 on: May 03, 2019, 10:54:03 am »
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)
« Last Edit: May 03, 2019, 11:07:45 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #163 on: May 03, 2019, 11:54:39 am »
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!
« Last Edit: May 03, 2019, 12:01:02 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #164 on: May 03, 2019, 12:12:38 pm »
If I setup a wave, with an offset of 0 via SCPI cmd:
Code: [Select]
C1:BSWV WVTP,ARB,FRQ,300,AMP,1.3,OFST,0

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

What could be a valid reason for that? Now the signal is still off!!
« Last Edit: May 03, 2019, 12:19:34 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #165 on: May 03, 2019, 01:53:18 pm »
So the DSO value ranges cannot be accurately “predicted” because of the very high offset. But it can be determined by searching for the highest and lowest value. And than determining:
Offset = (High + Low) / 2
Amplitude = High - Low

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

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

Start would be: MinSampleValue > 0.95 * 0.5 * Amplitude + Offset
High would be: (MinSampleValue > 0.45 * 0.5 * Amplitude + Offset) and (MaxSampleValue < 0.55 * 0.5 * Amplitude + Offset)
Low would be: (MinSampleValue  > -0.55 * 0.5 * Amplitude + Offset) and (MaxSampleValue  < -0.45 * 0.5 * Amplitude + Offset)
End would be: MaxSampleValue < -0.95 * 0.5 * Amplitude + Offset
« Last Edit: May 03, 2019, 09:29:56 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #166 on: May 03, 2019, 08:09:37 pm »
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
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #167 on: May 03, 2019, 08:40:56 pm »
I think the scpi offset does not have the awg offset applied to it. I will have a look today if there is any easy way to read that offset via command
If you can find it, great!

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

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

“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #168 on: May 03, 2019, 10:13:54 pm »
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.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #169 on: May 03, 2019, 10:35:43 pm »
Because it may be so that the AWG has scaling problems, which will be further tested, it might be informative to show how I calculated the range values without using floating point calculations, but with proper rounding. (It know it rounds a 1/2 down, but technically it is just as close to the below and above value, so I don't mind)
It's about moving divides to a single one and adding half of the divider before doing so.
Code: [Select]
            <Variable Identifier="SummedOffsetX2X100" Type="Int32" Init="(HighestValue + LowestValue) * 100"/>
            <Variable Identifier="SummedAmplitude" Type="Int32" Init="(HighestValue - LowestValue)"/>
            <Variable Identifier="Divider" Type="Int32" Init="100 * 2 * Count"/>
            <Variable Identifier="HalfXDivider" Type="Int32" Init="Divider div 2"/>
            <Execute Statement="StartRangeLow:= (95 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>
            <Execute Statement="HighRangeHigh:= (55 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>
            <Execute Statement="HighRangeLow:= (45 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>
            <Execute Statement="LowRangeHigh:= (-45 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>
            <Execute Statement="LowRangeLow:= (-55 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>
            <Execute Statement="EndRangeHigh:= (-95 * SummedAmplitude + SummedOffsetX2X100 + HalfXDivider) div Divider"/>
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #170 on: May 03, 2019, 10:49:09 pm »
The waveform setup only applies when you use "<trace>:WF? ALL" for what ever reason its ignored for "<trace>:WF? DAT2"

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

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

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

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

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #171 on: May 03, 2019, 11:27:46 pm »
The waveform setup only applies when you use "<trace>:WF? ALL" for what ever reason its ignored for "<trace>:WF? DAT2"
That’s good to know. Maybe it is also possible to grab one at a time segment/frame this way. I guess segment and frame are the same thing. This would be a step more robust then changing the active frame.
Using ALL I’ll need to do some more parsing. It would be nice if the documentation was better in this regard.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #172 on: May 03, 2019, 11:36:16 pm »
I can share what I have documented, but its mainly lifted from other manuals

Code: [Select]
:WaveForm | :WF
Query Syntax

<channel>:WaveForm?

Description

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

Parameter

Name

Type

Range

Default

 
<channel>

Discrete

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

 
Query Example

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

Code: [Select]
WaveForm_SetUp | WFSU
Command Syntax

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

Query Syntax

WaveForm_SetUp?

Description

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

Parameter

Name

Type

Range

Default

 
<first point>

Numeric

First Data Point

 
 
<num of points>

Numeric

0 is all, above is maximum amount of points

 
 
<spacing>

Numeric

0:1 is all, above sends only Nth point

 
Command Example

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

Query Example

WFSU?    /* */
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #173 on: May 03, 2019, 11:40:02 pm »

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

For this, I won’t use UI automation. These things can easily go wrong, if the UI is in a unexpected state, or something in it has changed. Also the offset I need cannot be created with the automatic zero function. Waves need a different offset value (a lot higher).
PS
I did test the BSWV? before, but there was no offset in it.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #174 on: May 03, 2019, 11:45:47 pm »
I can share what I have documented, but its mainly lifted from other manuals
I’m shopping out of other manuals too, thanks to Google. But a descent description of the returning data I’ve not yet seen. These things I don’t get. If one implements this stuff, it needs documentation as well, why not share it? That’s what you’re supposed to do with interfaces...
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #175 on: May 03, 2019, 11:47:09 pm »
There are also 3 related commands if you wish to navigate frames.

FPAR Frame_PARam
FRAM FRAMe_set
FTIM Frame_TIMe

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

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

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #176 on: May 03, 2019, 11:50:58 pm »
There are also 3 related commands if you wish to navigate frames.

FPAR Frame_PARam
FRAM FRAMe_set
FTIM Frame_TIMe

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

As to your last reply, the "default" key puts the scope in a known menu state and you can update that default to whatever settings you wish, for me it puts it on utility menu page 1, but I have edited it from the original so less clear what it was (now wondering if I can use it to jump to hidden menus)
That what i use now. But I like my commands to be as independent of the UI state as possible.
That’s just a habbit. Writing multi user / multi threaded stuff requires taking that into account.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #177 on: May 03, 2019, 11:58:01 pm »
Img..
I think it show it it the DC mode, but not wave. But that can still be handy!
Parsing the answer shouldn’t be to hard.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #178 on: May 04, 2019, 12:03:42 am »
these help?
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #179 on: May 04, 2019, 12:06:47 am »
these help?
If that’s not an offset on top of the zero adjustment offset, then it response depends on the route to this query.  :-//
« Last Edit: May 04, 2019, 12:09:25 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #180 on: May 04, 2019, 12:11:43 am »
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,
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #181 on: May 04, 2019, 12:21:57 am »
Like I said, the auto-zero offset does not get corrected for, so you will likely have to include it in your routine, and offset all values by that amount,
So that is the route dependency...(?)
But in my modded setup  it’s is only 1mV, and I want the 56mV of the needed wave offset in it. But using waves, that gets thrown out again by undoing it.
I could put 56mV in my scripts, but it would much nicer if it’s value was maintained, stored and accessible in the device.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #182 on: May 04, 2019, 12:32:01 am »
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
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #183 on: May 04, 2019, 12:45:56 am »
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...
« Last Edit: May 04, 2019, 01:05:52 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #184 on: May 04, 2019, 01:15:04 am »
"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
« Last Edit: May 04, 2019, 01:19:57 am by Rerouter »
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #185 on: May 04, 2019, 01:37:52 am »
"SHELLCMD reboot" is a start, if your better at linux than me, you may have ideas for what else could be done to implement what your after
For another device I followed this guide:
Support restart/shutdown through OctoPrint's system menu
In Settings > Commands, configure the following commands:
Restart OctoPrint: sudo service octoprint restart
Restart system: sudo shutdown -r now
Shutdown system: sudo shutdown -h now
 Note
If you disabled Raspbian's default behaviour of allowing the pi user passwordless sudo for every command, you'll need to explicitly allow the pi user passwordless sudo access to the /sbin/shutdown program for the above to work. You'll have to add a sudo rule by creating a file /etc/sudoers.d/octoprint-shutdown (as root) with the following contents:
pi ALL=NOPASSWD: /sbin/shutdown
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #186 on: May 04, 2019, 01:41:06 am »
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.
« Last Edit: May 04, 2019, 01:43:17 am by Rerouter »
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #187 on: May 04, 2019, 08:54:40 pm »
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.
« Last Edit: May 04, 2019, 09:03:45 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #188 on: May 04, 2019, 09:17:40 pm »
It is still running but as can seen below it is very repetitive (Next glitch dist is 3384 or 2028).

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

The next test I will try to run at 632mV. Which might be without being mathematically scaled. But that give's very small steps and thus maybe hard to measure. (Are the glitches even a multitude of the step size?)
« Last Edit: May 04, 2019, 09:26:40 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #189 on: May 04, 2019, 10:14:19 pm »
The more accurate values, where the relais clicks to switch to a different AWG ampl. attenuation are:
Code: [Select]
00.632424378781
0.063242837

Almost a factor 10...
« Last Edit: May 04, 2019, 10:43:21 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #190 on: May 04, 2019, 10:41:23 pm »
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!
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #191 on: May 04, 2019, 11:55:41 pm »
It's glitching at the same input values... (these are almost the full lists, the same stuff continues )

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

632.424378781 mVpp
Code: [Select]
InputValue Difference Next glitch dist
-31645 -0,00015 3384
-28261 -0,00014 2028
-26233 -0,00017 3384
-22849 -0,00013 2028
-20821 -0,00017 3384
-17437 -0,00013 2028
-15409 -0,00018 3384
-12025 -0,00013 2028
-9997 -0,00016 3384
-6613 -0,00014 2028
-4585 -0,00017 3384
-1201 -0,00016 2028
827 -0,00027 3384
4211 -0,00012 2028
6239 -0,00017 3384
9623 -0,00016 2028
11651 -0,00016 3384
15035 -0,00013 2028
17063 -0,00017
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #192 on: May 05, 2019, 12:07:40 am »
The question that might need answering is what is so special about going from 827 to 828. That glitch is both times relevantly lower (thus more glitchy) and is closest to 0.
Will do more of these experiments, to find out which factors change the outcome.
Code: [Select]
827=1100111011
828=1100111100

4211=1000001110011
4212=1000001110100

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

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

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

« Last Edit: May 05, 2019, 07:50:10 am by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #193 on: May 05, 2019, 09:43:42 am »
Binary conversion of the transition values
Code: [Select]
-31645/-31644
1000010001100011
1000010001100100

-28261/-28260
1001000110011011
1001000110011100

-26233/-26232
1001100110000111
1001100110001000

-22849/-22848
1010011010111111
1010011011000000

-20821/-20820
1010111010101011
1010111010101100

-17437/-17436
1011101111100011
1011101111100100

-15409/-15408
1100001111001111
1100001111010000

-12025/-12024
1101000100000111
1101000100001000

-9997/-9996
1101100011110011
1101100011110100

-6613/-6612
1110011000101011
1110011000101100

-4585/-4584
1110111000010111
1110111000011000

-1201/-1200
1111101101001111
1111101101010000

827/828
0000001100111011
0000001100111100

4211/4212
0001000001110011
0001000001110100

6239/6240
0001100001011111
0001100001100000

9623/9624
0010010110010111
0010010110011000

11651/11652
0010110110000011
0010110110000100

15035/15036
0011101010111011
0011101010111100

17063/17064
0100001010100111
0100001010101000

20447/20448
0100111111011111
0100111111100000

22475/22476
0101011111001011
0101011111001100

25859/25860
0110010100000011
0110010100000100

27887/27888
0110110011101111
0110110011110000

31271/31272
0111101000100111
0111101000101000
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #194 on: May 05, 2019, 10:11:32 am »
All the glitches (24x!) sum up to a total drop of -31mV (not very precise)
The extra offset I need to have the measurements in center is: 43mV

What if they are caused by the same error?

I haven't seen issues with the amplitude, though. So it is not as simple as that lower values output to high and that at the glitches it drops more to the expected output. If that was the case, the top of the amplitude wouldn't be raised as well.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #195 on: May 05, 2019, 10:57:07 am »
Binary conversion of the transition values
Code: [Select]
-31645/-31644
1000010001100011
1000010001100100

-28261/-28260
1001000110011011
1001000110011100

-26233/-26232
1001100110000111
1001100110001000

-22849/-22848
1010011010111111
1010011011000000

-20821/-20820
1010111010101011
1010111010101100

-17437/-17436
1011101111100011
1011101111100100

-15409/-15408
1100001111001111
1100001111010000

-12025/-12024
1101000100000111
1101000100001000

-9997/-9996
1101100011110011
1101100011110100

-6613/-6612
1110011000101011
1110011000101100

-4585/-4584
1110111000010111
1110111000011000

-1201/-1200
1111101101001111
1111101101010000

827/828
0000001100111011
0000001100111100

4211/4212
0001000001110011
0001000001110100

6239/6240
0001100001011111
0001100001100000

9623/9624
0010010110010111
0010010110011000

11651/11652
0010110110000011
0010110110000100

15035/15036
0011101010111011
0011101010111100

17063/17064
0100001010100111
0100001010101000

20447/20448
0100111111011111
0100111111100000

22475/22476
0101011111001011
0101011111001100

25859/25860
0110010100000011
0110010100000100

27887/27888
0110110011101111
0110110011110000

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

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

Also why do they glitch at the same input values? Only one of the amplitudes was chosen with great accuracy. So the scaling should not be the same.
Edit - correction: most of the scaling is done by a VGA (Variable Gain Amplifier). So it is very likely that if there's even scaling involved, that it is the same for the tested amplitudes.
That brings us also to following the question: if it is a calculation/rounding error, what needs to be calculated?
« Last Edit: May 05, 2019, 01:00:57 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #196 on: May 05, 2019, 11:15:52 am »
You can probe the pins on the DAC to see what is going on, it looks like there all in a row, If you have an example waveform of it just jumping between 2 values, and the SCPI commands (the actual ones, not the psudocode out of your program) I can see what is happening, as mine is currently pulled down

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

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #197 on: May 05, 2019, 11:46:07 am »
You can probe the pins on the DAC to see what is going on, it looks like there all in a row, If you have an example waveform of it just jumping between 2 values, and the SCPI commands (the actual ones, not the psudocode out of your program) I can see what is happening, as mine is currently pulled down

Equally if you had a USB analyser, the 4 pin header directly next to the USB port is all the USB pins
I might need to claim warranty on the device, so I keep it closed.

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

https://www.eevblog.com/forum/testgear/using-a-awg-and-a-scope-do-a-low-voltage-level-characterization-of-a-1n4005/msg2374044/#msg2374044
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #198 on: May 05, 2019, 11:51:33 am »
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?
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #199 on: May 05, 2019, 11:55:43 am »
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.
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #200 on: May 05, 2019, 12:06:24 pm »
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..
« Last Edit: May 05, 2019, 12:08:04 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #201 on: May 05, 2019, 12:10:59 pm »
Code: [Select]
InputValue Sum OutputValue SucceedingOutputValue Difference ValueDiff
-31645 -320143 -1,26E+00 -1,26E+00 -1,13E-03 3384
-28261 -532581 -1,12E+00 -1,12E+00 -1,25E-03 2028
-26233 -442748 -1,04E+00 -1,04E+00 -1,33E-03 3384
-22849 313497 -9,01E-01 -9,02E-01 -1,14E-03 2028
-20821 388458 -8,18E-01 -8,20E-01 -1,46E-03 3384
-17437 171607 -6,79E-01 -6,80E-01 -1,20E-03 2028
-15409 224395 -5,96E-01 -5,97E-01 -1,43E-03 3384
-12025 28208 -4,57E-01 -4,58E-01 -1,20E-03 2028
-9997 65218 -3,75E-01 -3,76E-01 -1,10E-03

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

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

That's probably where this comes in play as mentioned before: VGA (Variable Gain Amplifier).
« Last Edit: May 05, 2019, 12:19:46 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #202 on: May 05, 2019, 12:14:35 pm »
If you have the bin file, likley going to be much easier to just load via USB
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #203 on: May 05, 2019, 12:43:17 pm »
If you have the bin file, likley going to be much easier to just load via USB
Is not a doc, but a bin file  :-+

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

(it took some while, had to create and test one)
« Last Edit: May 05, 2019, 01:13:29 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline Rerouter

  • Super Contributor
  • ***
  • Posts: 4618
  • Country: au
  • Question Everything... Except This Statement
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #204 on: May 05, 2019, 01:39:59 pm »
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.
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #205 on: May 05, 2019, 02:47:19 pm »
Did some amplitude testing, the same 827 glitch can be seen until the amplitude of 1.99991, at 1.99990 it disappears.
At 1.99990 the average value is 80.3 mV
At 1.99991 the average value is 52.1 mV
The very small positive change in amplitude gives a glitch and a drop of 29.2 mV
I don't hear any relais clicking. This might be another useful peace of information.
I will now extract all the glitches at 1.9V and see at what values they're shown.
« Last Edit: May 05, 2019, 03:48:18 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline tinhead

  • Super Contributor
  • ***
  • Posts: 1921
  • Country: 00
    • If you like my hacks, send me a donation
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #206 on: May 05, 2019, 05:12:51 pm »
I might need to claim warranty on the device, so I keep it closed.

i think this is the major problem, you device is bit wired from beginning, you should replace it and continue AWG work after that
I don't want to be human! I want to see gamma rays, I want to hear X-rays, and I want to smell dark matter ...
I want to reach out with something other than these prehensile paws and feel the solar wind of a supernova flowing over me.
 

Offline HendriXML

  • Frequent Contributor
  • **
  • Posts: 719
  • Country: nl
    • KiCad-BOM-reporter
Re: Using a AWG and a Scope -> Automated exploring the wavedata
« Reply #207 on: May 05, 2019, 05:40:21 pm »
So at 1.99990V the other know glitch values come to live.
These are only 8 values
Code: [Select]
-32301 142770 -1,67E-03 10928
-21373 173773 -1,35E-03 6556
-14817 269850 -1,63E-03 10924
-3893 200975 -1,56E-03 6556
2663 -476178 -2,69E-03 10928
13591 246249 -1,28E-03 6556
20147 -407143 -1,75E-03 10928
31075 245817 -1,51E-03

Bits and stuff
Code: [Select]
-32301/-32300
1000000111010011
1000000111010100

-21373/-21372
1010110010000011
1010110010000100

-14817/-14816
1100011000011111
1100011000100000

-3893/-3892
1111000011001011
1111000011001100

2663/2664
0000101001100111
0000101001101000

13591/13592
0011010100010111
0011010100011000

20147/20148
0100111010110011
0100111010110100

31075/31076
0111100101100011
0111100101100100
« Last Edit: May 05, 2019, 06:29:39 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline