DS203 quad user interface design

[DrV]

Gabonator,

It is really good news to see you back in the forums.

I have been making intensive use of your app/interface for many purposes and you made it: the device is useable, simple and neat. There other developers focused in measurement accuracy/reliability but IMHO the device has to be easy to use also.
There are BASIC features that need to work fine before thinking of things like X/Y mode or FFT analysis.
My priorities with this device are:

1. Ease of use -> DONE
2. Readings accuracy
3. Rest

So I am really pleased your next aim is to fix the calibration issue.

I cannot help with the code as I am not familiar with these devices, however I can help with beta testing (test on real devices, not just lab tests with signal generators).

Regarding the CALIBRATION.

Is there any way to access the calibration subtask from your app? If I could start the calibration task I could run some tests and get linearity curves and so.
If not, could you make an app release with that feature so we can give it a try?

It is clear that a single compensation point is a joke as the device is not linear at all.
Are you using 6 compensation points for each grid? (V scale)
If it is working fine without moving the Vpos I think it is a good achievement for now and it is worth a try.

Thanks and good luck!

[gabonator1]

Hello again,

and thank you for your posts, it is a big motivation for me to continue with this project, when I see more and more people involved in my project. Some posts were about the compilation on linux platform. I can't remember exactly, but the script "arm_linux/Makefile" and necessary changes in "common/build.mk" were done by some guy here on this forum. When I am looking again to these files, it seems there are some errors like wrong slashes, and so on... Unfortunatelly I am not keeping the linux build scripts up to date, because I don't have a linux machine to test it. It maybe needs some light changes, so if someone finds out what to change to get it working, please let me know, or push me a request on github with your changes.

About the line ending. I thought that github autmatically changes the line endings to linux style when committing the files to the server. Maybe it does not know what to do with ".hex" files. So again, if you have any idea how to fix this problem, let me know... Installing a windows virutal machine just for compiling the source codes is stupid (sorry for this word). After all gcc was initially developed for unix platform, not for windows

I am currently working on the calibration process, during the weekend I have made a lot of measurements to find out what will be the best approximation algorithm for correcting the ADC values. Yesterday I made some graphs to review these measurements, but something went wrong and for negative voltages I get incorrect values. If you are interested, here is a screenshot:

and here is an interactive view of this graph:
http://pub.valky.eu/calibbad/meas9mage.html

Every curve represents different Vpos setting (from -20 to 280), on the horizontal axis there are voltages from -2.0 to +2.0 with step 0.1V. On the horizontal axis there is measured ADC value. These ADC values were calculated as average of full sampled waveform.

I am still having problems to understand, why the negative voltages are measured incorrectly. I used RIGOL signal generator as voltage source. I was changing the voltage offset of sine wave with amplitude set to minimum (it did not allow to set the amplitude to zero, but it was under 0.4mV or so). This DC voltage was measured accurately with UNI-T digital multimeter. And this voltage was connected with the A channel probe of DSO.

Maybe it has something with the ground loop...

To answer your question, no currently there isn't any way to calibrate the oscilloscope from the application. After I finish initial measurements and I will find a good correction algorithm, I will prepare a calibration application. But this app will be implemented probably in html/javascript with the use of DSO SDK, due the lot of calculations in floating point arithmetics.

gabriel

[alys]

gabonator. If in your software you want to use lists and have functions like getPrev, getNext, getFirst, getLast, for this is a class DoubleLinkedList which has a structure -
class DListElement //element of double linked list
{
DListElement *_prev, *_next; //here are pointers to prev and next element
...//your data
DListElement *get_next(){return _next;};
DListElement *get_prev(){return _prev;};
}

class DLinkedList //the double linked list itself
{
DListElement *_first, *_last; //pointers to first and last elements of the list
DListElement *get_first(){return _first;};
DListElement *get_last(){return _last;};
}

so you do not need this iterations over single linked list, as you have in your windows.
do not invite bicycle data structures must be suitable for algorithms.

also why are you trying to implement MS Windows style of UI objects, messages and functions, if this processor has only 64k of ram. MS Windows style is a C-style of GUI implementation, but you are using C++

[kb1gtt]

I enjoy your GUI, and your features. I can't wait to see what else you come up with, and I wish I were able to help. Keep up the good work.

[gabonator1]

Small update about the DSO calibration. As I mentioned I was measuring each combination of input voltage and channel vertical position. The dependency of ADC output from input voltage is pretty linear (at least in the range 16..240), so the only issue to achieve small error is compensating the vertical position. For each position I was calculating the linear approximation of measured values (adc => voltage) with well known formula Y=k*X+q. The "q" coefficient is function of vertical position and is pretty linear. The interesting thing is, that the "k" coefficient is really strange and I had to use 6-point linear approximation curve for it. Everything is calculated in HTML/javascript and all the charts / coefficients you can see here:

http://pub.valky.eu/dsocalib/calib_display.html

The javascript calculates everything necessary and produces directly C code that can be compiled with the DSO. Don't worry, it was only for the development/debugging purposes. I am working on onboard calibration algorithm, but it doesn't achieve so nice results because the internal generator of DSO cannot generate negative voltages. Currently I was able to calibrate my device in 200mV range and the results look really good!

Anyway, if it doesn't measure accuratelly, you can play a snake game I designed for DSO and is part of the User applications of latest firmware

Regarding the double linked list that alys mentioned. Yes I know about that. But I was thinking hard to design the CWnd class as simple as possible to keep the memory requirements as low as possible. Reverse iterator is only used when the back key is pressed and the window system is looking for previous children to give focus to it. Instead of having pointer to the previous children I decided to find it programatically by iterating the window parent's children. It is slower, but it doesn't matter, because the user can't notice it. So the pointer to previous window is redundancy and I was trying to remove all redundancy I was able to find.
The window system I designed is lightweight and easy to maintain. I am not using any dynamic allocation or other C++ things. I used only the C++ features to keep the code nicely organized and easy to read. I am not C/C++ expert, but I am sure that by using C++ your code will not require more than 10% extra rom/ram than the same project written in C.
Maybe the seeedstudio team will design new version of DSO with more powerful CPU and this will not be an issue at all Currently the binary size of my firmware is 64kB, so the half of the program space is still available....

Gabriel

[glikar]

When you convert the line endings of the hex file to DOS style (CR/LF) it works.

Been triying to use this app for 2 months and I just made it... had not thought of this simple thing.

1.download the file
2.open it with notepad++
3 Edit>EOL Conversion > Windows Format.
4.Upload it to the DSO
WIN

EDIT:

I am using marcosin's latest release (1.8) and I have overwrited his app with gabonator's

Link for the .hex file already converted to DOS type http://www.megaupload.com/?d=K1R82U7V

cheers

Good find! Unknowingly, I'm sure this has happened before. Using git in a linux terminal then over to xp in VirtualBox.
Thanks!

[gabonator1]

I finally figured out how to keep the line endings on the hex file correct. By calling this command "git config core.autocrlf false" from my github repository folder, it will commit the files to the github server without any changes... And when you download it, it should be the same file as when I was comitting it.

As a quick download link for latest hex file, you can use this one:
https://raw.github.com/gabonator/DS203/ ... P_G251.hex

[alys]

Gabonator! You mentioned that genarator gives signal above zero only. Connect generator and a probe via capacitor.
I missed the reason why device is so unlinear. But i see few experiments with it.(I have not device itself, so it is only imaginations).
1. Battery test. Take AAA(AA) battery and try to measure voltage. it must be about 1.5 volts in direct polarity and -1.5 in reversed. if it is so(omitting details that battery has not exactly 1.5v), then linearity in point 1.5/-1.5 looks good.
2. Test with sawtooth signal - connect generator and probe via capacitor, the waveform must be really linear and visually symmetric relative to zero level. if it is so...you really do not need any calibration.
anyway you can develop a calibration application based on measurements of "sawtooth via capacitor" measurement data.
regards.

[DrV]

Ive been busy for some weeks and just found this.
The first release was amazing but this one has impressed me even more.

I will give it an intense try, during the last weeks I have been using the latest comunity software compilation and I have been missing your interface SO much.

Thanks!

[glt]

Is this APP_G251 version based on pmos69 APP_G251 version with a new GUI?