On Fri, Feb 25, 2011 at 1:42 AM, <cas...@mminternet.com> wrote: > > Some years ago i wrote my own driver that interfaces my sim hardware (a > network of Microchip pics) to FG. It reads incoming messages and writes > the > > values direct to the tree. > > > > However, Nasal scripts controlling properties are becoming ever more > prevelant in FG. There can be a fight going on in software 10 times a > second > > as to a particular switch being on or off. Either the Nasal does not > work > > or > > the physical switch does not work! > > > > So for those of us who build sims, no one solution or custom IO module > suits > > all, (but if any one wants to copy my picF18 can bus setup they are most > welcome, just mail me) > > > > Is there a guide line for this kind of interfacing? > > > > If not and assuming nasal is the way to go, I would propose we specify > a > > dedicated sub branch and format on the propriety tree where sim hardware > values can be written. That branch would only occur when such a driver > is > > in > > use. > > > > Then those who need too, can modify model and system nasal scripts > accordingly, 2 people can have 2 different sim set ups with different > interface drivers, But the tweaks we would make to Nasal would in fact > be > > the same because we would both present our sim hardware settings to the > same > > properties tree branch. > > > > > > > > > > Comments, been done before or other options to consider? > > I've taken a different approach. My boards all connect via USB to > driver(s) that take the switch states, run subsystem models as required, > and feed it to FG via UDP control socket and on the FG side the incoming > socket packet is distributed to the property tree as required and nasal > scripting is not enabled in the first place. > > For the most part, only use the JSBSim models (which were also modified) > to handle engine operations and a complex tanking model for the 747. In > that way the cockpit side is pretty much immune from pertubations and > changes in FG, although have been "biten" a few times. > > John > > > > > > OK Thanks John,
I Guess I took the networked pic approach because I already had done a lot of the work the the pics before the sim building came up. Originally it was an UAV project using FG as the test aircraft, but there is no where in Bali to test fly, I meant moving back to Australia for open spaces, but the red tape there is murder unless you bush. However we both come back to the point of loading the property tree from our hardware, the difference being you are independent of Nasal. Problem for me is a lot of the refinements in the new models coming out do use it, This means I better have closer look at what the nasal is actually doing. I am sure my io routine could do a lot of it. But feeling well "bitten" here right now. Your set up sort of motivated me to build by the way. -- Regards Harry Sanur, Bali
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
