Dear Marco i am very pleased with your firmware 1.8! Tell me why, in contrast to the Chip firmware in your firmware scan mode draws the entire screen at once, rather than at one point? I think this mode in the firmware Chip is more convenient (it resembles the work cardioscope - point moves around the screen and draws the graph). You have not done so because it is difficult? Or are you more comfortable as it works in your firmware? I am a simple user and not engaged in writing the firmware.
I think it’s important to express their wishes in order to improve your firmware! Thank you for what you are doing! Sorry for my English - I’m from Russia.
Dear Marco,
I´ve been using APP251_1.8 (thanks a lot for your work, btw) and when using the “single page buffer” mode (sorry don’t know it’s real name, the values of RMS and Vdc are incorrectly calculated.
RMS seems to low, like the average is still being calculated with more samples than available in the buffer.
Is this a know “feature”?
Best regards,
Pedro
Dear Marco,
Just browsed your code to look at those calculations.
At first glance (but remember I’m only looking at the sources for the first time), it would seem the calculations for the RMS and Vdc values are not taking into account if the small “one-page” buffer is being used instead of the full buffer, and the same number of samples as the full buffer (4096) is always used to calculate the mean values.
I suppose a switch might be needed to account for the smaller sample number and do the correct calculation in that case.
Here’s the code in Menu.c (Display_Value function)
[code]case VDC:
if(Meter[i].Track == TRACK1){
Tmp = Ka1[_A_Range]+(Ka2[_A_Range](a_Avg/4096)+ 512)/1024 - _1_posi;
if((Tmp >= -2)&&(Tmp <= 2)) Tmp = 0;
Tmp = Y_Attr[_A_Range].SCALE;
if (_1_source ==2) Tmp=Tmp10;
if (_1_source == HIDE) Tmp=0;
}
if(Meter[i].Track == TRACK2){
Tmp = Kb1[_B_Range]+(Kb2[_B_Range](b_Avg/4096)+ 512)/1024 - _2_posi;
if((Tmp >= -2)&&(Tmp <= 2)) Tmp = 0;
Tmp = Y_Attr[_B_Range].SCALE;
if (_2_source ==2) Tmp=Tmp10;
if (_2_source == HIDE) Tmp=0;
}
Int2Str(NumStr, Tmp, V_UNIT, 3, SIGN);
break;
case RMS:
if(Meter[i].Track == TRACK1){
Tmp = Ka1[_A_Range] +(Ka2[_A_Range]*Int_sqrt(a_Ssq/4096)+ 512)/1024;
if(Tmp <= 2) Tmp = 0;
Tmp *= Y_Attr[_A_Range].SCALE;
if (_1_source ==2) Tmp=Tmp*10;
if (_1_source == HIDE) Tmp=0;
}
if(Meter[i].Track == TRACK2){
Tmp = Kb1[_B_Range] +(Kb2[_B_Range]*Int_sqrt(b_Ssq/4096)+ 512)/1024;
if(Tmp <= 2) Tmp = 0;
Tmp *= Y_Attr[_B_Range].SCALE;
if (_2_source ==2) Tmp=Tmp*10;
if (_2_source == HIDE) Tmp=0;
}[/code]Dear chip,
I suppose you may use the same “base” code for these calculations, as I have the same behaviour with your version (APP_B253)
…or peharps i’m wrong and I’m doing something wrong 
OK, fixed some errors and compiled a version of marcosin (1.7) with the fixes in GCC using garbonator1 makefile.
Not perfect, since the app only starts about 1/3 of the times.
If anyone wishes to try it, made the sources and HEX available here: github.com/pmos69/dso203_gcc
(compiled HEX in Bin directory - installs to slot1)
Changes:
- Removed -fno-common and changes -Os to -O3 in compile options
APP still only starts correctly 1/3 of the times - Fixed Vdc and RMS values display when in 1-page buffer mode (menu.c)
Calculation didn’t take into account the buffer size when calculating the averages - Fixed wrong calculations for Vdc and RMS (process.c)
the counters (a_Avg, b_Avg, a_Ssq, b_Ssq) were initialized with a value different than 0)
All thanks to:
- Seeed-Studio
- Marco Sinatti (marcosin)
- Gabriel (gabonator1)
Great work, Pedro!
More problems…
- I cannot use the .hex of your bin folder. It makes an error (APP_G251.err on the DSO)
- I can compile the source code with the following result: after the initialisition screen: 1/2 of the time black, 1/2 of the time 0.5 second of parasites, then freeze.
One more question: why didn’t you use Marco’s newest source code (1.8, see download/file.php?id=919)?
And even one more: does anybody know where to find the source code of Marco’s SYS file (and how to compile it)?
Unfortunately, it seems that Marco does not visit the forum any more…
I would be very glad to try and help correct the last bugs of Marco’s excellent code (e.g. the fact that the correction for 10x probes does not work) or ameliorate it (e.g. slower time bases, and so on)!
Patrick
PS: by the way, the developement installation /environment proposed be Petteri Aimonen (svn.kapsi.fi/jpa/dsoquad/freq/README.txt) seems to me much more easy to use than Gabonator’s
Strange. You shouldn’t get different results.
I’m using marcosin latest SYS (SYS150_1.6)
Not sure at this time which FPGA I’m using - may be latest or 2.22
I just used what I had available, but will look at 1.8.
I use the SYS I downloaded from Marco’s page sites.google.com/site/marcosinat … ronica/dso
Since his firmware 1.6, he names it SYS 1.50 1.6 but the filename in the RAR is SYS15116.hex. So do we use the same or not?!?
Furthermore, I have no idea why I cannot install the APP_G251.hex from you /bin folder. The format seems to be OK, but it fails to install (.err file on the USB drive).
Patrick
Yes, I think I’m using all the files from marco’s 1.8 release (except the HEX).
EDIT: I confirm that - including FPGA 2.22 (be sure to tranfer the FPGA configuration file first if you want to install that)
EDIT2: Just checked - also works with FPGA 2.61. Seems to get stuck in black screen more often, but the display is MUCH faster.
Anyway, here’s a zip with my whole tree.
Maybe there’s some of those problems with file conversion in git. (I’m really not an expert on the damn thing)
See if anything’s different if you can.
Thanks
dso203_gcc.zip (379 KB)
v1.1 - Now using marcosin 1.8 sources
https://github.com/pmos69/dso203_gcc
Tested with:
- SYS150_1.6 (from marcosin 1.8)
- FPGA V2.22 (from marcosin 1.8)
- FPGA V2.51 (seeedstudio) --> A lot faster screen drawing
Still only initializes about 1/3 of times.
dso203_gcc_v1.1.zip (395 KB)
Thank you, pmos69! especially for sources
No problem.
My first intention was just to fix the RMS and Vdc readings on marcosin’s release.
Hope an easy, free toolchain and compilation setup will encourage more people to contribute.
(The code seems a bit ‘messy’ in some places.)
Plus, it was fun 
- hadn’t compiled any C code in about 15 years.
Now, if any expert could help fix the inconsistent startup issues, that would be nice
v1.2 release
https://github.com/pmos69/dso203_gcc
- Just google-translated all the comments in the source from chinese to english, to ease code understanding (for some people at least )
- no code changes
PS: Marco told me he is very busy and has stopped development at this time.
Hope he can return one of these days 
dso203_gcc_v1.2.zip (395 KB)
Now the .hex can be installed on my DSO, but I get the same result as when I compiled your v1.0 myself: 1/2 of the time a black screen, 1/2 of the time half a second of parasites, then a freeze.
I use SYS150_1.6 (from marcosin 1.8). No idea about the FPGA, but I bought my DSO about one month ago, so I guess it should be the latest.
Marco’s firmware works well, so the problem has nothing to do with the source code. Gabonator’s port of the firmware (valky.eu/data/hardware/ds203 … soquad.zip) compiles and works well too with the same toolchain as Pedro’s, so it seems it’s not the toolachain… so what?!?
Unfortunately, my debugging opportunites are inexistent and I have not the slightest knowledge about the used tools… and thus no hope of installing Pedros’s modifications or improving myself Marco’s firwmare!!!
This is very frustrating…
Patrick
Hey, Patrick,
I had exactly the same behavior you describe before I changed the compile optimizations.
( see viewtopic.php?p=10657#p10657)
You didn’t revert the makefile to the older one, or something like that?
My HW version seems to be 2.6.
I’m still hunting the initialization problem, with my limited knowledge and using “caveman” debugging techniques.
We’ll see…
Hello Pedro
The behaviour is the same when I install directly your HEX file, so it’s not à compilation problem…
Patrick
You’re right. (that was a dumb question)
Still looking at the problem…
v1.3
- initialized FrameMode variable at creation
Can now start correctly everytime. (at least on my DSO)
If you have problems with bogus display in full-buffer mode, try saving settings and restarting.
dso203_gcc_v1.3.zip (395 KB)
Glad to see new activity.
It’s quite possible to realize HW debug for DSO4. It works well under IAR via ST-Link and J-Link. I did it in Dec 2011 and now forgot some details. But I upload all my exercices, so anyone could to restore it. I also made COM port module for DSO and draft VB shell for pushing DSO keys, as they are unaccessible in debug mode.
http://ifolder.ru/28843296 here are the sources.
Hello
Great! Unfortunately not for me… the behaviour is now 100% of the time “0.5 sec. parasites, then freeze”. It looks like that:
I have tried the following:
- FPGA 2.22 and 2.61
- original SYS 1.51 and Marco’s SYS 1.50 1.6 (file SYS15116.hex)
- reinstalled original APP and saved settings. did the same with Marco’s APP 1.8. Tried different settings.
The picture looks always the same but the details of the spikes vary every time. After switching off all channels in Marco’s APP, saving settings and reinstalling Pedros’s APP, I get the same picture without the traces, i.e. only the grid and a thin blue horizontal line (I guess the trigger level) - what I then notice is that the whole screen scrolls a little to the left before freezing.
It really looks like an initialisation problem. I would bet:
- configuration (settings) in flash memory is read at the beginning
- on Pedro’s DSO it is (by chance) correct, on mine it is not (don’t ask me why)
- no error handling on reading the configuration, values are used without checking, mine are not good ==> pointer to nirvana and crash
- can never save correct configuration because the app never runs long enough for that…
- for some reason, writing the configuration with the standard APP or Marco’s does not solve the problem - and both have no problem with this “wrong” configuration
Other idea, in my opinion much less likely: not correctly initialised variable, on Pedro’s DSO the value at reset is OK, on mine not, e.g. because of a hardware difference.
Pedro, what do you think about this behaviour? Is there any error checking on the configuration values read at startup time?
Patrick