The benefits of networking

One of the presentations I attended at KiCon 2019 was one entitled "Preserving History with KiCad" by James, the self-professed "Bald Engineer". Given my work with recreating the Intel 4004 CPU, his presentation sounded interesting to me.

Making Xilinx ISE 14.7 run on Ubuntu 18.04

While cleaning my office I came across a timing diagram I'd drawn for an HDMI decoder I'd starting writing for the Digilent Atlys board, which has a Xilinx Spartan 6 FPGA. Curious to see how far I'd taken this project, I fired up the Xilinx ISE IDE. Or at least I tried to.

The last time I ran ISE I was running a derivative of Ubuntu 16.04. Now that I'm running a derivative of Ubuntu 18.04, ISE wouldn't run. And since ISE hasn't been updated since 2013 (and won't be), this is a problem. Here's the error message I got:

libpng warning: Application jmp_buf size changed

Flipping the P170-DH power circuit layout

Last August I realized why some components on the original Canon P170‑DH calculator were mounted on the top of the board and some were mounted on the bottom: placing the through-hole components on top and the SMDs on the bottom allowed everything to be soldered on the bottom side of the board. That may have been a requirement, given the use of carbon tracks on the top side.

The original board used through-hole components for the power section. On my replacement board the only through-hole components are connectors, a fuse, and an electrolytic filter capacitor. None of the ICs I'm using are available in through-hole packages, and the FPGA has to be mounted on the bottom of the board because there isn't enough room to mount it other than behind the keypad.

Following the layout of the original board I'd placed the power section components on the top of the replacement PC board. Recently, though, I've reconsidered that arrangement. I'm just a bit concerned about surface-mount components already soldered on one side coming loose while later soldering the components on the other.

After making sure the schematic and board files were checked into my content management system (I use Git) I spent an evening flipping the power section circuits onto the bottom of the board. This required re-routing most of the circuits, and I took the opportunity to rearrange some of the circuits to make room for some components I hadn't placed yet. I haven't finished the re-route yet, but I'm happier than I was.

Linux CoreUtils developers break "ls"

I've been running Linux Mint 18.2 on my desktop for the last few years, and I've been pretty happy with it. However, it's based on Ubuntu 16.04, which is getting kinda long in the tooth. Specifically I found I couldn't compile the version of wxformbuilder I need for my KiCad work because it requires a newer compiler than is available for Ubuntu 16.04.

So I decided to upgrade my systems to something based on the Ubuntu 18.04 release, which is the latest long-term support release. Everything seemed to be going well until I started tried to list files in a directory. The first thing I found is that the sorting in "ls" now ignores underscores in file names.

For example, I was looking for a file named "pcb_parser.cpp" in the file listing:

pcb_layer_widget.cpp
pcb_legacy_draw_utils.cpp
pcb_netlist.cpp
pcbnew_config.cpp
pcbnew.cpp
pcbnew_printout.cpp

When I reached the file named "pcbnew_config.cpp" I figured I must have missed it and scanned the list from the top again. Confused, I looked more methodically and found the names continue:

pcbnew.cpp
pcbnew_printout.cpp
pcb_origin_transform.cpp
pcb_painter.cpp
pcb_parser.cpp
pcbplot.cpp
pcb_plot_params.cpp

What is this madness? This doesn't look like a sorted list to me.

As best I can tell, the people who maintain the core apps (like "ls") have decided to "improve" this fundamental application by changing the default sort algorithm to so-called "Natural Sorting". This means that if you have files with names from "file1" to "file20", you'll see "file10" after "file9" rather than after "file1". That's kind of a nifty trick, but the change in behavior is extremely confusing to those of us who have worked with Linux, Unix, and Unix-like systems for decades.

Apparently they also decided that underscores and spaces don't really count as a character, and file names are sorted as if they don't exist. Except when they do, because "file 13" will be sorted just before "file_13" which will come just before "file13", but after "file12". Clear?

That's all very nice. Except they decided to make "Natural Sorting" the new default behavior instead of an option you can choose. The docs say that the "-v" option turns on this behavior, but by trial and error I discovered that the "-v" option actually turns it OFF. Quite frankly, the unexpected change to a 40 year-old behavior is both unwanted and alarming.

Then I discovered something else: if you have spaces in a file name, "ls" now adds single-quote marks around the name. Like this:

pcb_plot_params.cpp
'pcb plumber.cpp'
pcb_screen.cpp

But only if it's displaying on a terminal, so sometimes you see them and sometimes you don't. Again, this is the new default behavior.

You can disable this by adding either "-N" or "--literal" to the "ls" command, or by setting an environment variable in your .bashrc file:

QUOTING_STYLE=literal

But to find this you have to go looking for this in email threads and bug reports, because it's seemingly not documented elsewhere.

Many people have objected to these changes, but the CoreUtils developers don't care. I guess they want to leave their marks on the world, even if they're black marks.

KiCad origin transforms

The problem with promising things to a project leader at a conference is that you need to deliver on those promises. Anything less and you lose credibility.

What did I promise to fix? When I started using KiCad in the spring of 2017, I whined about what I considered KiCad stupidity. I itemized seven specific complaints, some of which have since been addressed by the team of mostly-volunteer developers.  After talking about it off and on for almost two years, last month I promised to fix numbers 1, 3, and 5.

I didn't spend two days in Chicago (and pay for the cost of the trip) talking with developers only to lose credibility by not following through.

KiCon 2019: The KiCad Conference

A couple months ago I came across an announcement for a conference for KiCad users and developers in Chicago called KiCon. Since I now use KiCad for my schematic entry and PCB layout, I thought this would be fun to attend. So here I am in Chicago!

Simulating the VFD Grid/Anode driver

I was reading through an old posting about the VFD Grid and Anode driver circuit I'm planning to use, when it occurred to me that the resistor between the base of the PNP transistor and the collector of the NPN transistor might not be necessary. This is labeled R1 in the schematic to the right.

To calculate the desired resistance I'd done a bunch of hand calculations in my notebook, trying various combinations of target currents and resistor values. I started to do yet another with R1 set to zero when it occurred to me that this would be easier to do in simulation. At first I entered this circuit into LTspice using 2N3904 and 2N3906 transistors, as these are standard parts in the LTspice library. The simulation results matched my hand-calculated numbers, which gave me confidence that I'd done the calculations properly. I'm driving both transistors into saturation, and my turn-off times are anything but critical, so the choice of transistor isn't critical.

Then I wondered how closely this approximation matched the real Toshiba RN4604. At first I thought this would be a challenge, as the process for creating a Spice model description for a transistor from its datasheet isn't that easy. Wouldn't it be nice if Toshiba provided a Spice model? Well, they do, and it's available for download from their website. To make it easier to probe the base current of Q1A (Q1 in the Spice schematic) I extracted the transistor models from the subcircuits that add the built-in bias resistors and substituted them into my circuit.

My original plan had been to turn on Q1A by passing about 500 µA through its base. This was based on the spec'd saturation I_CE of 5 mA with I_BE of 250 µA, giving an h_FE of 20. In the actual application I've found a grid draws about 6 mA and its 10K pull-down resistor will draw another 3 mA, so I doubled I_BE for an I_CE of 10 mA. If I eliminate R1 the base current jumps to 606 µA. But this puts almost the full 30 volts across the input (between pins 1 and 2); the datasheet graphs stop with an input voltage of 9 V. Even with the original R1 of 10K the input voltage is almost 25 V. So I'm thinking I should revisit this.

Looking at the h_FE graphs I see the worst-case (at -25°C!) current gain at 30 mA is about 100. Of course this is in the transistor's linear region, but it implies that with a base current of 300 µA and a collector current of only 10 mA the thing will be saturated. So I tweaked my Spice simulation to sweep the value of R1 from 100 ohms to 150 Kohms. I graphed the base and collector currents of the transistor, along with the "input" voltage (the difference between pins 1 and 2 on the package). I also changed the collector load resistor to 1 KΩ to get about 30 mA collector current if the transistor was saturated. This would make it more obvious when decreasing the base drive would start having a significant effect on the collector current.

The trick to interpreting these graphs is to remember that this is a PNP transistor in a common-emitter configuration, so the base and collector currents are negative. Thus a rise in the graph means less current. Also, the horizontal scale represents ohms, even though it's reported in volts. So the "100KV" tick actually represents 100 KΩ.

It's pretty obvious I don't need 500 µA of base current. In fact, it looks like I could make R1 as high as 100 KΩ and still drive this transistor into saturation. Setting R1 to 63 KΩ gives me 250 µA of base current, while 47 KΩ gives me 295 µA. I'll probably choose 47 KΩ to allow a generous margin for variations in bias resistor values, which can vary as much as ±30% in absolute value in the RN4604.