About that Lexar video

21.01.2011 18:48

A few weeks ago Lexar, the company behind all sorts of flash drives, published this video with some really nice shots from both the Micron fabrication plant in United States and their assembly factory "somewhere in Asia". It's worth watching.

A couple of interesting things can also be seen there. There are two clips of a pick-and-place machine picking dies from a diced wafer and placing them on PCBs around 2:30 into the video. It appears the machine is ignoring some dies. If those are chips that have been found defective at wafer testing then the yield of their process is around 65 % (I count 80 % good wafers in first shot and 50 % in the second). There's also screenshot visible of what looks like a wafer test result and that puts yield at 86 %

A little later in the video there's a close-up of the placing and bonding process and you can see that two identical dies are stacked on top of each other and slightly shifted so that the bonding pads of the bottom one are left exposed.

And lastly, the video states that it takes more than a month to make a memory chip. I'm not sure what to think of that. What part of the process could take that long? Shipping to Asia for assembly?

Posted by Tomaž | Categories: Life | Comments »

Gyroscope repair

15.01.2011 23:10

On Tuesday I wrote a rant about how my indoor model helicopter didn't work correctly. It turned out that my hunch about a bad connection to the gyroscope was correct. After some exhaustive continuity testing of the nets associated with the gyro SMD I found out there must be a fault somewhere on the tiny break-out board that carries the gyroscope.

After I unsoldered it from the main part of the PCB, the problem was obvious:

Murata Gyrostar on a break-out board

The first pad (ground connection as it turns out) is mostly missing! Probably there was only a crack at first and the rest of the pad peeled off when I unsoldered it. Since I couldn't do anything about the missing pad I soldered the board back in place and made a bridge on the top side with a piece of wire (it's way too thick, but that's the smallest gauge I had at hand):

Fixed ground connection to the gyro

Here's a photo of the components on the bottom side of the circuit board (the black thing out of focus in front is the IR receiver):

Bottom side of the PCB inside micro RC helicopter

Now that the sensor ground has a proper connection the gyroscope offset is well within the trimmable range and the chopper flies as it should. I also managed to take it apart and reassemble it without breaking any of those hair-thin wires or stripping any of the tiny screws. Yay!

Micro helicopter flight test

(Click to watch Micro helicopter flight test video)

Interestingly, I first wasted time by focusing on the Vcc connection. The helicopter was rotating clockwise, which according to the Gyrostar datasheet should mean that the sensor output voltage was too low (i.e. erroneously reporting counter-clockwise rotation). But since the ground connection was flaky it was actually too high. So either the datasheet is wrong or my clocks are running backwards.

Also of note is that the reference voltage output of the gyroscope isn't used (only ground, Vcc and sensor output pads are connected).

Oh, and finally, remember that I said the web site of the company that sells these always throws a PHP error? Well, not if you set the preferred language to Austrian German (de-at) in your browser.

Posted by Tomaž | Categories: Analog | Comments »

Get to da choppa

11.01.2011 21:21

These little 3-channel IR-controlled indoor model helicopters seemed to be all the rage these holidays. They cost around 50 €, look quite solid with their metal frame and are electronically stabilized, which means you can fly them almost as if they were an RC car with an added Z axis.

3-channel IR-controlled indoor model helicopter

If they work correctly, that is. Needless to say, mine is defective. Just like most of the hi-tech stuff I get my hands on these days. It seems there's something wrong with the stabilization electronics. The helicopter mostly just wildly spins around as if the gyroscopic rotational sensor has a large offset. It's way beyond what is correctable with the trimmer on the remote control and a full left stick is just barely enough to stop the rotation. Sometimes though it will start to work correctly for a few moments giving me some hope that perhaps it's just a bad connection somewhere.

Circuit board inside micro RC helicopter

In search of that bad connection I took it apart. Which is surprisingly easy, since it is held together by screws and not glued together like most other such toys.

The electronic part of the helicopter is composed of a small single-cell 180 mAh lithium-ion polymer battery, a circuit board with a few transistors and an unmarked SMD chip, an IR detector and an angular velocity sensor (gyroscope).

Gyroscope element inside micro RC helicopter

The gyro used by this particular model seems to be Murata Gyrostar, a piezoelectric vibrating structure gyroscope. It's 8 x 4 mm in size!

So far I haven't found the cause of the problem. After I measured the output of the sensor on my desk it appeared to give the correct value for zero angular velocity and there are also no apparent bad connections. Testing that in flight is slightly more difficult, of course.

The datasheet for the Gyrostar warns about sensitivity to water condensation. Given that the steel parts inside of the remote control are a bit rusty it also seems likely that the whole thing was improperly stored somewhere.

Forgetting for a moment that the damn thing doesn't fly, I'm still astonished that all this can cost so little. Sure, the components are getting ever cheaper and anodized aluminum frames like this can be seen everywhere. But I see no way the 30-something tiny screws and hair-thin wires can be put together automatically. Just like for Pleo there must be non-trivial amount of manual work involved in manufacture.

For the sake of completeness, the helicopter I have is called Thunder Professional 2 by Modellbau Adam (their website is giving a PHP error ever since I first looked). But this info is mostly useless since I've seen this exact same model sold under a number of other names and I have no idea of its real manufacturer.

Posted by Tomaž | Categories: Life | Comments »

USB data eater

08.01.2011 14:23

I found a curious feature the other day while copying some (rather important) data from an 512 MB USB flash drive. The contents of the files differed each time I copied them. Some further testing turned out that there's a part of the drive's address space that is unreliable and will return single-byte errors when read back.

For instance, here's a list of bytes that differed between two consecutive sequential reads:

0x0078071b: d5 != 4e, 11010101 ^ 01001110 = 10011011
0x007807c0: fc != fe, 11111100 ^ 11111110 = 00000010
0x007836d6: 46 != 56, 01000110 ^ 01010110 = 00010000
0x00785267: 65 != e5, 01100101 ^ 11100101 = 10000000
0x007852c7: 11 != 51, 00010001 ^ 01010001 = 01000000
0x00785344: 65 != 39, 01100101 ^ 00111001 = 01011100
0x0078720b: 00 != 40, 00000000 ^ 01000000 = 01000000
0x00787250: 86 != a6, 10000110 ^ 10100110 = 00100000
0x00787274: 51 != d1, 01010001 ^ 11010001 = 10000000
0x0078732f: 6a != 38, 01101010 ^ 00111000 = 01010010
0x00787336: 75 != f5, 01110101 ^ 11110101 = 10000000
0x00787389: 53 != 73, 01010011 ^ 01110011 = 00100000
0x007890f2: 01 != 52, 00000001 ^ 01010010 = 01010011
0x0078919c: b7 != 37, 10110111 ^ 00110111 = 10000000
0x0078933d: c2 != e2, 11000010 ^ 11100010 = 00100000
0x00789676: 5c != 7c, 01011100 ^ 01111100 = 00100000
0x0078b478: de != fe, 11011110 ^ 11111110 = 00100000
0x0078b4ad: bf != ff, 10111111 ^ 11111111 = 01000000
0x0078b512: ae != be, 10101110 ^ 10111110 = 00010000
0x0078b54c: 0d != 4d, 00001101 ^ 01001101 = 01000000
0x0078b5d3: 75 != f5, 01110101 ^ 11110101 = 10000000
0x0078d70c: 02 != 12, 00000010 ^ 00010010 = 00010000
0x0078d799: 01 != 3c, 00000001 ^ 00111100 = 00111101
0x0078f69e: e4 != 9c, 11100100 ^ 10011100 = 01111000
0x0078f79f: b3 != 93, 10110011 ^ 10010011 = 00100000
0x00793653: 5d != 1d, 01011101 ^ 00011101 = 01000000
0x0079367a: 39 != 19, 00111001 ^ 00011001 = 00100000
0x007936de: c5 != 67, 11000101 ^ 01100111 = 10100010
0x007936f6: 3a != 2a, 00111010 ^ 00101010 = 00010000
0x00793738: 49 != 09, 01001001 ^ 00001001 = 01000000
0x007937a9: 36 != 16, 00110110 ^ 00010110 = 00100000
0x007990fe: c7 != 57, 11000111 ^ 01010111 = 10010000
0x007991c8: 0d != 1d, 00001101 ^ 00011101 = 00010000
0x007b5024: 38 != 81, 00111000 ^ 10000001 = 10111001
0x007b504b: 91 != 7b, 10010001 ^ 01111011 = 11101010
0x007b50ce: 86 != 06, 10000110 ^ 00000110 = 10000000
0x007bf094: 80 != c0, 10000000 ^ 11000000 = 01000000
0x007bf0e9: 48 != 9c, 01001000 ^ 10011100 = 11010100
0x007bf0f3: c3 != d3, 11000011 ^ 11010011 = 00010000
0x007bf10c: 69 != e9, 01101001 ^ 11101001 = 10000000
0x007bf17c: 1c != 5c, 00011100 ^ 01011100 = 01000000
0x007bf1d0: e2 != f2, 11100010 ^ 11110010 = 00010000
Address range scanned 0x00000000 .. 0x1e800000, 42 bytes differ

The errors seem to be limited to addresses between 0x00780000 and 0x007bffff, a 256 kB block, but the list of error addresses differs after each read. Bits will switch both from 0 to 1 and 1 to 0, as evident from the dump above, which seems to suggest this isn't due to faulty or stuck bits in the flash ROM.

For the record, the drive presents itself as:

usb 1-6.3: New USB device found, idVendor=0204, idProduct=6025
usb 1-6.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-6.3: Product: USB Flash Drive
usb 1-6.3: Manufacturer: PIXIKA

Just to be sure, I've tried reading this key on two different computers and both gave the same result (i.e. bytes from the address range above were always corrupted).

So, what is to be learned from this? Bad flash drives can silently corrupt your data (making my previous assumption about block level CRC invalid) - there is no evidence in kernel logs that the software was aware of corruption. I guess a fancy filesystem would protect you, but who uses that on USB drives?

Also of note is that badblocks(8) will not detect this by default (as it seems to depend on the kernel throwing an IO error). Only when run in read-write mode (-n flag, probably also -w) will it report problems with the drive.

This makes it the second case of silent data corruption in the last 3 months. Seriously, sometimes I feel like a magnet for broken technology.

Posted by Tomaž | Categories: Digital | Comments »

Code golf

03.01.2011 22:54

One of the more fun activities at the 27C3 was the code golf challenge organized by the <<</>>. It's a competition where you are given a simple task and the winner is whoever writes the shortest program that can complete that task (either overall or in a particular programming language).

Just about any language was valid, from Postscript to Z80 assembly. What convinced me to join was when I saw that the current Python leader had less bytes than the current Perl leader. As a seasoned Perl programmer I found that offensive - if anything, Perl is known for its ability to parse short, incomprehensible strings of line noise. How could the there-is-only-one-way-to-do-it Python win? So I used a couple of hours to correct that injustice.

The given task was to make a program that reads an integer in ASCII from standard input and outputs an ASCII art of a string of that many Cs:

$ echo 3 | perl x.pl
   ##  ##  ##
 #   #   #
#   #   #
#   #   #
#   #   #
 #   #   #
   ##  ##  ##

My best solution with 67 bytes came in at the 10th place at the end. The first place was taken by a program of just 26 bytes.

It was cheating, of course. What did you expect on an event like this? My first idea was to fetch the solution from a remote server, but I soon gave up when I realized the execution environment was closed more tightly than I thought. I'm sure just about everyone else tried something like that before starting work on a real solution.

However ySas' program that took the second place with 50 bytes is a legitimate solution and very interesting to pick apart. Here it is in its entirety:

print$\=($_='   #'x<>)|" $_
 "x/ +/,"$'
"x4," $'

Here's a sample output when 3 is given on the standard input (the colored parts of the code produce the parts of the output in the same color). Note that all white space (including new lines) is significant:

   ##  ##  ##
 #   #   #
#   #   #
#   #   #
#   #   #
 #   #   #
   ##  ##  ##

There are three tricks worth noting here:

First, all strings are made out of a basic building block constructed in the parenthesized part and assigned to the special variable $_ ("   #" repeated by the number read from standard input). The red part is made by binary ORing $_ with itself, shifted by one space. Space is ASCII 0x20 and "#" is 0x28 so space OR "#" equals "#". Also it appears that Perl zero-pads strings when performing binary OR.

The right-hand side of the OR operator is multiplied by "/ +/". This regular expression operator finds the three leading spaces in $_ and returns 1 in scalar context (so multiplication doesn't have any effect). However it also sets the special variable $' to the rest of the string ($_ without the leading white space). $' is then used in the green and blue part of the output.

Finally, the first part of the string also sets the $\ special - the output record separator. Setting it causes an implicit repetition of the red part of the string at the end of the print statement.

So, here it is - 50 bytes of Perl code which take an hour to understand. First valid solution in Python came in at 67 bytes (is it easier to understand?) and PHP in 91 bytes. In the end, my 10th place did in fact get me a bottle of Club Mate, because I was the only 27C3 Perl coder that showed up on the final code golf meet-up. But I guess sharing the tricks learnt also counts as something.

Posted by Tomaž | Categories: Code | Comments »

Talking analog in Cyberpipe

01.01.2011 18:16

With a new year comes a new challenge. In the following months I'll be organizing a series of talks revolving about electronics in Kiberpipa. It's an effort to bring some more hardware oriented topics to Ljubljana's hacker space. And with hardware I don't think Arduinos or FPGAs which are mostly software first and hardware later. I mean things where you need a soldering iron and an oscilloscope instead of a keyboard and a debugger. The stuff that works between 0 and 1.

I'm hoping to cover topics like analog audio and video, radio, batteries and power supplies. However I guess that mostly depends on the feedback from the audience and the interests of speakers. So the details will probably get filled in as we go along.

Banner with a random photograph of a PCB

The first talk will be this Thursday, 6 January at 19:00 by Miha Leskovec and Urban Medič, the team from the Faculty of electrical engineering that won the Texas Instruments' European Analog Design Contest last year. They will present their fully-analog interference-free optical pickup system for bass guitars:

The idea for the project came just before the competition was announced and it came as a prefect candidate to demonstrate that analog design still plays a major role in the era of the microprocessor. As a musician Urban came up with the idea to try and create a new pick-up for his Bass-guitar. We noticed that another company was already manufacturing a light-based pick-up that promised a big improvement over the widespread magnetic system that has been present for more than half a century. So we set up a proof of concept test rig and experimented with a DC driven IR transmitter and receiver module placed under the strings and found a lot of noise in the output from the ambient lighting. Instead of covering the pickup together with a substantial part of the strings as the existing company did we searched for a better solution to cancel the interference from ambient light based only on analog components.

Full paper in PDF format is available from the Texas Instruments site. The talk (in Slovenian language) will be streamed live and recorded by Kiberpipa.

Posted by Tomaž | Categories: Analog | Comments »