Moving code to GitHub

GitHub is a web-based hosting service for software development projects that use the Git revision control system.

I am slowly moving most of my projects to GitHub. GitHub is great because people can easily collaborate, fork, submit issues and patches and so on. Additionally, stuff gets shared in an open and unified way, making it much easier to others to find and reuse existing code.

I started with the firmware hack of the Dell PowerEdge BMC:
https://github.com/arnuschky/dell-bmc-firmware.git.

See here for the post explaining what it’s for.

Debugging solder paste

I am currently progressing with my first complete “product”, that is, electronics design including professionally made PCBs and plastics. Assembly will be done by us, which caused me to use solder paste for the first time.

The first run was bad: the solder points where brittle and the components came off easily. Could there be a better moment to play with our new USB microscope? (100 Bucks on eBay, great investment I think!)

Bad solder joint

Bad solder joint. The joint was brittle and the compontens came off easily. You can still see the little balls that make up the solder paste. Diagnosis: reflow temperature was too low!

Turns out that I used accidentally the wrong setting on the reflow oven. I though we still had some leftover lead-based paste in the applicator, but apparently it was lead-free paste after all. D’oh!

Good solder joint

Good solder joint. Here you can see that the little balls melted, resulting in a smooth surface. Also, the solder paste was sucked close to the component.

Now I just have to find out what the symptoms of old solder paste are. I heard that you can keep it only for a couple of weeks, but the paste I used here is about a year old. This had me wondering what solder joints would look like when you’ve used paste that was too old.

NB: Sorry for the colors by the way. VLC seems to switch the red and the blue channels on the snapshot (but doesn’t on the video itself), and I haven’t found an easy way around it yet.

Site’s not dead…

…even if it appears to be the case. We had to move twice over summer, which kept me well occupied. Additionally to that, various projects on the site and at work demanded full time commitment – and then there’s also that PhD that wants to be finished one day. Well, whatever, it’s winter now and I am injured so at least the sports (or the lack of) leaves me a bit more time.

Testing a new SD card under linux

SD cards are a common target for product forgery. Many cards on the market (be it eBay or retailers) are rebranded, have fake capacity or are simply bad ones initially removed from production that are resold afterwards by third parties. Bunnie has an excellent article on fake SD cards and how to test them. For more info on SD cards, check out this flash card survey.

The card I bought, a Sandisk 16GB class 4 Micro SDHC memory card, including adapter

I recently bought an SD card from Sandisk, one of the biggest target for forgeries. It was labeled “Sandisk 16GB class 4 Micro SDHC memory card”. I bought it on eBay, it was coming from China, and it was cheap (16GB for 8€ including shipping). Of course, I wanted to make sure that I got a good one, so I ran a couple of tests. (BTW, I guess the best up-front-protection against fakes is not to buy the cheapest offer on the market.)

Here’s what I did under Ubuntu Linux for testing my card. I ran two tests: one for the performance using flashbench, and another one to do a full-write test in order to reveal capacity problems. My laptop only has a USB card reader, so that I cannot read the manufacturer and other info of the card. Not the best for testing, but well.

Attention: the example below writes to /dev/sdb, which is the device for the card in my case. In your case, it might well be a disk. Make sure that you use the proper device (often something like /dev/mmcblk1 if you have a real card reader).

Running flashbench:

$ ./test_sd_card.sh /dev/sdb
4MiB    10.9M/s
2MiB    4.06M/s
1MiB    4.05M/s
512KiB  2.73M/s
256KiB  1.99M/s
128KiB  924K/s  
64KiB   508K/s  
32KiB   282K/s  
16KiB   194K/s  
8KiB    761K/s  
4KiB    959K/s

So, looking at the flashbench wiki this seems to be fairly reasonable for a class 4 card.

Next, I did the full-write test, to see if the card was actually had the promised capacity. Obviously, you need a bit of space on your disk for this. We’re creating a random data file, write it to the SD card, read it back, and check for differences.

Create a file with the required capacity, filled with random data. We’re writing blocks of 1024 bytes, so adjust the count to the capacity required (16GB in my case).

dd if=/dev/urandom of=rnd_init_data bs=1024 count=16000000

Now, we write the data to the SD card.

$ dd if=rnd_init_data of=/dev/sdb bs=1024 count=16000000
15558145+0 records in
15558144+0 records out
15931539456 bytes (16 GB) copied, 536.286 s, 29.7 MB/s

You can see, we didn’t manage to write all the bytes to the card. This is expected, as we don’t know the capacity of the card down to the last byte. As long as the capacity reported by dd (16 GB) is close to the expected result, we’re happy.

Now, we copy the bytes written to a new file, which we use for later comparison. Notice here the count, which we adapted to the bytes written to the card (15931539456 / 1024 = 15558144). I am sure this can be done easier using tools like truncate, but I didn’t want to start messing with programs that I don’t know by heart.

$ dd if=rnd_init_data of=rnd_written_data bs=1024 count=15558144
$ rm -f rnd_init_data

Read back the data from the card:

$ dd if=/dev/sdb of=rnd_read_data bs=1024 count=15558144

Finally, we’re comparing the two data files:

$ md5sum rnd*
dfed784abed6662926eb01f7fb5359ca  rnd_written_data
dfed784abed6662926eb01f7fb5359ca  rnd_read_data

Et voilà, my card is genuine (or at least does neither have abysmal performance nor fake capacity). Yay, I’ve been lucky!

Don’t forget to clean up (remove files, reformat card):

$ rm -f rnd_written_data rnd_read_data
$ fdisk /dev/sdb    # keys: o, n, p, 1, <accept defaults 2 times>, t, c, w
$ mkfs.vfat -F 32 /dev/sdb1

(The fdisk line creates a single primary FAT32 partition on the card.)

How to get Ubuntu Live running

This article described how to boot Ubuntu from a bootable CD without installing anything on the harddrive. It is meant for the many users of my script that described how to adjust the fan thresholds of a Dell PowerEdge.

Step 1
Download Ubuntu and burn it on a CD. The latest version with 32-bit will do fine.

Step 2
Boot from the CD and select “Try Ubuntu” (don’t install for obvious reasons). This allows you to try Ubuntu without installing anything. You can find more detailed instructions on the download page.

Ubuntu Search Menu

Step 3
After Ubuntu booted, click on the Ubuntu button on the top left. A search menu as seen on the right should open.

Step 4
Type “terminal” into the search box. Ubuntu should give you an icon for the corresponding application. Click on it to start the terminal.

Screenshot of the terminal


Step 5
You should now have a console prompt open. Type the following into the prompt to install the dependencies required for the script:

sudo apt-get install freeipmi freeipmi-tools openipmi ipmitool python wget

This should install the software necessary to query your server using IPMI. IPMI is a protocol for server management. See this link for more information regarding IPMI on Ubuntu.

That’s it! You can continue here: How to adjust the fan thresholds of a Dell PowerEdge.

Prey objects for the foot-bots

A Swarmanoid foot-bot gripping a prey object

I work in robotics, but on the artificial intelligence side of things. That means, almost all the lab is composed of computer scientists and the like. (and their non-affinity to hardware can be quite exasperating at times!) The robots are designed and build at other groups by people that, in contrary to myself, know what they are doing. :) Nevertheless, from time to time I get to dabble in hardware in order to fix things or to enable us doing certain experiments that where not possible without my additions.

This is the case with the objects we’ve designed here. It’s meant for the foot-bot, which is a wheeled robot designed during the Swarmanoid project (see this post for a video explaining the project). While the foot-bot features a gripper to connect to other robots, it cannot simply grab any object, as it depends on a special gripping ring for attachment. The objects we’ve designed are meant to close this gap: the foot-bots can grab and transport them, allowing us to do experiments in foraging and the like.

Left: The two rings that make up an object plus the required M2 screws. Right: An assembled gripping ring.

For me it was the first time to go from the design phase to a fully finished “product” that has the look and feel of a professionally made object. Well, we’ve got it made by a company, so that’s not really a surprise. Anyways, for someone that usually just hacks stuff together, it was quite a nice experience!

For more info on the objects and their design (which is, in the end, quite simple) you can check out the technical report and the supplementary on-line material.

Converting a PowerEdge SCSI backplane to support SATA

This post describes how to build a 8 drive storage server for under a hundred bucks (drives not included).

Last summer I bought a Dell PowerEdge 2800, which I converted to use silent fans and SATA drives instead of SCSI drives. See the project page for this server for more information on how to hack the BMC’s firmware in order to swap the fans agains silent ones.

This post is the writeup of the conversion of the server’s backplane from SCSI to SATA. My main reason for this conversion was money: servers that offer a lot of swappable SATA drive slots are quite expensive. SCSI-based servers, on the other hand, are quite cheap – nobody uses plain SCSI anymore I guess. After searching a bit on the internet, I’ve bought a Dell PowerEdge 2800 that supports 8 SCSI drive slots for 25 bucks.

I gutted the SCSI backplane and replaced the connectors with SATA connectors. Adding in a 3Ware 9500S-12 PCI-X card, I’ve ended up with a raid system that supports 8 SATA drives. (Cold-swappable only, which is what I aimed for. This server is not a production server, obviously, but just our home storage).

In the following, I illustrate the steps how I converted the PowerEdge 2800 to SATA. It’s quite easy to do, so I hope I can inspire others. Apropos others: there is a similar project that was featured on Hackaday around the same time I’ve started with my project.

Assumptions:

  • you do know how to use a soldering iron and which end of a screwdriver is the front
  • you have a Dell PowerEdge generation 8 (or similar, this should also work with generation 7 and 9 servers as the 2900)
  • you have a SATA hardware raid card (I used a 3Ware 9500S-12, but any other will do)

Required material:

  • 90 degree angled all-in-one SATA connector (I used Delock type 84307)
  • cables for connecting the drive LEDs
  • connector(s) maching the pin headers of your raid controller
  • glue, solder, time

So, let’s start! Open up your server and remove the backplane. Obviously, you have to remove all drives before being able to detach the backplane. I say obviously after I ripped of the connector of my floppy drive by brute force – I removed the harddrives but forgot completely about the other drives. D’oh!

Step

I first thought about replacing the whole backplane, but after I bought the server I realized that all the front-panel buttons, the optical drive etc are connected to the backplane. The backplane is therefore essential to the server, and the server does not even boot without it. So we have to leave the backplane in, fair enough.

The first step is to remove the old SCSI connectors from the backplane. Remove first the protective plasic shield from the backplane. Keep it, we will stick it back on later! The SCSI connectors are 68-pin bastards, so unsoldering them is out of the question. In the picture you can see the first connector removed – I pulled of the plasic part with some heavy pliers and stripped the pins one by one with a cutter.

Step

Next, remove all connectors as shown in the picture. After removing the first ones by hand, I ended up using a Dremel to remove the pins. It does not have to be perfect, but pay attention to remove any short circuits. You do not want to disturb the underlying SCSI system that is still active in the server, or (even worse) short circuit the power planes!

Step

Next, we are going to solder the harddisk access LEDs. This step is optional, but as everybody loves flashing LEDs this will give your project some street cred. No, seriously, the LEDs help you to see access on the harddisks and (if your controller supports it) to identify a specific disk/controller port.

The PowerEdge features 2 LEDs for each drive, of which we will use only one (does not matter which one). First, identify the traces on the backside of the backlane for each of the LEDs. Mark them with a pen according to drive number and if it’s the anode and the cathode. Cut the traces leading to the controller of the backplane leaving enough copper for you to solder a cable on.

In the picture you can see how I did this for one of the ports: one cable connected to the anode of the LED, and the other to the resistor, which in turn is connected to the cathod of the LED. Don’t forget to include the limiting resistor into the mix, because else you might burn your LEDs!

Step

Here you can see how I connected all ports on one side of the backplane. Note that I soldered the cable on the back of the backplane (is that the frontplane?? ;) Remember to fix the cables in place with a little hot-glue. No hacking project can call itself a proper hacking project without a little hot-glue, right?

Step

Next, we prepare the connectors to the raid controller. Most raid controllers support pin headers for connecting the drive LEDs. You’ve checked that your’s does support this before starting to solder the cables to the LEDs, right? Along the same lines, you’ve made the cables long enough to go all the way to the raid controller, even when all the fans etc are in the system? Ok, good.

Step

Configure your connector according to your raid controllers pinout. In my case, the pinout was given in the manual of the raid controller: here’s the relevant page. Pay attention not to swap pins.

Step

Reattach the isolating protective plastic shield and put back the power cable. Your backplane should look like in the picture above. Note that I’ve cut away the two bars at the bottom of the backplane’s PCB (at the bottom of the two big cutouts, which were closed before). This allows me to insert the backplane easier with all the cables in place, but it is not really required. If you do this on another type of system, make sure that there are no traces running in this part of the PCB.

Step

Now we start doing the actual conversion to SATA. Mount all drives in their drive cages and stick them in your server. With the backplane still unmounted, you should be able to see the back of the drives. Here, I plugged in the angled all-in-one SATA connectors (I used Delock type 84307, which worked really good).

As the PowerEdge servers do not have many drive power connectors and we cannot reuse the power connectors of the backplane, we have to connect the power cables of the all-in-one connectors together. This also reduces the cable mess. In the picture you can see how I did it: add the connectors one by one: plug the all-in-one connector in the drive, cut away the power cable that is longer than the distance to the next drive, add the next connector and solder the two cables together. Repeat until you have the whole column completed. It’s hard to explain but easy enough to do, so have a look at the pictures.

Step

This is how the end result should look like. Remember to properly protect all solder joints by shrink-tubes or similar. Use zip-ties to clean things up. In the end you’ll have a single power connector for each column of drives.

Step

Next, we need to attach the SATA connectors to the back plane. The idea is that the connectors stay on the backplane when you pull a drive out – without this you would have to dismount the backplane each time you want to swap a drive. I thought about many different ways to do this, but in the end I chose to use a kind of construction glue to do it. There are for sure ways to do this in a cleaner way, but this serves the purpose and is quick and cheap.

The glue should have the following attributes:

  • stick on plastic
  • must remain (at least a bit) flexible
  • must be able to cover distances of a few millimeters
  • must not shrink upon drying (will pull the connector back)
  • must be viscose (not too liquid)

Apply the glue to the back of the SATA connectors as shown in the picture (the white stuff). Be sure to clean the connectors and the backplane from any fat residues before doing so. Additionally, push your drives as far as possible to the front (there’s usually a little play in the cage mounting mechanism, and you’ll want it to be maxed out).

Then, put the backplane in. Wait.

Step

This is how your server should now look at the interior. You can see the 8 SATA cables coming out of the cutouts at the bottom of the backplane, just along the two power connectors. Additionally, you can see the cables that will connect the drive LEDs to the RAID controller (the two gray cables).

Step

After you’ve waited long enough (see glue instructions), you can remove and re-insert your drives to check if everything is in order. This is how your empty drive slots should look like.

Step

Plug the power connectors and connect the SATA and LED cables to the RAID controller. Fire up your machine and check the drive status, and the drive LEDs. Remember that your drives are only cold-swappable, so you have to shut down your server before changing them.

Welcome to your new SATA-based storage server!

Connecting to a car with ODB-II

Our Opel/Vauxhall Corsa B (engine X10XE, 55KW, 1.0l, 12V) has a problem: it lights up the MKL (“Motorkontrollleuchte”, the engine control/warning light) when we’ve been trying to accelerate on the Autobahn. In order to diagnose the problem, I wanted to connect to the on-board control unit and read the error code. Unfortunately, connecting to this unit proved to be a mess. It took me a while to realize that we have the only model of Corsa B where you cannot read the error code with a paper clip: the car has a modern interface standard to all cars nowadays, called ODB-II. You cannot read ODB2 data directly, you have to connect to it using a computer.

OBD-II adapter from www.blafusel.de for connecting to the onboard control unit of many cars. For Opel/Vauxhall, you have to us a multiplexer to switch between different pins. On the left, the ExpressCard adapter that allows to connect without timing problems.

The reader required for this can be quite costly – a couple of thousand Euros for the top-of-the-line standalone units. Well, I wasn’t keen on spending more than my car is worth, so I bought a Open Hardware/Source kit from www.blafusel.de. Amazing site with really knowledgeable, helpful people. I’ve paid ~20€ for the kit including cable, casing etc.

Unfortunately, the interface needs a serial port ans is extremly sensitive to timing (as so many low-level programmers/adapters are). But who the hell still has a real serial port on their laptop? I ended up buying severals adapters just to realize that anything USB-based does not work, and that most extension cards for laptops are based on cheap USB-to-serial adapters. Obviously, ExpressCard/PCIe<->USB<->Serial does not have the best timing properties. I found one chipset that does real PCIe<->Serial conversion, it’s the Oxford OxPCIe952. Any card based on this chipset should work with the ODB-II adapter mentioned above (and any other as far as I can tell). I payed about 20€ for the ExpressCard on eBay.

With the adapter, I managed to connect to the engine control unit alright, which allowed to read and delete the error code (P0103). Now I just have to find the reason for this error code…

PS: There’s unfortunately no open-source project for Opel available, but there is a demo version of the common OP-Com software. The ExpressCard adapter works out of the box with Linux (Ububtu 10.4) and Windows (XP).