Silicon Valley Redneck

At last...

I'd long been wondering when Grant would get around to this one:

On the latest Mythbusters - the JATO-car "This time for sure!", which deviates ever further from the original yarn, while retaining the Impala - he's finally hooked up a computer-game steering wheel and pedals to the RC box, to allow driving the 1:1-scale RC car like a car.

There's still the matter of having a totally separate radio-command system for firing the rockets, but I'm guessing that's a COTS secure system made for HPR or possibly blasting.

Oh, and on the Science! front?  They keep bandying about a conversion factor for thrust to horsepower.  There's no such thing.  The units are non-equivalent.  Thrust is force (pounds, Newtons, dynes: mass times acceleration, e.g., kg*m/s^2); power is force times distance per unit time (horsepower, Watts, BTU/hour, e.g.: kg*m^2/s^3).  Yeah, you could assign a rocket a horsepower rating based on fuel consumption or (almost equivalently) heat output, but that ain't how horsepower ratings work (though if you used BTU/hour instead, it would make sense: treat the rocket as a heater).

And in the department of I could'a told you that: if you're going for maximum range with your rocket car, and you're not giving it fins like a Cadillac (nor RCS, nor engine gimballing, nor active aerodynamic control surfaces, nor any other way of keeping it pointed straight), best results will be obtained by timing Brennschluß for just before the car leaves the ramp.  Not a couple of seconds later.  If memory serves, they'd already seen the nose-comes-down-leaving-the-ramp effect (because Gravity, duh) in at least one earlier episode (possibly involving an old TV show about hazardous ducks or something), so it should be no surprise that the thrust vector, immediately post-ramp, would be Highly Suboptimal.

Another thing for the "not this year" list

The Google I/O conference thingie does sound interesting, and I've got an idea in the queue that ties in with Android and optionally Google Glass....

...But, with the $900 price of admission (for that, I could buy half a 3D printer!) and the competition even to get a ticket, and the idea in question being one of this year's Summer Gadgets, to be built after I've got some code running on its predecessor from last year so's I can at least check out the hardware design properly, I think getting connected with the developer community is a Maybe Next Year thing.  Anyway, I'm sure there's some cheaper and lower-key way to meet Android/Google developer types, once things get closer to readiness.

No, I'm not being at all specific about the nature of the Gadget, 'cause if the idea got loose some young whippersnapper with time on his hands and a little spare cash could implement it in a couple of months.

Why manufacturers need datalogging capability

Found via Slashdot: Tesla rebuts NYT article on Model S range.  With detailed data.

I've worked on various projects in the past where having some amount of datalogging built into the product would have helped greatly with diagnosing problems, whether inherent in the product or caused by customer misbehavior.

The last few embedded controllers I've designed have had somewhat minimal event logging: basically, storage for a few hundred abnormal events, with minimal detail, plus cumulative statistics.

One of the current projects is an expansion of this, to storing hundreds of thousands of events, with greatly increased detail - basically, attempting to cover the entire working life of the product (which is likely to be many years).

This capability is somewhat constrained by the need to operate over an extended temperature range, and tolerate severe vibration, etc., so just using an SD card for storage isn't a realistic option.  Fortunately, there are now I-temp SPI flash chips of decent capacity available, with rumors of automotive-spec parts in the foreseeable future.

There was a suggestion of including voice recording, to capture the last few seconds of audio before a major fault - "Dmitri!  Hold my vodka and watch this!" - but doing that in any useful way would have been too much trouble, for basically a joke capability.  (Anyway, the board gets conformal coated, which wouldn't do the microphone any good.)

Awww... another idea taken.

A few weeks ago, I was pondering 3D printing, and contemplating mildly exotic materials.  Such materials not being available off the shelf at all, let alone in the form of 1.75mm diameter filament, I had the notion that a home filament extruder might be a good thing to build... and that it could become a product, as others might want to play with materials, create custom colors from stock material, recycle old ABS scrap, and so on.

Well, it seems someone else had the same idea: Filabot.  Mainly for recycling, it seems, but it ought to digest bits of custom-blended plastics, no?

And the price seems reasonable.  Not that I have a 3D printer yet, so I don't actually have any use for a Filabot at this point, but, once the need arises, it's kinda nice to know that the gadget exists, even if it's not me selling it.

Another bit of Awesome Tech doesn't do what I want

So, as I'm idly reading this item, I come across a link to this.

Atomic batteries!  K3wl!  Um... you'd never power a Batmobile with those things, but, in the wonderful field of Extreme Toasting, this may solve a problem that keeps threatening to come up.

But, dang!  Them's only rated -40 to +80°C, not even full I-temp.  And... external pressure, only to 33K feet above sea level?  OK, so that covers Everest, but suppose someone wants to use one of these toasters aboard a high-altitude balloon?

And, given the output power and the half-life, I'm not really seeing much use for them, at least given the environmental ratings shown.  Maybe extreme editions are available on special order?

(If memory serves, Tadiran makes a full-mil-spec lithium primary cell, which I may end up using in connection with an upcoming toaster accessory.  Ah, here we go: TLH series.  Maybe not designed to be shot out of cannons, but at least they meet the temperature-range requirements.)

 

Hmmm, more potentially useful free software!

Being as how I have need of sundry forms of CAD software from time to time, and what with Linux being my preferred environment, I've long taken an interest in What's Out There.

Back in the 90s, I took a look at this nifty thing called Open CASCADE, which on closer examination turned out to be the core of a high-powered 3-D mechanical CAD system... minus any sort of user interface.

And there was BRL-CAD, which had some interesting capabilities but was kind of specialized.

And so, these past several years, I've been using VariCAD, which, while right around the top of my price range, has proven useful... but it has limitations of its own: it lacks scriptability, and the only 3-D format it will import is STEP, which is hideously complicated (and getting access to the spec costs money).

Meanwhile, I've occasionally vaguely noted the existence of something or other that puts a GUI wrapper around Open CASCADE.

Well... just recently, I took another look at FreeCAD, which someone was using to build 3-D models of EAGLE PCB designs.  Hoo-hah!  Looks decently usable, imports and exports quite a variety of file formats, and is scriptable.

Naturally, I promptly try things VariCAD isn't good at, and run into limitations.  Like, it will happily import an airfoil data file, and extrude the resulting curve into a wing... but I don't find any way to do a tapered extrusion, let alone an extrusion tapering from one shape at the root to another at the tip.

But!  Looks like someone's got a Blender plugin that'll (if I can figure out how Blender plugins work) import X-Plane files, after which Blender can export wings (or entire planes) to one of the formats it shares with FreeCAD.

Not that migrating plane models into CAD is really a priority at the moment, but it's nice to have the path available.

Having the EAGLE-to-mechanical-CAD path is of more immediate interest, especially once I build up a library of 3-D models of, e.g., connectors.

Alarming new discovery!

It's possible to make U-233 from thorium!

Uh, guys?  I found that bit of enlightenment in the open literature quite some time ago.

Like, when I was a senior in high school.

And we walked fifty stadia to school every morning, keeping watch for saber-toothed tigers.  That's how long ago it was!

Well, that's annoying (LPC13xx edition)

That little radio board I was showing off a while back?

Just built up two more of 'em, taking a little more care when soldering the teeny-tiny EMI filters.

Also, I substituted LPC1317 chips for the original LPC1313, 'cause the 1317 has EEPROM, which should prove useful for storing things like network addresses.

Other advertised features of the 1317 as opposed to the 1313: 12-bit ADC instead of 10-bit, and more flash.

Well!

I copied my 1313-tinker project to 1317-tinker; updated the MCU type; launched the debugger....

The clock control has changed.  After some digging, I discover that there's no longer a SYSPLLCLKUEN register, so writing to it and waiting for the LSB to go high Does Not Work.

OK, so I take that part out of the CMSIS init code, and run again.  Do I get the nice twinkly sequence on my LEDs?

I do not.

Instead, I get a trap.  Seems my GPIO initialization isn't working.  Eh???

Oh.  The GPIO on the 12-bit ADC models is wildly different from that on the 10-bit ADC models.

And, there don't appear to be sample projects for the newer line.

Grumblegrumble....

Oops.  And pins 19 and 20 are now no-connects on the non-USB parts.  At least I wasn't using those for anything vital.  All the other pins seem to be in the right places.  But... I'll need to re-do (or at least re-define) everything relating to GPIO and pin assignments.

Redundancy

Still kinda under the weather, between What's Going Around and the change of seasons, and spending unproductive time skimming through the Air Crash Investigation stuff.

Coupla examples of planes that crashed due to a blocked pitot tube, or taped-over static ports.  (Taped over with plane-colored tape?  Couldn't the plane-washing crew use fluorescent orange masking tape?)

And, yeah, those were several years ago.  More recently, though: Air France 447 (airspeed sensor problem, followed by the pilot doing a Ben-Bernank at the controls), and that oh-so-modern stealth bomber that crashed due to an airspeed sensor problem.  So the problem hasn't been fixed.

And yet: all the newfangled planes have GPS... which will happily provide you with pretty darn accurate readings for altitude and ground speed.  Given even a vague notion of current wind, the computers can do a sanity check on the airspeed indicator, and coming up with the actual altitude (within several feet) should be a no-brainer.

True, knowing ground speed won't keep you out of coffin corner... but if you're high enough to be worrying about that, and you don't have an accurate airspeed indication, why not just be conservative about speed and angle of attack, and live with the loss of altitude for the nonce?

(For that matter: if you know weight, angle of attack, and sink rate, surely it's possible to calculate indicated airspeed, right?)

And, of course, if your pitot tube is blocked at takeoff, the computers bloody well ought to notice that indicated airspeed isn't keeping up with ground speed while you're still on the runway, and give a great big "critical flight instrument malfunction" warning while there's still time to abort the takeoff.

Update: hoo boy!  Consider, further, Turkish Airlines Flight 1951.  Pressure altimeter, GPS, and right-seat radar altimeter agree (taking local terrain into consideration): plane is about 2000 feet AGL.  Left-seat radar altimeter claims 8 feet BGL.  Stupid robot under the hood decides the plane is about to touch the runway, or has already landed, or perhaps is underground, and that in any case it's time to cut power, regardless of the pilot's opinions on the matter.  One of several instruments gives a wrong reading, and it has the deciding vote.  Brilliant!

Physics department? Really?

OK, so I saw the story on Slashdot this morning, thought it silly, and just now got around to clicking through to TFA.

So: a great innovation in wirelessly charging electric cars involves using grid power to spin a magnet in the garage floor, which spins a magnet in the car, which runs the generator that charges the battery.

Unwrapping this, we have:

Grid power to floor stator creates rotating magnetic field.

Rotating magnetic field acts on rotor to turn a shaft.

Shaft rotates floor magnet to create a rotating magnetic field.

Rotating magnetic field acts on car magnet to turn a shaft.

Shaft turns generator rotor to create a rotating magnetic field.

Rotating magnetic field interacts with car stator to produce electricity to charge the battery.

Um.

The way I see it, everything between the first and last rotating magnetic fields is extraneous, and adds weight and failure points.

Also, with that nice big on-board magnet, your car will pick up any ferrous debris you happen to drive over.  (Which is maybe OK if your other car is a Harley, and you can use the spare parts.)

And: frequency 100 times lower than what's used now?  I assume this is compared to competing inductive charging schemes and not, say, 60Hz grid power.

And this comes from a physics department?