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

[HendriXML]

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..

[HendriXML]

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).

[Rerouter]

If you have the bin file, likley going to be much easier to just load via USB

[HendriXML]

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)

[Rerouter]

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.

[HendriXML]

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.

[tinhead]

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

[HendriXML]

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


[HendriXML]

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 think there's not much to be tested anymore and at least one other AWG does not have the same problem, so it is not a firmware kind of bug.

It's very likely a DAC problem, what bothers me that I cannot relate it to a single bit. (It's repeating thus that would make sense)

I'll contact the seller and hopefully get a better one and not worse.

I understand the device and technology behind it a bit better, and it seems to me that it should perform a lot better.

[HendriXML]

The distance between glitches are at 1.9 compared to 2.0 are more wide (3.23x) and thus there less.
6556/2028=3,232741617357
10928/3384=3,22931442080378
This could mean a smaller portion of the DAC input range is used.
Value 2663 has a record glitch of 2.69 mV which also indicates the amplification is more.

So there 3 ways of controlling the amplitude:
* VGA
* Attenuation with relays
* Scaling

Here's what I got to understand.
Between ranges there's a coarse way of scaling, within a range there's the VGA:

0V..0.06V: VGA
Relay - analog scaling
0.06V..0.6V: VGA
Relay - analog scaling
0.6V..2V: VGA
Digital scaling (3.2x?)
2V..6V: VGA

If someone can improve this, please do so. It's very possible that the low ranges are also subdivided, but I've not tested it.

[HendriXML]

Just to have some idea how DAC error show up, I made a little simulation script.

It simulates the complementary output currents DAC (dac904) to see what happens when certain bits don't contribute the way they're supposed to.

In the first graph only 1 bit is non perfect. In that case one gets step differences up and down. Up being even more visible.

But when another bit is also affected things show up very differently.

Similar effects can be seen in my AWG's DAC response.

In my AWG the effects are to too profound for what I like to do with it. But how do other's perform? Testing the same input values might not show any issues, but others may.

So for the sake of science I could fancy up my scripts, so that is more "user friendly" if others would like to do their own measurements.

What would be needed to perform the test:
* SAG1021
* NI VISA setup (It uses a COM interface that comes with it)
* Ethernet/Wifi connection on Scope (Using the above with USB fails)
* Interpreter executable (64 bit Windows, developed by me)
* Script + Script libraries
* XML editor to alter some values (for example an offset to get the first batch in view, scopes ip-adress). I really like the free Visual Studio Community for that.
* about 2 hours of executing time

What does it do?
For each of the 65536-1 (16 bit) values it determines the step size (V) to the next one. It does this in batches of 500 blocks. Each batch is centred in the DSO view and a segmented acquisition is done. Of that multi frame averages are calculated (after discarding the 50% extremes). Then these values are averaged per blocks (centre samples) before calculating the final value.
Because values are measured with high sensitivity (5mV/div) and there's plenty of averaging the results are very useful.

[HendriXML]

It would be nice to measure the true response of each bit. In that case it would be possible to determine a lookup table which delivers a better setting of bits (thus another value) for each value. Creating a very high precision DAC. Only usable for arbitrary wave forms, but those can do all the other waves (with limitations?). It wouldn’t surprise me if the others are (calculated) arbitrary waves.

The problem is that here’s still the unknown scaling or even offsetting of the input values. That makes setting (or toggling for generating AC voltage, losing the DC component) individual bit impossible.

[tinhead]

Just to have some idea how DAC error show up, I made a little simulation script.
...
What would be needed to perform the test:

as i do have SAG as well, send me all i need, so i can run it on my hardware

[HendriXML]

Just to have some idea how DAC error show up, I made a little simulation script.
...
What would be needed to perform the test:

as i do have SAG as well, send me all i need, so i can run it on my hardware

I hope that you're comfortable with git (Github) repositories. I've placed it there, when used well it can be quite handy.

Setup for git is over here:
https://www.git-scm.com/download/win

After installing git, open a command line prompt and use a location of choice when executing the following:


git clone --recurse-submodules https://github.com/HendriXML/XMLScripts-Project-AWGStepTesting.git C:\AWGStepTesting

This will get the submodules as well.

I have made the script a bit more user friendly, let's see how well it goes. Using git, it's easy to sync changes.

If there're any issues then please use
https://github.com/HendriXML/XMLScripts-Project-AWGStepTesting/issues

in that way all that stuff will be at one easy accessible location, beneficial to others - not participating this thread- as well.

The first run of the script will probably not have the waveform in view, because of the 5mV/div it needs a accurate DSO offset. Using the pause checkbox the script will stop making manual adjustments possible. Unchecking pause and resume will continue without further pausing. (But it can be checked at anytime, to set a pause request. The script will have a script element for that to check this.)

[HendriXML]

It would be great if other could post test results with the same parameters, so we could do a side by side comparison. Maybe use standard 3V amp, 300 hz for that.
Posting the results from the Output tab would be enough to have Excel make a nice graph.

[HendriXML]

The waveform setup only applies when you use "<trace>:WF? ALL" for what ever reason its ignored for "<trace>:WF? DAT2"

Still have no luck limiting the number of points. This is the response using

WAVEFORM_SETUP SP,0,NP,1000,FP,0

C1:WAVEFORM? ALL

Each time I get a different but repeating output value.

Code: [Select]

14089.  viRead (TCPIP0::scope::inst0::INSTR (0x05981DB8), "ALL,#9000140346WAVEDE...", 1024000, 1363)
Process ID: 0x000011F0         Thread ID: 0x00001110
Start Time: 14:51:03.407       Call Duration 00:00:00.001
Status: 0 (VI_SUCCESS)
Buffer Contents
00000000:  41 4C 4C 2C 23 39 30 30 30 31 34 30 33 34 36 57  ALL,#9000140346W
00000010:  41 56 45 44 45 53 43 00 5A 1D 36 00 97 CB 00 57  AVEDESC.Z.6....W
00000020:  41 56 45 41 43 45 00 E0 49 E2 25 10 00 E0 25 00  AVEACE..I.%...%.
00000030:  00 01 00 5A 01 00 00 00 00 00 00 00 00 00 00 00  ...Z............
00000040:  00 00 00 00 00 00 00 00 00 00 00 E0 22 02 00 00  ............"...
00000050:  00 00 00 00 00 00 00 00 00 00 00 53 69 67 6C 65  ...........Sigle
00000060:  6E 74 20 53 44 53 00 00 00 00 00 AB CD 00 00 00  nt SDS..........
00000070:  97 CB 00 F4 49 E2 25 F8 49 E2 25 F8 49 E2 25 E0  ....I.%.I.%.I.%.
00000080:  22 02 00 E0 22 02 00 DE 22 02 00 00 00 00 00 DF  "..."...".......
00000090:  22 02 00 00 00 00 00 00 00 00 00 01 00 00 00 E8  "...............
000000A0:  03 00 00 01 00 00 00 00 00 00 00 0A D7 A3 3B 0B  ..............;.
000000B0:  24 B8 3F 00 00 FE 42 00 00 00 C3 08 00 01 00 95  $.?...B.........
000000C0:  BF 56 33 79 E9 26 31 08 AC 6C 3F 79 E9 26 31 08  .V3y.&1..l?y.&1.
000000D0:  AC 6C 3F 56 00 B0 36 00 00 00 00 BC FE 01 00 00  .l?V..6.........
000000E0:  00 00 00 8C 7B CD 00 20 69 1D 36 F0 00 00 00 01  ....{.. i.6.....
000000F0:  00 00 00 C0 C5 F5 36 34 C4 F5 36 8C 7B CD 00 EC  ......64..6.{...
00000100:  5B 1D 36 53 00 00 00 84 4A E2 25 01 00 00 00 74  [.6S....J.%....t
00000110:  66 1D 36 00 00 00 00 00 00 00 00 3C F9 01 00 20  f.6........<...
00000120:  5C 1D 36 60 64 1D 36 EC 5B 1D 36 05 00 00 00 60  \.6`d.6.[.6....`
00000130:  64 1D 36 5F 70 89 30 00 00 00 00 00 00 00 00 00  d.6_p.0.........
00000140:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000150:  00 01 00 13 00 00 00 00 00 80 3F 03 00 01 00 00  ..........?.....
00000160:  00 80 3F 0B 24 B8 3F 00 00 1C 1C 1C 1C 1C 1C 1C  ..?.$.?.........
00000170:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000180:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000190:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001A0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001B0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001C0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001D0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001E0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000001F0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000200:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000210:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000220:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000230:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000240:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000250:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000260:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000270:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000280:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
00000290:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................
000002A0:  1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C 1C  ................


[HendriXML]

I did some further tuning on the script and measurement parameters.

This one is with 100 instead of 500 blocks per batch. Much less, because otherwise the values go out of the scope’s measurement window. This because it is now measured with 2mV/div (!).
Also the frequency has been lowered to 90 hz. Meaning more of the cycle is in view and there’s more time between frames. (Short time interferences and stuff are more averaged out).

The results are very nice. The first graph is a zoom in on the second overview graph. The DAC steps are now clearly visible (1/4) of the time, because of 16 -> 14 bit.
Also less pronounced glitches, (DAC errors) can be seen. This is not the whole range because these “special” measurements take a really long time.

One good thing:
The script determines whether the scope measurement was saturated. If that happens that value will be the start of a new batch with a better offset.
Because of this the script can now even start with a mismatching offset and find the right one.

No one responded yet, but has someone tried to run it?

I'll will push the new version of the script later on, so if there's something I should look at, tell me!

I started a warranty procedure for the AWG, but before returning it, it would be major fun if I got to know how the input values are translated to DAC values (Scale and offset). I'm convinced that with the right lookup table it is possible to have almost no glitches/drops at all.

[HendriXML]

Just to have some idea how DAC error show up, I made a little simulation script.
...
What would be needed to perform the test:

as i do have SAG as well, send me all i need, so i can run it on my hardware

I hope that you're comfortable with git (Github) repositories. I've placed it there, when used well it can be quite handy.

Setup for git is over here:
https://www.git-scm.com/download/win

After installing git, open a command line prompt and use a location of choice when executing the following:


git clone --recurse-submodules https://github.com/HendriXML/XMLScripts-Project-AWGStepTesting.git C:\AWGStepTesting

This will get the submodules as well.

I have made the script a bit more user friendly, let's see how well it goes. Using git, it's easy to sync changes.

If there're any issues then please use
https://github.com/HendriXML/XMLScripts-Project-AWGStepTesting/issues

in that way all that stuff will be at one easy accessible location, beneficial to others - not participating this thread- as well.

The first run of the script will probably not have the waveform in view, because of the 5mV/div it needs a accurate DSO offset. Using the pause checkbox the script will stop making manual adjustments possible. Unchecking pause and resume will continue without further pausing. (But it can be checked at anytime, to set a pause request. The script will have a script element for that to check this.)

A new version of the script and modules are pushed. It's easiest to pull them fresh using a different directory. It may that people dislike to execute a large unknown executable like this. But the big size is just because it's an all in one Delphi executable.
https://www.virustotal.com/nl/file/2badeb990bf2d17d659b28987dc146f3964a46dc0876ec8d8c9b96c7b11ebfe3/analysis/1557510442/

[HendriXML]

My more slow parameter (not in upload) script ran about 8h40.

I'll try to analyse it, and to guess what bits are toggling at what moment. After having played with this stuff for a while now I'm quite sure this is what is happening on a glitch (that is a common name for these kind of errors).
When a DAC binary value of 00111 turns into 001000, the voltages out of 3 current sources are replaced by the voltage of 1 (more significant) current source. If however the more significant bit, delivers less voltage than the previous ones combined than instead of increasing, the voltage drops. In my AWG this happens frequently, and with quite some voltage (one with 9.6x least significant bit steps).
That a DAC drops instead of climbs is normally a very unwanted situation, certainly in feedback loops. This is a high speed DAC so it usage is different, but for creating trustworthy signals I would like it to be much lower. These fast unwanted voltage transitions will be in all the signals it generates, creating unexpected "high frequencies" (not noise but regularly repeating).

The reason I did the precise measurement is to have more information to gaze at. For example the most significant bit, might have the greatest step error. This is at 828, the DAC will than change from 1111111111111 to 00000000000000. (-1 to 0).
This might be -for instance- an indication that there's a offset of 828.

[HendriXML]

I added a previous, lower quality measurement graph to have a side by side comparison to show what the extra averaging and time between acquisitions can mean.

[HendriXML]

I uploaded a new version of the script, the horizontal TDiv parameter was not set back to match the other parameters.
Now it runs smoothly, this is what to expect:

Code: [Select]

Description: Global VISA COM I/O Resource Manager
Siglent Technologies,SDS1204X-E,SDSMMDBQ2R3764,8.1.6.1.26

[2019-05-10 23:20:35] Setting up wave -32768..-32269
[2019-05-10 23:20:35] Setting up DSO Window, centered at -1432,58 mV
[2019-05-10 23:20:36] Getting 66667 DSO samples
[2019-05-10 23:21:16] Process single cycle samples
[2019-05-10 23:21:16] Off centre voltage: -25,00 mV
[2019-05-10 23:21:16] Setting up wave -32768..-32269
[2019-05-10 23:21:16] Setting up DSO Window, centered at -1457,58 mV
[2019-05-10 23:21:17] Getting 66667 DSO samples
[2019-05-10 23:21:54] Process single cycle samples
[2019-05-10 23:21:54] Off centre voltage: 9,20 mV
[2019-05-10 23:21:55] Setting up wave -32269..-31770
[2019-05-10 23:21:55] Setting up DSO Window, centered at -1425,54 mV
[2019-05-10 23:21:55] Getting 66667 DSO samples
[2019-05-10 23:22:35] Process single cycle samples
[2019-05-10 23:22:35] Off centre voltage: 0,20 mV
[2019-05-10 23:22:36] Setting up wave -31770..-31271
[2019-05-10 23:22:36] Setting up DSO Window, centered at -1402,49 mV
[2019-05-10 23:22:36] Getting 66667 DSO samples
[2019-05-10 23:23:17] Process single cycle samples
[2019-05-10 23:23:17] Off centre voltage: -0,50 mV



[HendriXML]

Besides measuring step voltages, I also measured absolute voltages. These are measured precisely and mostly by the using the ADC of the scope to get the wave in view. The few mV that are in the measurement are added to that.
It isn't a perfect straight line, because probably the offset of the AWG is not very steady.

I did some measurement and the offset is a bit depended on the amplitude as well:
2.0 V amplitude: 25.3mV offset
3.0 V amplitude: 30,6mV offset (during measurement)
6.0 V amplitude: 49.7mV offset

With less then 2.0 V it jumps to a different range:
1.9 V amplitude: 54.7mV offset
0.7 V amplitude: 31.2mV offset

Off course this offset shouldn't be there. I suspect however the device is "managing" it. I think that a part of the DAC range is used to control an offset needed for a following stage.

This offset is then (partly) amplified by the VGA.

I suspect that "0V" output of the DAC is at the wave value of 828, this value is transformed (scaled and offsetted) to DAC inputvalue of 0.
Beneath the 2.0V amplitude
I suspect that "0V" output of the DAC is at the wave value of 2664. (This is a difference of 3.2x, about the same factor the glitches get spread. Also there're about 3x less glitches. )

I made a drawing how I think the stages interact with each other. Looking at the glitches we get info on the digital side. (And start assuming things to move forward in the analysis)

The glitches are "special" values on the DAC stage, it should be possible to guess them. If these blanks are filled, then the scaling and offsetting can be determined.

[HendriXML]

Because more glitches could be measured a relation to all the glitches input values can be shown. Taking the distances between input values this table arises:

Code: [Select]

Dist Count
676 7
1352 3 2 x 676
2028 8 3 x 676
2708 4 4 x 676 = 2704
3384 8 5 x 676 = 3380
I think the 676 is a factor to some "binary base value", (256, 512, 1024). At the ADC-input value side glitches should repeat at such intervals.

Maybe values are scaled close to this factor/divider pair: 676/1024

I'll have to check if using that and the offset of 828 get "special bit" arrangements.

[HendriXML]

When I substract 828 of the glitch values and multiply them by 676 these are the binary values:

Code: [Select]

0101100010000110110011111 0101100010000110110100000
0110011001111110001101111 0110011001111110001110000
0110100111111010101111111 0110100111111010110000000
0111010001110000010101111 0111010001110000010110000
1000010111100100010001111 1000010111100100010010000
1001000001011001110111111 1001000001011001111000000
1010000111001101110011111 1010000111001101110100000
1010110001000011011001111 1010110001000011011010000
1011110110110111010101111 1011110110110111010110000
1100010010110000011001111 1100010010110000011010000
1100100000101100111011111 1100100000101100111100000
1101011000100100010101111 1101011000100100010110000
1101100110100000110111111 1101100110100000111000000
1110010000010110011101111 1110010000010110011110000
1110011110010010111111111 1110011110010011000000000
1111010110001010011001111 1111010110001010011010000
1111100100000110111011111 1111100100000110111100000
1111111111111111111111111 0000000000000000000000000
0001000101110011111011111 0001000101110011111100000
0001101111101001100001111 0001101111101001100010000
0010110101011101011101111 0010110101011101011110000
0011000011011001111111111 0011000011011010000000000
0011011111010011000011111 0011011111010011000100000
0100010111001010011101111 0100010111001010011110000
0100100101000110111111111 0100100101000111000000000
0101001110111100100101111 0101001110111100100110000
0110010100110000100001111 0110010100110000100010000
0110111110100110000111111 0110111110100110001000000
1000000100011010000011111 1000000100011010000100000
1000101110001111101001111 1000101110001111101010000
1001110100000011100101111 1001110100000011100110000

All of them have at least 4 bits replace by a more significant one. Duno if that means something yet, because the values are now to large... With every division (2,4,8,16) bits will right shift out.

[HendriXML]

I think this is becoming more meaningful. A lot of the higher bits are about to overflow, or have overflowed.

Code: [Select]

Offset: 828
Factor: 512
Divider: 676
1111111111001111111101101 1111111111001111111101110
1111111111010011111110000 1111111111010011111110001
1111111111010100111110000 1111111111010100111110001
1111111111010111111110000 1111111111010111111110001
1111111111011100111110100 1111111111011100111110101
1111111111011111111110100 1111111111011111111110101
1111111111100100111110111 1111111111100100111111000
1111111111100111111110111 1111111111100111111111000
1111111111101100111111010 1111111111101100111111011
1111111111101110111111010 1111111111101110111111011
1111111111101111111111010 1111111111101111111111011
1111111111110011111111101 1111111111110011111111110
1111111111110100111111101 1111111111110100111111110
1111111111110111111111101 1111111111110111111111110
1111111111111000111111101 1111111111111000111111110
1111111111111101000000000 1111111111111101000000001
1111111111111110000000000 1111111111111110000000001
1111111111111111111111111 0000000000000000000000000
0000000000000101000000010 0000000000000101000000011
0000000000001000000000010 0000000000001000000000011
0000000000001101000000101 0000000000001101000000110
0000000000001110000000101 0000000000001110000000110
0000000000010000000000101 0000000000010000000000110
0000000000010100000001000 0000000000010100000001001
0000000000010101000001000 0000000000010101000001001
0000000000011000000001000 0000000000011000000001001
0000000000011101000001011 0000000000011101000001100
0000000000100000000001011 0000000000100000000001100
0000000000100101000001110 0000000000100101000001111
0000000000101000000001110 0000000000101000000001111
0000000000101101000010001 0000000000101101000010010