Thursday, September 30, 2010

An Update to the First Heavier Than Air Flying Machine

In July 1869, when Wilbur Wright was two years old, and Orville was as yet unborn, a heavier than air flying machine successfully flew two half-mile circles in a tethered flight test. The craft was known as the Avitor.

Lost in Time

The Avitor has been largely forgotten. It was what we'd call a hybrid vehicle today, very unlike the craft later flown by the Wright Brothers. The Avitor flew well and successfully, but an accident with a prototype resulted in its development being halted prematurely. If development had continued, it's very likely that modern aircraft would be very different from what they are today.

Many of the design concepts of the Avitor are being rediscovered and applied to new aircraft development. Among these are aerodynamic lift from the aircraft body (Blended Wing-Body aircraft, today) and hybrid lift (lift from a combination of buoyancy, power, and aerodynamics.)

The Past is the Future

The closest thing to a modern day Avitor is currently in development by Northrop Grumman. It's a vehicle they call the Long Endurance Multi-Intelligence Vehicle, or LERV. The name describes its use, something that can hang in the sky for long periods of time keeping an eye on things. The present program's goal is to develop a surveillance platform for use in Afghanistan. It is supposed to go there for operation testing within a year. First flight is to come this summer.

After a Brief 150 year Hiatus, the Return of Avitor?

There are other potential applications for this craft that Northrop intends to work toward. Perhaps by the Sesquicentennial of the Avitor's demonstration flight, we'll have our own 21st century Avitors roaming the skies.

Related Links:

Saturday, September 18, 2010

8085 Disaster! (well, a minor setback, but I'm not happy about it.)

I'm in the final stages of assembling the permanent hand-wired version of my 8085 project, and I've run into a problem.

3 Switches Become 1 Big Problem

There are three critical switch inputs to the 8085 on the front panel. They are the TRAP, RST5.5 and RST7.5 signals to the 8085. Essentially, each tells the 8085, "Stop what you're doing and do this instead."

It Worked Fine on the Test Bench!

When I built this project on solderless breadboard I didn't have any serious space limitations, so I did full "debouncing" on each switch, to prevent electrical noise caused by the switch from sending a whole bunch of "stop what you're doing!" messages all in a row when the user just presses the switch once.

On the soldered-up permanent version, I decided to save a little bit of space on the circuit board by trying to debounce on the cheap. A normal debounce circuit uses two inverters to clean up the electrical noise. I had a chip on the board that had six inverters in it, two of which were in use. That left me four inverters, for three signals. I needed six to do the job right.

Too Clever by Half

But, I had a "clever" idea. I thought I'd see if I could get by with a circuit that only uses one gate per signal. Not a full debounce, but a circuit called a "Schmitt Trigger." I built it up and tested it on the solderless breadboard.

It worked just great!

Then I built it up on the soldered board. It worked great there, too.

Then I went and bought some prettier switches to use on my new system's box. It worked pretty well. It seemed OK...

Then I did a test fit on the box with all the parts. I pressed my pretty new switches.

Disaster!

When I was pressing the new switches on a handheld box, rather than against a tabletop, I got a whole bunch of signals sent to the 8085 for each time I pressed the switch. The results were pretty ugly.

A Quick Fix is No Fix

I tried out some quick-fixes, as well as making sure all my connections were good. I'd hate to redesign and modify the circuit only to find out the problem was a loose connector all along. The connectors were tight, and the quick fixes helped a bit, but didn't fix the problem. The original (ugly) switches I used worked fine, but I tried a selection of switches in the circuit and most of them had the same problem when hand-held even when they didn't have any problems on the test bench. (I really did test the snot out of this when I first went with the shortcut. But I didn't get all the conditions right for a good enough test. Now I'm paying the price.)

I considered changing out the switches. But this would be a bit of a cop-out. I want to make this something someone else can build and enjoy without having to go through the tweaking and testing and all that I'm doing as I build it. I want others to be able to build it and just have it work, so long as all the bits are in the right places. I can't guarantee that everyone who decides to build it is going to get "clean" switches. So I have to go back and change the design to use real debounce. Then test that, under adverse conditions, like with a rusty knife switch.

One of the quick fixes I tried would probably have been good enough to work under most conditions with a software change that would have delayed any action on the switch input for a fraction of a second. I could have gone with that, and felt sorta pretty good about it. Except that there's a fairly likely condition that that wouldn't cover.

The Deadly Condition

If the user presses the switch, and holds it down for a bit before releasing it, there'll be a second switch event on the release. If someone has a habit of sort of "leaning on" the switches then this will occur to them fairly frequently, and probably ruin their experience using the computer.

I did say these switches are important--in the OS I use them for a warm reset, and vectoring to the user's program. The third one is left for the user in their own programs. But if those functions aren't reliable, it sorta hoses the whole affair. So it's time for me to do the right thing.

Test, Test, Retest, Pray and You Shall Receive

Tomorrow I expect to be protoboarding the correct circuit that I probably should have done in the first place. I'll test it, and if I'm not 100% convinced, I'll use a different sort of circuit, called a "one-shot" or monostable, and make darn well sure with belt and suspenders and a rope tied to a thick tree limb. I may try to avoid adding another IC to the board by using transistors for the last two inverters, or I may try to keep down the varieties of components I use by just dropping in another 4049 in addition to the one there now. On my other part choices I've opted to keep the number of different parts low by reusing the same chips over and over wherever possible.

I'm expecting to put in another 4049, even though it ties up more board space than I like. I might get creative about where I put it, but then again I may not.

Finally, Fitting It In

It's not like I don't have open board space. But I had plans for that space in the future. A memory bank select, another memory IC, and an RS-232 chip. I think the space saved for the RS-232 chip is going to get used. Besides, I may be able to fit in a little Dallas/Maxim chip in one of the odd corners later, or just "float" it on a daughterboard connected to the RS-232 connector.

After all, the core computer has to be working before I start worrying about expansions.

Wednesday, September 15, 2010

Cartooning Class: Drawn While You Watch

Today I'm preparing for the first substantive lesson this year in the cartooning class I teach. The first class, which was last week, is a get acquainted class, and I introduce the idea of drawing faces on circles as an activity. This week we start working on technique. I start with drawing eyes.

Each year, I'm tempted to bring in pre-printed sheets with examples of different artists' eyes on them. But each year, I end up discarding the idea, for the same reason. It'd be convenient to have specific examples from cartoons the kids recognize (and some they don't, yet) right in front of them as they work. Plus, even with my notes there's always something I miss covering (though I usually pick it up in review the following lesson.)

But I don't.

Watch the Cartoonist Draw, and Fumble

I think it's important, especially early in the class, to give the students confidence. Part of that is letting them watch me actually draw my examples on the board for the class. Aside from the fact that they get to see how I perform the strokes of the drawing, they also get to see my mistakes. They also get to see me hesitate as I prepare myself to shift from one style to another, and think through the details that define the new style (I do it verbally, so they can hear me think it through.)

I try to open up the process of drawing to them, so that they can be assured that it's not magic.

Some of them miss that point on the first pass. But I can point to the drawings on the board and ask questions like "did I get that one right the first time?" to make the point that I'm not perfect, even though I've been drawing these things since I was their age. I also tell them stories of how I learned these things the first time, and how pathetic my first attempts were. I often re-create these on the board or do them extra bad for a bit of humor.

The point, of course, is that the process itself isn't magic. But the results are. And the magic happens almost no matter what our skill level. We can scribble down a few lines on paper that have an emotional impact. At best, that impact hits the artist when they sit back and look at the drawing. But even when there's no impact there, it can hit others. So we pass our drawings around. There's nothing that does more for a worried student than to have a fellow student they barely know look at their drawing and say

"Whoa! That is so cool!"

Tuesday, September 14, 2010

8085 Computer Power Management

I'm in the final stages of hardware work on my 8085 computer project. Today I spent some time working on reducing how much power it uses.

8085 computer project during power use measurement and testing.
The MAG-85 still looks like a rats nest here. I pulled out a bunch of parts for today's testing. It'll go back together again even better.

With all peripherals turned on at full power, some of them at a higher level than would be normal or reasonable, the whole thing pulled 720mA at 5V. At full reasonable power levels, everything on, it came down to about 250mA. I put in current limiting to cap it at that level.

Then I went hunting for further power savings. The plan is to run this thing off of batteries in the not too distant future (I normally run it off an AC adapter now.) By seeing how little power I could feed to the LEDs in the system while still having them visible in bright light, I was able to cut overall power use down to about 160mA with everything on. It draws about 125mA with the LCD display on, the system running full bore, but no extra outputs pulling current. I can live with that.

What surprised me the most was that changing the CPU from an 8085AH microprocessor to an 80C85 (CMOS, low power version) didn't make any significant difference to the amount of power the system required. The LEDs accounted for almost all of the decrease from 720mA to 125mA.

8085 computer enclosure being sniffed by our cat.
The enclosure during inspection by Quality Control. The first attempt is on the left, the final version on the right.

I'm very close to closing this box up and calling it done. At least until I open it up for further upgrades. Upgrades like full 64K memory decode, an additional 8K of memory on board, and an RS-232 serial port. Later.

Thursday, September 9, 2010

Killing Time with Web Comics

School started this week, I've been busy with the preparations I've made for my classes as well as teaching them, on top of my regular work. I've been a bit low-key otherwise.

While I should be putting the finishing touches on my 8085 computer this afternoon, I've been reading funnies on the web instead.

The one I've been enjoying over the past few days I'm enjoying a lot. It's called Sheldon, and you'll be doing yourself a favor if you click on that link there. There are several years worth of archive up for the comic, so you can read it all from Strip One. I recommend doing it that way--it'll explain a lot that appears to make no sense otherwise.

I first learned of Sheldon through the book How to Make Webcomics. Sheldon's creator, Dave Kellett, is one of the book's authors. I got the book because I've been reading PVP for some years. and I got interested in the book. Among the things I cover in my computer classes is using the skills I teach in business, and I've incorporated some of the material in the book into my lessons.

Sheldon is cute, fun, clean (one mild swear word in almost ten years' comics I've seen so far, and some pretty abstract innuendo is the worst I've seen), and a great way to avoid doing the things I don't feel like I've got the energy for right now. Besides, the weather's turned cold and that means I can't paint the enclosure on my 8085 computer today. Maybe tomorrow, but for now, back to Sheldon. What's that duck up to now?

Saturday, September 4, 2010

Siig Multi-Touch Mini Keyboard Wrap-Up

A while ago I wrote about getting a Siig Multi-Touch Mini Keyboard. I wanted to get something of the sort because I wanted an integrated keyboard and mouse for use in the front room. I didn't want a separate mouse.

Well, after using it for the first few hours, I was pretty pleased. But as time went on I got less and less pleased. The touchpad was way too sensitive. It was registering clicks even when I wasn't touching it. When my palms were on the wrist rest, it would register clicks. I was getting all sorts of problems. Selections were just part of it, it'd be selected on something when I didn't even know it, so when I'd put my finger down to move the mouse pointer, I'd get an unintended drag. I'd see it--you can guess the natural reaction--and end up with an unintended drag and drop.

There's no way to make adjustments to the behavior of the touchpad. Adjustments in the OS don't affect it, nor do mouse adjustment. Siig's support barely acknowledges that the product exists, and there's no help there either.

Well, I tried just catching when it was happening, and tried avoiding making it happen. Neither worked well enough. My typing speed dropped through the floor, the errors continued, and there wasn't much I could do to keep it from happening. I just had to be prepared for it and try to minimize the damage. Not the best way to go.

Finally, I set aside the keyboard and put in another that annoys me with sticky keys. It was better. Two hours of typing later I was feeling better--with sticky keys on the keyboard. That pretty well sealed it.

I took the Siig keyboard back.

I've since replaced it with another keyboard. See my review of the Microsoft Wireless Desktop 3000.

Thursday, September 2, 2010

Installing Pygame on Mac OS X Leopard

In my ongoing campaign to broaden my programming abilities I decided to install
Pygame and play around with it. I want to try it out as something to present to my students this year. I've decided to add a small programming segment to the first semester of my high school computer class this year where we do a quick survey of several languages by doing tutorials in them before we go into Java programming in spring semester.

Pygame is an add-on package for python that makes it easy to develop games using Python. Python has no built-in support for native graphics, sound, etc.--Pygame adds that to Python.

When I went to install Pygame on my Mac, I ran into a couple of hitches. I managed to work around them without too much problem, but I thought what I did to get things going was worth sharing.

First, Pygame requires the python.org version of Python. Even though my Mac already came with Python installed (hurray for Apple for that), the version isn't one that Pygame is happy with. So I went out to python.org, clicked on downloads, and pulled the first thing I saw for my OS version. This turned out to be Python 2.7 for Mac OS X 10.5 or later. Yeah, I could have gone with 3.1, but to be honest I didn't look that far down the page at first.

Once I had it downloaded, I started the download of Pygame. I installed Python 2.7 from the Mac installer while that was going.

Once the Python install finished, I did python -V at the command line in Terminal. My answer:

#python -V
Python 2.5.1


Hmmm. That's the Mac preinstalled version, not the new one. OK, fine:

#whereis python
/usr/bin/python

#ls -l /usr/bin/python
lrwxr-xr-x 1 root wheel 72 Feb 21 2008 /usr/bin/python -> ../../System/Library/Frameworks/Python.framework/Versions/2.5/bin/python


Aha! I needed to set up the appropriate links to make the new Python the current one.

#cd /System/Library/Framework/Python.framework/Versions/
#ls
2.3 2.5 Current
#ls -l Current
lrwxr-xr-x 1 root wheel 3 Feb 21 2008 Current -> 2.5
#ls /Library/Frameworks/Python.framework/Versions/
2.7
#ln -s /Library/Frameworks/Python.framework/Versions/2.7 ./2.7
#ls
2.3 2.5 2.7 Current
#rm Current
#ln -s 2.7 Current
#ls -l Current
lrwxr-xr-x 1 root wheel 3 Sep 2 12:45 Current -> 2.7
#python -V
Python 2.7


Hurray! Next I went to install Pygame. I unzip the zip, then run the installer.

No Install

Pygame then complained that it wanted Python 2.6! Python 2.7 wasn't good enough for it. I took a look at the dependency settings by right clicking on the Pygame installer in Finder, selecting "Show Package Contents", then opening "Contents" and double-clicking on info.plist there to open it in the Property List Editor. I expanded the Root item (the only top level item), then expanding "IFRequirementDicts" and expanding item "0". There I saw the Python version requirements properties. I considered changing it to require Python 2.7 by editing the SpecArgument field to 2.7 instead of 2.6.

But, it's not like my hard disk is mine to control, so I wimped out and installed Python 2.6 by going back to the Python All Releases download page, finding the 2.6 version, downloading and installing it.

Once it was in place, I went back to Terminal:

#cd /System/Library/Framework/Python.framework/Versions/
#ls
2.3 2.5 2.7 Current
#ln -s /Library/Frameworks/Python.framework/Versions/2.6 ./2.6
#ls
2.3 2.5 2.6 2.7 Current


Now Pygame will install just fine.

Wednesday, September 1, 2010

Old Computer Orphanage

Computers on my Doorstep
I got up this morning to find a G3 iMac sitting on the floor of my living room. My wife told me a friend of ours had come by earlier to drop it on our doorstep.

What a fun little surprise for the day!

G3 iMac

It's a 450MHz G3--the top of the line--with Mac OS X Jaguar loaded (10.2, one of the best versions of that OS), and it has Classic, which lets it run the OS9 stuff within X. 128MB of memory (remember when that was plenty? What do you do now that you didn't do then? We had web browsers and MP3 players back then, you know.) All in all a very sweet little all-in-one system.

Aside from some cosmetic dings and a missing keycap (up arrow), it's in great shape.

Unfortunately, it's a little too old for me to donate to my school--we'd need at least an Intel processor there, we need to teach on Windows as well as MacOS. But I have plans for building a G3/G4 based game network here at home so that the family and guests can enjoy some of the old games like WarCraft II that we miss so much. I just need to reclaim some space in the garage from my overflowing heap of Apple II stuff. ;)