Silicon Valley Redneck

Paniiiic!

Need an HDMI cable.

Recall having one around here somewhere.

Dig around: nope.

Wait, see if it's plugged into the back of the office monitor: yup.

Unplug it, and try to pull it free of the computer kennel: nope, not comin' outta there.

Workstation is due for a software update that looks like it'll call for a reboot.  So:

Do the apt-get upgrade, and shut the workstation down.

Pull the workstation out, look behind it, and eventually find the other end of that HDMI cable.

Which has a DVI connector on it.  Which (a) explains why it was so hard to pull through the cable clump, and (b) isn't exactly what I was looking for, but maybe will do.

So, pull the cable through the other way, and put everything back together.

Reboot the workstation.

Text display during bootup has colored sparklies.

DVI connection to back of workstation wasn't properly secured.  With the jackscrews tightened, the sparklies go away.

Kdm thinks it starts up, but there's no X display.

Startx gives an error log that seems to say that it can't find a connected monitor.

OK, so re-configure the DVI cabling so the workstation's output goes directly to the monitor, bypassing the DVI switch (which isn't currently used anyway, what with the second workstation being retired).

Still doesn't work.

Boot the previous kernel: nope.

Fiddle around some more: still no soap.

About ready to panic here... has my software configuration gotten horribly broken?  On the last day of the month, when I ought to be doing Accounts Receivable this evening?  Will I have to use my laptop until I can get this sorted out?

Maybe if I boot some runs-from-CD distro...?  Pop the April edition of Kubuntu into the drive, and tell the BIOS to boot from it.

Meanwhile...

Hey, wait.  Could unplugging the HDMI cable have...

Once more unto the breach 'twixt desk and wall, narrow and cable-beclutter'd though it be.

Ah.  I hadn't tightened the jackscrews on the DVI connection to the monitor, a couple of years back.  When I unplugged the HDMI cable, I must have jostled it.

OK, tighten the jackscrews, reset the workstation in midKubuntuboot, and boot normally.

Well, looky here: kdm starts, and the X display comes up as normal.

And what I needed the HDMI cable for?  Maybe I'll get to that tomorrow.  Trying to diagnose some hardware that shouldn't need it, but maybe does.

Enough stress for now.  Time for some mindless entertainment, assuming the living-room infosystems are still in working order.

The new Five Year Plan!

Because inventing a whole new battery technology that has five times the performance at one-fifth the cost is a simple matter of throwing money at it.

And, while we're at it, why is anyone still building rockets?  Why isn't NASA funding a crash program to develop the Bergenholm generator?

Whattya mean, "because there's no reason to believe it's physically possible"?  What kind of excuse is that?

Improve, presumably, energy density by a factor of five.  Let's see... I don't have the number at my fingertips these days, but for a primary cell there's not much room for improvement on yer basic lithium coin cell.  I recall doing the math on that one 'bout twenty year back, when working on a project to develop a small electronic gadget that would operate for a decade without anyone having to be aware that it had a battery (and using 1993 technology).  Once we ruled out hydrazine-air fuel cells and RTGs, it looked like we were stuck with lithium as a safe-ish, self-contained energy store.

Assuming that the intended new battery tech uses chemical energy storage, just how dense can that get, anyway?  Another fun calculation, regarding single-use chemical energy storage devices:

AA alkaline cell, around 3AH * 1.5V * 3600 sec/hr = 16.2kJ.

.223 cartridge, 0.5 * 0.00356kg * (990 m/s)^2 = 1.74kJ.

Hey, look!  Those checkout-line batteries have better energy density than smokeless gunpowder!*

So what sort of chemicals are the new batteries to use?

Or will they use some other method of storing energy?  Warp the space-time continuum?  Spin up tiny black holes?  Force nuclear reactions to run uphill?

Is there any reason to believe any of this is possible?

Or is this just a new way of scamming funding, and anyone who questions it will be declared "anti-science" and "anti-environment"?

*Yes, this does mean that electrically-powered sidearms aren't obviously implausible; there's just the small matter of getting the energy out of the battery and into the projectile fast.

Not posting much lately, am I?

Got a largish topic in the queue, for some day when I have time, energy, and motivation, but....

Busy with work (various), family stuff (ditto), holiday-related disruptions (just when ya get done with one dang holiday, there's another one to prepare for), and seasonal crud (brought on by dry indoor air and early sunsets; even with the full-spectrum light on over my desk, I can tell that it's night out there).

And I failed to have a camera along last week when I encountered the Young Venison Stuffed With Bay Nuts (or at least stuffing itself with bay nuts), so no cute photo to post.  No photos of the Dread Guardians of Farm and Forest, either.  (The Dread Guardian of the Forest seems to be having trouble learning its line; it's good at striking a defiant pose astride the trail, but then instead of saying "None shall pass" it says "mew?", which is not at all a proper thing for a Dread Guardian to be saying.)

Miscalibrated

Here in the U.S. of A., it's Thanksgiving.

So why am I humming this?

Wrong funny hats; altogether the wrong set of pilgrims....

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.

Oh, noes! No more Hostess Twinkies?

Better stock up, quick!

Luckily, the shelf life is pretty well infinite.

They should make fine post-apocalyptic trade goods.

(Low-fat Twinkies, however, are An Abomination Unto Nuggan, or at least Unto the Goddess.  This was experimentally confirmed several years ago when someone tossed a low-fat Twinky* onto a fire as an offering, and it wasn't accepted.  Just sat there amid the flames, and eventually started leaking a bit.)

*That is the correct singular of Twinkies, right?

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!

Commercial software. Ugh.

Well, learning LabVIEW has been on my gotta-do list for some time now, but I've been putting off the evil day by doing all my cute-GUI test-automation stuff in Ruby instead.  I understand Ruby.  It doesn't have a weird draw-a-picture-and-guess-what-it-means interface.

However... just started negotiating a likely Deal that (a) could develop into a long-term arrangement, and (b) pretty much requires using LabVIEW, in order to fit in with the client's existing automation.

So, something to learn during the rainy season, and I can probably use an evaluation copy for the purpose.

So, what's LabVIEW cost for real?

Yipe!  $1K for the base version, which is Windows-only (the client is Windows-only, but I don't keep much in the way of Windows around here).  For the full version that can run on Linux... starts at $2700.  And for the development environment that'll compile your application to a .exe for distribution?  Neighborhood of $5K.  Or so.

Oh, and if you actually want to do useful stuff, like communicate with other applications?  $$$KA-CHING$$$

Ruby, meanwhile, costs $0 for the development license and $0 for the runtime license, and is nicely cross-platform.  And I can tell what it's going to do, 'cause I'm writing real code in a real language.

Oh, well: if I gotta have a LabVIEW development environment, I gotta price it into the business somehow.  (Or, conventionally, come up with the business capital to buy the software up front, and trust that it'll help bring in enough additional business to cover the bill.)

Relatedly, I was thumbing through a catalog a few weeks back and happened across the pricing for µC/OS (which I assume is pronounced "mucus").  I'd had a vague notion it was pricey, given that the company was handing out free copies of the big heavy printed-on-paper manuals at a trade show not so long ago, but... really?  Looks like the pricing strategy is "figure what it would cost to have Gumby develop it from scratch at his full consulting rate, and charge half that much for a single-product license."

Open relay spamademic!

These past few months, I've been getting an awful lot of bounce or delay messages, from unfamiliar hosts around the world, informing me of difficulty in delivering mail ostensibly from one or another of my addresses to, typically, one of the big free-email services.

I've been unsure whether these were actual bounces of spam on which my return address had been forged, or intentional reflectospam meant to be delivered to me disguised as bounce messages.

Either way, there must be a lot of misconfigured mail severs out there.

Well, lately my server log has been showing a lot of these:

2012-11-15 07:59:55 login_courier_authdaemon authenticator failed for ([192.168.2.33]) [213.153.47.1]: 535 Incorrect authentication data (set_id=cox)
2012-11-15 07:59:56 login_courier_authdaemon authenticator failed for ([192.168.2.33]) [213.153.47.1]: 535 Incorrect authentication data (set_id=cox)
2012-11-15 07:59:56 login_courier_authdaemon authenticator failed for ([192.168.2.33]) [213.153.47.1]: 535 Incorrect authentication data (set_id=cox)
2012-11-15 07:59:56 login_courier_authdaemon authenticator failed for ([192.168.2.33]) [213.153.47.1]: 535 Incorrect authentication data (set_id=cox)
2012-11-15 07:59:57 login_courier_authdaemon authenticator failed for ([192.168.2.33]) [213.153.47.1]: 535 Incorrect authentication data (set_id=cox)

and

2012-11-15 08:27:10 login_courier_authdaemon authenticator failed for 173-162-251-81-newengland.hfc.comcastbusiness.net ([192.168.2.33]) [173.162.251.81]: 535 Incorrect authentication data (set_id=dennis)
2012-11-15 08:27:10 login_courier_authdaemon authenticator failed for 173-162-251-81-newengland.hfc.comcastbusiness.net ([192.168.2.33]) [173.162.251.81]: 535 Incorrect authentication data (set_id=dennis)
2012-11-15 08:27:10 login_courier_authdaemon authenticator failed for 173-162-251-81-newengland.hfc.comcastbusiness.net ([192.168.2.33]) [173.162.251.81]: 535 Incorrect authentication data (set_id=dennis)
2012-11-15 08:27:11 login_courier_authdaemon authenticator failed for 173-162-251-81-newengland.hfc.comcastbusiness.net ([192.168.2.33]) [173.162.251.81]: 535 Incorrect authentication data (set_id=dennis)
2012-11-15 08:27:11 login_courier_authdaemon authenticator failed for 173-162-251-81-newengland.hfc.comcastbusiness.net ([192.168.2.33]) [173.162.251.81]: 535 Incorrect authentication data (set_id=dennis)

So: a zombie horde is knocking on my mail server in search of an open relay, and using a different zombie machine each time to get around fail2ban and such.

Must be some new botnet I hadn't seen mentioned anywhere.

Pessimal manning, optimistic design...

Been watching some episodes of Mayday / Air Crash Investigation on YouTube.

Seeing some really stupid stuff.

Like: air traffic control centers - more than one - with just exactly enough staff to handle normal traffic, under normal conditions, properly... assuming no one ever takes a potty break.  Any complications, and they're overloaded.

And: air traffic control centers with inadequate redundancy in radar and communication systems, so preventive maintenance means taking critical functions offline.

And then there's the lack of redundancy in aircraft systems.  We've all heard the propaganda about how totally redundant everything is, and how critical electronic systems are supposed to be not only triply redundant but from multiple vendors so that a shared design flaw won't take out all three systems, and, and....

Well, having worked for a while in the telco-electronics space, and having seen the standards for redundancy in big-name central offices, where even a momentary disruption of message traffic is considered completely unacceptable, I tend to freak out when looking at how airplanes are wired.

A few years ago, I read the tale of an early 50s jet fighter lost in the dark with no radio and only minimal (vacuum-powered, no electricity needed) instruments after a single short circuit took out the entire electrical system.

Then I happened to look at the wiring diagram for a popular modern light plane.  No redundancy!  One short, or one loose wire, and you lose your radio and all electrically-powered instruments.

But surely airliners...?

Nope.

Thoroughly modern airliner lost after a fire in a single electronics compartment (shared between critical systems and entertainment systems) knocks out all the instruments.  OK, so the fire was another factor in the crash, but losing all the fancy flight electronics on an airliner because of a single, localized fire?

And: slightly less modern airliner runs out of gas.  Engines stop turning.  Cabin lights go out: fine.  Navigation and communication go out: WTF?  You mean there's no battery backup for nav & comm?  Probably no backup for the powered actuators, either (which take a darn sight more power than the electronics)?  Not even a RAT?

Yikes.

Update: yet more instances of electricity and hydraulic pressure being lost because the engines stop.  A thought: why the smeg can't the APU be started in flight?  And, perhaps, be provided with its own little reserve fuel tank good for maybe half an hour?