| General > General Technical Chat |
| Why is this simple RC oscillating? |
| (1/4) > >> |
| eti:
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 |
| bob91343:
Because simulations suck. Too much is expected of them. |
| eti:
--- Quote from: bob91343 on December 17, 2021, 04:28:39 am ---Because simulations suck. Too much is expected of them. --- End quote --- LTSpice doesn’t “suck”, I think that this is a bug in E/Circuit. |
| daqq:
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, see https://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. |
| T3sl4co1l:
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 |
| Navigation |
| Message Index |
| Next page |