-
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). -
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.
-
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.
-
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. -
I can tell you this is under investigation at the factory for ~1 week now.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.
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 can tell you this is under investigation at the factory for ~1 week now.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.
Dunno about progress or outcome yet.
Thanks for all your work. -
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. -
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.
-
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.
-
With a amplitude of 1V the following values show a glitch when succeding to the next one. Notice the 2663
Code: [Select]-32301The 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.
-21373
-14817
-03893
02663
13591
20147
31075
-
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 -
These are the leaps to the next glitch:Code: [Select]
-32301 10928Something repeating can be seen. Which could maybe give us some clue!
-21373 6556
-14817 10924
-3893 6556
2663 10928
13591 6556
20147 10928
31075
-
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.
-
Doing the higher amplitude values I get issues and also get a pretty good idea about what should be solved first!
The waves I feed, are 16 bit. Just like the EasyWave app made them. (Here lies the danger of not having any documentation!) So I thought they would be scaled to 14 bit.
But I think it should be 14 bit values to begin with.
I'll start testing right away!
Edit..
Nope, the above seems not be the case, wishful thinking. It still seems to need 16 bits. But the higher amplitude acts really strange. I need to investigate that. -
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
-
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.
-
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...
-
Just nice to know, how does the AWG's amplitude (6V pk-pk) go above the 5V usb connection? A boost converter?
-
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? -
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 -
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".
-
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. -
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".
-
Here's some more information on offscreen voltages.
This:
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".
Exceeds the channel voltage offset range as listed in the datasheet, that's all you're seeing. -
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.