It’s not an emitter follower, it’s an upside down transistor with the emitter and collector swapped so would have low h_fe. Surprising that it works at all unless ngspice is swapping the nodes again.
I didn’t notice until now.
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.