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

0 Members and 1 Guest are viewing this topic.

Offline HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
For each input value that glitches it is now almost certain to say what bits are overflowed to a new active more significant bit.

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

It's also hard to tell how the AWG calculates the DAC input value. Does it first do a 16 to 14 bit conversion, or at the end? Or combined with the divider (*4)? The latter would be best, but I don't think it does. Also the offset, is that done before scaling or after?
Code: [Select]
Offset: 832, Factor: 12213, Divider: 10757
1111111111101101111111110 1111111111101101111111111 0
1111111111101111011111111 1111111111101111100000000 8
1111111111101111110111111 1111111111101111111000000 6
1111111111110000111111111 1111111111110001000000000 9
1111111111110010110111111 1111111111110010111000000 6
1111111111110011111111111 1111111111110100000000000 11
1111111111110101110111111 1111111111110101111000000 6
1111111111110110111111111 1111111111110111000000000 9
1111111111111000110111111 1111111111111000111000000 6
1111111111111001100111111 1111111111111001101000000 6
1111111111111001111111111 1111111111111010000000000 10
1111111111111011100000000 1111111111111011100000001 0
1111111111111011110111111 1111111111111011111000000 6
1111111111111100111111111 1111111111111101000000000 9
1111111111111101010111111 1111111111111101011000000 6
1111111111111110111000000 1111111111111110111000001 0
1111111111111111001111111 1111111111111111010000000 7
1111111111111111111111111 0000000000000000000000000 32
0000000000000001110111111 0000000000000001111000000 6
0000000000000010111111110 0000000000000010111111111 0
0000000000000100110111111 0000000000000100111000000 6
0000000000000101001111111 0000000000000101010000000 7
0000000000000101111111111 0000000000000110000000000 10
0000000000000111011111111 0000000000000111100000000 8
0000000000000111110111111 0000000000000111111000000 6
0000000000001000111111111 0000000000001001000000000 9
0000000000001010110111111 0000000000001010111000000 6
0000000000001011111111111 0000000000001100000000000 11
0000000000001101110111111 0000000000001101111000000 6
0000000000001110111111111 0000000000001111000000000 9
0000000000010000110111111 0000000000010000111000000 6\
« Last Edit: May 12, 2019, 12:33:23 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 HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
The previous table had a Divider larger than the Factor. That will not be the case in practice, so I ran the simulation taking care of that.

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

High significant bits toggling are probably responsible for the glitches. Now that I think about it, that only makes sense, but how much would be acceptable?
When is a DAC a rotten apple regarding this? For that we could take the datasheet of the DAC, but first I'll summarize stuff and make a new drawing.
Code: [Select]
Offset: 831, Factor: 1065, Divider: 1407
Value          Next value    Bit cnt Significant bit
10011111111111 10100000000000 11 12
10100111111111 10101000000000 9 10
10101001111111 10101010000000 7 8
10101111111111 10110000000000 10 11
10110110000000 10110110000001 0 8
10111001111111 10111010000000 7 8
10111111111111 11000000000000 12 13
11001010000000 11001010000001 0 8
11001111111111 11010000000000 10 11
11010110000000 11010110000001 0 8
11011010000000 11011010000001 0 8
11011110000000 11011110000001 0 8
11011111111111 11100000000000 11 12
11101000000000 11101000000001 0 10
11101010000000 11101010000001 0 8
11110000000000 11110000000001 0 11
11110010000000 11110010000001 0 8
11110110000000 11110110000001 0 8
11111010000000 11111010000001 0 8
11111100000000 11111100000001 0 9
11111111111111 00000000000000 15 16
00001001111111 00001010000000 7 8
00001111111111 00010000000000 10 11
00011001111111 00011010000000 7 8
00011011111111 00011100000000 8 9
00011111111111 00100000000000 11 12
00100111111111 00101000000000 9 10
00101001111111 00101010000000 7 8
00101111111111 00110000000000 10 11
00110110000000 00110110000001 0 8
00111001111111 00111010000000 7 8
00111111111111 01000000000000 12 13
01000110000000 01000110000001 0 8
01001010000000 01001010000001 0 8
01001111111111 01010000000000 10 11
01010110000000 01010110000001 0 8
01011010000000 01011010000001 0 8
« Last Edit: May 12, 2019, 03:45: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 HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
This is the very best match I can generate.
Code: [Select]
Offset: 836, Factor: 246, Divider: 325
1110011111111111 1110100000000000 11 12
1110100111111111 1110101000000000 9 10
1110101001111111 1110101010000000 7 8
1110101111111111 1110110000000000 10 11
1110110101111111 1110110110000000 7 8
1110111001111111 1110111010000000 7 8
1110111111111111 1111000000000000 12 13
1111001001111111 1111001010000000 7 8
1111001111111111 1111010000000000 10 11
1111010101111111 1111010110000000 7 8
1111011001111111 1111011010000000 7 8
1111011101111111 1111011110000000 7 8
1111011111111111 1111100000000000 11 12
1111100111111111 1111101000000000 9 10
1111101001111111 1111101010000000 7 8
1111101111111111 1111110000000000 10 11
1111110001111111 1111110010000000 7 8
1111110110000000 1111110110000001 0 8
1111111010000000 1111111010000001 0 8
1111111011111111 1111111100000000 8 9
1111111111111111 0000000000000000 15 16
0000001001111111 0000001010000000 7 8
0000001111111110 0000001111111111 0 11
0000011001111111 0000011010000000 7 8
0000011011111111 0000011100000000 8 9
0000011111111111 0000100000000000 11 12
0000100111111111 0000101000000000 9 10
0000101001111111 0000101010000000 7 8
0000101111111111 0000110000000000 10 11
0000110101111111 0000110110000000 7 8
0000111001111111 0000111010000000 7 8
0000111111111111 0001000000000000 12 13
0001000101111111 0001000110000000 7 8
0001001001111111 0001001010000000 7 8
0001001111111111 0001010000000000 10 11
0001010101111111 0001010110000000 7 8
0001011001111111 0001011010000000 7 8
The formula to get to the ADC value is then the following:
ADC = ((WaveValue - Offset) * Factor + Divider * 2) div (Divider * 4)
In non integer calculus:
ADC = (123 * Value - 102503) / 650
« Last Edit: May 12, 2019, 06:40: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 genghisnico13

  • Regular Contributor
  • *
  • Posts: 56
  • Country: cl
Could be something as simple as not enough decoupling in the DAC when several bits change simultaneously?
 

Offline HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
Could be something as simple as not enough decoupling in the DAC when several bits change simultaneously?
The output stays the same during long periods of holding a wave value. Also slight changes are expected. For instance the second highest significant bit determines 1/4 of the amplitude (0.9 V in the testing) if that value is of by 0.002 V it will lead to these glitches. That's still a tiny amount. A DAC bit handling needs thus to be very precise.
« Last Edit: May 12, 2019, 08:11: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 tautech

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

Hope it helps and flicks some thought switch ON.  ;)
Avid Rabid Hobbyist
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
I made a graph how values are scaled between different stages.

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

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

Otherwise it would  have been fun to measure the voltage change of each individual bit with a MM.
« Last Edit: May 13, 2019, 12:38:59 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 HendriXMLTopic starter

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

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

I used the glitches and the corresponding wave input values, to determine a relation between them (offset/scale). If that relation explains all the glitches, it is a good one. :-+
« Last Edit: May 13, 2019, 12: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 Rerouter

  • Super Contributor
  • ***
  • Posts: 4694
  • Country: au
  • Question Everything... Except This Statement
If you manually set the waveform amplitude to 6.3243878V pk-pk after loading your waveform, does it alter this scaling issue and use up the remaining DAC range?
 

Offline HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
If you manually set the waveform amplitude to 6.3243878V pk-pk after loading your waveform, does it alter this scaling issue and use up the remaining DAC range?
Only below 2.0V the digital scaling changes. I suspect it than becomes much more: 3.2 x 1.3212 = 4.2. But I won't do any testing in that range.

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

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

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

Maybe they are willing to send me a second one, or a replacement.  :popcorn:
« Last Edit: May 13, 2019, 01:53: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 HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
My seller responded quickly and has send me a second device to test. This will give some idea whether just mine is a bad apple, or whether the model has some (more) issues.

I really hope it is the first option  :-+
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 
The following users thanked this post: tautech

Offline HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
I did a full test of the other unit (device B) I received.

Here's the step size comparison between them.
“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 HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
The highest peek transition on the new device is shown attached screenshot.

Unit now I showed relative (steps) voltages. Now I added 2 graphs of the difference at each wave value to the expected output. As can seen the offset is a major part, but my guess is that the offset is not entirely stable.
« Last Edit: May 15, 2019, 12:52: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 tautech

  • Super Contributor
  • ***
  • Posts: 28139
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
I did a full test of the other unit (device B) I received.

Here's the step size comparison between them.
And you checked they are running the same firmware ?
Avid Rabid Hobbyist
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
Same firmware, because of the bit matching, we can safely say the "step errors" are HW and caused by the DAC.

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

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

I have to think about it some more, but second device's step errors are what one could expect reading the DAC datasheet. What I also like better is that they - except for on tiny negative one - are always positive errors. That makes the difference to the measured one and expected one also less (it supposed to do one stepvalue up).
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 
The following users thanked this post: tautech

Offline HendriXMLTopic starter

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

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

As can de seen the digital offset is now at 1668 instead of 828. However because of the negative side not matching, there's very little difference in bit scoring in succeeding glitches. However at 1667-1668 there's a minor negative spike - which is the only one - so we can assume that is the transition at DAC -1 to 0.
« Last Edit: May 15, 2019, 10:55:52 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 HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
Here's a comparison between the 2 devices in respect to the transformation of values.

Note that the output offset error is +31 mV vs -35 mV.
« Last Edit: May 15, 2019, 11:32:26 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: 4694
  • Country: au
  • Question Everything... Except This Statement
As some parts of this gets a little above what I am capable of fully parsing, is the delta you are seeing inline with what we would expect given the DAC and output OP amp specifications?

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

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

Offline HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
I think the step errors are related to this datasheet info.

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

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

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

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

(What I know of this stuff, I learned from others (you as well) a little research and doing this "exercise").
« Last Edit: May 15, 2019, 10:00: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 HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
The strange behaviour I saw in this graph is an explainable side effect of my testing.

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

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

The VGA is probably the one responsible for a DC error on the output. But if that's stable and predictable than that is not a mayor issue. The device has a offset capability.
« Last Edit: May 15, 2019, 01:13: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 HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
Looking at the sum of the steps a the 4 interval we can probably assume, that the conversion from 16 to 14 bits (shifting 2 bits out, or div 4) is done as a first step. The bits that are "shifted out" don't do anything but create small noisy differences. (Checked it also with the sum of abs() values)
0,4,8,12..0,55 mV0,02%
1,5,9,13..0,75 mV0,02%
2,6,10,12,14-0,40 mV-0,01%
3,7,11,12,153685,83 mV100,00%

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

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

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

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

  • Super Contributor
  • ***
  • Posts: 4694
  • Country: au
  • Question Everything... Except This Statement
so at this point, thinking a truncation issue, If so that should not be a hard fix, do the math on 16 bit, truncate 1 bit, save the other and truncate that bit, then just sum the number with the saved bit, If its a 1, the number rounds up anyway, if its a 0, it doesn't change anything, and you get free rounding with just a summation. 

00
01
10
11

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

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

Offline tautech

  • Super Contributor
  • ***
  • Posts: 28139
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Possibly, I'll point them to this again.
Avid Rabid Hobbyist
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline HendriXMLTopic starter

  • Super Contributor
  • ***
  • Posts: 1085
  • Country: nl
    • KiCad-BOM-reporter
so at this point, thinking a truncation issue, If so that should not be a hard fix, do the math on 16 bit, truncate 1 bit, save the other and truncate that bit, then just sum the number with the saved bit, If its a 1, the number rounds up anyway, if its a 0, it doesn't change anything, and you get free rounding with just a summation. 

00
01
10
11

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

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

With negative numbers we have to be cautious.

What gets really nice results, which also works with negative dividers is:
(It is like adding (or substracting) a 0.5 to let the value flip to the nearest when truncating.)
Code: [Select]
if (Value >= 0) = (Divider >= 0) then
  Result:= (Value + Divider div 2) div Divider
else
  Result:= (Value - Divider div 2) div Divider



« Last Edit: May 16, 2019, 02:31: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 HendriXMLTopic starter

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


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf