ESD wrist straps

I don’t know about you, but I strap mine on in the morning and then spend the day running around with it in the whole lab. I realize usually at home that I am still wearing it, and that I forgot to attach it again after that first break…

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.

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:

$ ./ /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.)

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 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 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).