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

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]

  • appW_1.hex, appW_2.hex…
  • [/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]

  • HEX size about 2.2 times real size
  • [/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]

  • :020000040800F2

    :10C000… - first slot at C000 hex



    :020000040801F1

    :104000… - second slot at 14000 hex



    :020000040801F1

    :10C000… - third slot at 1C000 hex



    :020000040802F0

    :104000… - fourth slot at 24000 hex
  • [/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.

    Yes.

    Check the readme (or the fisrt post on this thread).

    Calibration: long press button 2 (square)

    Thank you Wildcat, this is only firmware which work good for me to :wink:

    Is there a way to make this app install in another slot. It would be good to get the original firmware in slot 1-2 and this APP in slot 3-4 ??



    Thanks

    I’ve been using the Wildcat version as my main app which functions very nicely as a scope.



    I can’t seem to make sense of the signal generator part though. It sets the waveform and the amplitude OK but all the frequencies seem to be off by a factor of 4. E.g. when I set 1KHz I get a 250 microsecond period waveform on the display rather than the 1msec I was expecting. The timebase looks OK against normal external signals.



    Am I missing something here?

    Wanted to say Thanks. its wonderfull job there.



    There is something like a bug and is a kind of mirror behavior in realtime scan with short buffer







    Other Small thing is that the Square that tells the size of the buffer (bottom middle) only fills complete if the full screnn is off, when full screen is activated the scan looses almost 4 squares of measurement. Thank you

    Triggered by a comment in another post, I figured out that Wildcat needs the standard SYS rather than the modified SYS25116 I had been using on the community edition. I put Sys1.52 on and now the signal generator frequencies match the display.

    exactamundo.