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

[Rerouter]

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

FPAR Frame_PARam
FRAM FRAMe_set
FTIM Frame_TIMe

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

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

[HendriXML]

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

FPAR Frame_PARam
FRAM FRAMe_set
FTIM Frame_TIMe

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

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

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

[HendriXML]

Img..

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

[Rerouter]

these help?

[HendriXML]

these help?

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

[Rerouter]

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

[HendriXML]

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

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

[Rerouter]

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

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

[HendriXML]

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

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

[Rerouter]

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

[HendriXML]

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

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

[Rerouter]

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

[HendriXML]

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

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

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

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

[HendriXML]

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

Code: [Select]

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

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

[HendriXML]

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

Code: [Select]

00.632424378781
0.063242837

Almost a factor 10...

[HendriXML]

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

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

[HendriXML]

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

3000mVpp

Code: [Select]

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

632.424378781 mVpp

Code: [Select]

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


[HendriXML]

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

Code: [Select]

827=1100111011
828=1100111100

4211=1000001110011
4212=1000001110100

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

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

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

[HendriXML]

Binary conversion of the transition values

Code: [Select]

-31645/-31644
1000010001100011
1000010001100100

-28261/-28260
1001000110011011
1001000110011100

-26233/-26232
1001100110000111
1001100110001000

-22849/-22848
1010011010111111
1010011011000000

-20821/-20820
1010111010101011
1010111010101100

-17437/-17436
1011101111100011
1011101111100100

-15409/-15408
1100001111001111
1100001111010000

-12025/-12024
1101000100000111
1101000100001000

-9997/-9996
1101100011110011
1101100011110100

-6613/-6612
1110011000101011
1110011000101100

-4585/-4584
1110111000010111
1110111000011000

-1201/-1200
1111101101001111
1111101101010000

827/828
0000001100111011
0000001100111100

4211/4212
0001000001110011
0001000001110100

6239/6240
0001100001011111
0001100001100000

9623/9624
0010010110010111
0010010110011000

11651/11652
0010110110000011
0010110110000100

15035/15036
0011101010111011
0011101010111100

17063/17064
0100001010100111
0100001010101000

20447/20448
0100111111011111
0100111111100000

22475/22476
0101011111001011
0101011111001100

25859/25860
0110010100000011
0110010100000100

27887/27888
0110110011101111
0110110011110000

31271/31272
0111101000100111
0111101000101000


[HendriXML]

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

What if they are caused by the same error?

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

[HendriXML]

Binary conversion of the transition values

Code: [Select]

-31645/-31644
1000010001100011
1000010001100100

-28261/-28260
1001000110011011
1001000110011100

-26233/-26232
1001100110000111
1001100110001000

-22849/-22848
1010011010111111
1010011011000000

-20821/-20820
1010111010101011
1010111010101100

-17437/-17436
1011101111100011
1011101111100100

-15409/-15408
1100001111001111
1100001111010000

-12025/-12024
1101000100000111
1101000100001000

-9997/-9996
1101100011110011
1101100011110100

-6613/-6612
1110011000101011
1110011000101100

-4585/-4584
1110111000010111
1110111000011000

-1201/-1200
1111101101001111
1111101101010000

827/828
0000001100111011
0000001100111100

4211/4212
0001000001110011
0001000001110100

6239/6240
0001100001011111
0001100001100000

9623/9624
0010010110010111
0010010110011000

11651/11652
0010110110000011
0010110110000100

15035/15036
0011101010111011
0011101010111100

17063/17064
0100001010100111
0100001010101000

20447/20448
0100111111011111
0100111111100000

22475/22476
0101011111001011
0101011111001100

25859/25860
0110010100000011
0110010100000100

27887/27888
0110110011101111
0110110011110000

31271/31272
0111101000100111
0111101000101000


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

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

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

[Rerouter]

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

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

[HendriXML]

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

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

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

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

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

[HendriXML]

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

[Rerouter]

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