Top-Quark - Blog

Battery pack volume efficiency

Y'know, while I'm actually using this thing for the first time in a century...

Has it ever bothered anyone how amazingly inefficient current battery packs are with their geometric construction? Inside the nice monolithic battery packs you see out there for laptops, cordless tools, and the like, there's (typically) inside a large slab of soldered-together rechargeable variations on the everyday AA battery. Sure, they've got exotic chemistries, and they have tabs for soldering, but they're just a variation on a theme, and wasting so damn much space.

Nerd alert: If you think about it, actually.. say you have a battery pack of dimension (width, height, depth). There's w*h*d cubic units of volume in there, for whatever chemistry you care to fill it with. Now suppose you're constrained to filling this w*h*d with cylinder objects. Arbitrarily, I'm going to orient the length of the cells with the d dimension, set the diameter of the cells to h, and constrain dimension w to integer multiples of h. Our individual cell volumes look like (pi*(h/2)^2*d), multiplied by (w/h) cells. With a lil algebraic manipulation, you have (pi/4)*(w*h*d)... (pi/4) is ~0.785.

So, basically, you're throwing away ~21% of your total battery capacity by using this stupid construction technique. Actually more, since the individual cells have their own external packaging, thermal spacing, tabs, etc. Prismatic cells are a step in the right direction, but for fuckssake, they really need to be building *slab* cells. Yeah, I know there's engineering constraints like thermal migration, bulging, etc, but there's problems to be ironed out all the time. This is just delaying the inevitable.

PS: Extra credit - open up a 9V battery, and learn what fear is.

Firearms Tech Mini-Revisit

Cool - the powered picatinny rails idea I wrote about in 2005 is being worked on:

http://www.dtic.mil/ndia/2009infantrysmallarms/wednesdaysessionvTorbjoern.pdf

Looking back and reading my page, I'm pleased that the XM8 died, too.

you'll never know how nerdy i really am

Microcenter had an ad for cheap USB flash drives. Something like $10 for a 1 GB. I'm completely in love with the information density they offer, as well as their overall ruggedness, so I went ahead and grabbed a couple. They had two flavors - a Kingston DataTraveler 1 GB and a Microcenter-branded drive, with U3.

It started with wanting to find out which of the two drives was faster. Using XBench, a benchmarking suite for Mac, I went ahead and ran some hard drive benchmarks. The results were pretty comparable, with the Microcenter-branded drive coming out a touch faster on uncached writes. (results below - just you see)

Then in the process of trying to get rid of the U3 "feature", I re-found that OS X's disk utility is a rather powerful piece of software. You can, among other things, create RAID arrays from a variety of different devices.

Sooo...

Plug, plug

Click, click

So more benchmarks were set up with the new flash drive RAID, and the hard drive on my laptop. The results, with the original data, are below:

Really, the whole playing around with drives and RAIDing was just shits-n-giggles. What really scares me is that I automatically started putting numbers into an Excel spreadsheet, pivoting out results, and making charts. I was halfway through specifying chart series before I realized what the hell was going on. Working in the commodities trading industry has done terrible things to my apathy.

Results interpretation is sort of a repeated exercise in "duh", but the most obvious point is that the hard drive kicks the crap out of the flash drives in writing. What's also "duh", but notable, is that while the hard drive took a hit going from sequential to random large block reads, the flash drive (and flash drive RAID) performance was more-or-less unaffected. Surprisingly, the 256k block read performance on the flash RAID array exceeded the hard drive in both sequential and random cases.

Putting it all to practice, copying over XVID movies to the flash raid array allowed for skipping around the movie without playback delay, where the same files on the hard drive required some time to get going after moving. I imagine this could be useful for video editing, or perhaps some database access situations. There's the usual worry about the life of NAND flash memory, but that doesn't really apply to reads, and it's now often stated that wear-leveling has resulted in flash drive lifetimes comparable to magnetic disks.

Overall, what really sticks out in this case is a kind of general engineering observation, in the implementation of systems manifesting dichotomy. Rather than utilizing one approach or either, igniting numerous holy wars en route, the solution is often to utilize a hybrid approach. The most solid examples coming to mind now are CISC/RISC (Micro-ops), and the essential data storage dichotomy of fast+small and slow+big (caching).

The key in any of these is to allow for an offset between the approaches, such that the weakpoints of one side exactly coincide with the strongpoints of the other. The situation illustrated with the comparison between the flash RAID and the hard drive shows a dichotomy that could be exploited accordingly. An interface could be implemented where random reads could be directed to the flash component of a drive, and sequential operations directed to the magnetic drive component. This segregation could be realized by statistical examination, or just with some sort of miniature tournament model, where the interface issues commands to the flash and magnetic components, and waits for the first component to return the result of the operation.

I know it's livejournalish to post IM conversations, but I appreciate harsh truth:

[22:34:59] me: why am i doing this
[23:30:54] friend: why are you doing this?
[23:54:52] me: I don't even know
[23:55:22] me: but I do know that if I'm gonn do uncached random reads, a ghetto flash raid array is wonderful!
[00:06:55] friend: why can't you just have normal hobbies?

Edit: I'm never as clever as I wish I were:
ipod shuffle raid
hybrid hard drives

Java, OS X Terminal, and Unicode - a Sordid Tale

I'm pissed off, and I'm not sure who or what to blame.

See, right now, I'm trying to build a front-end to the UNIHAN database, which I've found to be profoundly useful for my East Asian language research; specifically the fact that it contains Tang Dynasty-era pronunciations for quite a few CJK (Chinese/Japanese/Korean) characters. The Mandarin, Japanese, and Sino-Korean pronunciations are also very nice to have. Unfortunately, the database itself is a massive UTF-8 flatfile, keyed by a character's hexadecimal UTF-16 codepoint, so it's not the easiest thing in the world to use.

So I'm using Java to make an application to allow me to type in a Han character, and get the UNIHAN data. What pisses me off, though, is the way that (Java/OS X/OSX's Terminal) handles unicode output. It's messed up as hell, and I don't. know. why.

Here's an example. Suppose I have code that looks like this:

System.out.println("你好");
System.out.println("\u4f60\u597d");

The first println works fine, and outputs the characters fine to OS X's Terminal. The second println, using the UTF-16 codepoints for those two characters (U+4F60 and U+597D, respectively), prints out two question marks. Cut-and-pasted, straight from terminal:

你好
??

I shit you not.

This isn't exactly something anyone I know can help me with, either. The most helpful answer I've gotten is that there're some very rare variant characters that have a codepoint associated with them, but no glyph representation in a font. This I knew, but there's a slight issue with that explanation. Namely, that the characters "你好" are roughly the Chinese equivalent of "hello".

Well, that, and the fact that the characters printed out just fine ON THE LINE RIGHT ABOVE.

So I don't know whether to blame Java, OS X, or Terminal, all of which are purported to be unicode-friendly. Actually, I think there's a strong chance that it's my fault, but we can pretend I didn't admit that. What I may just end up doing here is to declare a "screwit" situation, and just jump to the Swing app I was thinking about making, since that supposedly solves many issues.

Grado SR-60

Being on campus for 14 hours a day is not particularly fun. Lately, a large portion of that time's been spent with a pair of cheapie ipod-style earbuds stuck in my head. For various reasons, mostly my irrational disinclination for going deaf, I've decided to stop using earbuds. My replacement led me back to a set of headphones I'd had once, and really enjoyed - the Grado SR60.

Some very basic research on the net provides a treasure trove of reviews about the SR60. It's the darling of value-oriented sound enthusiasts, and a common infection vector for audiophilia. I won't really go into a huge analysis of my experiences: after about 48 hours of moderately loud break-in, they sounded excellent. My only complaints are that bass is a little weak, the upper end is a little lively ("bright"), and that there's not a lot of sound isolation, for either the listener or the public. These are expected, if one reads the reviews.

A pair of airline socks valiantly gave their lives to the cause of better sound.

Their sacrifice was certainly not made in vain; the socks improve every shortcoming of these headphones. Bass response is (imo, greatly) improved, with only a trace of muddiness. I think this very slight muddiness might be due to the choice of material; a less "fuzzy" sock might have crisper response. Also, rolling them tighter would probably be an improvement (I'd do it, but then I'd need to resew the stitches holding the "rolls" together). Sound isolation is also much improved over my original pair of "quarter-modded" (i.e., quarter-size hole removed) foam pads. The last major improvement is to comfort; I don't find the stock "comfy" pads to be as offensive as some do, but my last pair of decent headphones had earpads surrounding the entirety of the ear (circumaural), versus the "on ear" (supra-aural) design of the original foam pads on the SR60. Tradition won out, and I find that these new pads are much more comfortable than the stock supra-aurals.

More mods may be coming; I'm pretty sure I'm going to rewire the headphones with cable that's thinner. At 3/16 of an inch, the main cord on these is pretty hefty; enigmatically, the "branches" coming off the y-connector feel cheap and thin.

When I get around to opening up the headphones for recabling, chances are good that I'll be doing a couple other mods. Offhand, I'm thinking about adding jacks to the headphones, and plugs to the cable, so that I won't kill my phones if I stand up with my cable underfoot. I'm also thinking about making the wire connection to just one side, and running the wire up through the headband for the other side. Some audiophile nuts I talked with tried to convince me that this would degrade sound quality, on account of the signals being out of phase, due to the small amount of extra cable run.

Sitting down with my calculator, though, I figured a worst-case scenario of about 2e-4 radians offset. That's 0.0002 radians. If there's nothing else you should learn from this short excursion into the world of higher audio mania, it's that the term "audiophile" is a synonym for "sucker".

With profuse apologies to toshi, whose photographic obsession with desaturation has "colored" me. Ha ha.