Build your own computer-stabilized flying UAV/RPV drone platform

What distinguishes a radio-controlled  aircraft from an Unmanned Aerial Vehicle (or “drone”) is the presence of an on-board computer (the Auto-Pilot Module, or APM) capable of flying the vehicle with or without direct control of a person.

Before adding platform sensors (video/stil cameras, ultransonic sensors,  etc)

With Telemetry, but before adding platform sensors (video/still cameras, ultrasonic range-finders, etc)

I’ve been following and building autopilot systems since 2009, and they have come a long way!   With the new multi-copter kits in their store,  3D Robotics makes this drone technology really accessible.    Chris Anderson (founder of DIYDrones, CEO of 3D Robotics, and former Editor in Chief of Wired Magazine) has turned his focus to “amateur” drone development, and the effort really shows.

Since our government essentially allows no commercial use of UAV’s in the National Air Space (NAS), the only “approved” uses are for personal and non-commercial applications (hopefully this will change in the next few years).   Since I work with emergency service groups,  my application areas of interest are wildfires, flooding, and search & rescue.   In other countries, UAV’s are involved with a wide range of creative uses, including food & supply deliveries or delivering papers.

One of the amazing things about the DIYDrones projects is that the hardware & software is “open source“.  This means that all the circuit boards, diagrams, layouts, and programs are available to anyone in a form such that they can be copied and/or modified freely.   The usual caveat is that if you modify anything and use it for commercial purposes, those changes must be made available to anyone who asks.   All the resources are just a “google” away; even the development environments & tools used to make the software are open-source (how’s that for “bootstrapping“?).

Note: The main purpose of this post is to pull together disparate links & references into a linear form that can be easily followed (along with my experiences).  This is not a complete step-by-step tutorial; researching the embedded links and documents should fill in most of the gaps.

The hexacopter kit (one of several Arducopter products) provides a stable platform for flying a wide variety of sensors, telemetry, and imaging devices.  The basic auto-pilot module (APM 2.5+) combines GPS (position), magnetometer (directionality),  inertial measurement units (stability, position),  barometric pressure (altitude), and power sensors (an amazing amount of functionality for the price).  I chose the hexacopter over the quadcopter simply for additional payload capacity.

The basic components are the flying platform (‘copter, plane), ground control station (GC or GCS), and radio interfaces (control & telemetry).   A fun way to get an overview of how everything goes together (and what NOT to-do) is to read through the DIYDrones blog posts;  it took me a few days.    It’s a good way to spend your time while your waiting for your parts to arrive 😉


Hexacopter parts

With that said, let’s dive in-to what the raw costs are to build a hexacopter with video downlink, telemetry, auto take-off & landing sensor, ground station, batteries, charger, and radio:

Basic Parts Only (shipping & taxes not included):
$570  – Hexacopter basic parts, ublox GPS & APM 2.5+ 850KV motors and 10×4.7 props.
$425  – Spektrum DX7s/DX8 with receiver
$100  – (2) Spare Motors, (2) motor shells, (2) spare ESCs, (3) additional sets of props
$20   – Receiver => APM cabling
$1000 – Laptop ground station/mission planner (estimated)
$170  – Copy of windows 7 (retail) to run on laptop (if not included w/laptop)
$125  – LiPoly Charger & battery(s)

Optional Parts:
$40   – Ultrasonic ground sensor
$100  – Telemetry & APM cable
$270  – Hi-res video camera (not hi-def), lenses + Roll/Tilt mount & servos
$250  – Video (downlink) transmitter, receivers, and patch antenna
$200  – Diversity Receiver
$90   – Readymaderc(.com) pan/tilt antenna tracker
$350  – Video Goggles

Of course, your mileage may vary (YMMV) if you have some of these parts on-hand, or can acquire them used.

If you’re still with me, let’s look around the ‘verse to start building a vocabulary.   Starting with the Newbie’s guide to UAV’s to get a quick grasp of what’s this stuff all about.   Then be sure to read the DIYDrones site rules to know what’s expected of you.  Another quick overview page can be found here as well as here.

On the kit purchase page (hexacopter), you’ll find links to the assembly instructions and other places of interest (forum, development wiki, etc).   Another site that I found useful for assembly instructions is

As I mentioned above, you might consider ordering a couple of extra motors and a set of propellers.  These are the things most likely to be damaged in an “excursion”.  Motor shells are also handy to have around since they are an integral part of the propeller shaft.

Be sure to visit the “get it” page, which has useful purchase information along with links to radio gear, batteries, chargers, etc.   Being an electric r/c enthusiast, there’s a lot of assumed, but unmentioned familiarity with the technologies.  For example, care & feeding of Lithium-Polymer batteries/chargers (lots of great fire videos on-line; Boeing was recently bit by problems in their 787 using similar batteries), 2.4Ghz radios, ESCs, motors, etc.    A great site for lots of background & info is  I have several of his books covering traditional helicopter set-up and maintenance (BTW, this same APM hardware can be used to run traditional helicopters too – check this out).

When you place your order, be sure to also buy male-male 10cm servo lead wires to connect your receiver to the APM.  I found a good place on ebay (10 for $11, free shipping from USA).

Once your kit arrives, be sure to check your parts; the metric bolts (especially nylon) can be hard to find locally, so be sure you have them all.    The folks at DIYDrones support have been very helpful.   Also, before you install the power distribution board in the frame, it’s much easier to install the battery straps first (trust me ;-).

Before hooking up ESCs

Before hooking up ESCs

As you’re building the frame (and after putting the connectors on the ESC’s), it’s a good idea to check your ESC’s and motors before you mount them (and after).  I had a couple of motors that I felt were too bad to fly for either vibration or bearing noise issues.   Power them up using a servo tester, or with your receiver & transmitter.   After mounting the motors, test them again for vibration & noise. Before strapping your ESC’s in, it’s a good idea to get the motor rotation correct.  Remember, different propellers are needed for different motor rotations (so they all ‘blow’ down).  Just exchange any two of the three motor wires to reverse motor direction.

Important:  Wherever you have metal-to-metal bolt/nut connections, be sure to use some form of thread-locker to keep them from vibrating loose (struts, motors, ..).  I use “blue” Locktite 242.  Nothing quite makes your day like watching a motor fly off on its own (along with the subsequent vehicle “excursion”).   Likewise be sure your propellers are always secure.


Now that your frame is complete, let’s move into the “quick start guide“.  In step one, download and install the ground station/mission planner software.  The ground station software is also used to load your APM with the current firmware (assuming an Internet connection).  NOTE: You cannot use the USB connection and have the telemetry module connected at the same time; they share the same interface, so unplug the telemetry module, if installed.  For me, it took several attempts at uploading the firmware before it loaded and verified successfully (YMMV).  After uploading new firmware, it’s recommended going into the command line interpreter, issuing the “setup” command, then typing the commands: “flash”, and “reset”; this flushes out any old/stale parameter settings.

A good site for instructions on hooking up your APM power module is here.  This will enable your telemetry module to relay battery voltage to the ground station.

Since you’ve already built the frame (step 2), move on-to step 3, and connect your receiver to the APM 2.   Referencing your frame assembly instructions,  mark the motor booms as 1-6 indicated in the instructions, and connect the 6-pin connector from the power module to the 1-6 outputs of the APM.   Since the APM and power module share ground & power, only a single wire/ESC is needed to be connected to the APM.  DO NOT put propellers on at this time!

Continue to follow the quick-start steps 4-7, up to the point of flying.   I had to reverse several controls on my transmitter to match what the APM needed (how you do this will vary with transmitter type).

When I attempted auto-calibration of the ESCs, there was one that just kept beeping, and wouldn’t calibrate. So I lowered my throttle trim by “6 clicks”; then when I recalibrated, all went smoothly.   Apparently all the speed controllers are not created equal, and are subject to temperature tantrums (since they are not crystal-stabilized).  Here’s a link to the ESC manual.    There are better motor controllers out there, some of which are crystal-stabilized (temperature invariant), and with faster-response firmware (A.K.A Simon K) for similar prices.  Not using crystal-stabilized speed controllers means you’ll need to re-calibrate the ESCs when the temperature changes “too-much” (whatever that means to your ESCs).   Check out this site as-well for more information on the Simon K firmware & flashing).

Adding telemetry is covered here.  The clear plastic sheath which comes with the transmitter and receiver boards is heat-shrink.   Just be careful when soldering the right-angle pins on the ground-station side circuit board, and then also when connecting the 6-pin connector.    How-to set-up your ultrasonic range-finder  can be found here; for automatic take-off, landings & terrain following.

Flyable configuration

Flyable configuration before adding telemetry

Notice the vibration dampening foam under the GPS and APM module.  These units are sensitive and should be cushioned.   To minimize vibration, also balance your propellers! Testing your motors/direction (and other things) can be done through the command line interface, as discussed here.  The motor-test firmware I was using (2.9.1) didn’t behave the way as described; the firmware just spun each motor (1-6 in-order) for a second, so that direction and placement could be verified.

Note:  When reconfiguring the APM, shifting it, changing padding, etc, the accelerometers must be recalibrated!  Click on “configuration tab” in the mission planner (with USB cable connected interfaced to the APM), and on the left side, select “arducopter level”, then press “Calibrate Accel” & follow the directions.

The basic platform (no telemetry or sensors) weighs in at 3.4 pounds with a 3S-2200mAh battery.   This battery yields 4 minutes of flight time on the hexacopter, while the same battery allows 8 minutes of flight-time on my TREX-450.   A 3S-4000mAh battery lets me fly for 8 minutes; with lots of lifting power for larger battery packs (over two pounds).

The platform flies amazingly well.  My DX7 receiver has a 3-position flight mode switch, which I programmed during set-up for “stabilized flight”, “loiter”, and “return to landing location”.   I have yet to add more flight modes by using another channel switch (giving 6 modes).    It’s fun & easy to just push the platform around in stabilized mode;  it’s responsive and VERY stable.    Clicking over to loiter, the craft just hangs in the air, no hands on the controls are needed. The APM has lots of features, including data logging (as does the ground station) to help you figure out what happened when things go wrong.   I may cover this in a future post, but for the moment, I leave it as an exercise for the reader.

Check the forums or tech support pages for help; lots of questions can be answered from there.

As always, safety first; this baby is a flying Cuisinart(tm) so be careful (no bench testing with propellers)!   I also recommend joining the AMA, if you haven’t already; they lobby our government for personal/private use in the NAS.   They also have published, government approved, guidelines for flying these platforms.  Another organization lobbying for commercial use of UAV’s is the AUVSI.  They have chapters and events around the country.   Finally, I can’t end without a plug for the ARRL and amateur radio.  As you investigate radio & video systems, many come with the caveat that you must have an amateur radio license for legal operation.   This is due to the power output of some of these systems; they exceed FCC license-free use.  The ARRL is constantly working with the FCC to keep wireless spectrum open for personal/private use.  I can’t help but feel that without them, we wouldn’t have the (spectrum) freedoms we enjoy today.

Here’s an inexpensive & neat set of landing-gear upgrades.
Ultrasonic sensors don’t apparently work well below 50F; keep them warm!
Throttle failsafe in-action.

Posted in Remotely Piloted Vehicles | 3 Comments

In-car apps; who’s responsible when something goes wrong? – UPDATED

Next year, you’ll be able to update your car with your favourite “mobile” applications in-car (Forbes, Smart-Car Wars).   Once car makers start mixing their code with 3rd party developers, who is responsible when something goes wrong?   It may be a human issue; how many rounds of  frozen-bubble does it take to run off the road?   It may be a software bug; the stereo suddenly roars to full-volume, scaring you into the next lane.

We’re not talking about some benevolent AI here, these applications are dumb.   They may depend on the auto-makers API’s, where a unit conversion problem won’t cause your car to crash-land on Mars, but it might leave you stranded 40 miles from the nearest gas station.

Debugging in a controlled environment is difficult enough; how will application problems be determined after an accident?  Do we install “black boxes” that monitor every action an application takes?  An application may not, in itself, be the problem, but may trigger a long-dormant bug in the vehicle software.   After all, there’s only a hundred-million lines of code,  running in a modern auto (15 times more software than a Boeing 787 Dreamliner).

Then there’s the effect on the driver; did a rapidly flickering display initiate an epileptic seizure?   Should the black-boxes store in-car video as-well?

Toyota’s lingering acceleration problem shows the difficulties a supplier has finding problems in their own systems.

Once a 3rd party application interacts with a vehicle, the lines are blurred.  It’s not like a GPS stuck onto the dash; the app becomes an integrated part of the vehicle.  Even if the vehicle maker sandboxes applications, problems are continually uncovered, and fixes have to be applied.

It’s reasonable to predict auto manufacturers will ultimately be held responsible for safely running this new class of applications.   The applications will most likely have to be vetted (signed, tested, ..) for vehicle use.   When the lawsuits start flying (and they will), the manufacturers are the only ones with pockets deep enough to litigate.

UPDATE – “Hackers hijack software in a CAR and remotely control the steering, brakes and horn using a laptop

Posted in Software | Leave a comment

“Simply Unsustainable” – To the tune of “Simply Irresistible”

Dedicated to wayyy too many start-ups, founders, and politicians (music video):

How can it be permissible..
It’s compromise my principles, yeah yeah
That kind of love is mythical..
It’s anything but typical

It’s a craze you’d endorse, it’s a powerful force
You’re obliged to conform when there’s no other course
It used to look good to me, but now I find it..

Simply unsustainable..
Simply unsustainable

Its loving is so powerful, huh..
It’s simply unavoidable
The trend is irreversible
The business is invincible

It’s a natural law, and it leaves me in awe
It deserves the applause, I surrender because
It used to look good to me, but now I find it..

Simply unsustainable..
Simply unsustainable..

Simply unsustainable (It’s so fine, there’s no tellin’ where the money went)
Simply unsustainable (It’s all mine, there’s no other way to go)

It’s unavoidable, I’m backed against the wall
It gives me feelings that I never felt before
I’m breaking promises, it’s breaking every law
It used to look good to me, but now I find it

Simply unsustainable (It’s so fine, there’s no tellin’ where the money went)
Simply unsustainable (It’s all mine, there’s no other way to go)

Its methods are inscrutable
The proof is irrefutable, ooh-ooh-ooh-ooh-ooh-ooh-ooh
It’s so completely kissable, huh
Our lives are indivisible

It’s a craze you’d endorse, it’s a powerful force
You’re obliged to conform when there’s no other course
It used to look good to me, but now I find it

Simply unsustainable (It’s so fine, there’s no tellin’ where the money went)
Simply unsustainable (It’s all mine, there’s no other way to go)

Simply unsustainable (It’s so fine, there’s no tellin’ where the money went)
Simply unsustainable (Its’s all mine, there’s no other way to go)

Simply unsustainable (ka-ching)

(Music Video)

“Politics as this level is insatiable” – Nancy Pelosi

Posted in Business | Leave a comment

Director of Firmware Development at DVI

Director of firmware development was my position at an ambitious start-up seeking to redefine the storage industry.  The underlying storage technology seemed capable of leapfrogging magnetic drive densities by at least a decade (including HAMR drives).   I was hired to be responsible for SATA drive firmware development, but ended up with heaps more 😉

On the business side, my responsibilities included creating technology demonstrators (for investors), wear testers, predictive models, patents, contract negotiation, planning, schedules, and liaison to design, manufacturing, Q/A, and test.   The people at DVI were competent, skilled individuals with many years of disk drive development & manufacturing experience, and were a joy to work with (for the most part).

On the development side, some of my tasks were to create developer specifications & environments, hire & integrate engineers and developers, compartmentalize specialized (FPGA) firmware and general (C) code development, specify/purchase IP, develop prototypes, create (HIL) test frameworks to quickly test & validate changes, specify and purchase test equipment & software, and code/mill/solder/design, as necessary (to name some of the tasks).

Doing all this required more than a few (late) nights at the office (note plaid covered cot):

The company had a great start, and we accomplished, with a relatively small amount of capital, what had not been done before.   Unfortunately,  raising the second round of funding was delayed (for a number of reasons), and the company stalled.

I’d like to give a note of thanks to Hiren Patel at Intelliprop for all his help with the SATA IP; he has a great group of folks there.

Also noted is Eli Billauer, freelance Electrical Engineer.   His tech blog is great, and he was very helpful with embedding microblaze soft-core processors running linux(!);  He is personable, very knowledgeable, and I highly recommend him.  His site contains a treasure-trove of FPGA information & experience.   If you’re looking for IP that allows you to easily DMA over PCIe on windows or Linux, then check out Xillybus.

Posted in Life | 2 Comments

90th running of the Pikes Peak International Hill Climb

Working communications for the 90th running of the Pikes Peak International Hill Climb (PPIHC) made for a long day.   Arriving at 3AM to set-up, and finishing after 8PM, it proved taxing and rewarding.   The race was delayed 37 days due to the Waldo Canyon Fire (I worked emergency shelter communications during the fire), and was launched on August 12th.  A good review of the fastest (and longest) PPIHC ever, can be found here, with the course map.    “Ham” radio reporting spotters (Pikes Peak ARES members) were positioned at regular intervals along the race course; their purpose is to provide near real-time feedback on race progress and conditions.   Course preparation starts long before race day.   Repeaters must be installed and tested to be sure that all spotter locations have clear communications using VHF and/or UHF (144MHz or 440MHz) frequency bands.   Driving the course the day before yielded some amazing views (photo courtesy of Melissa Bishop):

Pikes Peak2

On race day,  I settled my Jeep Wrangler safely above Gilley’s Corner, laid out the solar panels, fired up the radios, and performed communications checks on all primary & alternate frequencies:

PPIHC 2012

Communications hardware was powered by an 80 Amp-Hour AGM battery running a pure sine wave inverter that everything was plugged into; providing the advantage of constant-voltage output, even as the battery discharged.   This turned out not to be a problem as the solar panels kept the battery over 13.1V while the sun was shining, and after sunset, it never dropped below 12.4V (but I did bring a spare battery).   12V equipment was run from a 110VAC to 13.8VDC switching power supply; some inefficiency, but again, constant output voltage.  All DC runs were terminated with Anderson Powerpoles (30, 45, & 75A) and fusing.

Here’s a  video of classic car racers taking the corner (I was reporting from the red Jeep). Mmm-mm can you smell the nitro?

The only severe crash closed the course for an hour or so; amazingly, no fatalities, but several folks tried to make off with pieces:

Late in the afternoon, a storm blew in which caused the finish line to be moved down the mountain.   The storm caused a repeater to fail intermittently due to high-voltage induction on the antenna; this was a shocking (but not lethal) discovery made by one of the hams resetting the repeater.   Subsequent investigation uncovered a faulty ground connection.

Posted in Amateur Radio | 2 Comments

Quicksilver Radio

After deploying for the Springer fire, arson investigation, and the Waldo Canyon fires, I have a few days to get ready for the Pikes Peak International Hill Climb (delayed due to fire).    Getting up on the mountain at 3AM, and not being finished until 7PM, it makes for a long day, especially on the remote power system (batteries).   As such, I decided to spruce up the radio & power equipment with Anderson Powerpole connectors; so I ordered a bunch of connectors, crimper, and cables from Quicksilver radio.  For the battery runs, I decided to use #6 cable and 75 amp Powerpoles to feed a pure sine-wave inverter.   What arrived was 30 feet of #8 red/black zip cord.   Unfortunately,  I didn’t notice the discrepancy until I had already cut-off 3 feet of cord.  The next (business) day, I called John at Quicksilver radio, and explained the situation. He promptly told me to keep the #8, and the #6 would ship out that day.

Great customer service, thanks Quicksilver!

NOTEARES and RACES use the same configuration for Powerpole assembly.  This assures that all equipment using Powerpoles will interconnect.    The 15, 30, and 45 amp housings are identical, and will interconnect.  The 75 amp connectors are physically larger, and will only fit with other 75 amp connectors.   The same convention “red to right, tab on top” is followed when connectors are viewed from the front (contact) side.

Posted in Amateur Radio | Leave a comment

Arduino Iambic Keyer and Side Tone Generator

The latest issue of QEX (March/April) came this week with an article about an open-source keyer (pages 25-31).   This article referenced an earlier QEX article from Sept/Oct 2009 using an Arduino.    Since I have a Bencher paddle lying around, but no practice oscillator, I decided to investigate a bit further.   An Iambic keyer needs logic for creating its output, so the Arduino seemed like a shoe-in, especially since they’re widely available, even through Radio Shack (SparkFun, and AdaFruit are other good suppliers).

Finding back-issue articles of QEX turned out to be nigh impossible, so a few quick searches on the ‘net  turned up programs that could be easily adapted.   The first was a tone generation tutorial.   The next was a simple, but functional program that signalled through the LED.  I trimmed the fluff from this program and added tonal output (source code below). Here’s what the basic parts look like:

Keyer components

Plus the paddle (of course).  The two 4.7K resistors on the 1/8″ jack are pull-up resistors and the paddle “shorts” them to ground when contact is made.  Note the 100 ohm resistor in series with the speaker.   Some folks have used speakers from “singing” greeting cards. Wired-up, the completed simple keyer looks like:

wired keyer

The speaker is wired between digital pin 4 and ground.  The paddle wires connect to pins 2 and 5.  The red and black wires to the 1/8″ connector (resistors, barrel) are +5V and ground (respectively).

The code to run is as follows (download the Arduino software here):

//  Iambic Morse Code Keyer Sketch
//  Copyright (c) 2009 Steven T. Elliott
//  This library is free software; you can redistribute it and/or
//  modify it under the terms of the GNU Lesser General Public
//  License as published by the Free Software Foundation; either
//  version 2.1 of the License, or (at your option) any later version.
//  This library is distributed in the hope that it will be useful,
//  but WITHOUT ANY WARRANTY; without even the implied warranty of
//  Lesser General Public License for more details:
//  Free Software Foundation, Inc., 59 Temple Place, Suite 330,
//  Boston, MA  02111-1307  USA
//  "Trimmed" by Bill Bishop - wrb[at]
//                         openQRP CPU Pin Definitions
// Digital Pins
int         tonePin  = 4;       // Tone output pin
int         LPin     = 5;       // Left paddle input
int         RPin     = 2;       // Right paddle input
int         ledPin   = 13;      //
//  keyerControl bit definitions
#define     DIT_L      0x01     // Dit latch
#define     DAH_L      0x02     // Dah latch
#define     DIT_PROC   0x04     // Dit is being processed
#define     PDLSWAP    0x08     // 0 for normal, 1 for swap
#define     IAMBICB    0x10     // 0 for Iambic A, 1 for Iambic B
//  Library Instantiations
//  Global Variables

unsigned long       ditTime;                    // No. milliseconds per dit
unsigned char       keyerControl;
unsigned char       keyerState;

#define NOTE_D5  587	// "pitch.h" at

//  State Machine Defines


//  System Initialization

void setup() {

    // Setup outputs
    pinMode(ledPin, OUTPUT);      // sets the digital pin as output

    // Setup control input pins
    pinMode(LPin, INPUT);        // sets Left Paddle digital pin as input
    pinMode(RPin, INPUT);        // sets Right Paddle digital pin as input
    digitalWrite(ledPin, LOW);   // turn the LED off

    keyerState = IDLE;
    keyerControl = IAMBICB;      // Or 0 for IAMBICA
    loadWPM(15);                 // Fix speed at 15 WPM

//  Main Work Loop

void loop()
  static long ktimer;
  int debounce;

  // Basic Iambic Keyer
  // keyerControl contains processing flags and keyer mode bits
  // Supports Iambic A and B
  // State machine based, uses calls to millis() for timing.

  switch (keyerState) {
    case IDLE:
        // Wait for direct or latched paddle press
        if ((digitalRead(LPin) == LOW) ||
                (digitalRead(RPin) == LOW) ||
                    (keyerControl & 0x03)) {
            keyerState = CHK_DIT;

    case CHK_DIT:
        // See if the dit paddle was pressed
        if (keyerControl & DIT_L) {
            keyerControl |= DIT_PROC;
            ktimer = ditTime;
            keyerState = KEYED_PREP;
        else {
            keyerState = CHK_DAH;

    case CHK_DAH:
        // See if dah paddle was pressed
        if (keyerControl & DAH_L) {
            ktimer = ditTime*3;
            keyerState = KEYED_PREP;
        else {
            keyerState = IDLE;

    case KEYED_PREP:
        // Assert key down, start timing, state shared for dit or dah
        digitalWrite(ledPin, HIGH);         // turn the LED on
        tone( tonePin, NOTE_D5 );
        ktimer += millis();                 // set ktimer to interval end time
        keyerControl &= ~(DIT_L + DAH_L);   // clear both paddle latch bits
        keyerState = KEYED;                 // next state

    case KEYED:
        // Wait for timer to expire
        if (millis() > ktimer) {            // are we at end of key down ?
            digitalWrite(ledPin, LOW);      // turn the LED off
            noTone( tonePin );
            ktimer = millis() + ditTime;    // inter-element time
            keyerState = INTER_ELEMENT;     // next state
        else if (keyerControl & IAMBICB) {
            update_PaddleLatch();           // early paddle latch in Iambic B mode

        // Insert time between dits/dahs
        update_PaddleLatch();               // latch paddle state
        if (millis() > ktimer) {            // are we at end of inter-space ?
            if (keyerControl & DIT_PROC) {             // was it a dit or dah ?
                keyerControl &= ~(DIT_L + DIT_PROC);   // clear two bits
                keyerState = CHK_DAH;                  // dit done, check for dah
            else {
                keyerControl &= ~(DAH_L);              // clear dah latch
                keyerState = IDLE;                     // go idle

//    Latch dit and/or dah press
//    Called by keyer routine

void update_PaddleLatch()
    if (digitalRead(RPin) == LOW) {
        keyerControl |= DIT_L;
    if (digitalRead(LPin) == LOW) {
        keyerControl |= DAH_L;

//    Calculate new time constants based on wpm value

void loadWPM (int wpm)
    ditTime = 1200/wpm;

This keyer program has few options which must be configured at compile-time.   This isn’t always convenient.  So, while gratifying, I still desired more functionality.   But, before I dug in adding features, I did a few more searches and found this absolutely brilliant project:

It has tons of features (including memories) and can be implemented by adding a few more wires and components.   Most of the features are accessible by simply adding a push-button switch, which allows commands to be specified via the paddle. I chose to add a 10K ohm potentiometer, and enable remote speed control by un-commenting the line:


Which has the keyer looking like:

Adding switching outputs and even a PS2 keyboard are among the many features.   Take some time to look around the site, there are many hidden treasures.   As K3NG points out, enabling many of the features at-once may cause “memory overflow” on the ATMega328P.   It’s been my experience that simply moving to the Arudino Mega 2560, with its larger memory space,  resolves this issue.      Don’t get discouraged waiting for the compile & download to the Arduino; it took about 1 and 1/2 minutes (small sketches take only seconds).

NOTE: that you don’t need to use an entire Arduino module to execute on a project.   Once the project is working, you can pop-out the Atmel chip from the Arduino (usually a ATMega328P) and wire directly up to the pins on a perf or proto-board (or an Evil Mad Scientist Target board).   The chips themselves are only four bucks and some change.   Be sure to buy ones that have the boot loader already installed, or else you’ll need to buy a separate programmer.   See this article for more details and clock parts.

Wrapping up, the project needs boxed & painted, more switches & potentiometers added,  and a power supply.   What did I end up doing?  I put the word out to the local radio artisans, and picked up a used MFJ-492X for a good price.

Additional Links:

Using an Iambic Paddle.
Keyers, Paddles, & More.
Voice & Morse Keyers.

Posted in Amateur Radio | 20 Comments

How-To Configure the Xilinx FPGA Design Suite 13.3 Under RHEL/CentOS 6.x & Fedora 15

Initial Install

The Xilinx Integrated Software Environment (ISE) 13.3 is the first version that is supported by Xilinx to run under RHEL/CentOS 6.x.   We’ll now step through how-to configure the Xilinx FPGA design suite.

If you have purchased a Xilinx development kit like the SP605, the software should be on a DVD in the kit. However, it’s usually not the “latest & greatest”. To get the most recent version, go-to the Xilinx homepage and navigate to support=>downloads at:

in your browser. Download the “Full Installer for Linux”; It’s 5GB; you’ll need at least 20GB more free-space to complete the install.

At this point, you’ll need to either sign-in to download the file, or create an account if you don’t already have one.

Once the tar file has been downloaded, don’t forget to verify it using:

md5sum Xilinx_ISE_DS_Lin_13.3_O.76xd.1.0.tar

The sum should match the one displayed on the Xilinx download page (370cda774748d959aec21b2732c919ee in this case).

Extract the contents from the .tar file:

tar xvf Xilinx_ISE_DS_Lin_13.3_O.76xd.1.0.tar

You’ll need another 5GB of disk space for this step.

At this point you might read the install and licensing guide located at:

if this is the first install for you. Xilinx has lots of great on-line documentation.

To perform the initial Install; you’ll need to either be root, or have write-access to the install directory. In my case, I simply created the directory /opt/Xilinx as owned by myself (the default install location). You’ll need yet another 15GB of free space for this step:

cd Xilinx_ISE_DS_Lin_13.3_O.76xd.1.0

Then read/agree to the terms, and select the edition to install. The System Edition contains the everything but the SDK, which we’ll have to install separately later. Once the hardware is defined, the SDK may be the only package needed for other developers (compiling “C/C++” code for MicroBlaze soft-core processors


At this point, if you have no existing licenses, you can either get an evaluation license, or, as in my case, redeem a voucher that came with the development system by navigating to:

and redeeming the voucher for the EDK license, then download the Xilinx.lic file to your local computer and install it (in ~/.Xilinx/Xilinx.lic). See:

as referenced above.


Here’s where there are a few twists. If you purchased an evaluation board, the above two steps (install, licensing) should also be covered in the included documentation. In the /opt/Xilinx/13.3/ISE_DS directory are the settings files that need to be “sourced” before running the Xilinx design tools. The $DISPLAY environment variable needs to be set first:

export DISPLAY=:0

See I put this into my file and “source it” (set env variables) by:


Then start the Xilinx tool suite by running:


If you’re new to the Xilinx tools, navigate over to the tutorials at:

and start with the ISE In-Depth tutorial.  To get the fpga editor to work, as root:

yum install openmotif compat-libstdc++-33

On Fedora 15 ONLY, also execute the following commands:

cd /usr/lib64
ln -s openmotif/ (Warning: hack)

Now, to get iMPACT working (the tool that downloads .bit files into your FPGA), a few things need to be worked out. First make sure the program /sbin/fxload is installed; as root, run:

yum install fxload

For RHEL 6.x users, you will need to get this package from the CentOS distribution:

With this and recent versions of ISE, the proprietry windrv kernel module isn’t necessary. However, the README file from:;f=README;hb=HEAD

points out that buried wayyyy down in the file heirarchy:


lies a script named setup_pcusb. See the video at:

Running the script as root:

./setup_pcusb /opt/Xilinx/13.3/ISE_DS/ISE

will create the file /etc/udev/rules.d/xusbdfwu.rules That must be modified (as root) with the stream-edit command (or your favourite variant):

sed -i -e ‘s/TEMPNODE/tempnode/’ -e ‘s/SYSFS/ATTRS/g’ -e ‘s/BUS/SUBSYSTEMS/’ /etc/udev/rules.d/xusbdfwu.rules

to allow access the JTAG programming interface on your FPGAs. This is all you need to do for RHEL 6.x, but on Fedora 15, you WILL need the usb-driver from:

(my guess is that the usb interfaces where moved from “/proc/bus/usb” to “/dev/bus/usb” in Fedora 15, causing some grief). This needs to be built and installed. Be sure to install the libusb development libraries before trying to build the usb-driver by running:

yum install libusb

Then untar the usbdriver and “make” it (compiler tools assumed); copy to the director /opt/Xilinx/13.3/ISE_DS, and add the line:

export LD_PRELOAD=”/opt/Xilinx/13.3/ISE_DS/”

to your file. Be sure to re-source it (. before running ise or impact. This should be all you need.


An easy way to test all this (assuming you have an evaluation board of some sort) is to fire up ise, then from the File menu, open an Example project (Pong game, Arbitrary Waveform Generator, etc). Then double-click on Synthesize – XST. When the systhesis process finishes, you can open view the RTL schematic, etc. After that, double-click on Implement Design which will map then place & route the design. Different reports can be created then viewed. Then double-click on Generate Programming File, which will create the FPGA bit-stream (.bit file). Then finally, double-click on Configure Target Device, which will bring up the iMPACT GUI. Double-click on the iMPACT Boundary Scan line in the iMPACT Flows dialog box to see detected devices (PROMs, FPGAs, etc). Then right-click and select Initialize Chain and walk through the dialogs selecting the .bit file. After all this, under iMPACT processes, the FPGA can be probed and/or programmed. This flow is covered in the tutorial Xilinx videos mentioned below.

SDK Install

The Xilinx SDK ( is an Eclipse platform targeting software development for FPGA soft and hard-core processors (MicroBlaze & PPC). Since the basic FPGA fabric isn’t modified, no “expensive” operations are required; just a quick compile and load. Once the basic system architecture is pinned-down, developers with more common C/C++ experience can be deployed for application development. The program data2mem combines the hardware & software bitstreams for download to the FPGA.

Even though the ISE Design Suite installer says that the SDK is installed when performing and EDK install, it isn’t. So, after installing either the “System Edition” or “Embedded Edition” (both produce identical set-ups), install the “Standalone Installation” by running:

./xsetup (again)

This will create an SDK directory in /opt/Xilinx/13.3. To keep from having to source multiple scripts, I simply moved the directory /opt/Xilinx/13.3/SDK/SDK to the /opt/Xilinx/13.3/ISE_DS directory since the rest of the SDK installation is duplicated.

Re-source the script, and from there, and start an embedded project by running:


Which will bring up the SDK GUI.


Xilinx Product support & Documentation:

Xilinx Free Online FPGA Design Training Videos:

Xcell Journel:

Write a software application with SDK:

Linux in a MicroBlaze soft-core:

Posted in FPGA | 9 Comments

Shred Baby Shred!

I was happily shredding some documents the other day when suddenly my Fellowes POWERSHRED 420HS ground to a halt.    This DOD approved high-security shredder has been serving me well for almost a decade:

It creates indecipherable chaff (shred baby food):

Peeking inside, there’s not much to it:

Hand-turning the drive motor didn’t budge the shredding gears, so I had to pull the 49.25 pound (22.4 kilo) mechanism out for cleaning and diagnostics.   All the retaining bolts are underneath the mounting platform:

After peering into the gearbox (right side), and having no luck getting the shredder teeth to turn, I popped the retainers & bolts off the other end to loosen the gears and applied generous lubrication.    At that point I was able to hand-turn the motor fan and got the shredder teeth to move a bit in each direction.    Adding more oil (I noticed some corrosion), and after more wiggling back and forth, I was finally able to get the teeth to break free and rotate smoothly.    Upon close inspection, I noticed three teeth that had been chipped:

I’m still not sure why the unit jammed, but after cleaning & lubricating, it’s back to its old self.   When I re-installed the unit, it wouldn’t stay running; I found a hall-effect sensor used to sense gear rotation had been nudged slightly off-kilter:

Moving the transistor-like device on the board just a bit fixed the problem.

Posted in Technology | Leave a comment

I bought my wife an Android, and now she has Tourette’s

’nuff said..

Posted in Technology | 1 Comment