DD doesn't cut it

14.10.2011 23:26

You can add the Seagate Momentus XT to the list of quirky storage devices.

I was cleaning a few disks in the usual way, by overwriting the data with zeros like this:

$ dd if=/dev/zero of=/dev/sdb bs=4096

I don't believe such data is recoverable by any ordinary means, so I don't do overkills like multiple passes with random garbage and such. However I am, as always, wary of broken software that doesn't do what it's told. So I check each disk afterwards by abusing the hexdump utility like this:

$ hd /dev/sdb
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

If all I get back are zeros, nicely collapsed into a single line like in the example above, then the data has been securely erased. I've never actually seen this test fail, until today. Imagine my surprise when hd revealed a good 10 MB chunk of data around 4 GB from the start of the 500 GB drive that should not be there.

I can't attribute this to anything else than some weird firmware bug. dd reported writing 500 GB data as expected. There was nothing in the kernel log. The boundaries of this unerased region didn't have any nice round numbers I could recognize. In the unerased data I could recognize parts of files from the disk (including a full copy of the GPL) although some parts seemed to be partially erased. For instance, one block would have 1 non-zero byte out of 8, another 3 bytes and so on. Again I could find no simple pattern.

A second dd command, targeted at the unerased region did remove the data for good, so it wasn't caused by some permanent error. Just to be sure I also did an ATA Secure Erase on the drive.

Weird. This is a hybrid drive with flash and magnetic storage which means it has a more complicated firmware than ordinary drives, so I guess it's expected to also have more bugs. In fact a search for "momentus xt firmware" reveals a bunch of problems, although none look similar to what I've stumbled upon. I'm just wondering how often such mishaps happen and go unnoticed when the buffer that should be written contains something more important than a bunch of zeros.

Posted by Tomaž | Categories: Digital | Comments »


10.09.2011 13:50

A while ago I was given this piece of hardware to analyze. It's a scary little bug that sits on the cable between a computer and a monitor and makes screenshots. It comes in HDMI, DVI and VGA (the one I have) flavors and looks more or less like a short extension cable. All of the nasty bits are hidden away in one of the connector housings and the only suspicious thing giving it away is an extra USB cable that goes into it. That is used for power supply when the device is in stealth mode, and for reading the captured data afterwards (you need insert the red USB key between the computer and the device in order to access it).

The manufacturer recommends using it on employees and children. In the latter case I hope to teach them how to evade such monitoring should they ever find themselves in a society that encourages that. The use I was exploring though was a bit less sinister capturing of presentation slides on lectures for Viidea.

VideoGhost, VGA version

The first thing I noticed the moment I plugged it in is that my EeePC 901 crashed and required removing the battery to get it to boot again. Trying it again on a different laptop produced similar results. However turning the machine off, plugging the VideoGhost in and turning it on worked.

Since VGA is analog output only that's a bit surprising. I suspected this has something to do with Display Data Channel, which is a fancy name for an I2C bus that's used in all recent monitors for identification. Poking around I quickly found out that all the pins on the middle row of the VGA connector are tied to ground, including pin 9, which is +5 V supply for DDC. Shorting this to the ground while the computer is turned on probably trips some fuses which cause the computer to crash.

I'm not sure whether this is a design or manufacturing error. I also wonder why they haven't used this pin for power supply instead of that suspicious USB cable.

VideoGhost, top PCB

Cracking open the shell wasn't trivial, since the whole thing is filled with hot glue. However a careful application of a hair drier and various sizes of flat screwdrivers did the trick. It still works (minus one SMD capacitor I managed to tear off), however I pretty much demolished the case.

The keelog.com site says the device contains a microprocessor and a FPGA chip. What I see inside more or less agrees with that.

There are two PCBs. The top one contains a chip in a QFP64 package that connects to the USB cable, a MicroSD card (hand soldered via tiny wires) and a backup battery wrapped in green masking tape. All markings are sanded off but it's most likely a microcontroller with hardware USB support. Quite a few ICs fit the description and after some searching around I wasn't able to find one that would fit the pin assignments exactly. I'm sure with some more effort the exact chip could be found. There's also an empty header for what might be a JTAG port.

The bottom board has a chip in a QFP80 package that is connected to the VGA signals. It talks to the top board through something that looks like a combination of a parallel bus and I2C.

Capturing a frame from the VGA requires three AD converters capable of 150 megasamples per second or thereabout. I'm not aware of any off-the-shelf FPGA chips that would contain such hardware. It's possible this is in fact a mass-produced VGA framebuffer IC. It's also possible the bottom side of the PCB contains another IC, but I'm reluctant to find out since it would mean more destructive tearing and I might break something.

VideoGhost, bottom PCB

I'm not all that impressed by this design. The amazing mess of wires inside doesn't give me confidence in it's reliability, neither does the already-leaking back-up battery inside. It does however offer some interesting challenges in reverse engineering. I might poke around a little more and perhaps try to sniff the I2C communication on the board or checkout that JTAG port. I also wonder what trickery is used in the USB key that enables the USB communication on the device.

Posted by Tomaž | Categories: Digital | Comments »

More than just audio

25.08.2011 17:02

I recently came across this very useful IC that looks like it might be useful in a number of scenarios. This is C-Media electronics CM108 (datasheet). It's an USB audio interface chip that is used in a number of cheap USB audio dongles and headsets. For instance, SPEEDlink SL-8850 goes for around 15 € with shipping from Amazon or the local retailer.

Inside Speedlink SL-8850

It contains two audio DACs and one ADC (48 kHz sampling rate), as expected for such a chip. What makes it interesting is that it also contains an interface for a simple serial bus (I2S) that is meant for driving external AD or DA converters, but can be abused to stream arbitrary digital data from or to the PC, as long as it fits into 32 bits times 48 kHz bandwidth. Also included in the package are 4 GPIO pins and 4 debounced key inputs.

As usual there's an optional place for a serial EEPROM for USB product/vendor IDs, which can also be programmed via the CM108 itself.

From the USB host side, the data stream is exposed as a standard USB audio device (usable for instance via snd_usb_audio ALSA driver in Linux) while the GPIO pins and keys use the HID interface which can be accessed via the HID API.

Right now I'm using it to record data from the 433 MHz receiver I was writing about previously, but it appears it might be useful in other projects as well. For example here's an article about using it for an audio-frequency oscilloscope. Considering you get the chip and a few other tidbits (USB connector, two audio jacks) for such a low price it's certainly worth considering in place of a USB-enabled microcontroller when it fits the requirements.

Posted by Tomaž | Categories: Digital | Comments »

Funcube Dongle Pro

23.08.2011 20:11

During the CCC camp I found out about the Funcube Dongle. It's a small USB device that contains a complete software defined radio frontend. It was designed to receive telemetry from the Funcube amateur satellite, but gained popularity among HAM radio operators and other folk interested in radio communications because of low cost (around 160 €, including shipping) and versatile frequency range (64 MHz to 1700 MHz central frequency with up to 80 kHz bandwidth). So much popularity in fact that the authors had problems keeping up with demand.

I have been playing with SDR interfaces a while ago and was pretty much sold on this gadget when I saw receipt of a satellite transponder from a hand-held antenna. It arrived via Fedex yesterday and I was eager to try it out.

Funcube Dongle Pro

The documentation says software support for Linux is still under development. However because the device uses USB audio and USB HID standards there are no drivers necessary. For setting up the radio frontend hardware there is a nice graphical QT application available that gives you access to all the knobs. It's called qthid.

Setting up qthid 3.0 on my Debian Squeeze system took a few tweaks. First, you need to install a few dependencies:

# apt-get install libusb-1.0-0-dev
# apt-get install qt-qmake qt-dev-tools

Note that you don't in fact need the complete QT Creator IDE to compile. This saves some considerable disk space.

It also turns out that libusb in Debian has a broken pkg-config, which means the following patch needs to be applied:

--- a/hid-libusb.c
+++ b/hid-libusb.c
@@ -40,7 +40,7 @@
 #include <pthread.h>
 /* GNU / LibUSB */
-#include "libusb.h"
+#include "libusb-1.0/libusb.h"
 #include "iconv.h"
 #include "hidapi.h"
--- a/qthid.pro
+++ b/qthid.pro
@@ -53,6 +53,7 @@ win32:LIBS += "C:\\Program Files\\Microsoft SDKs\\Windows\\v7.
 linux-g++ {
     CONFIG += link_pkgconfig
     PKGCONFIG += libusb-1.0
+    LIBS += -lusb-1.0

qthid should now compile with

$ qmake
$ make

After setting up udev rules as described in the README file, qthid still said No FCD detected. Documentation suggested that obsolete firmware might be the cause. qthid actually allows you to upgrade the firmware from within the program, but since it doesn't detect the device in the first place it's kind of a catch-22. I solved this by first setting up qthid 2.2, upgrading the firmware in Funcube Dongle to version 18f (latest stable release at this time) and then upgrading qthid to version 3.0. As you can see, this did the trick:

qthid screenshot

By the way, this is how the device presented itself before the firmware upgrade:

generic-usb 0003:04D8:FB56.0004: hiddev0,hidraw0: USB HID v1.11 Device
[Hanlincrest Ltd.          FunCube Dongle V0.0  ] on usb-0000:00:1d.0-2/input2

and after the upgrade:

generic-usb 0003:04D8:FB56.0006: hiddev0,hidraw0: USB HID v1.11 Device
[Hanlincrest Ltd.          FUNcube Dongle V1.0  ] on usb-0000:00:1d.0-2/input2

The next step is to get the latest version of GNU Radio framework working. After it finishes compiling I guess that shouldn't be too hard.

Posted by Tomaž | Categories: Digital | Comments »

Steampunk telephony

27.04.2011 19:04

Yesterday I went to the Museum of Post and Telecommunications in Polhov Gradec, which is a part of the national technical museum. With a relatively small exhibition it covers the history of telecommunications from horse carrying a bag of mail to digital mobile telephony. Certainly the most interesting exhibit there was a working electromechanical telephone exchange with three phones connected to it so you can actually look at the moving stepping switches while dialing a number.

I would say these machines have a similar appeal for electrical engineers as steam engines probably have for mechanical engineers. Everything is exposed and you can inspect their mode of operation simply by observing them with an unaided eye. Even with just basic engineering knowledge you can enjoy deducting interesting details of how they work.

More modern systems are certainly a valuable part of the collection, but their core components are simply much too small, too fast or too complex for this kind of observation. While observing a vintage transistor circuit can be just as fun, I doubt any museum allows you to poke their exhibits with an oscilloscope.

It is no wonder then that people are still building relay-logic devices (or steam locomotives for that matter).

Posted by Tomaž | Categories: Digital | Comments »

Samsung GT-I5700 disassembly

05.04.2011 22:38

I've already said plenty of bad things about the Android-powered mobile phone I bought nearly a year ago, so I'll refrain from repeating myself. I tore it down the other day to see if anything could be done to fix the highly annoying contact bounce the lock-unlock button developed lately. And also to satisfy my curiosity by poking around this made-for-the-scrapyard device.

Samsung GT-I5700 with the PCB exposed

Removing the back to expose the (single) PCB was pretty straightforward: six screws and some plastic brackets. There's a black GSM/UMTS antenna block attached to the back of the shell (under the keys) and three more similar contacts at the top in the shell itself. It looks like something is embedded into the white plastic, possibly a Wi-Fi, Bluetooth or GPS antenna. Connections to all of these are merely by gold-plated springs that push agains the back side when the phone is put together.

Samsung GT-I5700 PCB turned over

The backside of the PCB contains all the integrated circuits and is connected to everything else via tiny SMD connectors and bits of flexible PCB. The CPU has an RF shield that is basically conductive rubber ring that presses against the PCB and the aluminum frame. There's also a tiny backup battery on the right side.

Flexible PCB connections in Samsung GT-I5700

The PCB is held in place with a single screw at the top. The bottom hangs freely, giving the phone a distinctive tunning-fork-feeling it you knock on it.

I admit I haven't seen the inside of many phones, but this one got surprisingly dusty in less than a year of use (in what I consider a clean environment). The rubber seals around the holes in the casing obviously proved to be insufficient protection against the environment.

In the end, I tested the tiny SMD push button and it didn't seem to behave any differently than the other buttons, so I left it as it is. It's probably a better idea to replace everything else around that button.

Posted by Tomaž | Categories: Digital | Comments »

USB data eater

08.01.2011 14:23

I found a curious feature the other day while copying some (rather important) data from an 512 MB USB flash drive. The contents of the files differed each time I copied them. Some further testing turned out that there's a part of the drive's address space that is unreliable and will return single-byte errors when read back.

For instance, here's a list of bytes that differed between two consecutive sequential reads:

0x0078071b: d5 != 4e, 11010101 ^ 01001110 = 10011011
0x007807c0: fc != fe, 11111100 ^ 11111110 = 00000010
0x007836d6: 46 != 56, 01000110 ^ 01010110 = 00010000
0x00785267: 65 != e5, 01100101 ^ 11100101 = 10000000
0x007852c7: 11 != 51, 00010001 ^ 01010001 = 01000000
0x00785344: 65 != 39, 01100101 ^ 00111001 = 01011100
0x0078720b: 00 != 40, 00000000 ^ 01000000 = 01000000
0x00787250: 86 != a6, 10000110 ^ 10100110 = 00100000
0x00787274: 51 != d1, 01010001 ^ 11010001 = 10000000
0x0078732f: 6a != 38, 01101010 ^ 00111000 = 01010010
0x00787336: 75 != f5, 01110101 ^ 11110101 = 10000000
0x00787389: 53 != 73, 01010011 ^ 01110011 = 00100000
0x007890f2: 01 != 52, 00000001 ^ 01010010 = 01010011
0x0078919c: b7 != 37, 10110111 ^ 00110111 = 10000000
0x0078933d: c2 != e2, 11000010 ^ 11100010 = 00100000
0x00789676: 5c != 7c, 01011100 ^ 01111100 = 00100000
0x0078b478: de != fe, 11011110 ^ 11111110 = 00100000
0x0078b4ad: bf != ff, 10111111 ^ 11111111 = 01000000
0x0078b512: ae != be, 10101110 ^ 10111110 = 00010000
0x0078b54c: 0d != 4d, 00001101 ^ 01001101 = 01000000
0x0078b5d3: 75 != f5, 01110101 ^ 11110101 = 10000000
0x0078d70c: 02 != 12, 00000010 ^ 00010010 = 00010000
0x0078d799: 01 != 3c, 00000001 ^ 00111100 = 00111101
0x0078f69e: e4 != 9c, 11100100 ^ 10011100 = 01111000
0x0078f79f: b3 != 93, 10110011 ^ 10010011 = 00100000
0x00793653: 5d != 1d, 01011101 ^ 00011101 = 01000000
0x0079367a: 39 != 19, 00111001 ^ 00011001 = 00100000
0x007936de: c5 != 67, 11000101 ^ 01100111 = 10100010
0x007936f6: 3a != 2a, 00111010 ^ 00101010 = 00010000
0x00793738: 49 != 09, 01001001 ^ 00001001 = 01000000
0x007937a9: 36 != 16, 00110110 ^ 00010110 = 00100000
0x007990fe: c7 != 57, 11000111 ^ 01010111 = 10010000
0x007991c8: 0d != 1d, 00001101 ^ 00011101 = 00010000
0x007b5024: 38 != 81, 00111000 ^ 10000001 = 10111001
0x007b504b: 91 != 7b, 10010001 ^ 01111011 = 11101010
0x007b50ce: 86 != 06, 10000110 ^ 00000110 = 10000000
0x007bf094: 80 != c0, 10000000 ^ 11000000 = 01000000
0x007bf0e9: 48 != 9c, 01001000 ^ 10011100 = 11010100
0x007bf0f3: c3 != d3, 11000011 ^ 11010011 = 00010000
0x007bf10c: 69 != e9, 01101001 ^ 11101001 = 10000000
0x007bf17c: 1c != 5c, 00011100 ^ 01011100 = 01000000
0x007bf1d0: e2 != f2, 11100010 ^ 11110010 = 00010000
Address range scanned 0x00000000 .. 0x1e800000, 42 bytes differ

The errors seem to be limited to addresses between 0x00780000 and 0x007bffff, a 256 kB block, but the list of error addresses differs after each read. Bits will switch both from 0 to 1 and 1 to 0, as evident from the dump above, which seems to suggest this isn't due to faulty or stuck bits in the flash ROM.

For the record, the drive presents itself as:

usb 1-6.3: New USB device found, idVendor=0204, idProduct=6025
usb 1-6.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-6.3: Product: USB Flash Drive
usb 1-6.3: Manufacturer: PIXIKA

Just to be sure, I've tried reading this key on two different computers and both gave the same result (i.e. bytes from the address range above were always corrupted).

So, what is to be learned from this? Bad flash drives can silently corrupt your data (making my previous assumption about block level CRC invalid) - there is no evidence in kernel logs that the software was aware of corruption. I guess a fancy filesystem would protect you, but who uses that on USB drives?

Also of note is that badblocks(8) will not detect this by default (as it seems to depend on the kernel throwing an IO error). Only when run in read-write mode (-n flag, probably also -w) will it report problems with the drive.

This makes it the second case of silent data corruption in the last 3 months. Seriously, sometimes I feel like a magnet for broken technology.

Posted by Tomaž | Categories: Digital | Comments »


13.08.2010 18:43

Last week when I wrote about the Hewlett Packard 9000 I stumbled upon the High-Density Interconnect handbook. I got intrigued by a caption mentioning "stacked transistors" in relation to the HP FOCUS microprocessor that the 9000 series used. I went and dug a little deeper to see if I could find out what was meant by that phrase.

At that time HP was using the NMOS-III fabrication process, which was the successor to the NMOS-II. This was a 1 μm, two-metal layer process designed specifically for their new 32-bit 500.000 transistor FOCUS microprocessor.

I found a pretty detailed description of the technology in the HP Journal. The August 1983 issue is dedicated to the VLSI process while September 1987 deals with higher-level microprocessor architecture. Both are an interesting read for anyone that is into vintage integrated circuit technology.

Illustration of the NMOS-III process (from HP Journal, August 1983)

For instance, unlike CMOS circuits of today NMOS digital circuits had relatively large output impedance and drew a large quiescent current. First property became apparent when chips where unable to drive long PCB traces. This was especially problematic for the system's 18 MHz clock which had to be distributed throughout the computer. So they made a dedicated clock generator chip with gigantic output transistors (55 mm gate width!) and mounted everything on finistrates - special printed circuit boards with wire bonded dies, very small vias and very high-quality Teflon dielectric - all to decrease trace inductance as much as possible. Finistrates also helped solve the heating problem by having a thick copper core which conducted heat away from the components.

Remember the "self healing" RAM they mention in that advert? That was achieved with special polysilicon fuses which allowed the RAM chip to isolate defective parts by melting a part of the interconnect. Oh, and RAM used a four-transistor dynamic cell, unlike one-transistor commonly used today.

Fascinating stuff. Especially considering this was all published in a journal and not kept as a closely kept company secret.

However I didn't find what I was looking for. There is no mention of transistor stacking. On thing is clear though: NMOS-III process certainly did not have any provisions for vertical stacking of transistors (which is rare even today). So that caption most probably referred to some kind of circuit topology.

Posted by Tomaž | Categories: Digital | Comments »

27 years later

02.08.2010 19:29

Recently I came across this vintage advertisement for a Hewlett Packard 9000 computer at the (virtual) HP Computer Museum:

Hewlett Packard 9000 advertisement

The ad is quite an interesting read. For instance it mentions that the computer's integrated circuits used NMOS technology, which provided for copious amounts of heat, which in turn required a special PCB.

It's also interesting to compare it with this modern advertisement that happens to be on my table at the moment:

Microway advertisement

I can't help but think that the HP advertisement tries to help you make an informed decision while the new ad blinds you with bulleted lists full of trademarked names and buzz words. HP says they use a memory controller that can correct 32 bad memory locations, not that they have a SuperSelfHealMemTech™. Also it seems like HP advertised these computers to people that will actually use them (note how they mention finite element analysis, systems of equations, etc.) not some IT management that is only looking for a good deal on gigabytes per monetary unit.

Oh and HP 9000 name was more recently recycled for a series of printers. How sad is that?

Update: Figure 1 in the HDI Handbook I linked above says "HP FOCUS chip ... NMOS III (stacked transistors). What is "stacked transistors" referring to here? I can find no mentions of HP NMOS III process using any kind of vertical transistor stacking like ST-CMOS.

Posted by Tomaž | Categories: Digital | Comments »

The curious case of ViewSonic's EDID

03.06.2010 21:37

A couple of hours ago I was sitting in front of my desktop computer when I had to step away for a couple of minutes. When I returned, the screensaver had kicked-in and my ViewSonic VG2230wm LCD monitor was in sleep mode. Deep sleep mode it turned out, because I could not wake it up.

After some digging around and fruitless reboots, power cycles and cable reseatings I came to realize that xrandr was simply seeing the DVI-0 connector on my Radeon 4350 as disconnected.

Further, I stumbled upon this report in dmesg:

*ERROR* EDID checksum is invalid, remainder is 111
<3>00 ff ff ff ff ff ff 00 5a 63 1e a2 01 01 01 01  ........Zc......
<3>91 11 01 03 80 2f 1e 78 2e d0 05 a3 55 49 9a 27  ...../.x....UI.'
<3>13 50 54 bf ef 80 b3 00 a9 40 95 00 90 40 81 80  .PT......@...@..
<3>81 40 71 4f 31 0a 21 39 90 30 62 1a 27 40 68 b0  .@qO1.!9.0b.'@h.
<3>36 00 da 28 11 00 00 1c 00 00 00 ff 00 XX XX XX  6..(.........XXX
<3>XX XX XX XX XX XX XX XX XX 0a 00 00 00 fd 00 32  XXXXXXXXX......2
<3>4b 1e 52 11 00 0a 20 20 20 20 20 20 00 00 00 fc  K.R...      ....
<3>00 56 47 32 32 33 30 77 6d 2d 45 55 0a 20 00 39  .VG2230wm-EU. .9

radeon 0000:01:00.0: DVI-I-1: EDID invalid.
*ERROR* DVI-I-1: probed a monitor but no|invalid EDID

Did the EDID serial EEPROM just died on me? This story about reprogramming the EDID chip in a TV suggests that at least in some devices these EEPROMs aren't actually write protected. So it might also just been corrupted by a bug in the video driver or something in its vicinity.

OK, doing something like the procedure described in linked article above shouldn't be too hard. But where to find the original, uncorrupted EDID image? ViewSonic helpfully provides software for inspecting EDID, but doesn't include the original data.

Then, while searching for the original EDID image, I stumbled upon this thread about a similar problem. It suggested an amazingly simple solution:

  • Plug in both DVI and VGA cable into video card and monitor,
  • turn on computer and let it boot,
  • shut down computer,
  • unplug VGA cable but leave DVI alone,
  • unplug monitor for 10 seconds,
  • turn on the computer.

I found it hard to believe this voodoo would help, but considering the number of people there that said this helped, I tried it anyway. And it worked!

Interestingly, this is how EDID looks now (changed bytes in bold):

(II) RADEON(0):   00 ff ff ff ff ff ff 00 5a 63 1e a2 01 01 01 01
(II) RADEON(0):   22 11 01 03 80 2f 1e 78 2e d0 05 a3 55 49 9a 27
(II) RADEON(0):   13 50 54 bf ef 80 b3 00 a9 40 95 00 90 40 81 80
(II) RADEON(0):   81 40 71 4f 31 0a 21 39 90 30 62 1a 27 40 68 b0
(II) RADEON(0):   36 00 da 28 11 00 00 1c 00 00 00 ff 00 XX XX XX
(II) RADEON(0):   XX XX XX XX XX XX XX XX XX 0a 00 00 00 fd 00 32
(II) RADEON(0):   4b 1e 52 11 00 0a 20 20 20 20 20 20 00 00 00 fc
(II) RADEON(0):   00 56 47 32 32 33 30 77 6d 2d 45 55 0a 20 00 39

The changed byte represents the week of manufacture according to the EDID standard. 91h is invalid as a week number (at most 36h weeks in a year) and doesn't share any common bits with 22h. This makes it improbable that either some intentional mechanism or a random bit-flip in the hardware would cause this error, so it remains a mystery to me.

Is it just me or you just can't get any work done lately without some random piece of software or hardware going belly up on you?

Posted by Tomaž | Categories: Digital | Comments »

Tube clock

22.01.2010 18:51

I finally found the time to finish assembling the "Russian" tube clock I got from Dedek Mraz. It seems I'm starting to gather quite a collection of weird time keeping devices.

Assembled Ice Tube Clock from Adafruit.

Assembling the kit was a no-brainer - instructions include three pictures for every component you need to solder and have you check parts of the circuit before continuing. The only slightly tricky bit was getting the tube to align nicely with the casing before soldering its (many) pins.

Considering the kit comes from US, it was a nice touch to include 24 h European time and date format (yes, the clock can also show the day of week and current date). The power brick only had an US power plug though. I replaced it with the EU one - the circuit itself already supported 230 V.

Also, the pictures don't really show how the display looks like. Mine glows in a blue-green color and isn't particularly bright (I have the brightness set to 55). If you remember old video recorders that used to blink "12:00" (they also used to have VFDs) - that's how the tube actually looks like.

One annoying thing I noticed is that it's hard to set the clock to the second. You can't wait for the wall clock to catch up with the frozen seconds display because the menu will time out in less than a minute.

This means it's harder to assess the accuracy. Also this circuit doesn't provide a trimmer capacitor to fine adjust the oscillator frequency. I had the idea to add a DCF77 receiver (it appears there's a contact provided on the PCB board for that). However the FAQ page says the boost converter is too noisy for such a receiver to work near the clock. If that's true, I wonder what other devices also are also affected by this interference.

Posted by Tomaž | Categories: Digital | Comments »

VFD porn

18.01.2010 18:33

Vacuum Fluorescent Display from Adafruit's Ice Tube Clock

Vacuum Fluorescent Display tube from Adafruit's Ice Tube Clock, which I'm assembling right now.

Posted by Tomaž | Categories: Digital | Comments »

Normality restored

25.12.2009 18:04

The day before yesterday the ADSL modem connecting my server to the internet went belly up. I called the national ISP's technical support and was actually quite surprised when they quickly established that their modem is to blame (my previous experience was that they aggressively stick to the "reboot windows, check control panel settings" routine for all problems).

So yesterday a technician came and replaced the modem. tablix.org is back on-line and I can read my mail again. However instead of the old vanilla modem he installed some fancy new thing that among other things can also work as an ADSL modem.

Sinope 568+

The new device is a Sinope 568+ from Iskratel. It literally includes everything plus a kitchen sink - a PPPoE client, DHCP, DNS servers, HTTP proxy with a built-in censorware (a.k.a. parental control), VOIP, ... and 802.11abg hardware. In other words, everything I don't need. And what's worse, it appears all these capabilities are potentially under the direct control of the benevolent (?) ISP. At least judging by the instruction manual that says that if you can't set something up you just call support and they set it up for you remotely.

Somehow I'm not exactly content with the idea that there's a wireless transceiver in the house that's not under my control. Now I'm playing with the idea to replace the antenna with a nice little 50Ω terminator.

The particular device I got was obviously second hand, because it was already set up with a wireless SSID "Kresho" and a password I didn't know. After some experimenting I found that factory settings can be restored by holding the reset button while power-cycling the modem.

UPS load after replacing old ADSL modem with Sinope 568+

All these useless features also come with a power price. My UPS load went up 15% after Sinope was installed. I guess that is considered progress these days.

Posted by Tomaž | Categories: Digital | Comments »

901's belly button

04.12.2009 15:00

When I was replacing the left mouse button on my EeePC 901 the other day, I turned the motherboard around for the first time. Interestingly, there's a button there that doesn't seem to serve any purpose. It faces a solid plastic wall, so there's no way to get to it while the computer is in operation.

Button on the bottom side of the EeePC 901's motherboard

I wonder what's it for. Some kind of an alarm if the laptop's case was opened? But as far as I can see it doesn't get pressed when the case is assembled. Is it a vestigial reset button? Maybe the pinhole under it was scrapped as a cost-cutting measure.

It would be nice if Asus would include it as a spare mouse button, but unfortunately it has a completely different shape and size.

Posted by Tomaž | Categories: Digital | Comments »

Replacing mouse button on an EeePC

02.12.2009 18:56

A couple of weeks ago the left button on the touch pad of my EeePC 901 stopped working. At first it only skipped a click now and then, but it soon became completely unusable. It appears that I'm not alone with this problem.

I took the laptop apart and it was immediately obvious that the SMD tactile switch wasn't making a contact when it should be.

SMD tactile switch on EeePC 901 (left mouse button)

The switch itself is pretty special, so it wasn't easy to find a replacement. It has a standard 6x6 mm footprint with gull-wing SMD connections, but a very low profile (the top of the button is only 3.1 mm above the circuit board). Plus, it has a fifth connection for grounding its metal case.

After some time consuming searching (where's that semantic web when you need one?), I found a perfect match: APEM DTSGZM-62N. However, it turned out to be impossible for me to get it in any reasonably low quantity.

The Diptronics DTSMW-66N, as pointed out by Carl on his blog, proved to be a satisfactory replacement and was available from the local electronics shop. This switch has the same outside dimensions as the original, except the button is concealed inside a raised edge. The 901 has an extra millimeter of space under the touch pad (unlike 701) and the button is pressed by a needle that fits inside the circumference, so the raised edge isn't a problem and no other modifications were necessary. This Diptronics switch doesn't have a grounding connection, but as far as I can see, this doesn't affect its operation or the operation of the capacitive touch pad above it.

DTSMW-66N as left mouse button on EeePC 901

When I replaced the switch, the left click still wasn't working. After some more extensive searching for further faults I found that I must have had accidentally broken a minute PCB trace running from the button's contact to a tiny SMD capacitor nearby. I did a quick fix by bridging the gap with a blob of solder (you can see it at the button's top right pad on the photo above).

Now the left click is finally working again. Although the replacement switch has the same rated operation force (1.6 N) as the original, the button now feels slightly softer.

I must say that by now I'm severely disappointed with the quality of buttons and switches I'm seeing lately. I had to fix 901's hot keys when the computer was brand new and I'll only mention my terrible experience with the Happy Hacking Keyboard.

Posted by Tomaž | Categories: Digital | Comments »