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

Thanks, that seems to work fine. Regards Mike

[code]
v1.24

• (Quick&Dirty) Fix for analog channels sampling delay in relation to the digital channels
  • 5 sample shift in the display of the analog channels when any digital channel is also visible - the first 5 samples are dropped from display
• Fix for the clipping of values exported to CVS
  • Now has full range of 0-255 instead of 0-200
    [/code]
    Latest download: https://github.com/pmos69/dso203_gcc/zipball/master
    
    
    
    NOTE: The analog channels delay fix may not be adequate for everybody, but most references I’ve seen in the forum point to a 5 samples delay, and that’s what I could reproduce in my quad also.

Hi, have had a quick look at the timing fix and so far seems a definite improvement.

It appears that the logic channel has a lot of hysteresis, ie a large difference between the hi tripping level and the lo tripping level which can at first glance look like a timing error. In fact the logic channel now switches high as the analoge channel reaches its max level but only returns to low when the analogue channel returns completely to 0 volts, at fast timebase speeds this can appear as a slight timing error. This is demontrateable using input of 20khz and a timebase setting of 1us and looking closely at the rising and falling edges. However all this must all be taken in the context of a £150 product and what can sensibly be expected. The improvement in the useability of the quad now makes it so much better than with the original software supplied.

The only other question is, would it be difficult to move the trigger line to realign it with the now displaced analogue trace as this correct placement can be important in some situations? Not meaning to be picky but if it is a simple thing to do it would really finish the problem off.

Once again thanks for your time and knowledge, Mike

Greetings…



This device can be made to trigger properly… FIFO resets just need enough time to execute before trying to read trigger

events: Re-sequencing of functions to allow this fixes slow/random trigger problems at the fastest timebases. Calibration can also be made to

work better by applying gain correction referred to the signal zero point rather than the screen bottom, prevents interference with offsets

and Y positioning. Proper triggering in single screen buffer mode can be done by looking for start flags after completed frames and resetting.

Meters can be made to read more reliably as well, particularly time/freq function in single screen buffer mode.

See the following attached source files and compiled program for examples. Based on an early Community Edition version (without FFT)

but with most later fixes added.

My primary goal with these mods was to get the Quad to work properly as a scope… To make sure every included function

worked as well as it could.

Keep in mind the compiled program is my own personal version, with several control changes to suit my own preferences.

See README.TXT for a complete list of button functions, as well as a list of other bug fixes and mods. (Most controls remain the same,

a few are swapped, and several shortcuts have been added)

Overall, while the display and menus are basically the same, the goal was to make everything work right and add shortcuts to make it easier

to use. Be sure to re-calibrate!



Finally, I would like to give special thanks pmoss69, marcosin, gabonator1 and others for the GCC port, without which I would not

have been able to make this device work the way I wanted. Many thanks…

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]…
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;

…[/code]

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…

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.

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)

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

</s><i> </i>Output: A=0 B=255 C=0 D=255 E=255 F=254<e>

Where do I get binary files from?

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…

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…

Replaced original post archive, should work fine now…

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.

My congrats good work of Wildcat and Pmos!



You moved DSO Quad form almost unusable toy to quite nice DSO. I hope that we get soon merged FW of yours and Pmos’s version with good buttons layout - each FW i tried used different mapping and for me it was necessary to print help card with buttons mapping. (I see Wildcat buttons mapping to be most effective - especially moving some fucntion from jogdials to big buttons is nice.



May be let discuss some definitive buttons functions layout and keep it across future versions…



I was very disappointed by severity and amount of bugs in official firmware as very poor and incomplete doc.



So it is necessary strongly recommend to newcomers IMMEDIATELY switch to PMOS or WILDCAT version!!!



Zdenek Hladik

Let me ask for filename restrictions of FW files. As we found Widcat’s previous version used names

[list]

which was silently ignored (but renamed to .rdy) in process of update. So all seemed good but no app written!!!



Any tips for filename rules to avoid this crazy problems in future? In wiki is not rules for filenames.

I suppose 8.3 filename limit as CRLF (DOS) line ends in text Intel HEX files.



Also as I see in WIKI - DSO Quad have 4 32kB slots for applications, but any program can overlap to next segment(s) and in case

of all (official, pmos, Wildcat…) osciloscopes it takes 2 adjacent slots. Popular Logic analyzer probably takes only one slot?

Estimation of used memory from HEX file size is

[list]

Wildcat’s last uses about 56kB real memory with HEX file size about 120kB…

From first two lines we can recognize destination slot:

[list]

It seems slots are not protected and by overlapping you can totally corrupt existing application!!!



Please complement or fix my info if you know.



zhladik

Well, it’s not just my work - far from that. I’m just one of the contributors.

[code]All thanks to:

• The original firmware developers
• Marco Sinatti (marcosin)
• Gabriel Valky (gabonator1)
• JackTheVendicator
• Jerson (http://jerson.co.in)
• vblack[/code]
  …and now Wildcat.
  
  
  
  PS: I will try to merge Wildcat’s fixes into the current version, but I’ve been extremelly busy and haven’t had a chance to dive into that yet.

Can someone fix the first post? It notes

However per the last picture posted here, it’s really a sub set of green CH4. This buggered me for a while. Long press of play/pause doesn’t seem to do anything.

Yup.

It’s a “bug” in the readme file. It was changed to the CH4 menu in v1.20.



I’ll update the readme in the next version.

Hi Guys,



I have a new DSO203 which is reporting hw version 2.7 and a DSO SYS version of 1.52 I am trying your app version 1.24.

Is your latest software version compatible with my new DSO?

I cant seem to find how to calibrate from the software? No menu item.



Thanks in advance



Matt.