Prime Telephoto + Tiny Sensor = Super telephoto?

Sometimes I get an idea in my head and just can’t get it out.

Modern digital cameras often have tiny sensors compared to 35mm film.

High-quality 1970s “prime” 35mm lenses had a reputation for being very sharp.

When one of those lenses is mounted on a small-sensor camera, the sensor covers only a tiny central region of the 35mm-sized image formed by the lens – essentially the sensor is cropping from the middle of the image, resulting in a telephoto effect.

This gives rise to the “crop factor” of small sensor cameras – at a given focal length, the field of view of the small sensor is much smaller (more “zoomed in”) than on the original 35mm film the lens was designed for.

What, I wondered, would images from a high-quality 1970s prime 35mm lens mounted on a modern small-sensor camera look like? Especially, could I get super-telephoto effects by mounting lenses that were considered long (telephoto) by 35mm standards, multiplied the “crop factor”?

I had to try it.

35mm film frame vs Pentax Q sensor

35mm film frame vs Pentax Q sensor

Above is a diagram showing the relative sizes of a 35mm film frame compared to the 1/2.3″ sensor in the Pentax Q.

The Q has the smallest sensor of any interchangeable lens camera I know of. While this may make it – ahem – less than ideal for general photography purposes (altho to be fair the latest versions of the Q have moved to a larger 1/1.7″ sensor, a huge improvement), that little 6.17 x 4.55 mm sensor does have an immense “crop factor” of 5.6x (comparing effective field of view at the same focal length – the number isn’t exact because the Q’s sensor has a 4:3 aspect ratio, while 35mm film is 3:2).

Off-topic, but other points in favor of the Q are the tiny flange focal distance of 9.2mm – it can mount just about any lens ever made – and Pentax’s excellent UI. I’m not sure there’s a mass market for a camera like this, but it sure can do some things that no other camera can.

So, while a “normal” 50mm lens on a 35mm camera has a 39.6 degree field of view (horizontal), the same lens on the Q sees only 7.1 degrees.

And – here’s the neat thing – a “telephoto” 200mm lens on a 35mm camera sees 10.3 degrees – but on the Q, only 1.8 degrees. That’s the equivalent of an immense 1120 mm lens in 35mm format. And a super-telephoto 500 mm lens sees just 0.71 degrees on the Q – equivalent to 2800 mm on 35mm.

So, I tried it. I got some Minolta MD/MC type prime (non-zoom) lenses on eBay, mainly because they have an excellent reputation and are a bit cheaper than other brands (because they don’t fit many modern cameras), and an adapter for the Q (also on eBay – remember I said the Q can mount almost anything?).

Here’s what I ended up with:

Lenses tested

Lenses tested

Left to right:

  • Minolta 50mm f/1.7 MD Rokkor-X PF
  • Minolta 135mm f/3.5 MD Celtic
  • Minolta 200mm f/4.5 MC Tele-Rokkor  PE
  • Minolta 500mm f/8 RF Rokkor-X

From what I can tell online, these are all highly-regarded lenses. The “Celtic” line was Minolta’s cheaper brand, but it seems the economy came from using cheaper materials in the mount, etc. – supposedly it is optically identical the to more expensive “Rokkor” line. And of course, these are all primes – not zooms. Even today primes are generally sharper than zooms; this was even more true in the 1970s before improved manufacturing and computerized optical design.

In the second row you see the Pentax Q with a Tamron 3.5-8mm zoom f/1.8 lens in CS mount, via a “Hawk’s Factory” CS mount adapter (I told you the Q can mount most anything…), and the Minolta MD-to-Pentax Q adapter (just a hunk of metal – no glass).
Read the rest of this entry »


Back in 1996 I had an idea I called the “CreepAway”.

It was a device that would screen your phone calls – it would auto-answer (blocking the local ring), and then ask the caller to “Enter Extension Number” (really a password).

If the caller entered the correct password, it would ring the phone so you can answer.

If they didn’t, the caller would be sent to voicemail.

The idea is that you give both your phone number and your “extension” to your friends – they dial your number, enter your “extension”, and the phone rings.

Telemarketers and others calling at random only get to leave a voicemail.

I think this would be easy to do today with an Android app.

I’m sick and tired of getting robocalls offering me legal help with my (non-existent) IRS debt.

Somebody please build this.

Update, 2013-12:

I recently realized that not only would this be easy to do in an Android or iOS app (intercept the incoming call at the API level, assuming those APIs are exposed), but there’s an even simpler way.

Do it as a service.

Your phone company (Vonage, Google Voice, the PTT, whatever) would provide you with two numbers – a public one (to be given out) and a private one (known only to the phone company).

When people call the public number, the service provider (phone company) would prompt for the extension (or password, whatever). If the caller gives the correct one, the call is forwarded to your private number. If not, to voicemail.

That’s it. It would be trivial to implement in a modern SIP or H.323 based phone system. And they could charge for the service.

Hey – somebody – DO THIS.

What is it??

What is this?


This is not a quiz or a puzzle. I want to know what it is.

All I know is that it is something used in a biology lab. This thing was found loose inside a piece of used equipment.

It’s got 4 wires coming out – looks like a standard telephone cable. When I measure, I see 2218 ohms between black and red, 2267 ohms between black and green, and 4470 ohms between red and green. Yellow seems to be disconnected (open circuit).

IMG_7273 copy

The knurled ring thing (above) tightens down a rubber stopper – looks like it was meant to go into some kind of bottle or flask. The stopper isn’t airtight tho (it’s not completely sealed against the metal tube).

Below are oblique, end-on, and side views of the “business end”. It appears to have two little glass bulbs at the end, each with something black or dark grey inside. (The little white circles in the photos are just reflections of the ring light on my microscope.)

What is it??

IMG_7275 copy

IMG_7277 copy

IMG_7280 copy

Update, October 27 2013:

Looks like Bob was right.

When I wave a hot air gun at it (set at 100 C), the resistance between red and black instantly drops to about 1.4 k ohms, red to green goes to about 3 k ohms, and green to black goes down to 600 ohms or so. It definitely seems to be a temperature probe.

I suspect the two bulbs are arranged red – (bulb) – black – (bulb) – green, and that the two bulbs’ different responses somehow contribute to stability and/or linearization of the output. Probably it wouldn’t be too hard to calibrate it, but for now it goes on the shelf. At least I know what it’s for (even if I still don’t know who made it).

Play & record video at the same time in Linux

I didn’t think this would be so difficult.

All I want to do is play live video on my netbook (from /dev/video1:input=1:norm=NTSC) and record it at the same time. Without introducing lag.

mplayer plays the video fine (no noticeable lag).

mencoder records it fine.

The mplayer FAQ says you can do it this way:

mencoder tv:// -tv driver=v4l:width=324:height=248:outfmt=rgb24:device=/dev/video0:adevice=hw.1,0 -oac mp3lame -lameopts cbr:br=128 -flip -ovc lavc -lavcopts threads=2 -o >( tee filename.avi | mplayer -)

But that doesn’t work.

You can’t record and play at the same time because there is only one /dev/video1 device, and once either mencoder or mplayer is using it, the device is “busy” to any other program that wants to read the video stream.

I spent lots of time with mplayer, mencoder, ffmpeg, avconv, and vlc;  as far as I can tell none of them can do it, directly or indirectly. There are ways that work if you don’t mind 200 or 300 ms of extra latency over mplayer alone. But I’m doing a FPV teleoperation thing and that’s too much latency for remote control.

I found a way that sort of works. Here’s a bash script (works in Linux Mint 15, which is like Ubuntu):

mplayer tv:// -tv device=/dev/video1:input=1:norm=NTSC -fs&
outfile=$(date +%Y-%m-%d-%H%M%S)$1.mp4
avconv -f x11grab -s 800×600 -i :0.0+112,0 -b 10M -vcodec mpeg4 $outfile

This works by running mplayer to send the live video to the screen (full screen), then running avconv at the same time to grab the video back off the display (-f x11grab) and encode it. It doesn’t add latency, but grabbing video off the display is slow – I end up with around 10 fps instead of 30.

There must be some straightforward way to “tee” /dev/video1 into two virtual devices, so both mplayer and mencoder can read them at the same time (without one of them complaining that the device is “busy”). But I haven’t found anybody who knows how. I even asked on Stack Overflow and have exactly zero responses after a day.

(If you know how, please post a comment!)

Addendum for Linux newbies (like me):

After you put the script in file “”, you have to:

chmod +x # to make it executable (just the first time), then

./ # to run the script (each time you want to run it)

You’ll probably want to tweak the script, so you should know that I’m using a KWorld USB2800D USB video capture device, which puts the composite video on input=1 (the default input=0 is for S-Video) and requires you to do norm=NTSC or it’ll assume the source is PAL.

-fs makes mplayer show the video fullscreen. Since I’m doing this on my Samsung N130 netbook with a 1024×600 screen, the 4:3 video is the 800×600 pixels in the middle of the screen (starting at (1024-800)/2 = 112 pixels from the left).

Also, many thanks to Compn on the #mplayer IRC for trying really hard to help with this.

Update 2013-11-02:

I haven’t given up on this, so I’ll use this space to record progress (or non-progress).

I started a Stack Exchange thread on this.

On IRC I was told that VLC can do this. I got as far as getting it to display the video at 720×96 (yes ninety-six) resolution, with a lot of lag (the source is VGA, 640×480).  Googling about it, it seems the resolution problem is probably fixable with VLC, but the lag isn’t.  So I gave up on that.

The most promising approaches at the moment seem to be:

  1. This page about ffmpeg which gives ways to create multiple output from a single video input device – exactly what I need. But I haven’t found any way to get ffmpeg to read from input=1:norm=NTSC (as mplayer can).
  2. This thread on Stack Exchange seems to describe  ways to “tee” the video from one device into 2 (or more) other devices. One way using V4L2VD, the other using v4l2loopback. I haven’t figured out how to get either working.

Update 2013-11-03:

Pygame has the ability to read and display video streams, but ‘nrp’ (one of the developers of pygame) told me on IRC that he never implemented reading from anything other than the default input 0 (zero). He suggested that the info needed to update the pygame code to do that is here, and the source code is here. I’m not really up for doing that myself, but maybe somebody else will (I posted this bug on it, per nrp’s suggestion).

Another idea I had was to just buy a different USB video capture device, that works with the default input 0 and norm. So far I haven’t found one that does that.

But I’ve got two new leads:

Update 2013-11-03 #2:

I think I made a sort of breakthrough.

v4l2-ctl can be used to control the video4linux2 driver after the app that reads the video stream has started. So even if the app mis-configures /dev/video1, once the app is running you can configure it properly.

The magic word for me is:

v4l2-ctl -d 1 -i 1 -s ntsc

That sets /dev/video1 (-d 1) to input 1 (-i 1) and NTSC (-s ntsc).

Not only that, but I (finally) found out how to get avconv to configure video4linux2 correctly (and maybe also for ffmpeg).

For avconv, “-channel n” sets the input channel, and “-standard NTSC” sets NTSC mode.  I think the equivalents in ffmpeg are “-vc n” and “-tvstd ntsc” respectively, but I haven’t tried those yet.

But this works:

avplay -f video4linux2 -standard NTSC -channel 1 /dev/video1

Now I can try to ‘tee’ the output from /dev/video1….

  • do it…

Update 2014-06-01:

I gave up on this, but eventually got it working in Python with Windows (see this post); maybe that method will also work in Linux (I haven’t tried it).

For what it’s worth, this guy claims he has it working this way:

vlc -vvv v4l2:///dev/video1:input=1:norm=PAL-I:width=720:height=576 –input-slave=alsa://plughw:1,0 –v4l2-standard=PAL_I –sout ‘#duplicate{dst=display,dst=”transcode{vcodec=mp4v,acodec=mpga,vb=800,ab=128}: std{access=file,mux=mp4,dst=test.mp4}}’

I’m doubtful (esp. re latency), but you could try it.

Solar powered bike

I built a solar-powered bike. It works, but not quite as well as I’d hoped.

IMG_20130806_120725 copy

I started with a 2008 Currie “E-Zip Mountain Trailz” (sic; ugh) electric bike, which works pretty well.

That is powered by a pair of 12v 10AH SLA batteries, in series for 24 volts. I’ve always been afraid to ride for long distances for fear I’d run out of power before getting home. (The thing weighs 70 pounds, and I’m no athlete, so it’s painful to go up hills without power.)

I’d been thinking of putting solar panels on it to charge the batteries while I ride. I didn’t have any appropriately-sized panels around, so I didn’t do it until this summer, when I decided to try using a bike trailer to hold the panels.

The trailer solves the problem of the panels being shaded by my body when I ride, and also avoids problems with the weight of the panel hardware messing up the balance of the bike.

I have some 20 year old Siemens SM55 modules, rated at 55 watts (new, when pointed at the sun). These things are huge and heavy – 51 x 12 inches, and 12 pounds each (1300 x 330 mm, 5.5 kg). And since the eBike runs on 24 volts, I’d need 2 panels in series to charge the battery (at least without a DC-DC boost converter). That’s 24 pounds, not counting mounting hardware.

But, hey, with a trailer, who cares how much it weighs, right? And 110 watts is a lot of power – likely enough to completely power the bike while riding (on average, on a sunny day).

So I got a used bike trailer; $50 on Craigslist:

The bike trailer as I got it

The bike trailer as I got it (nylon roof & child seat removed)

I took off some of the trailer hardware to make it easier to mount the panels, and installed a plywood floor to make a storage compartment under the panels.

Then I used a couple of pieces of lumber to attach two panels together (at the ends), and mounted more lumber on the sides for mounting on the trailer. I cut slots to fit the trailer poles, and attached the panels to the trailer using standoffs and cable ties:

Cable tie straps hold the panels on

Cable tie straps hold the panels on

I also had to use more lumber to reinforce the trailer poles, which were only meant to hold a nylon sunshade (not 30+ pounds of panel hardware).

I was going to get a 24v charge controller to avoid putting too much voltage into the batteries, but I haven’t gotten around to that – I just wired the output of the panels (in series) parallel with the 24V battery; good enough for now.

Solar panel output wired in parallel with the battery

Solar panel output wired in parallel with the battery

"Watts-Up" meter is just used as a voltmeter. The venerable Garmin GPS V is also powered off the 24v system.

“Watts-Up” meter is just used as a voltmeter.
The venerable Garmin GPS V is also powered off the 24v system.

Finally, I made a bumper sticker to go on the back of the panel; it reads “CAUTION – HIGH CURRENT STAND BACK 500 MM” (just visible in the last picture below, if you zoom in). I figured that would keep the ignorant from messing with the bike (and it fits my skewed sense of humor).

So, how does it work?

It works. Mostly, sort of. As long as I’m riding in full sunlight I can go indefinitely if the road is level or not too steep.

I tried a test run riding to work – about 12 miles – on a sunny day.

I weigh nearly 220 pounds, the bike is 70 pounds, and the trailer with the panels is something like another 50 pounds. So the whole setup is maybe 350 pounds. That’s too much for the motor to pull up a steep hill without a lot of help from me.

I got to work OK and not too tired, in about 90 minutes (about 8.2 mph average – not at all impressive by road bicyclist standards). I did have to work my way up hills.

At work I got delayed and ended up going home close to dusk. I started out riding in the shade. Halfway home, I had a dead, dead battery and about 7 miles still to go. And 350 pounds to drag up each hill. After mighty struggles, I gave up and called for a ride home.

A week or so later, I tried the same trip on a light steel street bicycle (about 20 pounds, with narrow smooth tires and no suspension – in other words, efficient).

I got to work again in about the same time, only slightly more tired than with the electric bike. With the vastly lighter and more efficient bike, going up hills with that was no harder than with the solar bike (with the motor helping). And I was able to get home with no problem.

In the end, a simple street bike turned out to be just as fast, not much more effort to ride, and way more practical – it even works in the shade.

But it was fun to try.



Idea: Waterproof RV roofs with air pressure

Here’s another idea I don’t want to bother patenting.

I’ve owned 2 motorhomes so far, and the roofs always leak. There are lots of holes in the roof for vents, wires, etc., and with all the jostling a motorhome gets on the road, after a while lots of invisibly small cracks open up (despite sealant) and the roof leaks – even if you apply more sealant every year.

Make the roof a hollow structure with air pressure inside. It could be a flexible inflatable structure, or rigid but with a hollow air-tight space inside.

Then pressurize the inside of the roof with air from a pump or tank.

When tiny gaps appear in the roof, the air will escape outward (being replaced by the pump or tank) and will push away water, instead of letting it in. So the interior will stay dry.

The pressure doesn’t have to be high – a few PSI (tens of kPA) should be enough to prevent water from coming inside.

How often the pump runs (or the tank empties) is a measure of how many leaks there are in the roof – when there are enough to bother with, you go and apply sealant. When the leak stops, you’ve found the spot.

You could even pump in colored smoke to help find leaks.

This would be a cheap solution – a molded (or inflatable) roof doesn’t cost much and a $20 electric air pump are all you need.

I made a hovercraft

I made a RC hovercraft this morning. This is something I’ve been meaning to do for about 20 years.

It took about an hour.

RC Hovercraft

It’s a green foam tray (free on request from the produce department at the supermarket) with a hole in it, a cut-off plastic cup, a ducted fan/motor from eBay, battery, and RC receiver. And a lot of hot glue.

The bolt and washer are to balance the battery – they’re hot-glued down.

Here it is running. It’s way overpowered – it works best with the throttle at about 5%.

Later I made a skirt out of tape – no pics; it looks about the same, just flies higher by the width of the tape.

I’m glad I got that out of my system – now I can move on to something else.

OpenSCAD is great stuff! (Part 2)

[This is Part 2 of this post; click here for the first part.]

OpenSCAD is an open-source (completely free) 3D solid CAD program; it works on Windows, Linux, and Mac OS X.

It calls itself “The Programmers Solid 3D CAD Modeller”, and indeed that’s what makes it special.

Unlike any other CAD system I’ve seen, OpenSCAD is driven entirely by a program-like script. That sounds like it would be a lot harder to use than a GUI-based CAD system – but it’s not! It’s much easier to use, with a much shorter learning curve. The scripts use a C-like syntax that will be instantly familiar to anyone who’s worked even a little with C or a C-derived braces-and-semicolon language (C++, Java, C#, etc.).

In 15 minutes with OpenSCAD, I was able to do far more than I could with AutoCAD or SketchUp after several hours – with a lot less frustration. If you have any background in programming at all, you’ll find it ridiculously easy to learn and use.

OpenSCAD has a simple but effective IDE, so you can try things interactively at the keyboard – just type some commands, mash F5, and see the result instantly. Once your 3D model is rendered, you can use the IDE to zoom in and out and look at your model from any angle.

OpenSCAD showing my modeled speaker set

OpenSCAD showing my modeled speaker set

What makes OpenSCAD great for engineering drawings is it’s ability to position and size things numerically – if you want a part exactly 3.75 inches to the left of another part, just subtract 3.75 from the x-coordinate of the part, and that’s where it will be. If you want a part to be tall enough to cover 9 other parts, just get the dimensions of the other parts, add them up (in your script) and feed the result in as the height value.

That way, if you resize one part of your model, all the other parts that depend on it for their own size and position automatically get adjusted to compensate. If you want something centered with respect to some dimension, just take the dimension and divide it by 2 to get the proper position!

None of this is “magic” performed by OpenSCAD – this is stuff done by you, in your own script (program), so it’s 100% under your control.

For example:

cube([w, h, d]);

Gives you a rectangular prism with the given width, height and depth. “w”, “h”, and “d” can be literals – so cube([1,4,9]); gives you a 2001-type monolith. Or they can be program variables, which you can pass to a module and whose values you can compute.

There are commands to translate, mirror, and rotate objects (or groups of objects), and you can assign colors and transparency to them (but not textures, yet anyway). All the basic arithmetic and trigonometry functions are there to help you compute sizes, positions, and angles. And you can construct objects by any combination of adding or subtracting primitives (rectangular prisms, cylinders, spheres, and polyhedrons).

Conditionals and iteration are available with C-like “if” and “for” statements, so you can write a “real program”.

One unexpected thing is that the compiler is somewhat primitive – all variable values are computed at compile time (not “run time”); this has to be kept in mind when writing scripts, but I didn’t find it a serious problem.

The OpenSCAD website has an excellent manual (by freeware standards) that explains all this, as well as a handy “cheat sheet” for quick reference.

So far, I’ve used OpenSCAD only for this one project, and that took just a few hours – most of the time was spent tweaking the design of my speaker case. (Unlike all the other CAD programs I tried, hardly any time was spent figuring out how the program works.)

However, I quickly found a few tricks worth mentioning:

module part(name, w, h, d) {
cube ([w, h, d]);
echo (name, w, h, d);

This defines a module (something like a function) called “part”, which I use to define each separate part I’ll have to cut out of plywood to assemble the speaker set. Each part has a name, width, height and depth, and when the part is rendered, it prints out (via the “echo” statement) the name and dimensions, so I get a automatically-generated “cut list” of parts to make.

For example, I have this code:

module base(x,y,z) { translate([x,y,z]) { part(“Base”, BaseW, BaseH, BaseD); } }

This defines a module “base” that will create the base of the speaker case, using the dimensions in the variables BaseW, BaseH, and BaseD. The x, y, z inputs to the module give the position where the base should be.

Later in my script, I call:


Which creates the base of the speaker set, positioned at the origin of my coordinate space. It also prints the output:

ECHO: “Base”, 14.375, 0.75, 4.75

Which gives me the dimensions I need to cut to make the base. (The print formatting abilities of the script language are minimal, but adequate for this purpose.)

Here is the first part of my final script – it gives you an idea of how I calculated the dimensions of parts:

// Case for HelderHiFi amplifier, power supply, and speakers. 2013-03-27,


slop = (1/16); // inches
PartAlpha = 0.5;


AmpH = 1.75;
AmpW = 2;
AmpD = 5;

SpeakerW = 4.5;
SpeakerH = 7.25;
SpeakerD = 4.5;

BatteryW = 3.5;
BatteryH = 2.75;
BatteryD = 4;

PowerW = 3.35;
PowerH = 2;
PowerD = 3.5;


Thick = 3/4; // for load-bearing base, top, supports
ShelfThick = 1/4;
StripThick = 1/8;

StripLip = 1/4;

TopW = 8.5;

PlateThick = StripThick;


BaseW = slop + SpeakerW + slop + Thick + slop + BatteryW + slop + Thick + slop + SpeakerW + slop;
BaseH = Thick;
BaseD = max(max(max(AmpD, SpeakerD), BatteryD), PowerD) – 2*StripThick;

The idea here is that I’m allowing a “slop” of 1/16th inch – this is extra space beyond what is strictly needed per the component dimensions, to allow something for clearance and imperfect cuts.

Then I have the dimensions of the parts that need to fit inside the speaker case, and then the thickness of the plywood stock (3/4, 1/4, 1/8″) I’m going to use for different parts. Finally, from those I calculate the dimensions of the base – the width of the base is the sum of all the parts it has to hold, plus two “Thick” dimensions (for the vertical pillars), and slop around each of the parts. The base depth is calculated as the maximum of all the parts it will have to support, less “2*StripThick”, subtracting for retaining strips on either side of the base, which will be used to prevent the speakers from sliding off the base while being carried.

You can download my whole script here if you want to see it – I’m certain others have made vastly more complex and impressive things with OpenSCAD, but this shows what can be done after just a few hours of work.

When I run the script with F5, I get the rendered model:

Speaker set model. Grey boxes are speakers (translucent), blue box is amplifier. (Note the top, plus 1/8" lip around the speakers, prevent speakers from falling out unless carefully lifted.)

Speaker set model. Grey boxes are speakers (translucent), blue box is amplifier. (Note the top, plus 1/8″ lip around the speakers, prevent speakers from falling out unless carefully lifted.)

And this output:

Parsing design (AST generation)…
Compiling design (CSG Tree generation)…
ECHO: “Base”, 14.375, 0.75, 4.75
ECHO: “Long strip”, 14.625, 1, 0.125
ECHO: “Long strip”, 14.625, 1, 0.125
ECHO: “Short strip”, 0.125, 1, 4.75
ECHO: “Short strip”, 0.125, 1, 4.75
ECHO: “Pillar (less subtraction)”, 0.75, 7.625, 5
ECHO: “Pillar remove”, 0.25, 0.125
ECHO: “Pillar remove”, 5.875, 0.125
ECHO: “Pillar (less subtraction)”, 0.75, 7.625, 5
ECHO: “Pillar remove”, 0.25, 0.125
ECHO: “Pillar remove”, 5.875, 0.125
ECHO: “Shelf1”, 3.625, 0.25, 4.75
ECHO: “Shelf2”, 3.625, 0.25, 4.875
ECHO: “Power strip”, 3.625, 0.5, 0.125
ECHO: “Plate”, 5.125, 5.625, 0.125
ECHO: “Top”, 8.5, 0.75, 5
ECHO: “Clearance for speakers above lip”, 0.125
Compilation finished.
Compiling design (CSG Products generation)…
PolySets in cache: 15
Polygons in cache: 90
CGAL Polyhedrons in cache: 0
Vertices in cache: 0
Compiling design (CSG Products normalization)…
Normalized CSG tree has 21 elements
CSG generation finished.
Total rendering time: 0 hours, 0 minutes, 0 seconds

As you can see from the last line, this simple project renders nearly instantly.

From the cut list, I was able to go to my wood shop and cut out all the parts, ready to assemble:

Speaker set parts, per the cut list

Speaker set parts, per the cut list


I quickly piled the pieces together to see if they really fit with the components…

Front view. (Amplifier will go on top shelf.)

Front view. (Amplifier will go on top shelf.)

Back view.

Back view.


…and they did! Perfect on the first try!


Here’s the case part way thru assembly:

Case partially assembled.

Case partially assembled.


And the finished product, painted and wired up:


Front view.

Front view.

Back view.

Back view.

It sounds good, too.

OpenSCAD is great stuff! (Part 1)

It all started with a pair of Radio Shack Optimus Pro 7 bookshelf loudspeakers I picked up on eBay for a song.

These little speakers sound fantastic for their size, and at one time you could get them new at Radio Shack really cheap – I’ve been using a pair of white Pro 7AVs (the magnetically-shielded version) since the mid-90s as my PC desktop speakers.

Pro 7AV speakers (photo courtesy of Wade's Audio and Tube)

Pro 7AV speakers (photo courtesy of Wade’s Audio and Tube)

One day I was procrastinating by surfing eBay, ran across a black pair that looked nice, put in a bid, and soon had them in my basement, waiting for a project to use them.

Then I noticed the existence of low-cost TriPath TA2020-based amplifiers like this very popular one from Lepai. These things get fantastic reviews – the TA2020 uses PWM amplification and its distortion sounds like tube (valve) amplifier distortion. And audiophiles have been paying outrageous prices for tube amplifiers ever since tubes went out of style. Yet these TA2020 amplifiers go for 20 bucks! (And, yes, I know putting “audiophile” and “outrageous prices” in the same sentence is a bit redundant, but I’m not getting into that now.)

You may have figured out by now that I just can’t resist cheap things that deliver ridiculous value – it’s a character flaw. So combine the cheap-but-great loudspeakers with the cheap-but-great amplifier, and I just had to do something with them.

I decided to make a set of portable Bluetooth speakers. I’ve bought a few different Bluetooth loudspeakers and they all sound terrible to my ears; even the way-overpriced Bose ones sound bad to me (and I’m too cheap to pay that much anyway). So I thought I’d make my own.

There’s a guy Arjen Helder in Shenzhen (arjenhelder_electronic on eBay) who makes very well-reviewed TA2020 amplifiers, and he has a model “TA2024 MKV Bluetooth” with the Bluetooth module already built in. So 20 pounds sterling later (“Approximately US $30.35”), I’ve got one of those and I’m ready to start.

Helder HiFi TA2024 MKV Bluetooth amplifier

Helder HiFi TA2024 MKV Bluetooth amplifier

I wanted my speaker set to be portable, so that means they need a battery, and I happened to have an old 12V 5AH AGM battery around. Since the amplifier runs on 12VDC, that seemed a good fit. And I had a spare Harbor Freight 12V charger too ($9.99; did I mention I’m cheap?), so I figured I’d use that to both charge the battery and power the amp while it’s plugged in.

12V 5AH SLA battery and $9.99 Harbor Freight charger. (Not quite to the same scale...)

12V 5AH SLA battery and $9.99 Harbor Freight charger. (Not quite to the same scale…)

(Yes, I’m going to get to OpenSCAD. Be patient!)

So now I had most of the bits and pieces, and needed to come up with a design for the speaker set. I wanted a handle (to make it more portable; the speakers and lead-acid battery are heavy) and a place to wind some extra speaker cable, so I could separate the speakers for better stereo. That meant the speakers had to be held in a way that allows removing them, yet at the same time I didn’t want them to fall out by accident while carrying the set by the handle.

So I started sketching on paper. Here’s one of the earlier sketches:

Sketch1OK, so I’m not a good artist.

But the important thing was to get the dimensions right. I wanted it to be compact, but have room for all the pieces. (BTW, I hate using inches and fractions as much as anyone, but I’m in the US and lumber here only comes in those dimensions, so I’m stuck with them.)

As I made each sketch, I realized there were opportunities for improvement (perfectionism is another of my character flaws), so first I’d scratch things out, then at some point I’d start a whole new sketch:


and another:


and another:



This was frustrating. Any little change cascaded all across the design, and it was easy to make a mistake in calculating dimensions.

So I decided to see if I could find some simple CAD program to help. I spent some time communing with Google, and decided that SketchUp (ex-Google SketchUp, now owned by Trimble) was the way to go.

I spent a few hours learning to use it, and made moderate progress getting my design into the program:

How far I got with SketchUp

How far I got with SketchUp

However, I found it very difficult to transfer the dimensions from my paper sketches into SketchUp; there didn’t seem to be any direct way to force SketchUp to size things exactly, or to position parts at particular offsets with respect to other parts. SketchUp, although it’s far simpler than most “serious” CAD programs, still has a long learning curve, and it didn’t seem very well suited to the kind of engineering drawings I was trying to do. I could easily get things close, but couldn’t get them exact (I suppose there must be a way to do it, but I didn’t figure it out).

After trying and getting stuck for a few hours, I went looking for a better solution.

And that’s when I found OpenSCAD.

[To be continued in Part 2…]

Motorola’s USB charging scheme

As I mentioned in the previous post, I have a Motorola Xyboard 8.2 Android tablet [1].

Motorola Xyboard 8.2 (Xoom 2 ME) Android tablet

Motorola Xyboard 8.2 (Xoom 2 ME) Android tablet

Among other things, I use it as a GPS (with live Google Maps) in the car – it’s a WiFi-only tablet, but I tether it to my phone via WiFi or Bluetooth, so the tablet can talk to Google in the car. This works great.

But after a day of driving, the tablet always runs out of power, even though I had it plugged into a car charger the whole time.

I tried a bunch of different car chargers, including ones rated for tablets and iPads, claiming to source anywhere up to 3.1 amps, but they all did the same thing.

Finally, I hooked up the USB charging port to some meters and an oscilloscope to see what is going on.

About USB charging

USB charging is an unreasonably complex subject. You can read lots about the details here and here and here (and of course here), but I’ll summarize:

  • Per the USB 2.0 spec, all USB devices can draw 100 mA (at 5v) without negotiation.
  • Also per the spec, USB devices can draw up to 500 mA (again at 5v) after negotiating with the USB host

In practice, lots of devices draw 500 mA without negotiating. They get away with it because most PC USB ports just supply 500 mA to all the ports, regardless of whether or not the device negotiates.

Smartphones usually want more, and tablets, much more. My Nexus 4 draws up to about 750 mA when charging. And the Xyboard tablet can draw up to 1.5 A. Most phones and tablets are smart enough to reduce the amount of current they draw if the USB port can’t supply what they want – the result is they charge slower. In the case of my Xyboard tablet, 500 mA isn’t enough to keep it from discharging – it just drains the battery slower. That’s why I run out of power after a day of driving.

It would be expensive for vendors to make a dumb charger that’s smart enough to do the USB power negotiation, and even if they did, 500 mA isn’t really enough. So they came up with their own schemes:

  • Apple has a complicated and slightly-secret scheme where on their dumb chargers they put resistors on the D+ and D- USB data lines. The effect of the resistors is to put different voltages on these lines, which indicate to the device how much current the charger can supply.
  • In 2007, the Chinese set a standard that if the D+ and D- lines are shorted together, that indicates that the charger can supply more than 500 mA (at least 1000 mA; often more).
  • In 2009, the EU set a standard almost identical to the Chinese one, except they say to put 200 ohms between D+ and D-. Happily, this is close enough to the Chinese standard that they work with each other.

So as of 2013 (as I write this), virtually all non-Apple high-current chargers do the Chinese thing and short D+ to D- to indicate their capability.

But the result of this mess is that Apple chargers can’t charge Android devices (very fast), and vice-versa.

What Motorola does

But that still doesn’t explain why I couldn’t charge the Xyboard (well enough to keep it from draining), even with a high-current Android-type car charger.

It turns out that, at least on the Xyboard 8.2/Xoom 2 ME (and possibly on other Motorola devices), they don’t follow either standard.

I started by looking at the various car chargers I’d been trying. Some were Apple type, some were Android type. I even put power resistors on the output and measured how much current they could supply without the voltage dropping – lots (2.6 to 3.1 amps, depending on which charger).

But none would charge the Xyboard at faster than 640 mA.

Motorola uses their own scheme. When you plug in the USB charging cable, it gradually loads the charger over a period of about 2 seconds. If you watch the voltage on an oscilloscope, you can see it gradually dropping as the tablet pulls more current.

If at the full current draw of about 1.5 amps the voltage drops below about 5.3 volts, then the tablet decides the charger can’t supply that much, and drops the charge rate to about 640 mA. (The threshold was somewhere between 5.28 and 5.33 volts when I tested.)

Since USB ports are supposed to supply 5 volts DC, +/- 5%, 5.3 volts is slightly more than the maximum 5.25 volts allowed. So any conformant USB charger will be interpreted by the tablet as “low current”, even if D+ is shorted to D-, and no matter how much current it can actually supply.

I’m guessing only Motorola’s own chargers supply 5.3+ volts.

It’s a shame that Motorola’s devices can’t charge from standard Android-type USB chargers. I have one of the Motorola car chargers on order; I hope that works.

And I hope this info is useful to somebody.

[1] I’ve tried 7″ and 10.1″ tablets, and I really think the 8.2″ size is the sweet spot, at least for me.

I like the Xyboard 8.2 – Motorola priced it way too high so it didn’t sell.

As it ought to be for the price they asked, it’s very well built (they claim it’s waterproof), and the ICS implementation is good (except for the minor Bluetooth problem I mentioned in my last post). It’s getting old now – if you can find one at a cheap price, it’s a nice unit.

But be aware that it’s orphaned – ICS is the last version of Android you can put on it; it sold so few units that there aren’t any custom ROMs available (although you can root it). It’s called the “Xoom 2 ME” outside of North America.