Leaky thyristors

29.07.2010 19:52

As you might remember, my lab power supply in-the-making utilizes a thyristor pre-regulator stage. When I soldered the circuit together on the final version of the printed circuit board it had an interesting glitch. Occasionally it would get into a mode where the regulation circuitry completely failed to work, pegging the output voltage to the maximum with ill effects to the longevity of the linear regulator down-stream.

The solution, as you will see, was simple, but the exact cause still puzzles me.

This is the critical part of the circuit:

Simplified thyristor regulator diagram

Here you see the transformer with a 30 V secondary and two full rectifier bridges with a common return path. The lower bridge simply produces a pulsating voltage (SYNC) serving as a synchronization signal for the control circuit. The upper bridge creates the regulated voltage over the tank capacitor. It has thyristors instead of diodes on the positive side which are triggered in the right moment with current provided by the control circuit.

Now here's what it looks like on the scope:

Thyristor regulator oscillogram

The regulator is working correctly on the left half of the picture. Set point is 8 V (as shown by the yellow trace) and almost no load. The control fires thyristors when the AC waveform on anode falls a little bit above 8 V (just before the blue or gray trace crosses the yellow trace) to cover for the negligible loss of charge on the tank capacitor.

But what happens at the third cycle? The gray thyristor fires at the correct moment, however the blue thyristor fires as well as soon its anode voltage gets high enough, charging the output capacitor way above the set voltage.

The immediate reason for this fault is because the combined blue and gray lines never fell to 0 V at the same time. Here's a close-up of the oscillogram: you can clearly see that the blue and gray waveforms intersect at 8 V, not 0 V. Since the control circuit depends on the SYNC signal (which basically provides max(Ublue, Ugray) function) falling near zero it never switches off the trigger current and mistakenly triggers the blue thyristor too soon.

Thyristor regulator oscillogram, detail

So the blue thyristor firing is a secondary effect. The problem already shows itself well before that, when the gray voltage gets pegged at 8 V. So what's happening here?

If it weren't for the SYNC bridge the blue and gray voltages would be weakly defined when the voltage over the transformer secondary is less than 8 V because all diodes in the bridge would be closed. However, the SYNC bridge diodes are conducting down to 0.7 V above ground, so the voltages should not be floating at 8 V as the 10 kΩ resistor makes a good connection to the ground.

Take a look at the instant marked with the red line. Here are the voltages at that instant on all the active components:

Thyristor regulator diagram, annotated

Note that the voltage on the SYNC bridge's 10 kΩ load is 7.4 V, meaning 0.7 mA is flowing through it.

Kirchhoff's current law says this current must come from somewhere. Where? At that moment voltages on all elements point away from the bridge, so it can't be a large leakage current because it would point into the wrong direction.

The only exception is the blue thyristor, however it would have to leak pretty badly to account for almost a milliamp of current. These thyristors are rated at 1 mA reverse current at 800 V. And furthermore it appears as if the current starts the moment trigger current starts flowing into the gate.

As I said, the practical discussion ends with the finding that some stray source of current is affecting the circuit. The obvious solution is to decrease the load resistance of the SYNC bridge so far that it is able to sink the additional leakage current. And it worked - after decreasing the resistance to 5 kΩ the problem went away.

However, the underlying cause of this anomaly remains a mystery to me.

Posted by Tomaž | Categories: Analog | Comments »

New Nelma release

27.07.2010 12:27

This is a kind of a late announcement: A few weeks ago I released version 3.2 of Nelma, the numerical electromagnetics package. Changelog isn't very impressive, with the most significant change being a patch that fixes compilation on libpng 1.4.x (contributed by Thomas Klausner of the NetBSD's pkgsrc team).

To put some light in this almost forgotten project, here's a brief description:

Nelma is a command line tool for numerically calculating various electrical properties of printed circuit boards.

It is currently capable of calculating capacitances between objects - nets on a PCB. It returns a spice-compatible description of an equivalent circuit of stray capacitances that can be for example used for more accurate circuit simulation. Alternatively it can also produce field data that can be plotted for example with Gnuplot.

There's an export plugin available for gEDA PCB software that automatically creates a Nelma configuration from a PCB layout.

Nelma is available under the GNU General Public License version 2.

I admit I haven't really used this since I left the Faculty, but back then it did help me with a couple of projects. The emphasis was mostly on the simplicity of the algorithm, so I stuck with the relatively inefficient finite difference method (ouch, O(n3) complexity) instead of the usual finite elements. Right now it could really use some love in form of algorithm parallelization or conversion to finite elements method. Any takers for a summer project?

Posted by Tomaž | Categories: Code | Comments »

Ampersand Ay Em Pee Semicolon

25.07.2010 14:10

Most people don't seem to get content encodings. The most popular way of working with them seems to be randomly throwing encode() and decode() functions at the problem until it compiles/runs/displays in the browser.

I found the most recent example of such practice the other day at work. An ampersand is a pretty common character in URLs since it's used as a parameter separator in GET requests. One common place to find URLs is in RSS and Atom feeds. These two formats are dialects of XML, where ampersand is a special character, denoting a character reference or an external entity. Hence it must be escaped. See the problem?

It turns out a surprising amount of RSS and Atom feeds on the web have URLs that contain obviously incorrectly escaped ampersands. The most common mistake looks like this:

...
<link>http://www.example.com/?a=1&amp;amp;b=2</link>
...

This is valid XML, but the URL is:

http://www.example.com/?a=1&amp;b=2

when it obviously should have been:

http://www.example.com/?a=1&b=2

But since those GET parameters that get garbled are in most cases used for tracking people around, nobody ever notices that because pages still display fine in the browser. The corollary is that nobody ever looks at the results of that tracking or somebody would surely notice the missing traffic coming from RSS feeds.

So, what is the correct way of dealing with these URLs? In theory, a valid URL could actually contain the sequence of characters "&amp;". So there is no way to know for sure if this is an error on the part of the XML author or not.

In practice, the solution is to just call decode() on the URL until it eats up all &amps;. It seems to work every time.

But are there sites out there that legitimately use such URLs? If there are, they seem to be ignored by Google. "inurl:&amp;" query returns only sites that have an ampersand look-alike character in urls (U+FF06, "fullwidth ampersand"). So the query obviously runs in Google's index, but pages with such URLs are either missing or filtered out.

As a side note, the URL http://en.wikipedia.org/wiki/%26amp%3B actually always resolves to a server error page.

Posted by Tomaž | Categories: Code | Comments »

Light engineering

23.07.2010 18:01

My lab power supply is progressing steadily, with minor setbacks now and then. One trivial task that still needed to be done is putting lights into those nifty analog panel meters.

I ordered two instruments, a voltmeter and an ammeter, from Conrad. They come with fittings for (what I guess are) small incandescent bulbs for backlight, but no actual bulbs. Since I found incandescents a little too retro I decided to fit them with 3mm white LEDs instead. Luckily, they fit in almost perfectly.

I thought clear white LEDs I had would have a too narrow beam and wouldn't lit up the entire scale. So I decided to try my hand at Keith's LED diffusing technique.

It turned out that the single abrasive brush I had was a bit too rough and it ate through the clear plastic LED almost immediately. This was the best I could do, with the bulb still visibly deformed. I would do better to just use fine sandpaper:

Analog voltmeter, lit by one white LED

However, it turned out that when fitted in, the LEDs shine a bit upwards, so the nice bright beam on this photo turns into a single bright spot on the bottom. It actually makes no visual difference if the LED is frosted or not. So I left all subsequent LEDs in their original states.

I did notice though that most of the light was lost through the top of the instrument. So, the solution was straight-forward - put a white cardboard reflector up there.

Result as you can see is pretty good:

Analog voltmeter, lit by two white LEDs

By the way, the left LED is frosted, while the right one is clear.

Here is a close-up of the LED arrangement and the reflector on the top. I removed the metal spring fittings for light bulbs that were too tight and used LED's own leads sa simple spring latches. When the top cover presses down on them they sit pretty securely.

Panel voltmeter without the front cover

Finally, it's interesting to note that the 3 A ammeter has an internal shunt with the moving coil instrument connected directly over it, without any additional series resistance. The instrument itself has an instrument constant of 2.5 mA/A (e.g. 2.5 mA of current must flow through the coil to get 1 A reading).

These meters are advertised as accuracy class 2.5, which is pretty good considering that the shunt is a piece of metal, obviously soldered manually with little precision and gratuitous blobs of solder on both ends. Unfortunately I took the original shunt out before doing any measurements, so I can only speculate whether it actually lived up to its specifications.

Posted by Tomaž | Categories: Analog | Comments »

Can't do that Dave

21.07.2010 9:36

Recently Debian desktops (and probably other distributions) got smart and won't allow you, a regular user, to shutdown the system if they think other users are logged in. The warning says System policy prevents stopping the system when other users are logged in.

I'm sure this is a most welcome addition to those 0.1% of installations that are actually used by multiple (human) users and allow shutting down the whole system by non-administrators. For the rest of us, this is just an irritation that pops up whenever you want to turn off the laptop and there's a root console or a sandboxed application running somewhere in the background.

It turns out this can be fixed in a rather trivial way. This post on Arch Linux Forums showed the way.

Drop a file named multiple-users.pkla into /etc/polkit-1/localauthority/50-local.d (not under /var/lib as suggested in the forum, as that is under package manager's control) with the following content:

[shutdown privs]
Identity=unix-user:username
Action=org.freedesktop.consolekit.system.restart-multiple-users;org.freedesktop.consolekit.system.stop-multiple-users
ResultAny=no
ResultInactive=no
ResultActive=yes

Of course add your user name above.

What this does is grant the restart and shutdown privileges to processes running under your user name while you have an "active local session". Not sure how they define what a local session is. Maybe an utmp record for a local terminal. See man pklocalauthority(8).

Posted by Tomaž | Categories: Code | Comments »

Partition alignment tester

01.07.2010 19:52

Lenovo Thinkpad T61 I use at work has abysmal IO performance. The whole system becomes unusable if some process starts moving gigabytes of data around the disk (not so uncommon when dealing with, say, Wikipedia dumps).

This is also noticeable at boot: 75 seconds from power-on to login prompt, then 45 seconds to get to a usable GNOME desktop and a further half a minute to start Firefox. All the time the hard drive disk LED is constantly lit up (which always reminds me of how Windows 95 used to boot). This is on stock Debian Squeeze (but was the pretty much same on Lenny)

Since colleagues running Windows on the same hardware don't complain about such problems I thought that maybe the problem was in the way I partitioned the disk. See, the computer came preinstalled with Vista, which I promptly deleted. I also repartitioned the disk while installing Debian. If the disk is one of those with 4 KB physical block size perhaps the new partitions I made are misaligned?

This laptop is now a bit over 2 years old and as far as I know 4 KB blocks weren't used back then (hence my ignorant repartitioning). But perhaps Lenovo was a little ahead of time?

Unfortunately it's impossible to reliably tell the physical block size from the information reported by the disks' firmware (dirty details here). For instance, WD EARS disk in my Desktop plainly reports 512 B physical sectors even though I'm certain it uses 4 KB ones.

So I made a little tool that reads or writes 4 KB blocks from a partition with different alignments and measures the throughput. On a disk where logical and physical block size differ, throughput should be significantly lower on unaligned accesses because the disk must do multiple physical accesses per single logical operation.

Here are the measurements on the Thinkpad:

Writing to /dev/raw/raw1
Size 514805760 bytes, reported FS block size 0
10 processes, each writing 100 * 4096 bytes
align	elapsed	throughput
0	3 s	1.3 MB/s
1	3 s	1.3 MB/s
2	3 s	1.3 MB/s
3	4 s	1.0 MB/s
4	3 s	1.3 MB/s
5	3 s	1.3 MB/s
6	3 s	1.3 MB/s
7	3 s	1.3 MB/s

And here on my desktop with WD EARS drive:

Writing to /dev/raw/raw1
Size 514805760 bytes, reported FS block size 0
10 processes, each writing 100 * 4096 bytes
align	elapsed	throughput
0	3 s	1.3 MB/s
1	35 s	0.1 MB/s
2	37 s	0.1 MB/s
3	38 s	0.1 MB/s
4	39 s	0.1 MB/s
5	38 s	0.1 MB/s
6	38 s	0.1 MB/s
7	39 s	0.1 MB/s

As you can see Thinkpad has the same throughput regardless of the alignment while unaligned accesses get a huge penalty on my desktop. Head seek time dominates in these measurements, hence the relatively low maximum throughput on both machines.

I tried to cancel the effect of any caches the best I knew in my code but with all the magic that sits between a write() call and the physical platter on a modern system it's impossible to be sure. Still I think this is a pretty strong indicator that partition alignment isn't the cause of the performance problems here. And it's also a pleasant confirmation that I did properly set up partitions on my desktop (Ted has a really good guide how to do that - just ignore the fact that he is talking about SSDs)

You can get the alignment tester code from git:

git clone http://chandra.tablix.org/~avian/git/alignment_tester.git

Make sure you read the source and understand what it does before running. Also you will need a scratch partition because tests are destructive (I used the swap partition on both machines for that). Oh, and do a full backup first.

Posted by Tomaž | Categories: Code | Comments »