DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes)

Moderators: lily.li, salmanfarisvp, violet, jeremy882, crail.lyu969

pmos69
Elementary-1
Elementary-1
Posts: 134
Joined: Fri Feb 17, 2012 10:51 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: dso203

Re: DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes

Post by pmos69 » Sat Jun 23, 2012 11:32 pm

Wow, lots of changes there :)

It's a pity you made them over v1.7, and that I'm extremely busy at the moment :/
Would you consider forking the current github repo (https://github.com/pmos69/dso203_gcc) and adding some/all changes, even little by little? (there's some overlap with latter changes in v1.8-v1.24)
If you fork the github repo, you can commit changes there and issue a pull request at any time so that changes can be merged in the current code.

PS:
Just did took a very quick look at some changes in the calibration and there are a few things I still don't understand.
For example, in Balance() and Calibrat(), I don't understand why you initialize a_Avg and b_Avg with anything other than 0, since they are not really averages but cumulative values and the averaging is only done at the end.

ex from Calibrat():

Code: Select all

...
 a_Avg = 2048;  b_Avg = 2048;               
    for(i=0; i <4096; i++){
      DataBuf[i] = __Read_FIFO();         // read into the 32-bit FIFO data
	swap=0x300;
	swap &= DataBuf[i];
	if ((swap==0x100)||(swap==0x200))DataBuf[i]^=0x300; //swap 2 least significant digits of chB, fixes error in FPGA programming
      a_Avg += (DataBuf[i] & 0xFF );    			    // cumulative DC average
      a_Avg-=ADCoffset;	
      b_Avg += ((DataBuf[i]>>8) & 0xFF );
      b_Avg-=ADCoffset;	
           
    }
    TmpA  = Ka1[Range] +(Ka2[Range]*(a_Avg/4096)+ 512)/1024;
    TmpB  = Kb1[Range] +(Kb2[Range]*(b_Avg/4096)+ 512)/1024;
...
From what I understand, all 4096 values in the buffer are added first in avg_a and avg_b, and at the end those cumulative values are divided by 4096 to get the average values.
If that's the case, it doesn't make sense to initialize avg_a and avg_b with anything other that 0.
It would make sense to initialize them to a value representing 0, if avg_a and avg_b were averages to begin with, and not cumulative values.

If one imagines, for example, that the buffer only had 1 value, and not 4096, I would presume the cumulative values for avg_a and avg_b would have to be equal to the values in the buffer, whatever the values in the buffer, and dividing the cumulatives by the number of samples (1) the averages would also also always be the same as the values in the buffer.
That does not happen in the current code.

As the math is done, if I imagine different buffer sizes with all constant values, the end result varies with the buffer size, even if the values in the buffers are all the same, and that doesn't seem right.
It's a fact the "error" tends to zero as the buffer size increases, but nonetheless..
Image

bobtidey
Elementary-1
Elementary-1
Posts: 174
Joined: Sun May 13, 2012 9:39 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes

Post by bobtidey » Sun Jun 24, 2012 12:04 am

Wow indeed. It would be great to get all these fixes into the base community edition. The UI chsnges seem well thought out as well.

On the subject of the avg offset it looks like the 2048 is there to give a 0.5 bit rounding offset per sample into the average value as it is divided by 4096.

pmos69
Elementary-1
Elementary-1
Posts: 134
Joined: Fri Feb 17, 2012 10:51 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: dso203

Re: DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes

Post by pmos69 » Sun Jun 24, 2012 1:10 am

bobtidey wrote: On the subject of the avg offset it looks like the 2048 is there to give a 0.5 bit rounding offset per sample into the average value as it is divided by 4096.
Yes, but assuming 2048 is samples/2, what it does is simply add 1 (decimal) to the real average in (Ka2[Range]*(a_Avg/4096)+ 512)/1024
Average values will change from 0-255 (real) to 1-256.

(assuming Ka1[Range]=0 Ka2[Range]=1024 and ADCoffset=0 for simplification)
Image

Wildcat
Elementary-1
Elementary-1
Posts: 166
Joined: Fri Jun 22, 2012 1:29 pm
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes

Post by Wildcat » Sun Jun 24, 2012 6:21 am

It just preloads the starting point at 1/2 least significant bit. I actually didn't give it a whole lot of thought, this is common practice when working with ADC's. Has to do with integer math, where most compilers will not round out a value. For example, if you start out at 0, then add 0.999, you will still get 0, however, subtract 0.001 and you will get -1. This creates a 1/2 LSB offset biased towards the negative. If you preload it at +0.5 then it takes an equal level to bring it positive as it does negative, effectively "centering" the zero level. This is also the reason the original author added "512" to the calibration calculations, these subsequently get divided by 1024, biasing the value to +1/2 LSB.
The original code initialized these @ 2048 (out of 4096 samples). I just changed it so it would work correctly when using the smaller buffer.
As I mentioned, I did not give this huge amount of thought at the time, it may be that the 1/2LSB offset is taken care in subsequent calculations, so you may be right...

pmos69
Elementary-1
Elementary-1
Posts: 134
Joined: Fri Feb 17, 2012 10:51 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: dso203

Re: DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes

Post by pmos69 » Sun Jun 24, 2012 7:34 am

Wildcat wrote:It just preloads the starting point at 1/2 least significant bit. I actually didn't give it a whole lot of thought, this is common practice when working with ADC's. Has to do with integer math, where most compilers will not round out a value. For example, if you start out at 0, then add 0.999, you will still get 0, however, subtract 0.001 and you will get -1. This creates a 1/2 LSB offset biased towards the negative. If you preload it at +0.5 then it takes an equal level to bring it positive as it does negative, effectively "centering" the zero level. This is also the reason the original author added "512" to the calibration calculations, these subsequently get divided by 1024, biasing the value to +1/2 LSB.
The original code initialized these @ 2048 (out of 4096 samples). I just changed it so it would work correctly when using the smaller buffer.
As I mentioned, I did not give this huge amount of thought at the time, it may be that the 1/2LSB offset is taken care in subsequent calculations, so you may be right...
Thanks for the explanation Wildcat.
I suppose you're right, but the way it's done, there's a constant shift of 1 (decimal) to the average value, not 0.5.
This happens because 0.5 is also being added to the value in the +512/1024 part of the calculation.
This means that 4096 samples of value 0 will give an average of 1, and 4096 samples of value 255 will give an average of 256.
(...unless the shifts are both truncated in the integer math. would have to check)

PS:
Nevermind - It will give correct values.
http://codepad.org/elskAHll

Code: Select all

main(){
int a, b, c, d, e, f, Ka2, a_Avg, b_Avg, c_Avg, d_Avg, e_Avg, f_Avg;
   Ka2 = 1024;

   a_Avg = 0 + 2048;
   b_Avg = (255 * 4096) + 2048;
   c_Avg = 1 + 2048;
   d_Avg = ((255 * 4096) - 1) + 2048;
   e_Avg = (255 * 4096) - ((255 * 4096) - (254 * 4096))/2 + 2048;
   f_Avg = e_Avg - 1;

   a = (Ka2 * (a_Avg / 4096) + 512)/1024;
   b = (Ka2 * (b_Avg / 4096) + 512)/1024;
   c = (Ka2 * (c_Avg / 4096) + 512)/1024;
   d = (Ka2 * (d_Avg / 4096) + 512)/1024;
   e = (Ka2 * (e_Avg / 4096) + 512)/1024;
   f = (Ka2 * (f_Avg / 4096) + 512)/1024;

   printf("A=%d\n", a);
   printf("B=%d\n", b);
   printf("C=%d\n", c);
   printf("D=%d\n", d);
   printf("E=%d\n", e);
   printf("F=%d\n", f);
return 0;
}

Code: Select all

Output:
A=0
B=255
C=0
D=255
E=255
F=254
Image

elektrinis
Pre-kindergarten
Pre-kindergarten
Posts: 3
Joined: Mon Dec 05, 2011 9:08 pm
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: nano v2

Re: DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes

Post by elektrinis » Tue Jun 26, 2012 3:22 am

Where do I get binary files from?

dragon1111
Pre-kindergarten
Pre-kindergarten
Posts: 1
Joined: Tue Jun 26, 2012 7:55 am
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: all

Re: DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes

Post by dragon1111 » Tue Jun 26, 2012 8:16 am

I found HEX binaries in root directory of archive, but if I tried to install any of them (i suppose there are three version to three different slots), no one is possible to install. Each try seems to be succesfull (fast unmount/mount and rename HEX to RDY extension) but nothing on DSO is overwritten. There is still previous one version of DSO active in slot1 and previously installed LOGIC analyzer in slot 3.

May be I missed something, or included HEX is wronlgy compiled a recompilation necessary. I want to start building of development environment for future improvement participation, but now I need to use DSO with best actual FW...

Wildcat
Elementary-1
Elementary-1
Posts: 166
Joined: Fri Jun 22, 2012 1:29 pm
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes

Post by Wildcat » Tue Jun 26, 2012 10:49 am

Wow... YES, I see that... It appears to be because I renamed the files just before archiving them...
Rename them app1.hex app2.hex app3.hex and they should work fine....

Wildcat
Elementary-1
Elementary-1
Posts: 166
Joined: Fri Jun 22, 2012 1:29 pm
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DSO Quad

Re: DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes

Post by Wildcat » Tue Jun 26, 2012 11:12 am

Replaced original post archive, should work fine now...

bielec
Pre-kindergarten
Pre-kindergarten
Posts: 38
Joined: Wed May 18, 2011 5:43 pm
Are you a staff member of seeedstudio?: no
Which products/projects are your favorite?: DS203

Re: DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes

Post by bielec » Tue Jun 26, 2012 9:48 pm

Thank you very much Wildcat. You fixed the triggering so now I can see occasional bursts of data on a serial line. This scope hase been practically useless to me until now.

Post Reply