cyto wrote: there certainly is a timing issue... ...ie. less than 10sec - I'm sure this is a trigger issue)
I've had a quick look, and I'm pretty sure that you are right about the triggers.
For a 10s window, the sample block size is just over 1000 samples - so the output values are changing at around 40Hz.
Even on a powerful system, a Tick100 rarely manages more than about 60Hz, and this drops dramatically when the CPU is stressed - eventually to the point where you can't guarantee that there will be a trigger during the ~25ms window between value updates. On my 'baby' Atom powered machine, the 'jerky' movement of the display is obvious without even needing to use a 'test signal'.
A larger window size (as you point out) reduces this problem - but the limit of resolution is rather arbitrary as we can't predict what machine the end-user might have.
So a system is needed to cater for the possibility of more than one data point per trigger - kind of like a 'low resolution' version of aliasant's system.... (see below)
aliasant wrote:Trogg PLEASE Help us with this
He he, thanks for the vote of confidence! Have a lot of boring chores to do today, but for the problem above, I think there may be a solution similar to what I use in my older 'CRT scope' schematic. It works something like this...
1) Write the detector output value into a 'mem' using a Wave Write and pointer.
2) When a trigger does make it through the M2F, convert mem->array..
3) Also read the array index (M2F), use this to truncate the array and to know how many pixels to scroll.
4) Draw the truncated graph and scroll.
5) Send a flag to the detector code to tell it to reset to index zero of the mem.
But this still leaves a problem... some samples may pass before the 'reset' flag is seen by the code (it can't be sent until the mem to array operation is done, and green->stream is not sample synchronised). This is why my earlier 'CRT scope' schematic uses two alternating (and slightly overlapping IIRC) buffers. TBH, it's so long since I made that, that I can't quite remember the logic that I used, but I will try to take a look and see if it can be adapted (and hopefully improved).
I think that by juggling the detector block size and the mem array size, this might make a good start for a "dynamic" system. You would be able to juggle between the Draw Graph doing most of the work (to show detail), and the 'scroller' taking over when 'zoomed out' to the the long term 'envelope' - and using Cyto's "block" method should mean that scrolling is always in whole pixels, getting around the 'anti-aliasing' fuzziness problem that I had when I tried this before.