Nothing but 'Net

OK; I'm going to have to turn in my Paleotechnologist Card -- or at least cross out the "Paleo" part -- but this is pretty cool. I'm on the Amtrak, connected to the 'Net via Internet sharing on my HTC Mogul -- connected via Bluetooth PAN. Cool, especially using this connection to access my desktop back in PHL via Remote Desktop.

It seems to me that devices like the Mogul are the first of a new class of device. With connectivity via cell, WiFi, and Bluetooth, in addition to USB etc, it can handle cell phone calls, the usual Internet functions (POP, SMTP, HTTP, SSH, FTP yada yada) -- and can also act as a router/NAT proxy. Not bad for a pocket-size gizmo.

Now if they could only improve the battery life. I wonder if it'll make it to FBG?

Edit: Nope. The battery gave up just past Washington. It was fun while it lasted, though.

VSI gauge progress

The first CHComm-based instrument is starting to take shape. A Futaba servo connected to a PIC16F877a (yeah, I know -- gross overkill -- but it was handy) to make a VSI gauge. At this point, it works intermittently; it seems to only register changes of the hundreds' place; I really need to get an LCD on it to help diagnose what's going on.

On the bright side, it's up to 9600 baud, from 2400, so that helps.

Getting the PIC to properly multitask while communicating with the serial port is an interesting proposition. Right now, the main loop provides constant position pulses to the servo while polling the serial port line every 500us or so, to see if a start bit has been received. I'm leaning towards a 2-MCU solution for each gauge, though -- one to handle comms and one to run the servo. That way, the servo MCU would be guaranteed a very short data-update cycle, rather than allowing for a potential stoppage should something happen to the serial line. (Servos act strange when their position pulses are interrupted.)

CH Comm works!

Just finished testing CH Comm -- it works, both with FS2004 and FSX! A whole interesting list of FS data can be exported to the RS232 port in standard format. This should make it fairly straightforward to create PIC-based instruments.

At this point, the next steps are:
* Try to get RS232 comms working reliably at a higher speed than 2400 baud -- preferably 115200, even if this means a dedicated MCU to handle the comms (which it probably will.)
* Go through the CH Comm .ini file to pare down the output to what is needed (all this data takes an appreciable fraction of a second to export at the default 9600 baud -- which would make for poorly-responding instruments.
* Choose one or two parameters for a PIC to read, and display them on a LCD or via a servo.

Tandy PC-6 (circa 1986)

It's baaaaack!

A quick trip to Radio Shack for batteries, and my beloved, venerable Tandy PC-6 from back in junior high school(!) is back among the living. (I actually must have remembered to remove the old batteries before they started to corrode -- wow!)

Here it is, folks -- BASIC-language paleotechnology, 1986-style!

Steam gauges!

Well, no actual steam will be involved -- just a PC or two, Flight Simulator, and several PIC microcontrollers. the idea is to create actual realistic-looking (working) instruments for use with FS. Having found CHComm3a, which claims to be able to output data from FSUIPC to an RS232 port, it seemed like a good idea to try to do something useful with this data.

My plan is to go for something like a Cessna 182RG setup eventually -- mostly, by building the "easier" components first. Clockwork components like the altimeter may have to wait until I can find a suitable (read: nonfunctional but in nice condition; I don't want to ruin a perfectly good instrument) part on eBay.

I just picked up a copy of "Programming 16-Bit Microcontrollers In C," which seems to have some good tricks for migrating from the 8-bit parts I'm familiar with to the PIC24 family.

Here's the To-Do list so far:

• Verify RS232 output from FS9 / FSX
• Verify PIC can actually parse said output
• If no, co-opt a QBasic box to do it??
• Integrate Assembly and C routines
• Decide on best calibration scheme
• Build "easy" devices:
• ADF gauge (stepper motor w/gear drive?)
• Variometer
• Fuel gauges
• Decide how to make altimeter movement
• Work on Ethernet connectivity for PICs
• One local IP address per instrument/control
• Instruments talk to control PC, which interfaces w/FSUIPC?