Fixing KiCAD Custom Plugin Error


As of this writing, when one attempts to run a custom Python3 plugin script for KiCad (v6) where the script file is not located at /Applications/KiCad/ python complains that it cannot find the KiCad libraries.

Apple security boffins have made it all but impossible to set global env variables, so export PYTHONPATH="..." isn’t really an option, when running plugin scripts from within the KiCad GUI (Generate BOM for example.)

I did get that working by wrapping the text in Command line running the generator: with sh -c 'export PYTHONPATH="/Applications/KiCad/ && [original command here] ' … but then I realized …

Better Way (probably)

In your custom Python script, simply change this …

import kicad_netlist_reader
import kicad_utils
import csv
import sys

… to this …

import sys
import kicad_netlist_reader
import kicad_utils
import csv

I guess KiCad itself may be able to fix this quirk on macOS some day. For now, I’ll stick with what’s working.

Bypassing Low Voltage Warning in OctoPrint

Say what now?!

Octoprint has a built-in module “Pi Support” that gives warnings if something’s up with your ‘Pis power supply or if it’s been “throttled” any time since system boot-up.

Very clever … but what happens if your sweet old Raspberry Pi 3+ Model B has a faulty MxL7704 power management chip, say one that reports low 5V_SYS even though it’s fine? Let’s just imagine you’ve already hooked a laboratory voltmeter and scope up to your R’Pi to verify this sad state of affairs.

Here’s a script that will bypass the warning. It should go without saying that using this is NOT a good idea but who am I to judge?

ANYTHING_BUT_THROTTLED=`$VCGENCMD $* | sed 's/\(throttled=\).*/\10x0/'`
exit $?

Use your favorite editor to create the script somewhere tidy like ~/scripts/vcgencmd-bypass and make it executable using chmod a+x vcgencmd-bypass.

Now all you have to do is point Settings => Pi Support => Advanced options to this script rather than the default /usr/bin/vcgencmd executable; Like so …

Why you naughty hacker you!

The script allows all vcgencmd commands through, changing only the likes of any throttled=0x50000 output to throttled=0x0.

Now of course, that same faulty chip is going to tell Raspbian to throttle even when it shouldn’t … or is it? Turns out that in my case, the glitch only seems to occur once during boot-up. I am guessing around the time the first I2C initialization event occurs. I have benchmarked the Pi to death trying to get it to produce throttled=0x4 (Currently throttled) with no or should I say only joy.

In case you’re wondering what made me suspect a faulty chip … well that would be connecting a 4 Amp power supply the wrong way around, directly to the PCB, bypassing the fuse etc. That seemed to outright kill the Pi but a few hours later when I plugged it in one last time before trashing it … YIPPEE! It worked again. I guess the cip cooled down? 😛

… or I’ve fallen down some garden path in a comedy of life’s wonderful little errors. shrug. Either way, you’re welcome!

Have fun!

Intel Quartus 16.1: Fix for, “Inconsistency detected by dl-close.c”

If you stumbled on this via Google, I hope you found it useful in your specific use case.

While using intelFPGA (Quartus) Lite v16.1 on my Ubuntu Linux 16.x system, I was seeing this shared library-related error …

Inconsistency detected by dl-close.c: 811: _dl_close: Assertion `map->l_init_called' failed!

The problem turned out to be some kind of incompatibility with Quartus supplies and indeed requires v1.59.0, while my system has v1.58.0 installed, being the latest pkg manager version at the time.

It turns out that the Quartus commandline tools refer to plain file, which is in fact a sym-link to Meanwhile, the GUI tools explicitly require the latter. Hmmm.

Damn the torpedos! FULL STEAM AHEAD!

The easiest fix I could see in my busy litle day was to simply remove the symlink, such that the Quartus command-line tools would use the system lib (found by, in the normal fashion) …

~$ cd ~/intelFPGA_lite/16.1/quartus/linux64/
~/intelFPGA_lite/16.1/quartus/linux64/$ rm -f

… and that actually did the trick, for once! Astonishing! 🙂



The Mandella Effect

I’ve known about these Mandella Effect people (online) for a few months now. Yet another fucking religion is born! *sigh*
NLP folks will all be nodding their heads in amusement, as will magicians the world over. David Copperfield will be turning in his grave. Wait. Copperfield is alive? I could swear the Chinese Wall swallowed him up in the ’80s! Damn. I must have taken a bend in the space-time curvature too fast or something. :-/
Isn’t it interesting how the Internet gives us so much freedom and opportunity to grow as an intelligent species … yet at the same time, the ever misguided masses use it to to dumb themselves down, faster than ever.
Large numbers of people believing in something, despite facts or good reason, are perhaps the most dangerous threats to not only civilisation but to our very species. Surely no one could disagree with that.
Belief systems. Hell, we should remove the word, “belief” from the @#$! dictionary, as far as I’m concerned. The word, “hallucination” covers it better. Perhaps belief in the present is a requirement for sanity and a good thing, in the grand scheme of things. What is not good, is believing in our beliefs, despite all evidence — regardless of the dimension we got kicked into last night.
Logik for da wise!
P.S: Spread the word! Everyone needs to STOP USING AUTOMATIC WASHING MACHINES IMMEDIATELY! Every time one of those things hits a spin cycle, it creates another dimension-changing time vortex! If it weren’t for clothes dryers doing likewise at a tangent, we’d all be truly screwed. (I was the first one ever to figure this out, by the way. Just saying.)

The Gruvinator 3D (Printer)

As my latest experiment with 3D printing — and frankly the only one to date worthy of a blog post — I purchased the cheapest Chinese clone, Prusa i3 based printer I could find, took the parts I liked, ditched the rest and created the, “Gruvinator 3D”, 3D Printer.

The final result is a mash-up of (mostly) my own Prusa i3 style printed parts and Chinese electronics, motors and misc. hardware from the kit.

Continue reading “The Gruvinator 3D (Printer)”

BluzDK — How to gain stability and save battery power!

This is intended for the average hacker using the BluzDK BlueTooth Low Energy module … who may not have the benefit of a Computer Science degree under their belts … and is written by one of similar ilk.

“Now, I’m no expert. But …” — Someone famous, for those very words!

BluzDK is Special

Battery life is everything

BluzDK differs from Particle’s Photon, SparkCore etc, in an important way. It does not have built-in multi-tasking abilities – and in fact if it did, it would not be so light on our batteries.

The upshot of this is that we need to take care that the setup() or loop() functions never block, certainly not for more than a very short while. If we do block, BluzDK wouldn’t be able to process cloud events, such as OTA updates, and would consume a LOT more power!

A, “blocking” function is simply one that hogs CPU clocks by not returning to its caller as swiftly as possible. Something like …

while(true) { /* do stuff forever */ }

The above example will block forever! But even blocking for a long time – just a second or more, mind you – can cause real problems.

For example, the following pseudo code could easily prevent BluzDK from being able to process radio events for too long, causing it to disconnect or worse …

void main() {
    while (somethingTrueForTooLongTime) {
      /* sit in this loop for a too long a time, just waiting for something */

But wait!

Isn’t waiting an unknown and often lengthy time for something just exactly what we almost always want to do? Yup!

So HOW then?

One could invent any manner of cleverness to deal with such a problem. Luckily though, some clever people long ago came up with a programming pattern, called a Finite State Machine or FSM. By all means Google that to learn the juicy details. Suffice to say for now, it’s a beautifully simple, easy to read and understand pattern and is possibly the most uses programming pattern of all time.

Here, I present a simple (standard C – not C++) FSM style example of how we can wait a potentially long time for something without ever staying in `loop()` for more than a few microseconds. (Feel free to Google up on some fancy C++ classy versions.)

void setup() {


#define TIME_TO_WAIT 5000 /* milliseconds */

typedef enum {
} FSM_state_t;

void loop() {
    static FSM_state_t myState = WAIT_ONLINE;
    static uint32_t saveTime;

    switch (myState) {

        case WAIT_ONLINE: // stay in this state  until we're connected to the big old cloud in the sky
            if (Particle.connected()) myState = ALIVE;

        case ALIVE: // we're alive! shout about it
            Particle.publish("Came online at", String(millis()) );
            myState = SET_TIMER; // next time through loop(), we'll set up our custom timer

        case PUBLISH: // it's been TIME_TO_WAIT milliseconds -- make some noise!
            if ( !Particle.connected() ) { // first though ... did we get disconnected somehow?
                myState = WAIT_ONLINE;
            } else {
                Particle.publish("PING!! at ", String(millis()) );
                myState = SET_TIMER;

        case SET_TIMER: // record the current time for the WAIT state to reference back to
            saveTime = millis();
            myState = WAIT;

        case WAIT: // stay in this state until TIME_TO_WAIT milliseconds have gone by since the SET_TIMER state
            if ( millis() > (saveTime + TIME_TO_WAIT) ) {
                // Time's up! But we'll drop out of loop() for and get it done next time through
                // This allows all the background network stuff the best chance of keeping up with business
                myState = PUBLISH; 
            myState = WAIT_ONLINE;

    // We can save MUCH more battery drain this way too! ...


Notice that each time loop() is called by the BluzDK system, only two or three instructions get executed (in this example) … even though the state machine as a whole is achieving quite a bit more – including not one but two potentially long waits.

Want to have virtual multitasking but could never find an efficient way to structure the code? Just use two or more state machines – each with its own internal state tracking.

 void loop() {

Just so long as each state machine takes care of itself and always drops through to return to loop() as soon as possible, then your system could appear to be three distinctly separate devices in one. Multitasking for the poor — whilst maintaining a degree of code readability, for next year, when you come back to make changes.

Apple OS X Prevent or Stop Three Dots (…) Being Converted to a Single Unicharacter

By default, in Apple OS X, when you type “…” (dot, dot , dot) and press [space], the three dots get converted to a single unicode character, ‘…’, which can cause problems in some scenarios.

There are several mechanisms involved for this feature, making it difficult to disable in some versions of OS X or in certain applications, if you don’t know where to look.

Since OS X Mavericks (10.9) most Apple apps have the menu option, Edit -> Substitutions, wherein Text Replacement and other auto-type features can be turned on or off, though oddly not just for the app in question, but system wide …


But what about all those non-Apple apps or earlier versions of OS X, that don’t have an Edit -> Substitutions menu item?

As of OS X Mavericks, the ‘dot,dot,dot’ feature specifically, is an auto-replace item, found in System Preferences -> Keyboard -> Text. You can delete the ‘…’ item entirely.

In earlier versions, there is  System Preferences -> Language and Text ->Text. Then un-check the ‘…’ item.

Note that since Mavericks, these auto-replace items are synced across all your devices, via iCloud. So removing the ‘…’ auto-replace item on your Mac will also remove it on your iPhone, iPad, etc.


USB Traffic Meter Thingy (gMeter) Update

First working gMeter-MLF build

I’ve now completed two versions of the envisaged USB visual meter and alarm sounder device, both based on the ATmega88P MCU and as envisaged in my previous post. A photo of the smaller version is shown, right.

I have published the design files and firmware as free open source (GLP v3) at Google Code.

Below is an image of the same board, with the first 5 of 8 LEDs lit up.

gMeter-MLF lit
Showing the first 5 green and yellow LEDs lit up. The next three are orange (x2) and red.

The original version of the gMeter board is larger (at about 150% the size of the MLF version) and uses an easier-to-hand-solder (bigger) ATmega88P microcontroller chip. It also includes a 4-pin header to connect a commonly available Bluetooth module (currently not supported in any way by the published firmware) as well as four spare I/O pads for expanded use, should the user wish to wrangle with the firmware source code, to that end.

Original gMeter
The original, larger gMeter board, with Bluetooth header and four spare I/O pads.