Please don’t think I’m complaining, I really appreciate all the effort everyone has put in to make this a useable tool. I have now worked out that the measurements only go silly if you have FFT on AND connected to the PC, no real problem to work round. I was also only wondering if the flickering, I described a couple of posts ago, was to be expected or whether I had more stuff to instal or upgrade.
Yes, it’s just lazy programming.
When the waveform box is “printed” to the screen, it’s done drawing complete vertical lines (with the waveform dots in the middle) from left to right, so that erases the previous screen content in that area. Only then is the text printed on top of that.
To eliminate the flickering of text written in the waveform box, the text witting would have to be incorporated in the line drawing sweep itself, or something like that…
Yeah… here is some code for that if someone is really bothered by the flickering
https://svn.kapsi.fi/jpa/dsoquad/logic/gui/
vblack comes to the rescue
No flickering any more.
[code]v1.22
- FFT flickering fix, with improved drawing code (vblack)[/code]
Latest download: https://github.com/pmos69/dso203_gcc/zipball/master
Thanks, this looks so nice now. I appreciate all the effort everyone has put in to this program, it makes the Quad a useful tool instead of a toy. Thanks again, Mike
Hi all,
Is there thread with current list of major bugs, which needs to be fixed? I can try to fix them.
Well, apart from the hardware part, which has major flaws but is out of our reach, and the triggering issues that are part of the fpga, the calibration, or better yet, the measurement corrections part also has major issues, especially in relation to the vertical alignment.
Not having easy access to extra equipment to help test this part has kept me from looking at it.
Can I mention a couple of things?
Having installed the “flicker free” App I now notice that on the digital inputs vertical transitions are in a different colour from the trace colour. ie with either a square wave input or a saved waveform on Ch4 the horizontal line is green but any rise or fall appears in cyan, Ch3, normally magenta, shows white on vertical transitions, any ideas?
The bug that affects me most is the horizontal misalignment of the digital and analogue channels. The analogue appears delayed from the digital when fed with the same input. The displacement is 1 graticule dot and doesn’t change with timebase settings which suggests this is not a signal timing error through the input circuitry but possibly a sampling problem, a solution would be great.
Regards Mike
Just one dot/sample?
Which one is delayed (further to the right)?
I fix the color issue.
Regarding issue with Analog/Digital delay. On my DSO I have digital delayed a lot in compare with analog (See attached screenshot).
That’s a huge delay
Does the timescale make any difference?
Some people mention 1 sample delay, others 5 samples, and now this…
This even seems to be the opposite of what others are seeing.
EDIT: Just checked my quad and have results like previously reported: About 5 samples delay on the analog channels compared to the digital channels.
Timescale makes no difference - Delay is constant.
[code]v1.23
Yes in my case timescale make difference. On my DSO it is looks like signals really captured with this delay.
Hi, I can’t get the latest app (the one that fixes the trace colours) to run on my quad, comes up with err message and the quad crashes on boot. Reloading the “no flicker” version restores operation with no flicker but wrong trace colours. Have downloaded and unzipped a couple of times but still has same problem so I don’t think I am doing anything silly, any advice?
I will investigate my timing errors more thoroughly and post info as soon as I have time, maybe later today. Mike
Hi, I can’t get the latest app (the one that fixes the trace colours) to run on my quad, comes up with err message and the quad crashes on boot. Reloading the “no flicker” version restores operation with no flicker but wrong trace colours. Have downloaded and unzipped a couple of times but still has same problem so I don’t think I am doing anything silly, any advice?
I will investigate my timing errors more thoroughly and post info as soon as I have time, maybe later today. Mike
Maybe i messed up the hex. I’ll check that.
Done
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.
- Now has full range of 0-255 instead of 0-200
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…