Scilab emphasizes, that the Linux world is rich with Technical / Scientific Computing platforms…

In my previous posting, I listed several (Open-Source) platforms for Computing, available under Linux at no cost, which have emphasis on Technical and Scientific applications. These platforms differ from conventional programming languages, in that conventional languages mainly specialize in allowing applications to be built, that perform a highly specialized function, while technically oriented platforms allow a user to define Math problems to be solved, to do so, and then to define a whole new Math problem to be solved…

My previous posting had also hinted that, when it comes to Computing tools of this kind, I prefer ‘the lean and mean approach’, in which the learning of specialized scripting languages would be kept to a minimum, but where, through his or her own resourcefulness, the User / Scientist knows how to apply Math, to solve their problem…

Yet, solutions do exist which go entirely in a different direction, and I’d say that “Scilab” is one of them. Under Debian Linux, one usually installs it as a collection of packages, from standard repositories, using the package manager.

Scilab is an application – and a workbench – with a rich GUI. It combines many features. But again, If somebody wanted to use it for real problem-solving, what would really count is, to learn its scripting language (which I have not done). Yet, Scilab typically comes with many Demos that tend to work reliably out-of-the-box, so that, even without knowing the scripting language, users can treat themselves to some amount of eye-candy, just by clicking on those….

 

Screenshot_20210709_062947

Screenshot_20210709_063146

Screenshot_20210709_063651

 

As I’ve stated repeatedly, sometimes I cannot gauge whether certain Scientific Computing platforms are really worth their Salt – especially since in this case, they won’t cost much more than a household quantity of salt does. ;-)  But, if the reader finds that he or she needs a powerful GUI, then maybe, Scilab would be the choice for them?

 

Dirk

 

A realistic way of driving LEDs.

One concept which has existed for some time is, that LEDs can produce a variable amount of light, and this will be the case, regardless of whether that amount of light needs to be constant, modulated slowly, or modulated at very high frequencies. But, LEDs have as a property which many other components do not have, that they tend to produce a fairly constant, forward voltage drop (like any diode), but that, as the voltage increases only slightly past a certain point, current increases rapidly. And, in the History of Electronics, this has often caused circuit designers to put a resistor in series with the LED, to regulate its current accurately.

One big drawback of doing this is, that power gets wasted, as current flows through the resistor, and gets transformed into heat. The amount of power that gets wasted in that way, most strongly depends on what fraction of the supply voltage appears across the resistor, instead of across the LED. Another drawback is the fact, that the current which flows through a resistor, which has simply been connected between a supply voltage and an unpredictable component – such as the LED – is itself not constant, And, when supply voltages are low – such as 5V – small changes in supply voltage are large, in comparison to the only slightly smaller voltage-drop across the resistor. And so, technology does offer as alternative, a chip, with active components to regulate the current more precisely, and often, while wasting less energy. In principle, such a chip can also be installed by the manufacturer of LEDs, into the same package as the LED.

According to the schematic below, I have demonstrated such a circuit…

 

IMult_LED_1

 

What is happening here is, that A presumed control current is fed in to a presumed input pin, and this circuit actually doubles that current, resulting in an amount of current which will be drawn from the cathode of the LED. Additionally, more than one LED could be connected in series, to the current-sink.

Continue reading A realistic way of driving LEDs.

Why the Simpson’s Sum Does Not Get Used In Circuit Simulations

In recent postings I have been sharing my experiences, learning to use the software ‘NG-SPICE’, which uses numerical methods to simulate circuit-diagrams. Well, to simulate ‘Netlists’ anyway, that represent circuits. And the GUI which I have has as drawback, not being as fancy as some commercial GUIs, and only allowing me to perform certain types of simulations, that include DC Sweeps, AC Sweeps, and Pulses. I think that if I was to delve deeper, and edit my Netlists using a text-editor, I might be able to expand the range of possibilities…

But then I do think that a premise of how ‘SPICE’ works in general, is to state the Voltage as a Primary phenomenon, to which Current is Secondary. By that I mean, pure capacitors are simulated as having current, that is the derivative of voltage, while in pure inductors, the current is merely the integral of voltage. ( :2 ) And so, SPICE uses numerical approximations of both derivatives and integrals. ( :1 ) And in the many settings my GUI does offer me, I get to choose which method of integration out of two I prefer: ‘Trap’ or ‘Gear’.

The question could just pop into somebody’s head: ‘Methods of numerical integration were taught to me, which are more accurate than Trap, such as The 3-point Simpson’s Sum. (Actually, I was taught to compute 2/3 times the Midpoint, plus 1/3 times the Trap Sum, not their average.) Why can’t I select that?’ And the answer I would suggest is as follows: I already wrote a posting about the simplest method of numerical differentiation, and about how, if the step-size is too long, it can generate differentials which are too high in amplitude. If this was combined with an unsuitable method of integration, one of two paradoxical results could follow:

  1. An LC tank circuit, aka a pure inductor connected to a pure capacitor, could end up unstable, gaining amplitude, or
  2. The same, simulated circuit could lose momentum, apparently to nowhere, and stop ringing.

Either result is counter to what happens in Physics. And so it would seem that the medium-range errors in the Trap method, happen to complement the errors exactly, in the simplest method of differentiation. If the differentiation came into being because consecutive samples were subtracted, then simply to add them again, will reproduce what we started with. And so our pure, lossless resonant circuit, would resonate forever, as it should… The engine has no place for ‘dampened integrals’ here.

The other method available, ‘Gear’, is also known as ‘The Backward Differentiation Formula’, or the ‘BDF’. It’s mainly suited for trying to simulate systems which are ‘stiff’ i.e., where the step-interval is assumed to be too long, and where heavy bodies interact with great force, approximated with coarse time-steps. It’s like The Simpson’s Sum on steroids. I’ve heard bad things about it. One main reason not to use it, is the History by which it will stabilize a simulated circuit, while the same circuit, when actually etched into silicon, became unstable. There might be cases where only the Gear Method can be used, but it should be used as a last resort.

The (simpler) ‘Riemann Sum’ has as a problem, that it must either be conceptualized as being ‘left-handed’ or ‘right-handed’, which means, that each input sample must either represent an abstract rectangle that follows it, or that preceded it. With critically-sampled – i.e., long stepped – signals, doing so would introduce a phase-shift. The Trap Sum alleviates such a phase-shift.

(Updated 06/23/2018, 19h35 … )

Continue reading Why the Simpson’s Sum Does Not Get Used In Circuit Simulations

Another Simple Output-Amplifier, Using Discrete MOSFET Transistors

One of the facts which I’ve been writing about, is that I possess the open-source version of ‘SPICE’, that is named ‘NG-SPICE’, and that this acronym stands for ‘Simulation Program, with Integrated Circuit Emphasis’. The full, associated suite of programs allows me to edit schematic diagrams graphically, but to export ‘Netlists’, so that I can then simulate the circuit – and see if it works.

And one of the facts which I have also been contemplating, is that by default, SPICE will put transistors, which correspond to micron-sized transistors, which will therefore never be able to drive output-loads, from a hypothetical IC, unless an explicit attempt is made, to design output-buffers, which can. These output-amplifiers have as function, that they should merely follow their input voltage, but draw as little current from their respective inputs as possible – that are outputs of other, more interesting ICs – while allowing low load-resistances to be connected to their own outputs, which correspond to plausible external components, such as 100Ω load-resistors.

I had posted an earlier, conceivable design, of such an output-buffer, which had a major flaw, that I also pointed out in the preceding posting: That amplifier could only produce a range of voltages, which was a direct function of what the Gate-Source threshold voltages would be, of the component transistors used. Hence, because I had also specified low-quality, outdated MOSFET transistors with high threshold-voltages, the output-voltage-range, was also modest but reasonable. But, newer transistors will have lower threshold voltages by design, which would, oddly enough, reduce the voltage-range of that amplifier. This would be an important consideration if the transistors were not in fact discrete, but needed to be incorporated onto the IC, where low-threshold-voltage transistors are already standard. Which means, that I needed to design a better output-buffer.

So below is a better output-buffer, schematic:

buffer_2_i

And these are the SPICE definitions, of the discrete transistors which I decided to base my design on again, both enhancement-mode MOSFETs:

http://dirkmittler.homeip.net/text/2N7000.mod.txt

http://dirkmittler.homeip.net/text/BS250P.mod.txt

The main disadvantage of this latest design would be, that the transistors which I labeled ‘X2′ and ‘X3′, do in fact conduct current to their combined inputs, which makes the additional transistor ‘X1′ necessary, since this amount of current would already be excessive, to connect to an output, of any pre-existing IC circuits. But then, the advantage goes so far, that ‘X2′ now models a level-shift, which exactly mirrors the level-shift of ‘X4′, and the voltage-level-shift of ‘X3′ now mirrors ‘X5′. There is design beauty in this. But one disadvantage now is, that the Gate-Source threshold-voltage of (1) n-Channel MOSFET (2.2V) plus (1) p-Channel MOSFET (3.2V) gets subtracted from the input-voltage, so that the available voltage-range still suffers, with respect to both the supply, and the input-voltage. Input-voltage now ranges from 5.4V to approximately 12.5V, which is closer to the range of supply-voltages than what the previous circuit allowed, and the resulting output-voltages are graphed below:

screenshot_20180618_075248

(Update 06/20/2018, 0h20 : )

There is another observation which I should add:

In the days of vacuum tubes, ‘transconductance’ was measured in Amperes / Volt, and was therefore given in ‘Mhos’, which were the reciprocal of Ohms. Apparently, in modern days, the transconductance of a MOSFET, also given as its ‘KP’, is in Amperes / Volt2 . :-D This conscious design-decision must follow the real-world behavior of MOSFETs, but makes my earlier Math, of multiplying such a component-property by the series-resistance, to arrive at gain, incorrect. Gate-Source voltage-changes lead to current-changes, but greater Drain-Source voltages, lead to greater current-gain. This is good, because the actual gain of a MOSFET, reduces the apparent capacitance at its Gate.

The low-end output-voltage came into being as follows:

Continue reading Another Simple Output-Amplifier, Using Discrete MOSFET Transistors