A First, Complicated Project at Circuit Design with NG-SPICE

One subject which I wrote about in an earlier posting, was that software exists by the name of ‘SPICE’, which stands for “Simulation Program with Integrated Circuit Emphasis”. There are several variants of this software in existence, but the version which I am focusing on for now is the Open-Source ‘NG-SPICE’ system, which needs to be bundled with numerous other packages under Linux, really to be useful. One important package is ‘ngspice-doc’, but there is a whole suite of Linux packages referred to as ‘gEDA’.

Simply having tested a few demo-projects, is not the same thing as actually having designed a circuit, and having witnessed that project ‘work’, at least according to the simulation. Just last night, I did the latter, in order to get a better, working grasp of how to use the software, and also, some idea of the sort of error messages and problems which invariably occur on a first-time basis. What this means is that I actually designed a circuit using the ‘gEDA Schemtic Editor’, which is also known as ‘gschem’, and then ran multiple simulations of the circuit, discovering at first that it had performance issues as I had imagined it, modifying it numerous times, and ending up with a version of the circuit, which I could be satisfied with for now.

The circuit which I was designing, actually involved MOSFETs, because those are the most important components in circuit-design today, and surely enough, I did run into initial problems. One of the tasks which we must complete, when using active components in SPICE, is to define the component, which is as fundamental as the fact that we also don’t just put a resistor, but must also specify what the Value of the resistor is in Ohms. Well with active components, we must do something similar, which also goes under the GUI heading of the Value attribute for the component. Therefore, MOSFETs, be they NMOS or PMOS, also have values, and by default, those values are defined by a Model Card, from which the computer can predict such physical properties about the NMOS or the PMOS transistor, as what its gate-capacitance is, how well it conducts when switched to conductive, conversely when the gate-voltage is zero, etc., etc., etc..

But, because NG-SPICE (v26) is advanced software – though still not the latest version – it may not require that the user defined all these parameters each time he or she considers designing a circuit, because standard component specifications exist.

By default, our MOSFETs have Reference Descriptors that begin with the letter “M”, and not with the letter “Q”, which would stand for a Bipolar Transistor, but which the GUI of ‘gschem’ suggests for the user when he first clicks a MOSFET into his circuit. So we override that, by editing the RefDes into a text-string that has the letter “M” followed without spaces by a number.

What I next proceeded to do, was to put MOSFET-transistors into my circuit, which from the GUI, only had 3 pins. This is a common way in which MOSFETs are often diagrammed, and looked something like this:


Believing that I could just accept what the GUI had constructed, I next tried to simulate the circuit, and received the error, which roughly stated “Unable to find Definition of Model.” This error-message wasted much of my time trying to solve, because I had in fact created a Model Card for the transistors which I was going to use, and at first, I despaired that NG-SPICE might not be as good as paid-for software. But I soon learned that indeed, the following example is a sufficient Model Card for an arbitrary NMOS transistor, with which circuits can be designed:


Similarly, we can conjure a default PMOS transistor like so:


In actual circuit-design, we’d drop the .TXT Filename-Extension, that makes the above examples readable in a Web-browser. Not only that, but we can also use the ‘gschem’ GUI, to embed such definitions directly into the Netlist, by giving them as a ‘Model’ attribute. So what was causing this error message, in my example? The fact is that MOSFETs are 4-pin components by nature. They have a hypothetical Source, a hypothetical Drain, a Substrate Electrode, and a Gate. It’s the voltage between the Gate and the Substrate Electrode, that finally determines how conductive the MOSFET is to become. By convention, many practical MOSFET-packages tie the Substrate Electrode together with the Source lead, which also happens to make the Source different from the Drain.


By telling NG-SPICE that we’re including a ‘MOSFET_TRANSISTOR‘ in our circuit, we’re telling this program to read 4 Nodes from the Netlist, to parse what the transistor is to be connected to. But, when the GUI only provides 3 arguments, an error ensues, that garbles the attempt of NG-SPICE to parse the Netlist. That’s all. Curiously, the reverse error does not happen. If I conjure a 4-lead MOSFET-symbol from the GUI, but specify a 3-lead MOSFET (more on that below), then I obtain a well-managed error message, that tells me what the problem is.

(Updated 06/14/2018 … )

Actually, the symbols above are also different in another way. In theory, one stands for an enhancement-mode, and the other, for a depletion-mode transistor. But, because under Linux, ‘this software is divided into two departments’, effectively, this does not matter.

The GUI allows schematics to be drawn in such a way, that Netlists result, while the actual NG-SPICE software emulates what these Netlists define. It’s in the emulation of the Netlists, that the decision is also made, as to whether a component is an enhancement-mode or a depletion-mode, or a subcircuit component… ( :1 )

(Updated 06/16/2018 : )

Continue reading A First, Complicated Project at Circuit Design with NG-SPICE

Browsing Android Files using Bluetooth

One of the casual uses of Bluetooth under Android, is just to pair devices with our Android (host) device, so that specific apps can use the paired (slave) device. This includes BT-headphones, and many other devices.

But then a slightly more advanced use for BT under Android could be, that we actually send files to a paired Android device. It’s casually possible to take two Android tablets, or a tablet and a phone, and to pair those with each other. After that, the way to ‘push’ a file to the paired device, from the originating device, is to open whichever app displays files – such as for example, the Gallery app, if users still have that installed, or a suitable file-manager app – and to tap on ‘Share’, and then select ‘Bluetooth’ as what to share the file to. Doing this should open a list of paired devices, one of which should be suitable to receive a pushed file in this way.

But then, some people would like to take Bluetooth file-sharing up another level. We can pair our Android device – such as our phone – with a Bluetooth-equipped, Linux computer, which may be a bit tricky in itself, because the GUI we usually use for that assumes some legacy form of pairing. But eventually, we can set up a pairing as described. What I need to do is select the option in my Linux-BT-pairing GUI, which requires me to enter the pass-code into the Linux-GUI, which my Android device next displays…

And then, a question which many users find asking themselves is, ‘Why can’t I obtain FTP-like browsing capability, from my Linux-computer, over the files on the phone? Am I not giving the correct commands, from my Linux-computer?’

Chances are high, that any user who wishes to do this, is already giving the correct commands from his or her Linux-computer…

(Updated 06/03/2018, 20h45 … )

Continue reading Browsing Android Files using Bluetooth

tex4ht / mk4ht Broken (Problem Solved).

As of 05/26/2018 :

I have just been experimenting with a GUI front-end to LaTeX, that is called ‘LyX’, and it tries to be a WYSIWYG LaTeX Editor.

LyX tries to give editing capabilities for LaTeX documents, using an editor style similar to most word processors. Mind you, this task cannot always succeed 100%, because by its nature, LaTeX will encode the logical structure of a document-to-be-typeset, while conventional word processors try to control the appearance of documents.

And so one feature that LyX does have, is to import and export documents of various formats, most of which revolve around different LaTeX coding-styles, or around ‘rendering’ our LaTeX document to such formats as PDF or DVI, just because those two output-formats have arbitrarily emerged as standard publishing formats. DVI is really only interesting as a legacy Linux graphics format.

And so what some people will want to do, is convert documents from LaTeX either to OpenDocument format, or even to MS Word Format. These formats are initially visible in the Export Menu, if the user has command-line tools such as ‘mk4ht’ installed.

What can frustrate some people who are new to Linux, is that the command-line itself may be defective in some way, meaning that it malfunctions, and in my own experience, trying to get ‘mk4ht’ to work can be futile, when it does not work out-of-the-box. And then, trying to fiddle with the GUI of LyX is also to no avail, because the GUI can finally only work as well as the command-line, back-end that it has detected.

So instead of trying to repair ‘mk4ht’ – which, if it was working, could just as easily be tested from the command-line:

mk4ht oolatex somefile.tex


(Edited 05/27/2018 : )

I would propose that any readers of this blog, who have run into such a problem, and who are running Debian / Stretch, try instead, to install a Debian package called “pandoc”, as well as “pandoc-citeproc”. When LyX recognizes these programs as installed, they will become available as ways to export to or import from .DOCX as well as .ODT formats.

(Updated 05/28/2018, 1h00 … )

Continue reading tex4ht / mk4ht Broken (Problem Solved).

Now, I have LuxCoreRender working on one of my computers.

In This Earlier Posting, I wrote that a rendering-engine exists, which is actually a (‘software-based’) ray-tracer, making it better in picture-quality, from what raster-based rendering can achieve, the latter of which is more-commonly associated with hardware acceleration, but that this rendering engine has been written in a variant of C, which makes it suitable both in syntax and in semantics, to run under OpenCL, which, in turn, is a driver for running massively-parallel computations on our GPU – on our Graphics Processing Unit. Assuming we have a sufficiently-strong graphics card.

That ray-tracer is known as “LuxCoreRender”.

Well previously I had spent a long time, trying to get this to run on my computer, which I name ‘Plato’, using the wrong methodologies, and thus consuming a whole day of my time, and tiring me out.

What I finally did was to register with the user forums of LuxCoreRender, and asking them for advice. And the advice they gave me, solved that problem within about 30 minutes.

Their advice was:

  1. Download up-to-date Blender 2.79b, from the Web-site, not the package-installed 2.78a, and then just unpack the binary into a local, user-space folder on my Linux computer,
  2. Insert the binary BlendLuxCore / Tell Blender 2.79b to install it directly from its .ZIP-File.

It now works like a charm, and I am able to define 3D Scenes, which I want LuxCoreRender to render! :-)  And running the code on the GPU – using OpenCL – also works fully.


I suppose that one advantage which ray-tracing affords, over raster-based graphics, is that the Material which we give models is not limited to U,V-mapped texture images and their H/W-based shaders, but can rather be complex Materials, which Blender allows us to edit using its Node-Editor, and the input-textures for which can be mathematically-based noise-patterns, as shown above.