Glider
"In het verleden behaalde resultaten bieden geen garanties voor de toekomst"
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).

July
Sun Mon Tue Wed Thu Fri Sat
      3 4
5 6 7 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
Using a JTAGICE3 programmer under Linux: Setting up permissions

JTAGICE3

Last week, I got a fancy new JTAGICE3 programmer / debugger. I wanted to achieve two things in my Pinoccio work: Faster uploading of programs (Having 256k of flash space is nice, but flashing so much code through a 115200 baud serial connection is slow...) and doing in-circuit debugging (stepping through code and dumping variables should turn out easier than adding serial prints and re-uploading every time).

In any case, the JTAGICE3 device is well-supported by avrdude, the opensource uploader for AVR boards. However, unlike devices like the STK500 development board, the AVR dragon programmer/debugger and the Arduino bootloader, which use an (emulated) serial port to communicate, the JTAGICE3 uses a native USB protocol. The upside is that the data transfer rate is higher, but the downside is that the kernel doesn't know how to talk to the device, so it doesn't expose something like /dev/ttyUSB0 as for the other devices.

avrdude solves this by using libusb, which can talk to USB devices directly, through files in /dev/usb/. However, by default these device files are writable only by root, since the kernel has no idea what kind of devices they are and whom to give permissions.

To solve this, we'll have to configure the udev daemon to create the files in /dev/usb with the right permissions. I created a file called /etc/udev/rules.d/99-local-jtagice3.rules, containg just this line:

SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2110", GROUP="dialout"

This matches the JTAGICE3 specifically using it's USB vidpid (03eb:2110, use lsusb to find the id of a given device) and changes the group for the device file to dialout (which is also used for serial devices on Debian Linux), but you might want to use another group (don't forget to add your own user to that group and log in again, in any case).

 
0 comments -:- permalink -:- 13:57
Current measurement helper board

Recently, I needed to do battery current draw measurements on my Pinoccio boards. Since the battery is connected using this tinywiny JST connector, I couldn't just use some jumper wires to redirect the current flow through my multimeter. I ended up using jumper wires, combined with my Bus Pirate fanout cable, which has female connectors just small enough, to wire everything up. The result was a bit of a mess:

Messy setup

Admittedly, once I cleaned up all the other stuff around it from my desk for this picture, it was less messy than I thought, but still, jamming in jumper wires into battery connectors like this is bound to wear them out.

So, I ordered up some JST FSH connectors (as used by the battery) and some banana sockets and built a simple board that allows connecting a power source and a load, keeping the ground pins permanently connected, but feeding the positive pins through a pair of banana sockets where a current meter can plug in. For extra flexibility, I added a few other connections, like 2.54mm header pins and sockets, a barrel jack plug and more banana sockets for the power source and load. I just realized I should also add USB connectors, so I can easily measure current used by an USB device.

The board also features a switch (after digging in my stash, I found one old three-way switch, which is probably the first component to die in this setup. The switch allows switching between "on", "off" and "redirect through measurement pins" modes. I tried visualizing the behaviour of the pins on the top of the PCB, but I'm not too happy with the result. Oh well, as long as I know what does :-)

Improved setup Top Bottom

All I need is a pretty case to put under the PCB and a μCurrent to measure small currents accurately and I'm all set!

 
0 comments -:- permalink -:- 18:27
Updating the Xprotolab portable firmware on Linux

Xprotolab Portable

I recently got myself an Xprotolab Portable, which is essentially a tiny, portable 1Msps scope (in hindsight I might have better gotten the XMinilab Portable which is essentially the same, but slightly bigger, more expensive and with a bigger display. Given the size of the cables and carrying case, the extra size of the device itself is negligable, while the extra screen size is significant).

In any case, I wanted to update the firmware of the device, but the instructions refer only to a Windows-only GUI utility from Atmel, called "FLIP". I remembered seeing a flip.c file inside the avrdude sources though, so I hoped I could also flash this device using avrdude on Linux. And it worked! Turns out it's fairly simple.

  1. Activate the device's bootloader, by powering off, then press K1 and keep it pressed while turning the device back on with the menu key. The red led should light up, the screen will stay blank.
  2. Get the appropriate firmware hex files from the Xprotolab Portable page. You can find them at the "Hex" link in the top row of icons.
  3. Run avrdude, for both the application and EEPROM contents:

    sudo avrdude -c flip2 -p x32a4u -U application:w:xprotolab-p.hex:i
    sudo avrdude -c flip2 -p x32a4u -U eep:w:xprotolab-p.eep:i
    

    I'm running under sudo, since this needs raw USB access to the USB device. Alternatively, you can set up udev to offer access to your regular user (like I did for the JTAGICE3), but that's probably too much effort just for a one-off firmware update.

  4. Done!

Note that you have to use avrdude version 6.1 or above, older versions don't support the FLIP protocol.

 
0 comments -:- permalink -:- 10:22
Dynamic memory allocation debugging

Arduino Community Logo

While trying to track down a reset bug in the Pinoccio firmware, I suspected something was going wrong in the dynamic memory management (e.g., double free, or buffer overflow). For this, I wrote some code to log all malloc, realloc and free calls, as wel as a python script to analyze the output.

This didn't catch my bug, but perhaps it will be useful to someone else.

In addition to all function calls, it also logs the free memory after the call and shows the return address (e.g. where the malloc is called from) to help debugging.

It uses the linker's --wrap, which allows replacing arbitrary functions with wrappers at link time. To use it with Arduino, you'll have to modify platform.txt to change the linker options (I hope to improve this on the Arduino side at some point, but right now this seems to be the only way to do this).

 
0 comments -:- permalink -:- 21:47
Twente Mini Maker Faire

Twente Mini Maker Faire Logo

I just returned from the Twente Mini Maker Fair in Hengelo, where I saw a lot of cool makers and things. Eye-catchers were the "strandbeest" from Theo Janssen, a big walking contraption, powered by wind, made from PVC tubing, a host of different hackerspaces and fablabs, all kinds of cool technology projects for kids from the Technlogy Museum Heim and all kinds of cool buttonsy projects from the enthousiastic Herman Kopinga. All this in a cool industrial atmosphere of an old electrical devices factory.

Also nice to meet some old and new familiar people. I ran into Leo Simons, with whom I played theatre sports at Pro Deo years ago. He was now working with his father and brother on the Portobello, a liquid resin based 3D printer, which looked quite promising. I also ran into Edwin Dertien (also familiar from Pro Deo as well as the Gonnagles), whom seemed to be on the organising side of some lectures during the faire. I attended one lecture by Harmen Zijp and Diana Wildschut (which form the Amersfoort-based art group "de Spullenmannen") about the overlap and interaction between art and science, which was nice. I also ran into Govert Combée, a LARPer I knew from Enschede.

Strandbeest by Theo Jansen

Overall, this was a nice place to visit. Lots of cool stuff to see and play with, lots of interesting people. There was also a nice balance of technology vs art, and electronics vs "regular" projects: Nice to see that the Maker mindset appeals to all kinds of different people!

 
0 comments -:- permalink -:- 13:11
Uses and requirements

Okay, so I'm gonna build a system to do administration tasks in our LARP club. But, what exactly are these? What should this system actually do for us? I've given this question a lot of thought and these are my notes and thoughts, hopefully structured in a useful and readable way. I've had some help of Brenda so far in writing some of these down, but I'll appreciate any comments you can think of (including "hey wouldn't it be cool if the system could do x?", or "Don't you think y is really a bad idea?"). Also, I am still open for suggestions regarding a name.

General outline

The general idea of the system is to simplify various administration tasks in a LARP club. These tasks include (but are not limited to) managing event information, player information, event subscriptions, character information, rule information (skill lists, spells, etc), etc.

This information should be managable by different cooperating organisers and to some extent by the players themselves. We loosely divide the information into OC information (info centered around players) and IC information (info centered around characters). OC information is plainly editable by players or organisers, where appropriate. IC information is generally editable by organisers and players can propose changes (but only for their own characters). These changes have to be approved by an organiser before being applied.

The information should be exported in various (configurable and/or adaptable) formats, such as a list of subscribed players with payment info, a PDF containing character sheets to be printed or a list of spells for on the main website. Since the exact requirements of each club and/or event with regard to this output vary, there should be some kind of way to easily change this output.

See more ...

 
0 comments -:- permalink -:- 15:26
Debian Squeeze on an emulated MIPS machine

In my work as a Debian Maintainer for the OpenTTD and related packages, I occasionally come across platform-specific problems. That is, compiling and running OpenTTD works fine on my own x86 and amd64 systems, but when I my packages to Debian, it turns out there is some problem that only occurs on more obscure platforms like MIPS, S390 or GNU Hurd.

This morning, I saw that my new grfcodec package is not working on a bunch of architectures (it seems all of the failing architectures are big endian). To find out what's wrong, I'll need to have a machine running one of those architectures so I can debug.

In the past, I've requested access to Debian's "porter" machines, which are intended for these kinds of things. But that's always a hassle, which requires other people's time to set up, so I'm using QEMU to set up a virtual machine running the MIPS architecture now.

What follows is essentially an update for this excellent tutorial about running Debian Etch on QEMU/MIPS(EL) by Aurélien Jarno I found. It's probably best to read that tutorial as well, I'll only give the short version, updated for Squeeze. I've also looked at this tutorial on running Squeeze on QEMU/PowerPC by Uwe Hermann.

Finally, note that Aurélien also has pre-built images available for download, for a whole bunch of platforms, including Squeeze on MIPS. I only noticed this after writing this tutorial, might have saved me a bunch of work ;-p

Preparations

You'll need qemu. The version in Debian Squeeze is sufficient, so just install the qemu package:

$ aptitude install qemu

You'll need a virtual disk to install Debian Squeeze on:

$ qemu-img create -f qcow2 debian_mips.qcow2 2G

You'll need a debian-installer kernel and initrd to boot from:

$ wget http://ftp.de.debian.org/debian/dists/squeeze/main/installer-mips/current/images/malta/netboot/initrd.gz
$ wget http://ftp.de.debian.org/debian/dists/squeeze/main/installer-mips/current/images/malta/netboot/vmlinux-2.6.32-5-4kc-malta

Note that in Aurélien's tutorial, he used a "qemu" flavoured installer. It seems this is not longer available in Squeeze, just a few others (malta, r4k-ip22, r5k-ip32, sb1-bcm91250a). I just picked the first one and apparently that one works on QEMU.

Also, note that Uwe's PowerPC tutorial suggests downloading a iso cd image and booting from that. I tried that, but QEMU has no BIOS available for MIPS, so this approach didn't work. Instead, you should tell QEMU about the kernel and initrd and let it load them directly.

Booting the installer

You just run QEMU, pointing it at the installer kernel and initrd and passing some extra kernel options to keep it in text mode:

$ qemu-system-mips -hda debian_mips.qcow2 -kernel vmlinux-2.6.32-5-4kc-malta -initrd initrd.gz -append "root=/dev/ram console=ttyS0" -nographic

Now, you get a Debian installer, which you should complete normally.

As Aurélien also noted, you can ignore the error about a missing boot loader, since QEMU will be directly loading the kernel anyway.

After installation is completed and the virtual system is rebooting, terminate QEMU:

$  killall qemu-system-mips

(I haven't found another way of terminating a -nographic QEMU...)

Booting the system

Booting the system is very similar to booting the installer, but we leave out the initrd and point the kernel to the real root filesystem instead.

Note that this boots using the installer kernel. If you later upgrade the kernel inside the system, you'll need to copy the kernel out from /boot in the virtual system into the host system and use that to boot. QEMU will not look inside the virtual disk for a kernel to boot automagically.

$ qemu-system-mips -hda debian_mips.qcow2 -kernel vmlinux-2.6.32-5-4kc-malta -append "root=/dev/sda1 console=ttyS0" -nographic

More features

Be sure to check Aurélien's tutorial for some more features, options and details.

 
0 comments -:- permalink -:- 12:18
/ Blog / DIY
Putting my office chair on legs

For a while, I've been annoyed by the height of my desk. It is slightly higher than ergonomical, which causes my shoulders to be always raised when I'm working behind my computer.

Since sawing off a bit from the feet of my desk was a bit too irreversible for me (and it's hard to figure out how much to cut off exactly), I looked for a way to raise my office chair a bit further than its normal adaptable range. I couldn't find a way to get the central pillar loose from the base (even though the pillar looks threaded, it wouldn't turn), so I looked for a way to extend the wheels a bit.

The wheels are fixed into the base of the chair using a pin in the wheel that clamps into a socket in the base of the chair ("klemstift").

Chair wheels

I was hoping to find a part that has a pin at the top, and a matching socket at the bottom, which I could use to extend the length of the pins of my wheels a bit. It seems these things don't actually exist, at least I couldn't find any online.

Looking at the wheels more closely showed me that the pin wasn't actually fixed in the wheel, but it was actually a two-side pin that also clamped into the wheel.

This opened up the option of replacing the pin with one that has one threaded end, which can receive a "coupler nut" (not sure how these things are really called connecting to another identical pin, which can be inserted into the chair base again). These parts should be available from a proper hardware store for less money than the webshops I linked, by the way.

Chair wheels

The end result is that I now have a chair that is around 5cm higher than before. It looks a bit weird and a bit fragile, but it actually feels more robust than it looks.

My legs are now pushed against the bottom of my desktop, so this is as high as it gets. For the perfect ergonomical position, I should be even higher, but that seems impossible unless I find a desk with negative thickness (I suspect this is because my arm length to torso length is a bit non-standard due to my above-avarage body length). Even so, I can already feel that this handful of centimeters greatly helps to improve my posture and removes a ton of strain from my shoulders. Yay!

Chair wheels

 
0 comments -:- permalink -:- 12:41
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.

Outlets

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.

Finished

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
dconf-editor is the new gconf-editor

Gnome

A I previously mentioned, Gnome3 is migrating away from the gconf settings storage to the to GSettings settings API (along with the default dconf settings storage backend).

So where you previously used the gconf-editor program to browse and edit Gnome settings, you can now use dconf-editor to browse and edit settings.

I do wonder if the name actually implies that dconf-editor is editing the dconf storage directly, instead of using the fancy new GSettings API? :-S

 
0 comments -:- permalink -:- 17:07
Showing 11 - 20 of 152 posts
Copyright by Matthijs Kooijman