Avian’s Blog

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

I managed to bring the broken Time Capsule from the office back to life today. It turned out that the problem really was only in the Flextronics power supply, so when I connected the +5 V and +12 V rails to a lab power supply it booted up.

The yellow LED is blinking which, according to the manual, means it cannot get an IP from the DHCP server. After restoring the factory settings I saw the "Apple Network XXXXXX" on wireless and was able to connect to it with my laptop.

Unfortunately, even with the hardware working, it's still a brick as far as I'm concerned. It appears that these things can only be configured with a proprietary Mac or Windows application. There's no friendly HTTP server to greet you. Instead nmap shows port 5009 "airport-admin". I did find this Java configurator, but it doesn't say anywhere if it works with Time Capsules and I haven't tried it yet.

As far as the broken power supply is concerned, I haven't found the problem so far. Starting from the largest components and going downwards in size, I got to the high-voltage MOSFET and the rectifying diodes, all of which appear to be fine.

Even if I manage to fix it, I don't think I'll be putting it back into the white box just to get overheated again.

Look what I found today:

It's an old DE-620 Ethernet adapter that was manufactured by D-Link. This used to be the only way I could get onto an Ethernet network with my Compaq Contura 4/25cx.

It has a parallel port connector on one end (largely obsolete today) for connection to a host PC and a 10BASE2 (thin coaxial, very obsolete) and 10BASE-T (UTP, common today) connectors on the other. This device had wonderful support on the old 2.0.x series of Linux kernels.

I can't recall what kind of bandwidth I could get with it, but I believe it was several orders magnitude better than a serial modem connection (especially since Contura's UARTs could only manage 9600 bit/s), but slower than the theoretical 10 Mbit/s for Ethernet.

Another curiosity was that it required external power through a power brick that's rated at 12 V and 500 mA (parallel port didn't provide power to devices). Today I guess I could almost run a complete EeePC with those six watts of power.

On my last post Dušan pointed to an article that raised suspicion that errors in non-ECC RAM are one of the main causes of computer crashes these days.

I tend to disagree - I have seen and administered enough computers that ran ordinary desktop PC grade hardware and I haven't seen the numbers of unexplained software crashes that I should have if non-ECC RAM would really be that unreliable.

However, that may just be another case of the old story where a software engineer will blame hardware when his software crashes and a hardware engineer will claim vice-versa.

So, I'm starting a very simple experiment: I'm dedicating 10% of my server's non-ECC RAM for cosmic particle detection. In other words, I've written a short program that allocates 128 MB of RAM, fills it with a test pattern and checks once every day if the same pattern is still there. I'll keep it running as long as possible.

With the best FIT figure from Google (25000 failures per 10⁹h per Mbit) and assuming that bit flips have a Poisson probability distribution:

I should have over 98% probability to see at least one error in 7 days. I would bet the proverbial case of beer that won't happen.

Of course, the logical argument here would be that my machine simply isn't in those 8% that see errors. So it would be interesting to see if this program reports any errors on some machine that experiences lots of unexplained crashes.

A while ago Google and University of Toronto published an article (PDF) about the results of a two-and-a-half year long study into DRAM reliability.

The bottom line of their findings is that they have seen on average 25 to 70 thousand errors per 10⁹ operating hours per Mbit, and 8% of the memory modules having some kind of an error in the course of a year.

Those are some pretty large numbers. My server currently sports 1 GB of non-ECC RAM. With that kind of an error rate, I would be seeing a bit-flip every day or so. I'm pretty confident that's not happening. Of course, without ECC, I don't have any way of being sure. But with a bit-flip per day, I'm sure the software would be crashing much more often than it is.

Of course, with only 8% of the population affected by errors, it can be that I just got lucky.

But still, non-ECC modules with these kinds of error rates would be unusable. Does that mean that ECC modules being sold are actually of lower quality than non-ECC? I can imagine that an ECC module with an occasional recoverable error would be easier to pass through quality control than an non-ECC one with similar reliability.

Apple users at Zemanta used to backup their machines to an Apple Time Capsule. I say used to because it went belly-up a while ago, probably for the same reason as many others of its kind. On Friday we did some clean-up in the office and I took the white brick home, to see if I can still find some use for it.

Disassembly went quite smooth. Actually, the approach was somewhat similar to what I did with Piki the Pleo. And similarly irreversible.

Inside is a normal hard drive and an embedded computer which I hear is running NetBSD. As far as my web searches have shown nobody has yet managed to run any kind of custom software for it, so I guess that option is out.

It also becomes obvious why these things are dying of overheating. What kind of a thermal design is that? The fan does nothing - it just mixes hot air around the case as there are hardly any holes in it. There's also precious little air to actually mix around because the case of so packed. Interestingly, there seems to be a temperature sensor glued to the hard drive.

So far I haven't done much more than just poked around for a couple of minutes, so right now I have no idea why it's simulating a brick and whether it's fixable or not. Nothing is obviously blown out.

DLP-232PC is described as a low-cost USB data acquisition module for process monitoring and control. In practice that means a tiny circuit board that fits into a 300 mil DIP18 socket, sports a mini-B USB connector and has 14 GPIO digital channels, 8 of which can also be switched to analog read-out. From the USB host point of view it presents itself as an USB-to-serial converter and is controlled by sending single byte commands through the virtual serial port (e.g. sending ASCII '1' puts pin 1 high).

Now imagine some old hardware that connects to the PC's parallel port and used to be controlled by old-fashioned DOS software doing bit-banging on the printer's pins. DLP-232PC sounds like a good tool to easily port that old software to a modern operating system running on a modern computer that doesn't have a parallel port (USB-to-parallel converters don't work, but that's a whole new story). Simply replace parallel port writes with appropriate writes to the virtual serial port, recompile for Windows and everything should work fine.

Well, some experiments showed that in practice it's not that simple. The data-sheet says that the serial port baud rate is set to 460800, so in theory it should be able to take 46080 single-byte commands per second (i.e. around one state change per 20 μs). Unfortunately DPL-232PC is actually implemented with a 18F2410 PIC microcontroller that reads commands from the UART and controls its GPIO pins in software.

Here's the first, simple experiment: do a burst of 8 impulses on channel 3 by writing a block of 16 bytes (8 repetitions of ASCII "3E") to the device (e.g. /dev/ttyUSBx on Linux, or COMxx on Windows).

This is the result the oscilloscope showed. You can see that doing anything that require real-time determinism is going to be hard. First two impulses are cca. 80 μs wide, while the rest are closer to 25 μs. The pattern of pulse widths changed with different block lengths. This was the result when DLP-232PC was controlled from a Windows XP host. An equivalent test with my Linux-running EeePC gave a more regular waveform, where all impulses were 80 μs wide (i.e. around 4 times theoretical minimum).

I'm not sure what is causing this. Maybe it's a quirk in the USB transport, or Windows drivers. But it does make me a little skeptical if you can reliably bit-bang, say, an I²C protocol on this.

This is another test, to see how it handles two channels. It was done by continuously writing "36EY" as fast as possible to the device, which cycles states of channel 3 and 6. Again, running on Linux gives a this deterministic waveform, with the pulse width around two times that of the first test (as expected). On the Windows machine, the things look much more chaotic.

One other interesting feature of this device had shown itself during testing: during the two channel test DLP-232PC simply froze. From the oscilloscope trace it appeared that the IO pins were put into the high-Z state and the device stopped responding to any commands from the PC (even to the reset and ping commands). Disconnect/connect didn't fix it, although the USB handshake worked normally (we did notice that the diagnostic LED blinked a little different pattern than usual on power-on). Only after being disconnected from power for a couple of minutes did it unexpectedly return to life.

My only explanation is that somehow the software in the PIC crashed (maybe receive buffer overflow) and the microcontroller didn't reset properly when the power was absent only for a short time.

So, the first impression says this is not exactly fly-by-wire grade material. Beware of hardware that is actually software in disguise.

Mailman just brought me a box of goodies. Among other things a couple of these were inside:

I never worked with an Arduino before and I thought I might try playing with one considering all the buzz that's been going on around them. And I might have just the right place to use it.

Actually, I wanted to add two more concluding notes to my saga about the Happy Hacking Keyboard.

First about the unreliable keys. Trimming the plastic leftovers from the molding process on the bottom of the keys and thoroughly cleaning the membranes only helped for the escape key. Cursor keys were still pretty unreliable, often failing to register keystrokes.

The final solution I found after disassembling the keyboard something like ten times and that has been holding for two weeks now are several strategically placed pieces of cardboard. These help to support the metal plate under the keys. My theory is that the plastic stubs that press it in place weren't manufactured precisely enough and the plate buckled somewhat, especially in the corner under the cursor keys. I guess tolerances are pretty tight if you want to make a reliable switch with such a membrane.

Second thing I wanted to add is a comment about the usability of the built-in USB switch. I thought that together with the keyboard's small size it was a nice addition to reducing the clutter on the desktop. Well, the switch is pretty useless for any device that doesn't come with it's own USB extension cable. The connectors are recessed into the casing and the openings are narrow enough so that none of my USB keys can be used with them.

Finally, considering my experience with this Happy Hacking Keyboard Lite2, I can firmly say that I don't recommend buying it. It appears however that some are happy with it - see for example Unr3a1's comments on my first post.

Last time I reported some weird problems with my new Happy Hacking Keyboard Lite2 USB. Escape and down cursor keys appeared unreliable and sometimes skipped keystrokes.

After some experimenting I found out that these two keys wouldn't register if I pressed them under some specific angles.

This got so annoying that I went back to my previous keyboard at work and decided to check if I can do something about it. Sending the keyboard back under warranty was pretty much out of the question: it took a month and coordination of three of my colleagues to get it from United States to Slovenia.

Opening the case is as simple as it gets: eight screws (one under the sticker with DIP switch instructions) and no plastic latches.

There three layers here:

• At the bottom is the membrane with switch matrix. It is itself composed of three layers of flexible plastic: bottom contacts, spacer and top contacts. They are only fused together at two spots (in contrast to the Sinclair Spectrum keyboard, where the contacts are hermetically sealed in bubbles in the membrane). This makes it possible to get finger grease on the contacts if your not careful handling it.
• Flexible domes formed out of silicone-like substance. They act as springs that push keys back out after you press them.
• Hard plastic keys, latched into the upper cover.

After visual inspection the most obvious problem appeared to be a couple of pieces of plastic freely floating on the membrane. They were most likely leftovers from the molding process (i. e. molding flash). Some keys (including the two I had problems with) also had irregularities on the bottom, so the surface that pushed onto the dome wasn't even. I carefully removed the excess plastic with a scalpel.

After assembling the keyboard back, the problem seems to be gone, but I guess it will take a couple of days of use to see if I really fixed it.

This is the second keyboard in a row that I had to repair after getting it brand-new from the factory (the first was on my Eee 901). They really don't make them as they used to (even when you pay $1.50 per key).

It seems even hardware is not immune to heisenbugs.

A week ago my wireless access point in Logatec (an old version of SMC Barricade G) started behaving weirdly. A network scan showed the SSID broadcast, but association was not possible. I tried several different devices (among those my Eee 901 with Atheros card and the work laptop with an Intel IWL), but none was able to connect. iwconfig just showed not associated and an ever increasing Rx invalid nwid counter.

Interestingly, kismet found the network and showed constant traffic on it. It also warned of broadcast disassociate requests which it seemed to indicate a denial of service attack on the network. But I just couldn't believe that someone would keep such an attack going for that long in that part of the country.

The problem fixed itself after a couple of days. But since it started working just after I moved the access point around, I thought that maybe there's a bad connection somewhere. So I took it apart.

The only two things that caught my attention were a loosened nut on the left antenna connector and plenty of dust on the RF part of the circuit.

I tightened the connector and vacuumed the dust and the access point has been working flawlessly since then.

I'm not sure I actually did anything. It's conceivable that the loosened nut did something to the grounding of the circuit or that there was something nasty in that dust that shorted a trace or changed its impedance enough, but I find that hard to believe.

Here's a close-up of the RF front-end of the transceiver (minus the dust). The chip in the middle is the receive/transmit and diversity switch.

The microstrip line carries microwave frequencies, so the correct characteristic impedance is very important. There's no solder resist over he line to prevent it from affecting its characteristics and the upper and lower ground planes are well connected with a lot of vias.