Why is this simple RC oscillating? - Page 1
Forum section: electronics / general

author: eti
author_rank: Super Contributor
timestamp: December 17, 2021, 04:07:02 am
content: I was doing a basic RC in “Every Circuit” and it’s oscillating. Can’t work out why. Any ideas? Looks like a bug,As LTSpice isn’t oscillating with the same schematic.Thanks

author: bob91343
author_rank: Super Contributor
timestamp: December 17, 2021, 04:28:39 am
content: Because simulations suck. Too much is expected of them.

author: eti
author_rank: Super Contributor
timestamp: December 17, 2021, 04:39:13 am
content: Quote from: bob91343 on December 17, 2021, 04:28:39 amLTSpice doesn’t “suck”, I think that this is a bug in E/Circuit.

author: daqq
author_rank: Super Contributor
timestamp: December 17, 2021, 08:13:19 am
content: It's probably too accurate - simulating quantum fluctuations.More seriously, simulations are tricky to implement correctly, you can get weird phenomena such as this and the sources can be strange, seehttps://www.eevblog.com/forum/projects/better-than-a-hartley-oscillator/.Even LTSpice is not perfect, you will occasionally get weird behaviours - an oscillator won't start due to lack of noise, something will oscillate though it shouldn't... Internally, the voltages and other parameters will be stored as a float - a finite resolution data type and time will be discrete, approximations will be made, the computation is done by a huge set of equations... This can have all sorts of weird outcomes. The results of simulations need to be taken with a grain of salt.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: December 17, 2021, 01:12:24 pm
content: Most simple simulators (I don't know about that one specifically, but Falstad is this) just use a fixed timestep, which has the advantage of being very simple to write, and always has a solution (so that it doesn't get stuck doing a more advanced equivalent of "divide by zero"*), but that solution need not be very representative of whatever it is you're trying to model. So you can get spooky things like random transients (actually I wonder if this isn't due to some other hackery), or a divergent result (magnitude grows exponentially), or anomalous time constants.Basically, timestep should be adjusted to within some ratio of the shortest time constant in the system, given desired accuracy and the numerical precision in use. Consider if timestep is say 1/1000th of the shortest time constant: then we expect changes on the order of 0.1% for each iteration, and if we want accuracy within 1%, we need 0.001% error or >5 digits of numerical accuracy to do anything at all. And rounding errors are cumulative so we'll need even more than that. (Not a big deal with 15+ digit floats being standard, but there will always be some combination of settings where that source of error becomes substantial.)It's not obvious at a glance if this is exactly the problem seen in the screenshot, but in any case, one should appreciate, there is nothing physical about the system in question -- it is only a numeric model, and only as representative as it's been created to do. We would like simulators to be something more realistic than they are, but that would also be a huge burden to set up and use; what we have is a compromise between usefulness and capability.*A singular matrix is the linear algebra equivalent of division by zero. To solve for the next timestep, it needs to invert a matrix, and the matrix needs to be conditioned well enough to make that computation. Indeed, SPICE spends most of its time (AFAIK) attempting this for different size timesteps, attempting to find the best-suited case, given the tolerances specified (ABSTOL, CHGTOL, VNTOL, TRTOL, RELTOL). Everything depends, nonlinearly, on timestep, so the results can vary wildly in a general system (i.e. with time-dependent (capacitor and inductor) elements, as well as nonlinear diode, transistor, etc. elements; or both, like junction capacitance or reverse recovery).Speaking of which [usefulness and capability], SPICE was created to model integrated circuits -- as such, inductors and especially transmission lines are something of an afterthought, among other quirks in its design. Not that you can't model inductors, they're fine -- as simple as capacitors after all, well okay slightly less because mutual inductance exists; but, just that it's rare that you'd have been able to use them back in the day, aside from modeling the circuit around an IC, that is. It's something of an abuse that we use it for board-level simulation, and this explains why the default settings are kind of ill suited to such application (mainly that the currents are higher, so CHGTOL and ABSTOL can be raised). For reference, SPICE has its roots in the 70s, with Berkeley SPICE released through the 80s to early 90s, XSPICE early 90s, and various branches since then, mostly commercial (including support for advanced analysis modes, and support for higher level -- more accurate -- transistor models provided by foundries, only under strict license of course).SPICE really hasn't been all that useful over the past some years, unfortunately -- most solutions are pre-baked and you'd really learn very little from a model, if they provided one at all (e.g., SMPS controllers, MCUs*, other ASICs), and those models aren't easy to make; and even a crude (behavioral) model might reveal too much about the inner workings for their tastes. Or they give out the whole shebang (actual transistor-level model), but only with encryption or under strict NDA, and you need compatible software to run it (e.g. HSPICE).*Which have shown up in simulators from time to time! Multisim for example had/has a number of cores supported.The main things where you stand to gain, are modeling basic circuit topologies, switching circuits for example; and things that just need to be dialed in, like tweaking component values in a signal filter, or resistors and tolerances in a diff amp, etc..Tim

author: vk6zgo
author_rank: Super Contributor
timestamp: December 17, 2021, 02:11:18 pm
content: Quote from: daqq on December 17, 2021, 08:13:19 amWe had a posting some time back, where a "radio receiver" circuit used LC tuned circuits at both the non-inverting input & output of an Op Amp.The schematic had the normal negative feedback loop used in the classic amplifier configuration.On LT Spice, it "worked a treat", but in real life, it was an oscillator..The simulated LC networks were ideal, & tuned precisely alike, whereas in the real world, they weren't, & there was phase rotation of the feedback signal."Old Farts" like myself, automatically thought "Tuned Plate, Tuned Grid Oscillator", & knew that would happen.(OK. It's not quite the same, but the vital "phase rotation" is the key to both!)I wonder if anyone has tried to simulate a TPTG oscillator?My guess is that it wouldn't work on the simulator.

author: mawyatt
author_rank: Super Contributor
timestamp: December 17, 2021, 04:16:29 pm
content: Simulations & models can mislead and most older analogish IC designers learn to "Listen to the Silicon" as a means to discover these simulation mishaps (IC design errors are extremely costly, and career limiting!). Recall trying to teach grad students to have a good "view" of the expected circuit nodal waveforms before sitting in front of Cadence (popular IC design simulation package), this way when the simulation is fibbing you'll be able to catch it!! Sadly only a few heeded this advice, we hired those that didRecall a few situations where an unexpected waveform "glitch" appeared at the input of a MOS gate, turns out the simulation was violating "Conservation of Charge", or when trying to achieve the best performing linear MOS switch and finding the 2nd derivative of the channel conductance of the BSIM4 Berkeley MOS model had a discontinuity traced to an absolute value function used in the gate to source/drain definition (had discussions with the model folks at Berkeley about this and later corrected with BSIM6), or working with a new IBM SiGe BiCMOS bipolar model which created an usually good noise figure at certain bias setups, traced to an algorithm which created a negative resistance parameter in the base!!Anyway, simulations and models shouldn't be taken as absolutely truth, unless you are willing to verify such, which usually requires a solid baseline foundation of circuit analysis, physics (especially solid state), and simulation algorithms/behavior, otherwise you are likely to get fooledBest,

author: CatalinaWOW
author_rank: Super Contributor
timestamp: December 17, 2021, 05:08:30 pm
content: This is absolutely the simplest case I have seen that demonstrates the necessity of validating any simulation, whether it is a circuit model, a mechanical analysis, an astronomical model or a flight vehicle. Validation is the process of demonstrating that the simulation represents the modeled system with adequate accuracy over an acceptable range of input parameters.After you have been through a validation process you can accept the results of the simulation with some confidence within the validated range.Simulations are inaccurate for a wide variety of reasons - coding errors, inadequate models, incorrect models and the type of numerical instabilities mentioned above are just a few of the more common ones.In this case some adjustments to the timestep and/or accuracy inputs probably will clear the problem up, but you will have to be aware that until you have done a very large amount of variation with the simulation you will have no reason to believe the results without comparing to actual hardware.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 17, 2021, 06:16:20 pm
content: “Every Circuit” is cute but I have no clue how reliable it is. The web site is just that, cute, and says nothing even about the kind of simulation that is implemented (unless I missed it). This isn't serious.Just use reliable tools. And yes, you still need to know the limitations of simulators. But this one looks unacceptable.

author: basinstreetdesign
author_rank: Frequent Contributor
timestamp: December 18, 2021, 04:24:05 am
content: With every computation there can be a thing known as "chopping error" or "truncation error". This comes from the finite representation of every number in the machine. It usually is very small but results from the fact that a number may not be perfectly represented due to repeating decimals, etc. e.g. 1/3 Volt is guaranteed to be represented incorrectly by a nano-Volt or two. Most floating point calculations, even on home machines is done double precision (14 digits) but that website may be doing only single-precision math (7 digits) for the sake of speed. As well, each iteration of the matrix calculations can result in these as well as alternating +ve and-ve truncation errors and the more iterations that pass the larger the errors can get.

author: EEEnthusiast
author_rank: Frequent Contributor
timestamp: December 18, 2021, 12:37:57 pm
content: Don't use online tools for any serious simulations. Better stick to the well known AMS simulators. P-Spice for TI, LTSpice, Mplab Mindi (Simplis + Simmetrix). Most of these come free with small limitations, except for LTSpice. For faster convergence, try to use non-ideal components like a cap with finite ESR and leakage, Inductor with finite DCR and SRF and so on.

author: Neper
author_rank: Frequent Contributor
timestamp: December 18, 2021, 12:52:18 pm
content: Maybe it's the virtual equivalent of the old adage that homebrew oscillators, on first power-up, never oscillate but homebrew amplifiers always do.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: December 18, 2021, 01:32:34 pm
content: Quote from: Neper on December 18, 2021, 12:52:18 pmYou don't usually have to screw up an amplifier very much to make an oscillator, though. How badly do you have to screw up a passive filter to make an oscillator or amplifier?(Obligatory Simpsons reference)Tim

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 19, 2021, 06:56:18 pm
content: Well you can certainly make a purely passive LC circuit oscillate. At least for a while. But pure RC or RL circuits? I'd like to see that.

author: amyk
author_rank: Super Contributor
timestamp: December 19, 2021, 08:42:49 pm
content: This simulator has someveryweird parasitics...

author: ejeffrey
author_rank: Super Contributor
timestamp: December 19, 2021, 09:09:13 pm
content: Quote from: T3sl4co1l on December 18, 2021, 01:32:34 pmIn this house we obey the laws of thermodynamics!

author: NiHaoMike
author_rank: Super Contributor
timestamp: December 20, 2021, 01:19:25 am
content: Quote from: Neper on December 18, 2021, 12:52:18 pmI wonder if it's the result of a workaround that disturbs the circuit slightly if it senses things settling down, as a workaround to allow oscillators to start.

author: mawyatt
author_rank: Super Contributor
timestamp: December 20, 2021, 03:36:39 pm
content: Remember back in undergrad electronics the Prof telling us, "If you want an Amplifier design an Oscillator, if you want an Oscillator design an Amplifier"Best,

author: mawyatt
author_rank: Super Contributor
timestamp: December 20, 2021, 04:10:49 pm
content: On a more serious note. A steady state sinusoidal electronic oscillator meets the Barkhausen Criteria, however the nature of a simulator is a sampled system which subtly removes a tiny amount of energy from the oscillator's fundamental waveform and displaces it well outside the oscillator loop bandwidth inherent in the sampling process. Thus the very fact of a simulation subtly violates the Barkhausen Criterial for steady state of exactly unity loop gain.In high "Q" oscillator designs which don't have excessive loop gain this can create an extremely long simulation startup until the oscillator reaches an acceptable steady state (it actually never does reach steady state). A solution we developed a few decades ago was to estimate the oscillator active device steady state dynamic semi-sinusoidal waveform current and replicate this with a PWL bipolar current "doublet" source strapped around the tuned portion of the circuit, usually the inductor. This PWL current doublet source would "ping" the oscillator at startup with a waveform that closely resembled the steady state waveform and quickly achieve a semi-steady state solution, since the doublet had no offset (average value is 0) this had little effect on the bias conditions which usually have a very long time constant. The closer the doublet replicated the final semi-steady state condition the quicker the simulation converged on such. Using this technique proved highly useful with very high "Q" oscillators of various types, and much later Cadence implemented a special feature for quickly achieving steady state circuit operation. If you use this concept start the transient simulation with the biasing conditions preconditioned so the simulation doesn't have to deal with the bias ramp up and the doublet will kick start the oscillator very close to a semi-steady state condition.Best,