New SM Oscilloscope

[trogluddite]

Moved this here from it's old home to make it easier to get at.

It's a new oscilloscope module done as a real-time simulation of an old CRT 'scope...

Scope Grab.png (37.13 KiB) Viewed 3844 times

CRT Scope 1_1_2.osm

(128.53 KiB) Downloaded 524 times

...you can only use one of the 'Scope Display' modules per schematic, but you can have as many 'Scope Trace' modules as your CPU (or eyes) can handle. All traces show on the same display in perfect sample-accurate sync. You must have an audio driver active for it to function, and the Display and Trace modules must all be on the same level of your schematic for the wireless links to all work.

Also has...
-Automatic calibration to fit your signal range on screen.
-Triggering to enable traces to be synchronised to green triggers or rising/falling transitions in any trace.
-Single Shot mode to freeze the next scan after a trigger is detected.
-Timebase can be set in either samples or milliseconds (click the label to choose which)
-Screen splits for the traces so you can position and scale them any way you like.
-Display module can be resized, and the controls can be hidden for more screen space.

There are some instruction bubbles inside the schematic telling you how the functions work - but just post here or PM if you need help/have suggestions/spot any bugs.
Oh, and watch your CPU if you make the display very big - like all SM animations, it can be a bit greedy.

[Dell]

Cheers Trogluddite!

[trogluddite]

Just upped v1.1.1. (in the top post)
-Fixed a problem with the samples/milliseconds timebase getting garbled on saving and loading.
-Screen redraws are now stopped whem you've taken a 'Single Shot' sample to avoid sucking unnecessary CPU juice.

Also added another little module to play with, for analysing the spacing and frequency of SM triggers - or it can count triggers from transitions in a stream (like the scope uses) - it's done in code for sample accuracy, so needs audio active to work..
You can see the average interval and frequency, the max and min tick durations, and (very approximately) the standard deviation (an average measure of how much things vary from the average reading - i.e. how bad is my jitter).

It's a real eye opener for any regular tick100 users - mine is tick60 at best, with a standard deviation of about 50% from the average. With the scope running as well, it drops to about tick30! Worse still, some ticks only last 9 samples, but start interacting with the mouse and I get some as long as 1/4 second!!
So animating more than a tiny area with a tick100 seems a dead loss, as the animation slows it's own frame rate - this is on a QuadCore, so hardly a puny machine.

Tickers, tikker, tikka - Mmmm, curry, now it's time for supper....

[Dell]

Nice.

I shall give it a go once I am on a Windows Machine.

Cheers!

[aliasant]

Just upped v1.1.1. (in the top post)
-Fixed a problem with the samples/milliseconds timebase getting garbled on saving and loading.
-Screen redraws are now stopped whem you've taken a 'Single Shot' sample to avoid sucking unnecessary CPU juice.

Also added another little module to play with, for analysing the spacing and frequency of SM triggers - or it can count triggers from transitions in a stream (like the scope uses) - it's done in code for sample accuracy, so needs audio active to work..
You can see the average interval and frequency, the max and min tick durations, and (very approximately) the standard deviation (an average measure of how much things vary from the average reading - i.e. how bad is my jitter).

It's a real eye opener for any regular tick100 users - mine is tick60 at best, with a standard deviation of about 50% from the average. With the scope running as well, it drops to about tick30! Worse still, some ticks only last 9 samples, but start interacting with the mouse and I get some as long as 1/4 second!!
So animating more than a tiny area with a tick100 seems a dead loss, as the animation slows it's own frame rate - this is on a QuadCore, so hardly a puny machine.

Tickers, tikker, tikka - Mmmm, curry, now it's time for supper....

Now its getting interesting

The Trigger counter....thingy.

When I first launched it I got about 50/sec and that is really lousy but then I had a look at your readouts and realized that you didnt just redraw the numbers but also the black background behind every readout. I cached those and now I get about 60/sec. Something to think about perhaps

Then I tried the frequency part and realised that this one is actually tracking the freq pretty good.
Some oddities though. If I set a Sin at 1000Hz I will get the aprox result of 1021Hz.
Average Samples are 47.
Shouldnt Average Samples at a samplerate of 48kHz and a freq of 1000Hz be 48?
Maybe something wrong in that math. Maybe simply add a 1 to Min, Avg and Max Delta? On my system that corrects the errors.
Next step could be to had a 4th result for current freq tracking? That way we have a sharp frequency tracking system?

Love it Trog.

[trogluddite]

Thanks for the pointers there - I'll have another look at the algorithm, probably just needs some of the timer maths re-ordering to catch sample No.1.
I've been looking into changing the display redraw stuff already - I think it would be better to have a mode where the values are not displayed continuously at all when measuring green ticks, but they just get shown after a certain time of sampling the data. The whole re-draw thing makes it all a bit 'quantum physics' - you can't have a module that updates continuously that doesn't affect its own timing results - the counter used as a 'tick to stream' converter most likely affects the timing results too.
Having said that, precise results for green ticks are never going to be that useful in reality - it's maybe good to have a way to measure in a relative/qualitative way (to check for improvements in .osm redraws, say), because simply measuring CPU load tells you nothing about the variation in timing - but precise values can only ever apply to one specific PC setup - I can force my results to change by opening a Firefox window, for example.
A stream to frequency convertor is easy though (I think there may be some already on the forum) - but measuring zero-crossings etc. can be notoriously unreliable with harmonically rich waveforms that have more than one zero crossing per cycle.

[trogluddite]

v1.1.2 now in the top post.
No changes to the 'scope, just updated the timing analyser following aliasant's suggestions. The readouts now only get shown after you stop the calculating engine, so that there's no unecessary CPU load. Also changed the engine so that it interpolates triggers that don't fall exactly on a sample - there's still a small inaccuracy from the interpolation and rounding errors, but it's pretty close now - feeding 1000Hz sine comes out as 44.10 samples at 44100 sample rate just like it should.
Also added the requested audio to frequency module - been having fun using it to drive some oscillators, like an old Roland GR guitar synth - as long as you heavily LP filter the guitar and play very cleanly, it tracks surprisingly well.

[Jay]

That's some fine work right there Trogluddite! really cool mate!

I have made my little opto-coupled test osc board so i will play around with it and see how well this works with your scope and see if it reproduces the traces from some circuits!

Thanks for this marvel

Best Regards
Jay

[trogluddite]

Thanks, glad you like it

Just a shame that .exe exports have such limited access to the soundcard - and even as a VST, you're unable to resize the screen or have easy routing from multiple tracks. Kind of makes it awkward to use unless you mind having to use SM as your host environment all the time.

[DigitalWhiteByte]

Thanks Trog, I had lost this your wits