CentOS 7 and the Soekris net6501 - LED wrangling

Have you been looking for a way to handle the READY and ERROR lights on your net6501 without compiling a special program or building a kernel module?  If so, then this is the post for you.

Here are some shell commands to handle the READY and ERROR lights:

To turn the READY light on:

echo -ne "\01" | sudo dd of=/dev/port count=1 bs=1 seek=1693

or back off:

echo -ne "\00" | sudo dd of=/dev/port count=1 bs=1 seek=1693

To turn the ERROR light on:

echo -ne "\01" | sudo dd of=/dev/port count=1 bs=1 seek=1692

or back off:

echo -ne "\00" | sudo dd of=/dev/port count=1 bs=1 seek=1692

These scripts are just writing 0 or 1 to ports 0x69C or 0x69D (1692/1693 in decimal).

Advanced Pilot Guessing

I was recently pointed to an article by John Deakin about aircraft starts and run-ups at the following URL:

http://www.advancedpilot.com/articles.php?action=article&articleid=1844

I gave it a read, and now is my opportunity to complain about it.

Let me start by saying that I'm by no means the world's foremost expert, and these are just my uninformed opinions.  John Deakin's bio lists 39,000 flight hours, which I'm not going to be able to compete with.

I'm really more interested in the conversation than being right.  If I'm really lucky, someone will correct me and I'll learn something.

Moving on...

The article starts with a sentence saying that the article will "cover some new techniques with engine monitors."  The article then goes on to say, in short: "look at the engine monitor sometimes, maybe in the normalized mode, maybe not."  Not a good start.

He goes on to say that you should try to avoid blowing away other airplanes when you start up, and try to avoid excessive power.  It's hard to disagree with that.

He also goes on to recommend a technique that involves not changing the throttle between shutdown and startup.  While you may be able to do this in a fuel injected engine, it's not going to work very well in a carburated engine without a primer (or with only a primer that shouldn't be used for routine starts).  I think that's a pretty large demographic to give bad advice to.

The next part of the article extols the virtues of lean-of-peak operation on the ground, even through the run-up.  I'm not convinced that this is a good idea for all the same reasons doing it in flight - although worse due to the reduced airflow.  In fairness, he does recommend keeping the run-up short, but rushing through things may not be the best idea if you happen to have less than 39,000 hours under your belt.  I fail to see the advantage for light singles or twins, and I'm not convinced for bigger iron.  There is a distinct lack of measurements or documentation.

He mentions that his oil temperature monitor is located at the far end of the oil passages.  I've been told (but never confirmed) that oil temperatures are normally measured at the oil cooler exit.  Once again, he seems to give advice that will silently lead the typical GA pilot astray.

I cannot disagree with his advice to not ride the brakes, disturb the airport's neighbors, or blow away other aircraft while doing your run-up.

Speaking of run-ups, he is strongly against using the parking brake.  I find that to be a pretty common opinion, but I'm neutral.  For the aircraft that I have experience in, I recommend either whatever the manufacturer recommends or whatever makes you happy.  The important thing is this: keep one eye outside the aircraft.  Distracted feet are no better than leaky parking brakes.  Also, leaky parking brakes should be fixed, not worked around.  They are a hazard to people and property and shouldn't be ignored just because they aren't a flight control.

There a wive's tale in there about crosswind run-ups causing damaging prop imbalances.  I'll just say that the torque, P-factor, turbulence, and maximum power of every takeoff would seem to make these worries moot, although I have no empirical evidence.  I'm comfortable with that, since he doesn't either.

He recommends doing a run-up at "the traditional" 1700 RPM.  Every Cherokee I've been in says 2000 RPM in the manual.

If you are seriously worried about wearing out your prop by cycling it three times per the manufacturers instructions, then you need to sell your airplane before it kills you.

I see a high-time pilot turning anecdotes into advice contrary to the published opinions of the engineering teams at Lycoming and Continental.  Great pilots are not necessarily aeronautical engineers any more than the converse.  The extraordinary claims are going to require extraordinary evidence.

How to fix locked/corrupted database messages on a Garmin Aera 796

This can happen if you have a more than one 796.

It turns out that the offline/manual update program for the Garmin Aera 795/796 does not confirm which device is plugged in and will happily program a key into an incorrect device.

The unit is then unable to decrypt the database when it boots, resulting in "Unable to Unlock Database" and "TERPs corrupted" messages.

Also, the browser-based update plugin will stubbornly (and silently) refuse the recognize the device if you are not logged into the appropriate account for the unit that's connected.

Libvirt and MPLAB do not play nicely in Fedora 20 (and have not for some time)

There's been a conflict between the MPLAB development environment for Microchip PIC microcontrollers and the Fedora virtualization system for some time.

The basic issue is that you cannot start or view your virtual machines.  You've double-checked that your BIOS has virtualization enabled and that the appropriate kvm kernel module is loaded, but it stubbornly refuses.

The issue (for me, at least) was that the MPLAB IDE installed some libusb libraries that were causing a conflict.

Here are the files in question:

/lib/libusb-1.0.a
/lib/libusb-1.0.la
/lib/libusb-1.0.so.0.0.0

With these files in place, virtualization is not reliable.  If they are not there, MPLAB cannot see my PICKit programmer.

The obvious, if ugly, solution is to move them out of the /lib directory when I want to run a virtual machine and to move them back when I want to update firmware.  It's far from ideal, but it works just fine.

How to design a site that prevents users from creating weak passwords

I found the heart of this gem in the FAA's Advisory Circular AC 120-78 "Acceptance and Use of Electronic Signatures, Electronic Recordkeeping Systems, and Electronic Manuals" - at the top of page 8, specifically.

In short: don't permit any two users to have the same password.

My first thought upon reading that is that I'd have to store plaintext passwords for every user in order to accomplish it, but that was foolish of me.  It's easy to check for duplication in exactly the same way that a users password is checked against their username during a normal login - SALTed hashes pose no problem.

Whenever a user creates or changes a password, check it as the password for all other users, against all usernames, and against a dead password list.  If there's no match, they're golden.

If you do find a match, three things must happen:

1. The user doesn't get to use that password (obviously)
2. The other users with the matching password get flagged as having insecure passwords.  These passwords can be invalidated and an email sent with a code to change the password on the next login.
3. The bad password is added to the list of dead passwords.

Even with no other safeguards, this means that you'll have at most 1 user with any given bad password, which goes a large way to defeat dictionary attacks.  It has zero cost for users that create good passwords to begin with.  Bad passwords are removed from the system automatically, even as new patterns emerge.  The cost to implement it is minimal - it reuses existing techniques.  The dead password list can be initialized with common bad passwords in advance, prevent most people from picking poorly to begin with.

There's always some cost to having your users actually use good passwords.  Obviously, it would be easier for them if everyone just used "password123".  If you accept the effort of creating a password that is actually unique across your site as an acceptable requirement, then there's no reason not to use this system.

The best part is that there are no arbitrary limits on number or types of characters, which is a huge point of frustration for many.  In fact, choosing a password is no different than picking a unique username.

I just don't understand why I only see this languishing in this FAA document, of all places.

How to create a geodesic dome in Blender 2.6

I've made a number of attempts at modeling a geodesic sphere or dome in Blender, but it has always ended in disaster.  It turns out that geodesic domes are more formally known as Truncated Icosahedrons, and that these can be created by chopping up an icosahedron.

Blender can create an icosahedron by adding an Icosphere with Subdivisions=1.  You can then Subdivide it with 2 cuts to split each edge into thirds.  Finally, dissolve the excess vertices and you are left with a geodesic sphere, and well on your way to that dome, soccer ball, Buckminsterfullerene, etc.

In more detail, for Blender 2.6:

1. Shift-A | Mesh | Icosphere
2. In the lower left, under Add Ico Sphere, set Subdivisions to 1.
3. TAB for edit mode
4. Mesh | Edges | Subdivide
5. In the lower left, under Subdivide, set Number of Cuts to 2.
6. Create the hexagons:
1. Select the vertex in the center of any large, flat triangle.
2. X | Dissolve Vertices
3. Repeat for every large, flat triangle.
7. Create the pentagons:
1. Select the vertex at each of the points.
2. X | Dissolve Vertices
3. Repeat for every point.