Avian’s Blog

Charging stations like this are starting to pop up around the city. So far I've seen four of them, in the city center and the shopping district BTC (this site lists 13 however)

Surprisingly, they appear to be nothing more than glorified AC power sockets. This one is the only one I've seen that even has a display and buttons. The socket is of the exact same kind you have at home - that is an ordinary schuko, not some newly developed automobile connector.

That's good to know because the brochures for the electric cars of course state that you can charge their batteries in 30 minutes. However that is only possible with a socket like the new ISO 62192 type 2 that will provide as much as 250 A of current. You won't get one of these in you home any time soon and I have yet to see one in a charging station. With around 10 A that a schuko will provide you'll have to spend half a day shopping while the batteries charge.

That said you can't actually buy an electric car yet although it appears at least three models will get here sometime later this year. It's unclear what kind of a charging standard they will support.

The topic of electric cars also exposed (again) how completely devoid of even basic understanding of physical quantities most journalists are. Almost none of the articles covering this topic in print can correctly match the current, voltage, power and battery capacity with their respective units and meanings. Even the commercial for one of the cars states the power in kWh. Seriously?

While I must admit an electric car sounds neat, I don't see myself having one anytime soon. Even with the 5000€ government subsidy, the early-adopter cost will be roughly 3 times that of an internal combustion powered vehicle of comparable size and vastly superior range. Also I'm kind of skeptical of the green energy badges on these charging stations. We don't have enough domestic capacity even from dirty sources to power any significant number of electric vehicles.

Here's one final note in what turned out to be a series of posts on thyristors.

In the case where the cathode of the thyristor isn't at the ground potential you usually need some way of galvanically separating the control circuit from the thyristor's gate potential. The most common components that can do that are a pair of coupled coils (impulse transformer), a capacitor or an opto-isolator. And in fact you can see all these three used in practice.

Here are examples of all three principles I've seen in real-life circuits with some comments:

This appears to be the most common way of doing it in older devices. For instance, the Hewlett Packard 6286 power supply uses an impulse transformer to control its thyristor preregulator.

The control circuit sends a current pulse through the primary winding and the matching impulse on the secondary side triggers the gate. The resistors are there to limit the current and assure proper distribution to both gates.

The coil makes this an expensive solution.

This approach is usually seen in modern circuits. You can also get thyristor with the opto-coupler already built-in, which removes the need for an external component.

In the case above the opto-coupler acts like a switch that short-circuits the gate to the thyristor's anode, providing triggering current. The trigger current is again limited by the resistor and depends on the anode-cathode voltage. The resistor should be carefully chosen to keep the current within safe limits for all anticipated switching voltages.

This is arguably the cheapest and most troublesome solution. While in the previous two solutions the trigger current was independent of the cathode voltage, this isn't so in this case thanks to the I = C dU/dt characteristic of the capacitor.

The galvanic separation of the control circuit is achieved by the 1 nF capacitor. Thyristors are triggered by letting it charge through the 2.4 kΩ resistor and the thyristor's gate inputs. After they are triggered the control circuit grounds its output and the capacitor discharges through the 1N4148 diode. Note that V+ doesn't need to be higher than cathode voltage for this to work.

So far so good. However there are several potential sources of problems here:

• To achieve a powerful enough impulse to adequately open the thyristors either the capacitor should be large or the supply voltage should be high. However the same amount of charge must also flow in the other direction when the capacitor discharges. A large capacitor hence means a longer discharge time and longer delay before thyristors can be triggered again.
• When a thyristor fires there is a positive step change in the capacitor voltage, which directly translates to a voltage spike on the control side. Without proper protection this can reduce the life time of ICs in the control circuit.
• When a thyristor is opened during the second quarter of the sine wave the gate voltage has a negative slope before the thyristor commutates. This negative dU/dt charges the capacitor in the opposite way (say -0.7 V if there are protection diodes on the other side). After the first thyristor closes, the current flowing through the capacitor while the negative charge dissipates can falsely trigger the second thyristor, causing misfires.

(Update: that is a 1 nF capacitor in the last schematic, as Žiga noted in the comments)

Two years ago I ranted about how gnome-mount insults the user by giving absolutely no feedback on whether the operation was successful or not. Since then a lot of things changed and now the preferred way of mounting filesystems without root access seems to be udisks. This is what appears to be used by GNOME these days to mount things from the GUI and there is also an udisks command line tool.

After re-installing Debian last week mounting external USB drives no longer worked. GNOME stubbornly said Error mounting: mount exited with exit code 1: helper failed for all plugged-in drives while mounting them manually as root with the trusty old mount worked flawlessly.

Going to the command-line didn't improve the situation much:

toybox$ udisks --mount /dev/sdb1
Mount failed: Error mounting: mount exited with exit code 1: helper failed with:
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Ok, so it's trying to mount the drive using a wrong filesystem. dmesg output confirmed that, saying kernel was trying to use UDF-FS, while this drive has a plain old VFAT on it.

No problem, I'm going to specify the filesystem type myself:

toybox$ udisks --mount /dev/sdb1 --mount-fstype=vfat
Mount failed: Error mounting: mount exited with exit code 1: helper failed with:
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

That's weird. Maybe some internal detection is overriding my type specification (even though it shouldn't - all command-line interfaces I've seen give the command-line arguments priority over any configuration file or autodetection). Let's see what udisks thinks about the filesystem type.

toybox$ udisks --show-info /dev/sdb1|grep vfat
  type:                        vfat

Right. It knows without my help that it's a VFAT formatted disk. So why does it try to mount it using UDF? udisks offers no option to increase the verbosity or to enable debug output. It doesn't write anything helpful into syslog. How exactly is one expected to find a problem? Or even file a meaningful bug report that won't immediately be rejected for the lack of information?

In the end, it turned that the culprit was the Debian installer that for some reason put the following line into /etc/fstab. Removing it restored normality.

/dev/sdb1       /media/cdrom1   udf,iso9660 user,noauto     0       0

Don't get me wrong. udisks is light years ahead of gnome-mount in terms of usability. But what is it with these wrappers around mount? Must they always actively derail any and all attempts to find out why they aren't working correctly?

A few days ago I finally managed to upgrade my work laptop, a Lenovo T61. To help with the really bad IO performance I replaced the original drive with a hybrid Seagate Momentus XT. I also reinstalled Debian Squeeze from scratch, replacing the old system that went through several Stable-to-Testing-to-Stable cycles. Not because that would be needed per-se, but because I wanted to have a true amd64 system and did not want to go through the adrenalin rush of doing that on a live system again.

Squeeze installation went smoothly. It went so smoothly in fact that I probably would not believe it if I wouldn't see it with my own eyes. Everything was setup correctly and the computer rebooted into a nicely themed GNOME desktop. Proper partitioning, Nouveau-powered X server, reliable suspend-to-RAM and working volume buttons on the keyboard out of the box. Beautiful. Congratulations to the Debian team!

One thing also worth mentioning is that Squeeze now ships with hybrid CD images for installation. This means that you can simply dd an official Debian installation ISO to a USB flash drive and it will boot up correctly. I will happily forget the old routine of installing SYSLINUX bootloader and the ISO image separately.

It is interesting how different this freshly-installed system is from the previous one that was constantly upgraded in small steps (most of the time I tracked the Testing release, updating weekly). The computer no longer freezes if I remove it from the docking station while it's running. I haven't had a single freeze waking up from suspend-to-RAM while previously that was a daily occurrence. Also there are various small cosmetic improvements, like the cool Ubuntu-like notification balloons - although some of this can probably be attributed to my new home directory, free from dot-file clutter.

I'm sure all of these problems could be fixed in the old system. But this install from scratch just turned out so much more time efficient than any specific tweaking that I will seriously consider freshly reinstalling other desktop machines when the next release comes.

Going back to the hard drive upgrade. It's hard to say whether improvements in performance can be attributed to the 4 GB cache of the Momentus XT hard drive or the fact that it's a 7200 RPM drive (compared to the old drive's 5400 RPM) and of course changes in the OS and the freshly created file system.

What ever the cause, the improvements are significant. The new system:

• Boots up to GDM password prompt in 30 seconds (old one before reinstall took 53 seconds),
• takes further 8 s to a fully loaded GNOME desktop (previously 53 s),
• 3 s to start Iceweasel (previously 22 s),
• 6 s to start Icedove (previously 15 s),
• and 4 s to start OpenOffice.org (previously 16 s).

Again, these can be attributed to changes in software. For instance, the old times in the list above were measured just before reinstalling and they are somewhat different than the measurements I took half a year ago on practically the same system. So I guess only time will tell if this hybrid disk was really worth its price.

Après-ski in a cottage in Austrian Alps sometimes offers opportunities for weird experiments that don't involve drinking beer.

The compass in my mobile phone didn't show north and this salt and pepper stand was the culprit - it happened to be magnetized along handle. In combination with the magnetometer and the compass application in the phone it turned out to be a pretty good demonstration of a Hall-effect absolute rotary position sensor.