[simpits-tech] Controlling synchros

[Simon Bennett]

>	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.

See, since everything's controlled by a second computer (which doesn't care 
what software the first computer is running), switching sims would be an 
almost trivial process. I'd have to write new software to export the data, 
that's it. I want to stick to FS2004 because I have it and I know it pretty 
well.


>	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).
>

Since these computers run DOS,  the graphics software will be written by me. 
It should be just fine.  I'll just write my own DOS graphics library for C. 
Considering the simplicity of the MFD and HUD symbology, I don't have to do 
anything special.

>
>	Ehh, couldn't you store the last known state of the switch (assuming you 
>get
>unique signals for "on" vs "off" events)?

You don't. I suppose I could with another set of 74HC148s and some inverter 
ICs, but that would greatly increase complexity, chip count, and cost. Using 
latches and a counter would be much easier.

>
>	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.

See, it's easier to spend the money in small chunks than large ones. I need 
to keep costs down. Besides, skipping an EPIC card gives me a few hundred 
dollars I can spend on real parts. Also, I firmly believe that if you want 
something done right, you do it yourself. I just can't justify spending so 
much on an EPIC and expansions when I can get the same functionality by 
soldering together a few dollars of components.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/