# LTSpice DC Block capacitor

I saw some other questions here about DC Block capacitors in LTspice and none of them helped me with my problem.

The question is very simple, why we have a DC offset when using capacitors as DC block in LTspice (even with a parallel resistor)?

The facts:

With Stop time = 10 m (very large!), Maximum Timestep = 0.01 n (very small!):

SPICE log (no floating nodes):

Simulation command:

Is there anything I should fix?

Thanks a lot!

• Looks like the mean value is about 0, once you take the uneven mark-space into account. What's the specific problem you are asking about? May 11 '20 at 21:27
• Hi Brian, thanks for your comment. The average value is -12.887mV and not zero as expected. I just want an average value equal to zero. May 11 '20 at 21:42
• @astable It's because of the way that PULSE works in LTspice. Have you read the documentation about what it does when you specify "0" for the rise and fall times and how this relates to the time HIGH and the time LOW?
– jonk
May 11 '20 at 21:43
• Hi Jonk, yes. As you can see in the SPICE log these limits are generated automatically. FYI: Limiting rise time of source v1 to 1.5625e-009 Limiting fall time of source v1 to 1.5625e-009 May 11 '20 at 21:47
• @astable Then think more closely, here. The ton is fixed by your requirements. The tperiod is also fixed by your requirements. So the 5% rising edge and the 5% falling edge are subtracted from the toff period. Thus, toff is 40% but ton is 50%.
– jonk
May 11 '20 at 21:52

Perhaps we shouldn't trust LTSpice on-screen graphing, but I can't help but suggest that using eyeball techniques, duty cycle is not 50%. I have offset the graph (in orange) to see that pulse width spends more time "high" than "low":

• Wow! Thanks to your eyes of eagle the problem was solved!! You're right. we must subtract from Ton the needs of Trise and Tfall. Due to this difference of Ton and Toff some residual current remained in the capacitor and then it integrated the voltage plus a constant value from before: \frac{1}{C} \int i(t)dt+cte. The average value is always different of zero, but at least +V is equal to -V. May 11 '20 at 23:33
• seems @jonk got there first. Ton gets priority, and seems to be 50%, while Toff takes up the slack from Tperiod, so Toff gets short-changed in this case by some part of Trise and Tfall. May 11 '20 at 23:43
• Yes, @jonk was right, and when he posted his answer, I didn't understand the relationship between his comment and the integration of the remaining current in the capacitors. I just understood when you showed the graphs. My bad. May 11 '20 at 23:53
• Nice way to make it more clearly visible. May 12 '20 at 12:29

Adjusting Ton to take into account the need for Trise and Tfall the maximum voltage and minimum voltage can be matched. See Glen_geek comment and Jonk first comments for more detail.

Even if you make the source with a perfect average of peak/2, given your circuit you'll still see a tiny amount of DC in the signal because of the resistive network. If you remove any resistances, set any internal parasitics to zero, all, but keep R1 (to allow discharging), the error will be diminished, but then the floating point rounding will have its say. And if you switch to the alternate solver, which is supposed to be about 2x slower than the normal solver, but with a 1000x greater internal accuracy, you'll still see differences because nothing is perfect.

• Did you notice the .TRAN card? He's selected only the last 10 ns of a 10ms period.
– jonk
May 11 '20 at 21:50
• @jonk Darn it, I missed it, I'll modify accordingly. Thank you. May 11 '20 at 21:51
• @aconcernedcitizen I've tried the alternate solver and also with no resistors before post the question. With these "fixes" I can reduce about 1/10 the average value, but it still strange. The maximum value is 169.02727mV and the minimum value is -206.57188mV. There is always a boring DC offset. I will try to post this question on some forum with LTspice experts. Thank you anyway. May 11 '20 at 23:02
• @astable Have you certified that the Ton and Toff are equal to each other, yet, in a run?
– jonk
May 11 '20 at 23:37
• @astable That's what my very FIRST comment was trying to get you to look at. Glad to see it done, now.
– jonk
May 11 '20 at 23:43