So maybe you should pick a Q symbol with that pin sequence so that the schematic reflects the reality.
That is indeed a workaround, but an ugly one. If a PCB is made for it later, it wonāt work becase of the wrong pin assignment. In the past I have managed to get things to work with Alternate Node Sequence, but now Iām stuck there.
It looks like you wrote
321
as alternate node sequence. What about writing
3 2 1
?
Aaahhrgg, adding spaces helped indeed.
Iām feeling a bit silly now.
Some kind of complaint that it could not find pin āThreehundred and Twenty Oneā or a parsing failure for the Alternative Node Sequence would have been nice though.
Completely true, but in that configuration it is one, although with miserable performance.
Concerning āalternate node sequenceā, you should indeed use spaces. No need for workarounds.
Itās still not an emitter follower. In an EF, the BE junction is forward biased as normal. Here itās the BC junction thatās forward biased and the BE junction is reversed biased. It will show miserable gain. An emitter follower has unity or less voltage gain.
Anyway it was actually working in commom emitter mode, just a discrepancy between KiCad and ngspice pin numbering.
Looking at the schematic again, youāre right. Configuration is common-emitter (although itās the collector). Never mind. I hope the āalternative nodeā thing has been sorted out now.
I suppose this is not what you wantā¦but if you mainly want a good oscillator, I like a comparator oscillator. It can be done with a single section of an LM339, although that is not quite what I have here. Strictly in terms of component cost, 1/4 of an LM339 might sometimes be cheaper than two bipolar transistors. And the comparator oscillator is a very good circuitā¦
1 Like
An application of copyright and licence: Paul, woud you allow me posting your astable on my application page (after slight modification, flip the transistors, no base resistors)? Licence may be āPublic Domainā.
Bobz, unfortunately ADI does not offer any freely accessible spice model for their ADCMP609, so I have to setup and post a similar circuit with a different OpAmp.
Iām happy to release anything about this project into the Public Domain.
On top of that, the astable multivibrator is likely too generic to even be copy-rightable. In this case the giants before me were Henri Abram and Eugene Bloch.
My first attempt was a straight copy from the screenshot LM21 posted. It has some starting problems, but that may make it more interesting as an simulation example.
Additional notes:
- I already uploaded a version with fixed node sequence and straight up transistors and edited that into one of my earlier posts: 2022-11-22T23:06_astable.zip (8.1 KB)
- I used a schematic symbol of a battery for the voltage source but had to change the RefDes to a V for ngSpice to recognize it.
- The spice model for the transistor I used is likely from https://github.com/kicad-spice-library/KiCad-Spice-Library/blob/master/Models/Manufacturer/TRT-Electronics/2n3904.lib (Or from some other copy of that file).
One more notice. Spice does not simulate wires, if you do not give their values. So, normal circuit with standard transistors in Spice, does not have parasitic oscillation. I think resistors and capacitors have some strays, but very little.
Edit: LTspice@groups.io | Home
I remember that I had built such an astable multivibrator with two Germanium power transistors (AD133) to replace the mechanical relay for the direction indicator of my 1966 Beetle (with 6 V electrical network). It worked like a charm.
I had another look at this astable, and when I plotted the current through C1 I got a quite strange result:
Zooming in reveals the simulator oscillating between two alternate values on each next sample points. Here with a sample time of 10us:
And when decreasing the sample time to 1us, the oscillation frequency also just increments with a factor of 10:
It looks like some kind of convergence issue, and for me itās mostly a confirmation of not trusting those simulators.
The simulation suffers from ātrap ringingā. This is indeed due to the matrix solving algorithm called ātrapā.
It may be avoided in ngspice by adding the text line
.option method=gear
to the Eeschema canvas. Unfortunately gear has also its quirks, so trap is standard, gear often used when simulating smart power (converters etc).
Other simulators have introduced a āmodified trap solverā, which is nothing but filtering (building the mean of 2 consecutive data points).
Ah that reminded me another simulator, the one inside Falstad, mentioned trapezoidal approximation so I guessed trap is short for trapezoidal and not a tool that catches things, and sure enough a search verified it.
Ok, thanks for the confirmation and naming it, but for using simulations it remains extra uncertainty and annoyance that I do not really want to deal with.
Iāve got a (hardware) oscilloscope, and it does sin(x)/x and anti aliasing by default, while this ātrap ringingā leads to very serious aliasing distortions at some zoom settings.
That seems a sensible āsolutionā, especially when combined with doubling the āsimulation rateā, so the resulting filtered rate is the expected rate. I do not know if this has unfortunate side effects though.
Simulation is a tool, no more. It was never intended for absolute ātruthā, but itās damn helpful when designing a circuit.
It reminds me a bit of some students in first year engineering, whoād measure a rectangle using a cheap plastic ruler and then using their fancy TI calculators for finding the diagonal length with 8 decimal placesā precision. They all got marked down one point by the professor.
Use tools as they are, know their limitation, but in the first place use the brain.
Thatās what I took with me from that class. Served me well ever since.
It is guite easy to accidentally get impossible results, like kiloamps or gigavolts, from simulation. So it is best if the user knows somethings about the circuit.
1 Like
My apologies to everyone, I know some will not like this. But my concern is: what is the use of a tool unable to offer true results in the most basic cases?I feel very dissapointed by ngspice.
Commercial simulators also sometimes make the same sort of errors. Why we still prototype boards and and keeping experienced engineers employed