[simpits-tech] Controlling synchros

[Matt Bailey]

On Wednesday 01 June 2005 21:22, Simon Bennett set 1,000 monkies in front of 
keyboards and came up with the following:
>
> I'm using FS2004, for sure, and possibly LOMAC or Falcon 4, eventually. I
> plan on having the sim hardware being totally independent of the software.
> All of the gauges, switches, lights, etc. are to be managed by a second PC.
> This box will run FreeBSD as an operating system since I hate windows and
> the windows API with a passion. It also frees up resources on the main sim
> computer, since all it has to do is swap a few bytes back and forth across
> the LAN. The second PC communicates with the cockpit electronics over the
> serial port. The cockpit electronics tell the 2nd computer when a switch
> has been pressed. The 2nd computer then decides what action to take and
> communicates with the main sim computer either directly over the LAN, or if
> that isn't possible, by telling the homemade keyboard interface to send a
> command in the form of a keypress.

	Second PC, good idea, for precisely the reasons you mention. Also, since you 
share my intense dislike of Windows :) have you considered X-Plane as a 
candidate for sim software? It's Windows, Mac, and Linux compatible, and is 
quite open. It has native support for sending and receiving data over a 
simple UDP network connection to get/set a few internal variables (many of 
the switch states, for instance), and there's an SDK that allows *extensive* 
access to the guts of the sim (for instance, recently I left out a couple of 
OpenGL calls in my plugin script and was thereby controlling the location & 
orientation of the cloud matrix.......). I think there are over 1,000 
internal variables accessible through the SDK. Then there's FlightGear, which 
is also cross-platform, and this one is open source, so it's even more open. 
I have to admit I don't really care for FG, but that's a preference thing.

> All of the cockpit electronics will be PIC microcontroller based. I'll
> probably use mainly 16F88 chips, since they are cheap, packed with neat
> features, and pin-compatible with the ubiquitous PIC16F84. I'll have to
> design my own data bus and break everything down into systems and
> sub-systems to keep everything moving in the right direction.
>
> If I opt for MFDs or a working HUD, I have a couple 386 laptops that would
> be more than able to drive the displays.

	Hmmm, what sort of software will you use for the graphics? I've also 
considered MFDs and for now I intend to use Pygame, a set of extension 
modules for Python that allow use of SDL. http://pygame.org I will probably 
use PyOpenGL to improve performance and allow some fancier graphics. I'll 
have to use relatively modern computers though (at least K6-2/Pentium II 
class, probably). I have two machines networked right now but haven't got 
around to doing the software yet (too busy with X-Plane plugins and a couple 
of games).

<snip>
> My original idea was to have a line encoder like
> a 74HC148 to send a binary signal to the PIC when a switch was triggered,
> but this wouldn't let me tell whether the switch was on or off at any given
> time.

	Ehh, couldn't you store the last known state of the switch (assuming you get 
unique signals for "on" vs "off" events)? It would stay in sync as long as 
the computer is on and your software's running (assuming your software scans 
quickly enough that it's not likely to skip a rapid on/off/on or off/on/off 
cycle).

> For output to LEDs or the like, for, say, an annunciator panel, I could
> just use the same approach only have a few latches to keep track of whether
> the light should be on or off. Hmm.
>
>
> So this is what I get for not having any money for an EPIC card. Well, it's
> more fun to do it yourself, anyway.

	Heh, you're definitely taking the homegrown route. :) I originally was really 
concerned about the expense of a pit, but I've long since resigned myself to 
this being a fairly pricey project. That means I can't do it right now, it 
will have to wait til I have a more substantial income. But in the mean time 
I've learned a fair amount of Python programming, got a Phidget quad servo 
module working (in Linux, no less), and have gotten into interfacing X-Plane 
using a new Python interface to the SDK. Still, advanced electronics and PIC 
stuff is beyond my skill level, which is why I'll mostly be sticking to 
Phidgets for hardware interfacing. A bit pricier than rolling everything 
myself, but still, I'm pretty sure I can keep my Phidgets expenditures under 
$1,000 for what I need in the pit (some interface kits for *some* of the 
switches and all lights, a few character LCD modules, and 3 or 4 servo 
modules). In addition to that I'll probably use BetaInnovations gear for most 
of the analog controls, quite a few switches/buttons, and some rotaries (the 
Cyclotron looks nice.........).

> Sorry for the rantyness.

	Hey, no sweat, I like hearing about other folks' plans/projects. :)

	-Matt Bailey