Rectified and Attenuated RC Low Pass Filte

SimulIDE_1.0.1-R1374_Win32

On the previous schematic, test_2a.sim1, I added a rectified attenuated RC filter to drive the MCU pin C1 (ADC1). The real trace of the voltage at that pin (C1) looks as on the image, test_2b.png (for mains peak voltage equals 311V, 220Vrms). The MCU internal limiting diodes have no role in this case.
I couldn’t let the oscilloscope display it while debugging test_2b.asm (which is a copy of the previous one, test_2a.asm).

I also noticed that by decreasing the mains voltage peak from 311V to 200V for example, the 50% duty cycle at pin D3 (INT1) decreases too appreciably. On a real board, the duty cycle stays close to 50% while varying the mains voltage.

On the previous schematic, test_2a.sim1, I added a rectified attenuated RC filter to drive the MCU pin C1 (ADC1). The real trace of the voltage at that pin (C1) looks as on the image, test_2b.png (for mains peak voltage equals 311V, 220Vrms). The MCU internal limiting diodes have no role in this case.
I couldn’t let the oscilloscope display it while debugging test_2b.asm (which is a copy of the previous one, test_2a.asm).

About that "bump", it seems a problem with breakdown voltage in the diode model, try setting it to 1000 (for example).
Let me have a closer look to this.

I also noticed that by decreasing the mains voltage peak from 311V to 200V for example, the 50% duty cycle at pin D3 (INT1) decreases too appreciably. On a real board, the duty cycle stays close to 50% while varying the mains voltage.

This seems a problem in the properties update.
By now you need to set "Middle Voltage" again to 0.

This seems a problem in the properties update.
By now you need to set "Middle Voltage" again to 0.

Solved at trunk Rev 1393.

About that "bump", it seems a problem with breakdown voltage in the diode model

Solved at trunk Rev 1394.

I fixed temporarily the diode breakdown voltage by setting it 500V (instead of the default 0).

After commenting the infinite loop by commenting the line 563 in test_2b.asm, I noticed that the traces on the small and expanded oscilloscope (which are well now) are not moving, after a while, in time with the simulator (they look somehow frozen).
You may like testing this by setting breakpoints on two lines (or more) on the list of RJMPs (from line 1951 to 2260).

After commenting the infinite loop by commenting the line 563 in test_2b.asm, I noticed that the traces on the small and expanded oscilloscope (which are well now) are not moving, after a while, in time with the simulator (they look somehow frozen).

I don't understand the problem.
On one side the simulation is frozen if the debugger is not running.
In any case if there is a trigger in the oscilloscope then the traces don't move.

arcachofo wrote:

After commenting the infinite loop by commenting the line 563 in test_2b.asm, I noticed that the traces on the small and expanded oscilloscope (which are well now) are not moving, after a while, in time with the simulator (they look somehow frozen).

I don't understand the problem.
On one side the simulation is frozen if the debugger is not running.
In any case if there is a trigger in the oscilloscope then the traces don't move.

Yes indeed, the trigger, as you said, gives that effect, that is the traces seem not to move though they do.

For instance, as you know, the traces on a real oscilloscope (not as in the ideal case of SimulIDE) are usually noisy. Even the relatively very small amplitude of their noise shows that the screen is refreshed by consecutive trigger signals.
I forgot that the traces are noise-free on the SimulIDE oscilloscope.