Averaging in Scope

I thought I had read the request already somewhere, but I did not found it.

It would be great have an activatable averaging for the voltage shown at the scope. Best would be finite and infinite impulse response filters. This could solve CPU load problems when using RC components to average PWR in order to see the analog result. There, an average of the last x Milliseconds would be much faster.

Alternatively an individual component for such an averaging would be good.

I thought I had read the request already somewhere, but I did not found it.

I don't remember something like this...

It would be great have an activatable averaging for the voltage shown at the scope. Best would be finite and infinite impulse response filters. This could solve CPU load problems when using RC components to average PWR in order to see the analog result. There, an average of the last x Milliseconds would be much faster.

I don't think that the oscilloscope itself adds a lot of cpu usage.
In RC circuits, most of the cpu load is generated by the activity created by the RC components.
If you can average in the milliseconds range then you probably can reduce a lot the Reactive step, and this will actually reduce the circuit activity and the cpu load.

Alternatively an individual component for such an averaging would be good.

For averaging this would be proper solution IMO.
And now you can do this easily with the new "scripted" component:
https://simulide.forumotion.com/t990-custom-components-scripted

This new type of components is still in development and have limitations, but should work very well for simple analog components.
Here is an explanation of how to create one (there are examples in trunk version):
https://simulide.forumotion.com/t1185-equivalent-to-cd4046-phase-locked-loop#5222

I had a atmega328 generate a 3phase signal via its Timers (PWM).

At this point I saw the following:
Once I put this three outputs on scopes I get a speed of 43%, with a RC filter it is about 25%.
Once I use instead of the scopes a LED, the speed is 70%, and with a RC filter 32%.  

Now I found out, that the drop is not based on the scope it self, but on some of the settings: Once I fiddled around with Time/Div, Volt/Div and Volt Pos, then the speed is dropping.

Ok, this will not be solved by an averaging...

But still strange.

I had a atmega328 generate a 3phase signal via its Timers (PWM).

Depending on the PWM frequency that can be a lot of changes in the circuit,  so anything you add to the outputs will be slow.

A LED can be very fast if you use the "Grounded" option, if you use resistor + ground it will be much slower.

If you are using the development version it is quite fast indeed, just try it in 1.0.0 and compare...

There is still some optimization that could be applied to MCU outputs in cases like this, but not implemented yet.
This could reduce a bit the cpu load coming from the AVR outputs, but not from circuit activity.

EDIT:
Last trunk build ( R1530) uses fast output for AVR PWM (optimization mentioned above).
It is a little bit faster now, but not much.

It was me:
https://simulide.forumotion.com/t1164-average-time-of-meters#5116

I also mentioned it at the end of post #10 on the thread:
https://simulide.forumotion.com/t1206-time-as-a-variable-in-the-function-element#5329

I used the version 1.0.0. R1232.

As I wrote, when I rechange the properties of the 4 scopes the speed nearly doubles and is about the same as with LEDs (classic LED setup with connection to ground and shunt resistor).
What confuses me, is that 4 scopes can reduce the simulide performance about 50%...

I attached zip file includes the following files:
- fastSimulation.sim1
- slowSimulation.sim1
- Master.hex
- Slave.hex

The hex's are for the similar named atmega328's in each of the simulations. Once the hex are loaded and the simulation is started the Hd44780 shows first a "splash screen". This is shown with the same simulation speed on both sim1 files (at my WIN10 system: 100% speed, 70% load). Once the temperature and illumination figures are shown at the display the slower simu has 50% speed at 70% load whereas the faster shows 100% speed at 70% load... The only changes I'm aware of between the simulations are the properties of the scopes.

I can't reproduce your results.
There are minor differences between the two circuits and with/without oscilloscopes.

50% speed at 70% load does not make much sense: if the speed is below 100% is because the load reached 100%.
Not sure if this is an error in the program, but I can't reproduce it.

But at 3:09 (slowSimulation) the speed is around 60% with load at and around 70% and at 0:42 (fastSimulation) the speed is 100% with load at around 70%...

So, the clip just shows what I also saw. Shouldn't the speed be approximately the same?

Yes, you are absolutely right. Seems that I was a bit too focused in the load value

I was scratching my head because I could not reproduce the results in the video again...

And I found that it only happens while I'm recording the screen, so  this must be an error calculating the speed when the cpu is overloaded.

Oscilloscopes are updated in a different thread that the simulation, but if you reach the maximum of your cpu then everything goes down the hill, the application starts to miss timer events or the timer can't keep the speed.

I will try to figure out how to solve this, but I don't even know what is exactly happening.


Changing the oscilloscope values can make the simulation faster or slower.
For example the oscilloscope at the bottom has 3 active channels, then:

FastSimulation circuit: at 1ms time div, this is 10 ms for the screen, so around 10*31k*2 = 620 k samples per channel, so 1.86 million samples to read when updating the screen.

SlowSimulation Circuit: at 5 ms time div, is 9.3 million samples.

Also setting voltage offset for example add some calculations, making it worse.

Finally I understood what is exactly happening.

The GUI is indeed overloaded and the timer can't keep the speed, it is firing in the 60-70 ms range instead of 50 ms (in my PC).
Usually what happens is that the simulation is slower than the GUI if the circuit is complex or has high activity, but in this case the simulation can still keep real time, so "load" is < 100% but the GUI can't keep the target fps.

This is somehow an extreme case: for this circuit the oscilloscope Time Div should be around 10 us and only 1 oscilloscope, this reduces the number of samples to deal with from several millions to a few dozens and the GUI runs fine.

But it can happen in some other case that the GUI gets overloaded.
A solution in cases like this is reducing the FPS value in Circuit settings.
And in very extreme cases or very slow computers then there is not much to do.

Thanks for the detailed investigation. In the given simulation, the idea was to see the duty cycle of the PWM at PWM period in some of the scopes and the RC low-pass filtered long-term sine wave in others. But somehow this ended in the given amount and setting of the scopes.

I try to remember this, when I again have some of these issues ;-).

But anyhow, it is a good thing that there is no bigger issue behind this.

I was not aware about this situation, so it was interesting.

the idea was to see the duty cycle of the PWM at PWM period in some of the scopes and the RC low-pass filtered long-term sine wave in others.

With RC filters the simulation will slow down a lot.
But doing a filter with scripted component is quite simple and fast (trunk version).
I added a function to get the simulation time and made a very simple duty->voltage filter, not perfect but does the job: