Got my DSO Quad a few weeks ago, and it has so far been brilliant. There seems to be something wierd going on when using normal or single mode though, where even though the screen refreshes as soon as the trigger fires, it still shows the old trace. This is particularly noticeable when the time scale is changed to try and look at a feature in the pulse properly, the trigger fires again on the pulse, but the even though i’ve changed the time scale, the waveform looks the same. Playing around a bit more, it looks like it might have something to do with filling the buffer, when the time per div is set to 100ms or so, i can take some time for the buffer to completely fill, or something. Using the scan mode at this sort of resolution is particularly useless. On a similiar note, when a trace has been caught, trying to scroll through the buffer doesn’t always work, the trigger line and the background scrolls, but the trace doesn’t. Again, only with certain timescales, above a few ms per div, i think. Anyway, just thought i’d post to see if anyone else can confirm this behaviour, and if we can get a fix.
I’ve tried the single mode and was disappointed. It doesn’t work properly and its behavior is similar to that one you have just described. So I confirm that there are problems with SINGLE mode and this problems make impossible using this mode.
The original buffer draw code has a shed load of bugs in it . The capture buffer is correct but when it is drawn and scrolled it does not update the window region correctly. I have re-written the screen write for the real time DSO buffer, and this will be in the first release (coming soon) of an alternative DSO software for the Quad.
Here is test build based on slightly modified dsoquad by tmbinc sources. “scan” mode was changed to produce output in real time. Don’t try to scroll horizontally in this mode, data is captured only to the visualized portion of the buffer.
Application is compiled for slot 2&3
Flash with standard procedure.
Start with POWERON+KEY2. app2_v251bag.zip (34.2 KB)
First of all, thanks to Skyrift for the detailed description of this bug: according to me this is the major problem of this device, as it makes dso USELESS when time scale bigger than 1ms is selected (with 10ms the screen is refreshed only once per second and becames progressively slower when bigger timescales are selected).
@adrian.inspiritive: as far as i understood, you are building a “alternative DSO software”; how is going on?
@bag2: i tried your .hex loading it with standard procedure (POWERON+RUN/HOLD_KEY, copy .hex into DFU disk, waiting for .rdy file), but it seems to behaviour exactly like the original version, with the huge delay during the drawing of the signal. Did i misunderstand the changes in your version?
Because the “Application is compiled for slot 2&3”, you’ll have to hold down Button 2 every time you turn on the power, to get the custom app instead of the built-in (slot #1) app.
Bag2, i have no words to thank you for this result: it works like a sharm! For this bug i was seriously thinking to ask for refund, but with your work you changed this stuff in something useful.
I hope that at seeedstudio someone will understand how important this fix is and will include it in the next official release.
Are you thinking about to share the source code? i’m really curious to compare it with the original to see exactly where the issue come from.
And just about the code: from the official source code it seems that Sync. Mode “NONE” does exactly the same as “SCAN” (from Process.c):
…
break;
case NONE:
case SCAN:
__Set(TRIGG_MODE, UNCONDITION);
Process();
break;
…
as after “case NONE:” there’s no “break” statement (i guess this’s another bug); hence, why not using NONE mode to implement your fix, leaving the original behaviour in SCAN? or maybe i’m missing something and NONE mode is really different from SCAN?
. The capture buffer is correct but when it is drawn and scrolled it does not update the window region correctly. I have re-written the screen write for the real time DSO buffer, and this will be in the first release (coming soon) of an alternative DSO software for the Quad.
.