"In het verleden behaalde resultaten bieden geen garanties voor de toekomst"

Current filter: »Hardware« (Click tag to remove it or click and/or to switch it.)

About this blog

These are the ramblings of Matthijs Kooijman, concerning the software he hacks on, hobbies he has and occasionally his personal life.

Most content on this site is licensed under the WTFPL, version 2 (details).

Sun Mon Tue Wed Thu Fri Sat
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Powered by Blosxom &Perl onion
(With plugins: config, extensionless, hide, tagging, Markdown, macros, breadcrumbs, calendar, directorybrowse, entries_index, feedback, flavourdir, include, interpolate_fancy, listplugins, menu, pagetype, preview, seemore, storynum, storytitle, writeback_recent, moreentries)
Valid XHTML 1.0 Strict & CSS
JTAGICE3 converter board

Side view after assembly

Last year, I got myself an Atmel JTAGICE3 programmer, in order to speed up programming my Pinoccio boards. This worked great, except that as can be expected of the tiny flatcable they used (1.27mm connector and even smaller flatcable), the cable broke within 6 months.

Atmel support didn't want to replace it, because it wasn't broken when I first unpacked the programmer, and told me to find and buy a new cable myself. Since finding these cables turns out to be tricky, and I didn't feel like breaking another cable in 6 months, I designed a converter board.

See more ...

0 comments -:- permalink -:- 17:05
Introducing Tika

Tika Tovenaar Supermicro 5015A

(This post has been lying around as a draft for a few years, thought I'd finish it up and publish it now that Tika has finally been put into production)

A few months years back, I purchased a new server together with some friends, which we've named "Tika" (daughter of "Tita Tovenaar", both wizards from a Dutch television series from the 70's). This name combine's Daenney's "wizards and magicians" naming scheme with my "Television shows from my youth" naming schemes quite neatly. :-)

It's a Supermicro 5015A rack server sporting an Atom D510 dual core processor, 4GB ram, 500GB of HD storage and recently added 128G of SSD storage. It is intended to replace Drsnuggles, my current HP DL360G2 (which has been very robust and loyal so far, but just draws too much power) as well as Daenney's Zeratul, an Apple Xserve. Both of our current machines draw around 180W, versus just around 20-30W for Tika. :-D You've got to love the Atom processor (and it probably outperforms our current hardware anyway, just by being over 5 years newer...).

Over the past three years, I've been working together with Daenney and Bas on setting up the software stack on Tika, which proved a bit more work than expected. We wanted to have a lot of cool things, like LXC containers, privilege separation for webapplications, a custom LDAP schema and a custom web frontend for user (self-)management, etc. Me being the perfectionist I am, it took quite some effort to get things done, also producing quite a number of bug reports, patches and custom scripts in the process.

Last week, we've finally put Tika into production. My previous server, drsnuggles had a hardware breakdown, which forced me wrap up Tika's configuration into something usable (which still took me a week, since I seem to be unable to compromise on perfection...). So now my e-mail, websites and IRC are working as expected on Tika, with the stuff from Bas and Daenney still needing to be migrated.

I also still have some draft postings lying around about Maroesja, the custom LDAP schema / user management setup we are using. I'll try to wrap those up in case others are interested. The user management frontend we envisioned hasn't been written yet, but we'll soon tire of manual LDAP modification and get to that, I expect :-)

0 comments -:- permalink -:- 14:10
JTAG and SPI headers for the Pinoccio Scout

Pinoccio Scout

The Pinoccio Scout is a wonderful Arduino-like microcontroller board that has builtin mesh networking, a small form factor and a ton of resources (at least in Arduino terms: 32K of SRAM and 256K of flash).

However, flashing a new program into the scout happens through a serial port at 115200 baud. That's perfectly fine when you only have 32K of flash or for occasional uploads. But when you upload a 100k+ program dozens of times per day, it turns out that that's actually really slow! Uploading and verifying a 104KiB sketch takes over 30 seconds, just too long to actually wait for it (so you do something else, get distracted, and gone is the productivity).

See more ...

4 comments -:- permalink -:- 18:01
DIY desk cabinet and power switch panels

Since ages, I've been using switched power bars to connect my computer equipment. Originally, I used a normal outlet to connect my PC and a switched bar to connect my monitor, speakers, printer, etc. This allows me to actually completely switch off everything when I'm not using it, saving a couple of Watts of leakage power and removing the need to switch all of my equipment off separately.

Since then, the amount of electrical stuff on my desk has increased a bit, now also including quite some stuff unrelated to my computer. I now count: a laptop adapter, an USB hub, speakers, a printer/scanner, an external hard disk, a battery charger, a phone charger, a charger for my shaver, some soldering equipment, a pile of wireless access points (my work for Fon).

Plugging in all this stuff in a single power bar wasn't very helpful: I would have the bar turned on most of the day when working on my laptop, so all the other devices would be leaking power as well.

Brennenstuhl outlet

It thought I found the perfect solution when I found this power bar with five individually switched outlets from Brennenstuhl. However, because both the switches and the outlets need some space, this power bar is pretty huge (±60 cm long), making it pretty impossible to give it a useful place on my desk (without taking up too much desk space), so I would have to think of something else.

I have been thinking about building a nice cabinet to put on top of my desk to put my laptop, speakers and printer on top of and to put various paperwork and other misc items in (to replace the cardboard boxes that kept my laptop at an ergonomical height until then). In the design of that cabinet, I realized that I could just as well include some power switch panels in the cabinet.

After a few iterations of the design, I ended up with the following result:

Desk cabinet overview Left switch panel detail Right switch panel detail

As you can see, there's two switch panels with eight switches each in the lower corners. Each switch controls one or two outlets, most of which are hidden behind the panels. Since most of the devices don't move around much, it's perfect if the outlets and plugs are hidden inside the cabinet, since that means less cluttering of my desk.

However, I also have some devices (mostly wireless access points, settopboxes and monitors that I use for my work) that are not fixed all the time and regularly change. If I would need to get behind the switch panels everytime I wanted to change a device, I would get tired of that real quick. I could of course have used a completely separate outlet bar for those devices, but I still like to make those devices individually switched (since most of them have power adapters, which are prone to leak power, and I hardly ever use all of the devices at the same time).

So, I ended up making five of the switches in the right panel control outlets in a separate power bar, which I put on my (second) desk instead of behind the panel. To be able to do this, I had to get a length of thick power cable containing 12 separate leads (two for each outlet, plus one for the earth terminal). Also, since I didn't want the cable to be fixed onto the switch box, I got a humongous power plug, containing 10 contacts (plus chassis earth).

I designed these boxes for a current up to 10A. All components should be able to handle 16A, except for the power inlets, which contain a 10A fuse. Each switch panel contains 8 switches, for controlling 9 outlets (theres one switch in each box that controls two outlets).

I used two-pole switches, which can switch both the line and neutral terminals of each outlets. In theory, it should be sufficient to only switch the line terminals and leave the neutral terminals always connected, but since the boxes are connected to a wall socket using a normal power plug, there is no way to tell which incoming power wire is the line terminal and which is the neutral terminal, so you have to switch both of them.

One thing I had not accounted for in advance, is that the switch boxes themselves also draw a bit of power. The power inlets I used contain some filtering circuitry, which should improve the stability of the power delivered. However, these inlets also draw about 50-100mW (hard to measure since it's so little and has a low power factor) each, when there is nothing else connected. On yearly basis, this would amount to about one kWh, so that's not really a problem.

In addition, the lights in the switches also draw around 300mW, but since that only happens when a device is switched on, that power draw is negligible compared to the power usage of the connected device.

I started out building the cabinet, which took me just under a day (I just screwed all the panels together, not bothering with fine dovetail joints or other fine woodworking details, since I mostly wanted this cabinet to be functional without costing too much time. Then I started on the switch boxes, which took me three or four days in total, which seems really out of proportion :-)

Front panels

I started out preparing the front panel, using an oldschool fretsaw. Fortunately, the switches have a small front panel that covers up a few milimeters of the hole, so I didn't have to get perfect cuts (though a few mm of space is still not that much room for error).

The switches are mounted in the panel by just snapping them into the holes cut out of the panel.


For the outlets, I was considering to use these power sockets or standard wall sockets, with the big downside of them being fairly expensive (± €8, I would need 20 of them). Fortunately, I found a box of old wall outlets at van Altena, local second-hand hardware store that has all kinds of old and new tools and equipment at cheap prieces. I ended up paying €0,75 per outlet, which reduced the total cost of the project quite a bit (though it still cost me around €175 in materials).

To save a bit of space and make everything fit better, I ended up cutting off the top of the outlets, so the outer mantle would come off and the outlets could be placed closer togeter. After doing the first one with a saw, I ended up doing all the others using a belt sander, fixed upside down in my vice creating an ad-hoc stationary belt sander.

Box construction

Next, I created a base for the boxes and constructed the boxes on top. Apparently I didn't take any pictures of the process (I remember doing so, but perhaps I somehow lost the pictures, not sure). The base plate is thick (18mm) MDF, on which I've used my router to route out a 10mm deep "trench" in the wood through which the cabling can be put (so it can go underneath the outlets). You can see one of the trenches on the left of the right box below.

Most of the rest of the construction is 15mm plywood, except for the top plate (with holes for the outlets), I used 6mm MDF for that.

Distribution wires

To connect the incoming power lines to each of the switches, I had a bit of a challenge. The switches have blade connectors, onto which blade receptacle connectors can be attached. These blade receptacles are "crimped" onto a cable. I tried to find some component that I could use to connect all a dozen of blade receptacles onto, but I couldn't find any of those. There are special blade connectors that allow daisy chaining each switch onto the next, but I didn't like the idea that the last switch would be connected through two dozen of crimp connections (and I did not have those daisy chaining connectors when I was working on this).

I also could not use a Twist-on wire connector, since that only works with solid cable (and the crimped blade connectors need stranded cable).

In the end, I just settled for soldering all these cables together. It's not very elegant, but I'm confident that this soldering connection should be capable of easily handling 16A of current, which is the most important in the end. I used two layers of heat-shrink tubing to insulate the big lump of soldering tin.

The last picture shows the end result: four cable octopusses that connect with one wire to the power entry point, and with eight wires to each of the switches. There's four of these in total, for both the line (with the brown marking tape) and neutral (with the white marking tape) connections in both of the boxes.

Connecting the outlets

The line and neutral connections of each outlet need to be connected to a single switch. I first connected wires to all of the outlets, with a blade connector crimped onto the other side. I used wires cut from the multicable I bought, which are conveniently numbered. Since the line and neutral connections are interchangeable in the European outlet system ("Schuko"), I didn't need to add labels to distinguish both cables coming from the same outlet.

The earth terminals do not need to pass the switch, these need to be always connected. In the bigger box, I used an earthing terminal block (which is intended to be used in a breaker box) to connect the outlets in a "star" topology. For the smaller box, I couldn't find a smaller earthing terminal block, so I just daisy chained the outlets together. Since there's only a few outlets and there should never be much current through the earth terminals, this shouldn't be a problem here.

I also connected the multicable connector in the same way, but those wires are already covered by a MDF plate in the pictures.

The end result is 32 cables sticking out from each box, four cables for each switch.

Connecting the switches

Connecting the switches was a matter of connecting all the 32 wires I prepared to the switches in the panel. After connecting the switches, I glued the front panel onto the box (so there would not be any visible screws on the front panel).

Assembled boxes

Now the boxes are assembled and ready for use, time to build the external outlet bar.

Note that the outlets seem a bit randomly placed, but I've tried to leave as much room available for power adapters to stick out in different directions, without blocking other outlets.

External outlets

For the external outlets, I got an old powerbar (again at van Altena), which has each outlet individually connected internally. I connected the big multicable to all of the outlets on side and to the big connector on the other side of the cable

The old powerbar also had a single powerswitch to control all of the outlets. Since I couldn't find any use for this switch, I just removed it. To cover up the hole that it left, I used two rectangles cut out of an old plastic cable conduit. The smaller rectangle exactly fits in the hole, the larger rectangle just serves to glue the smaller one in place. The result is a cleanly covered switch hole.

Fixing the front panels

After installing the boxes into the cabinet, it turned out the front panels weren't glued on properly, the left one came off. Since I was already doubting if they would hold, I settled for a less elegant, but more secure solution: I just added some screws in an angle from the back, making them just long enough to not stick out at the front.


So, here's the finished thing. I really like the contrast between the green buttons and the red mahogany finish I used, it gives the thing a very classic look.

To be able to plug in devices, I can pull out the boxes towards the front. This is not very quick to do, but since I do not need to switch devices very often, that works out just fine.

I also added labels to the various switches, so I won't have to remember where I plugged in every device.

Design drawings

And just for historical reference, here are the design drawings I created during the process. If they look fuzzy to you, that's probably because I erased every part of the drawings probably at least once...

Related stories

0 comments -:- permalink -:- 12:10
Booting an old Sparc Ultra1 with dead NVRAM

Sun Ultra1

To be able to debug a bug in OpenTTD that only occured on SPARC machines, I needed an old SPARC machine so I could reproduce and hopefully fix the bug. After some inquiring at our local hackerspace, Bitlair (which had a few SPARC32 machines lying around, but I needed SPARC64), I got in touch with The_Niz from NURDSpace, the hackerspace in Wageningen. Surprisingly, it turned out I actually knew The_Niz already through work :-)

In any case, The_Niz was kind enough to lend me a SPARC Ultra1 workstation and Sun keyboard, and r3boot gave me a Sun monitor I could use (of course Sun hardware doesn't use a regular VGA connector...).

There was one caveat, though: The NVRAM battery in the Ultra1 was dead. The NVRAM chip stores the boot settings (like the BIOS settings in a regular PC), but also the serial number and MAC address of the machine (called the IDPROM info). Without those settings, you'll have to manually select the boot device on every boot (by typing commands at a prompt) and netbooting does not work, for lack of a MAC address (I presume regular networking, e.g., from within Linux, does not work either, but I haven't tested that yet).

Sun has taken an interesting approach to their NVRAM chip. Where most machines just use a piece of EEPROM (Flash) memory, which does not need power to remember its contents, Sun has used a piece of RAM memory (which needs power to remember its contents) combined with a small rechargeable battery.

This means that when the machine is not used for a long time or is very old, the battery will eventually die, causing the machine to spit out messages like "The IDPROM contents are invalid and "Internal loopback test -- Did not receive expected loopback packet".

I needed to install Debian on this Ultra1, so I needed some way to boot the installer. Since netbooting did not work, my first attempt was to ignore the NVRAM problem and just get the machine to boot off a Debian boot cd. This did not quite work out: the cdrom player in the Ultra1 (a 4x burner connected through SCSI) didn't like any of the CD-Rs and CD-RWs I threw at it. It spat out errors like "Illegal Instruction", "Program Terminated" or "SProgram Terminated" (where the first "S" is the start of "SILO", the SPARC bootloader).

As we all remember from a long time ago, the early generation CD-ROM players were quite picky with burnt CDs, so also this one. I found some advice online to burn my CDs at a lower speed (apparently the drive was rumoured to break on discs burned at 4x or higher), but my drive or CD-Rs didn't support writing slower than 8x... I could write my CD-RW at 4x and at one occasion I managed to boot the installer from a CD-RW and succesfully (but very, very slowly) scan the CD-RW contents, but then it broke with read errors when trying to actually load files from the CD-RW.

So, having no usable CD-ROM drive to boot from, I really had to get netboot going. Apparently it is possible (and even easy and not so expensive) to replace the NVRAM chip, but I didn't feel like waiting for one to be shipped. There is a FAQ available online with extensive documentation about the NVRAM chip and instructions on how to reprogram the IDPROM part with valid contents.

So, I reckoned that the battery was only needed when the machine was powered down, so I should be able to reprogram the IDPROM info and then just not poweroff the system, right?

Turns out that works perfectly. I reprogrammed the IDPROM using the MAC address I read off the sticker on the NVRAM chip and made up a dummy serial number. For some reason, the mkpl command did not work, I had to use the more verbose mkp command. Afterwards, I gave the reset command and the "Internal loopback test" error was gone and the machine started netbooting, using RARP and TFTP.

By now, I've managed to install Debian, get Xorg working and reproduce the bug in OpenTTD, so time for fixing it :-D

0 comments -:- permalink -:- 17:06
Thinkpad X201 mute button breaking speaker output


Recently, I was having some problems with the internal speakers on my Lenovo Thinkpad X201. Three times now, the internal speakers just stopped producing sound. The headphone jack worked, it's just the speakers which were silent. Nothing helped: fiddling with volume controls, reloading alsa modules, rebooting my laptop, nothing fixed the sound...

When trying to see if the speakers weren't physically broken, I discovered that booting into Windows actually fixed the problem and restored the sound from the speakers. It's of course a bit of a defeat to accept Windows a fix for my problem, but I was busy with other things, so it sufficed for a while.

When migrating my laptop to my new Intel SSD, I broke my Windows installation, so when the problem occured again, I had no choice but to actualy investigate it.

I'll skip right to the conclusion here: I had broken my sound by pressing the mute button on my keyboard... Now, before you think I'm stupid, I had of course checked my volume controls and the device really was unmuted! But it turns out the mute button in Thinkpads combined with Linux is a bit weird...

This is how you would expect a mute button to be implemented: You press the mute button, it sends a keypress to the operating system, which then tells the audio driver to mute.

X201 volume buttons

This is how it works on my Thinkpad: You press the mute button, causing the EC (embedded controller) in the thinkpad to directly mute the speakers. This is not visible from the normal volume controls in the software, since it happens on a very low level (though the thinkpad_acpi kernel module can be used to expose this special mute state through a /proc interface and special audio device).

In addition to muting the speakers, it also sends a MUTE acpi keypress to the operating system. This keypress then causes the audio driver to mute the audio stream (actually, it's pulseaudio that does that).

Now, here's the fun part: If you now unmute the audio stream through the software volume controls, everything looks like it should work, but the hardware is still muted! It never occured to me to press the mute button again, since the volume wasn't muted (or at least didn't look like it).

I originally thought that the mute button handling was even more complex, when I found some register polling code that faked keypresses, but it seems that's only for older Thinkpads (phew!).

In any case, the bottom line is: If you have a Thinkpad whose speakers suddely stop working, try pressing the mute button!

0 comments -:- permalink -:- 00:13
And the saga continues....

As you might have read in my previous post, I have been vastly unimpressed by MSI's warranty department. Or actually, I have been actually been quite impressed by the amount of incompetence that they have managed to concentrate in that department. But, I digress.

A few weeks back, MSI managed to take weeks to not replace my hard drive. I have been complaining about this, and they offered that I sent them the faulty drive (again) so they could replace it. Yet they could not send me a new drive, before they had received the old drive, since "the system would not allow it". They would not, however, require me to send back my entire notebook again, as a courtesy. It's not like I could use it for anything but decoration without a hard drive (it does not support booting from an USB stick, I discovered after installing debian om my stick), but well.

See more ...

0 comments -:- permalink -:- 22:28
So much for MSI support....

I was going to write a nice piece about MSI support here, as soon as I got my notebook back from MSI. About their nice service (pick up and return with UPS!) even though they are a little slow-ish. About their nice battery warranty (minimal 80% of capacity after a year) and their flexibility in applying that warranty (I was a few days too late, technically) But, I've decided not too.

There are several reasons for this. First of all, my notebook HD broke in the first place. Not a nice thing to do, though I should probably blame WD for not making HD's that can sustain repeated writes resulting from hibernation in the same area of the disk.

It could also be because it took them nearly a week to respond to my service request when I complained about a bad HD (with complete smart status and error logs to back up my case). All I got back was a UPS label, but I reckoned it took them a while to fully read through my case and decide what to do with it. As it turns out now, it seems they didn't even read it and just needed 6 days to send me a UPS label.

See more ...

1 comment -:- permalink -:- 19:57
Undervolting your AMD PowerNow notebook using Linux

I've previously mentioned that I've undervolted my MSI Megabook S270 notebook. I got a request about how exactly I did this, so I'll elaborate here.


Undervolting is modifying your hardware parameters in such a way, that the system CPU runs on a lower voltage that it is supposed to. Running on a lower voltage means the CPU uses less power and produces less heat, which are both wanted on a mobile system. Different laptops have different methods of undervolting. What I describe here should applies to AMD Turion64 processors (Which I have), but should also work for all other AMD processors with PowerNow support.

PowerNow & cpufreq

AMD PowerNow is AMD's technology for scaling CPU frequencies and voltages. How exactly the scaling itself is performed is not all that interesting, how to control it is. Linux has a special cpufreq driver for PowerNow processors, which exports its interface through /sys/devices/system/cpu/cpu0/cpufreq. Here you can select a governor which decides at what speed your CPU should run.

Hidden from the cpufreq interface (which only concerns CPU speed changes), the PowerNow driver also changes the CPU voltage when the speed changes. So, your CPU voltage is already automatically decreased whenever the CPU speed is lowered. Yet, we want to decrease it even further.


Since we cannot set the CPU voltage when scaling, only the frequency, how does PowerNow know what voltage to set? You might think that the CPU itself handles this, but fortunately this is not so. The PowerNow driver gets the information about the possible states and corresponding voltages from the system itself, through one of two means: ACPI and legacy BIOS.

The preferred way of retrieving this information is through ACPI and this might or might not work. For me, this didn't work (There were errors in my kernel logs with CONFIG_CPU_FREQ_DEBUG enabled). When ACPI does not work, the PowerNow driver uses some legacy BIOS call I don't fully understand to get its values.

So, we want to modify the voltage values the PowerNow driver finds. Since I didn't fully know how the BIOS thing worked, that wasn't the way to go. So I had two options:

  1. Hack/hardcode the voltage settings in my kernel
  2. Fix my ACPI and modify my ACPI table.

I settled for the last one, since that is nicer and a lot better when upgrading kernels.

Fixing ACPI

Some poking around with the kernel and its debug output, I found that the ACPI object (CPU1._PSS) holding the PowerNow information was not properly loaded by the kernel. Doing the decompile-and-recompile-with-Intel's-compiler trick, showed that the Intel ACPI compiler didn't like that _PSS ACPI object either. See my older post about how I fixed these compilation errors. After fixing these, the PowerNow driver properly gets its settings from ACPI.

With CONFIG_CPU_FREQ_DEBUG enabled, PowerNow properly reports the found settings (don't know if this was any different before fixing ACPI, I don't want to break my ACPI and reboot to find out).

powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.50.4)
powernow-k8:    0 : fid 0x8, vid 0xa
powernow-k8:    1 : fid 0x0, vid 0x1c
powernow-k8:    0 : fid 0x8 (1600 MHz), vid 0xa (1300 mV)
powernow-k8:    1 : fid 0x0 (800 MHz), vid 0x16 (1000 mV)
powernow-k8: cpu0, init lo 0x808, hi 0x1
powernow-k8: policy current frequency 1600000 kHz
cpu_init done, current fid 0x8, vid 0x8

Part of fixing the ACPI table, is recompiling a fixed version and inserting it into the kernel source. Now, instead of getting the ACPI table from the system on startup, Linux uses your modified table. This means we can modify any value in the table as if the actual ACPI table was changed.

Tweaking PowerNow

Time to turn to find out how to read the ACPI table and find out which value to actually change. After searching a lot I found the "BIOS and kernel developers guide for Athlon 64 and Opteron". At page 278 they describe where PowerNow gets its information. From there I find that the CPU1._PSS ACPI Package contains a number of (unnamed) packages, one for every CPU State (Two in my case). Each packets contains 6 32bits numbers, which represent various settings. This is my original _PSS Package:

Name (_PSS, Package (0x02)
    Package (0x06)

    Package (0x06)

From the PowerNow specs we learn that every CPU state has a fid and vid, for Frequency ID and Voltage ID respectively. The frequency is calculated as 800 + fid * 100 (in MHz). The voltage is calculated as 1550 - vid * 25 (in mV). This means the frequency cannot go below 800MHz, and since the maximum vid value is 0x1e the minimum voltage is 800mV. I seem to vaguely remember that either the fid or vid can only be set to multiples of 2, yet I can't seem to find any hint of that in the specs now. I did find that the maximum supported frequency change in one go is 200MHz, but the kernel takes care of that, so we don't need to worry about this.

The actual vid is coded into the fifth value in the package, at bits 6-10 (Powernow specs page 280). This means you can increment the fifth value by 0x80 to decrease the voltage by 50mV. Below is the package from the ACPI table I use now, along with a few other examples of different voltages (// denotes a comment).

Package (0x06)
    //0xE0202D80, // 1000mV
    //0xE0202E80,  // 900 mV
    0xE0202F00,  // 850 mV
    //0xE0202F80,  // 800 mV

I've tried running as low as 800mV, but then my system seems to boot okay, but as soon as I login (type my password correctly), it powers off. This seems so predictable that you would suspect the voltage change to have this effect, but increasing the voltage back to 850 mV gives me a stable system that is slightly cooler and uses less power. I'll repeat the (very rough) benchmarks I made back then here (current values are for the entire system).

  • 800MHz, 800mV - Crash on startup
  • 800MHz, 850mV - ~980mA/39°C idle, ~1170mA/48°C load
  • 800MHz, 1000mV - ~1020mA/41°C idle, ~1330mA/50°C load

As you can see, the power savings are very little when the CPU is idle, but quite significant when the CPU gets busy (100% load, though still at 800MHz). I have so for only undervolted my 800MHz state, since I barely ever need all my 1600MHz. But since my CPU gets especially power hungry when it's really fully loaded at 1600MHz (up to 2500mA), I suspect that a lot of power can be saved here. If you try this and get it to work, do tell! And don't forget to mention the actual voltage you get it to run on.

Update: Youri Matthys has been experimenting with undervolting too, and has managed to make his Turion at 1600Mhz run on 1000mV instead of the default 1300mV. The power savings are even better then I'd have hoped for: Under full load the battery usage drops from around 2500mA to 1700mA.

9 comments -:- permalink -:- 22:58
Pretty lights!

I've been working on my own binary clock for a while now. I've managed to get the PIC microcontroller from Microchip working for some time now. After being busy with other stuff I slowly resurrected this project. Since the microcontroller part is mostly done (the software works, for the limited prototype hardware I have so far), I am focussing on the actual casing for the clock now.


The casing of the clock has a big influence on the rest of the hardware (and thus software) design. The basic idea of a binary clock is to have 3 rows of 6 LEDs each, one row for hours, minutes and seconds, each representing a binary number. Since representating a binary number isn't limited to leds but anything that can represent on and off, 1 and 0.

I'll settle for leds for now since they are easy to use and give pretty lights. The exact form is not decided yet. I had this idea of making the clock a very flat box, probably black, with 18 small (1cm) squares that illuminate (something like the TIX Pattern clock, but smaller). For that I would need white leds and colored, halftransparent plastic to put in the squares.

Shopping spree

So I went shopping today and returned with a bunch of stuff. I got some fully transparent and half transparent sturdy plastic from a hobby shop, I got some colored half transparent plastic from a carrying folder and a handful of leds in yellow, green, blue and white. I also returned with a toy gun (full metal, so nice and heavy!) for lextalionis perhaps, liquid latex that is hopefully fit for making LARP weapons and looking for a box of pins, a nice 1000 page book about hardware design of game consoles, but that's beside the point.

The box design

I also found a box meant to hold sewing accesoires. It is a half-transparent plastic that contains 18 compartments (or 17 really, since one panel is missing). When I saw it I got a vision of the backside of the box, every compartment being one bit of the clock, with leds inside.

It turned out this idea actually seemed to work out nicely. I haven't been able to try this with multiple compartments lighting up at the same time, I expect I need to add some extra (light) shielding between the compartments. Also, I need LEDs with a bigger angle. Since my leds focus the light in a tight angle, only a part of the compartment backside is lit. If I put the led within a compartement, only a small circle of light appears at the outside. I need to put the LED about 10cm from the backside to get full coverage, which is impractical and reduces light strength.

Though this design seems to be quite nice, there are two main disadvantages to it. First, when it is turned off, the clock will probably look butt ugly. After all, it's not more than a plastic bogs when the lights are off. Second, the box is big. It's way bigger than needed to hold the leds, wiring and other electronics. I would say somewhere between 95% and 99% of the space is unused. Not so nice.

I'll get some wider angle LEDS first and then I'll see if I'm gonna build it like this. For now the box serves as a way better storage for a bunch of resistors, leds and other electronic components than the small glass bowl that used to contain my electronic junk.

The squares design

As noted above, I was envisioning some sort of black box containing coloured squares that could light up. I tried this design using a few layers of paper (not black, but you didn't see the difference with the lights off) with a hole in them. I put a coloured piece of plastic with a white light behind it. This was not very succesful. The white light is so bright, you barely saw the blue colour of the plastic. When using uncoloured plastic, the light was just too bright to look in.

The other approach, using half-transparent uncoloured plastic squares, with coloured LEDs behind then, worked out better. The red, yellow and green leds had the advantage of being less bright (nicer to the eye). The blue led looked nice, but was still a little bright.

All leds suffered from the same problem as with the box design above: Their viewing angle is too small. I had to put the leds at a distance of around 5cm from the paper, which is way more that the thickness I had in mind. Also, due to this focussing the center of the square is brighter than the edges.

This looks like a very promising design. I need to get a decent piece of (black) wood, plastic or cardboard to do some more tests once I can get my hands on some wide angled LEDs.

Note to self: Get a cheap digital camera, since conveying these ideas in words is crappy ;-)

0 comments -:- permalink -:- 01:51
Showing 1 - 10 of 12 posts
Copyright by Matthijs Kooijman