Hallo Torsten :-) in the meanwhile I've reviewed what I've done in the past with the Seneca NLG, that NASAL code ... it was fun :-) I think I'll try this approach first.
> Von: Torsten Dreyer <tors...@t3r.de> > > I suggest not to send the raw encoder data to FlightGear but to compute the > frequencies internally in your arduino and send the result as a frequency > or channel to fgfs. > ... > I use I2C communication between my PC and the microcontrollers, but that > could > easily be changed to a serial-over-usb protocol for the Arduino. It's a design decision, my first idea was to use the external hardware as a replacement for physical input/output devices, no intention to put too much logic in there other than what pertains to what knobs/displays/levers physically do. I would leave the rest of the processing into FlightGear. That means something like that: - a frequency selector knob knob rotates --> the rotation gets passed to FGFS that then makes the internal instrument logic do what it's originally meant to do. - an FGFS frequency display changes value --> the value gets passed to the external hardware that updates it's state accordingly. Another example just to be clear: I don't want to build a Yoke physical replacement that sends aircraft attitude values to FGFS, it should only send it's physical movements and let FGFS do the rest of the simulation processing. That way, the physical external hardware should be a simple replacement of those 3d elements that we generally controll using mouse clicks on the screen. I guess I will move more of the instrumentation's internal functionalities to the external hardware/software in the future anyway (I'm already tempted now), but according to my plan that has to be done in a second step. Anyway, I accept your suggestion and I will investigate in what practically implies sending the frequency to FlightGear instead of sending the knob rotation alone; but I will leave that for a second stage project. > Von: Gene Buckle <ge...@deltasoft.com> > > I used outbound UDP from FG to send data from the sim to my host > interface software and then a telnet based command channel that > would be used to set properties. I was not happy with Telnet performance, not even after pumping it's speed up. It has some advantages, I could send only changing values to fgfs and not everything/always, but its poor reactivity makes it a poor choice for more interactive input/output. I'm working on the KX165 now, but it's only a piece of the puzzle, I have yoke/pedals/indicators in mind too. > Von: Curtis Olson <curtol...@gmail.com> > > I don't know if this is the best approach or not, but when I > tackled this task for the ATC Flight Simulator interface > (FAA certified flight sim based on FlightGear) I dug in and > wrote some C++ code. I find that intriguing (not less than Torsten's i2c/ATMEL prototype) and I will think about that, but I'm still not very confortable with C++ ... I'm writing C++ code now first time in my life, I'll try and make things simple at first. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
