Re: [Flightgear-devel] Terragear terrafit memory leak
Durk Talsma wrote: I'm explicitly deleting all the Triangle and Edge objects. This has improved performance a lot I'm still not able to process the entire Eurasian continent in one pass, after this fix, the total number of .fit files that can be created on my linux box has gone up from 15881 to 94865. I hope to be able to commit these changes one way or the other. Hi Durk, glad to see you are also tackling some TG issues. I'm looking forward for your patches. Maybe you can also take a look at the patches in this repo here: https://gitorious.org/papillon81/terragear-cs Some of the commits might be worth integrating. Thanks Chris -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terragear terrafit memory leak
On Sunday, August 14, 2011 15:20:10 Durk Talsma wrote: Hi Adrian, I realize that it's almost three quarters of a year since your message was posted, but it wasn't until today that it caught my attention. Hi Durk, As they say, it's never too late to fix a bug. I remember encountering these issues on my Corine+OSM Europe scenery, though I skipped them by running terrafit.py which worked like a charm. If you're at it, maybe you could investigate why does the clipper (or constructor, can't remember now which one was the culprit) sometimes blow up and stop generating triangles for a limited area. This usually happens in very detailed and crowded scenery builds, and the problem is best described at the bottom of this page: http://www.cullam.com/flightgear.htm I hope you can fix some of these bugs. Best regards, Adrian -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New aircraft: SF-25
Hi all, Athanasios Goritsas (cc-d) created a nice Falke 3D model with a basic Yasim profile, based on the aircraft he flew with. I would like to develop his model further (I'm doing my PPL on the real thing atm). We would both like to see it in Git (under a GPL license), maybe more people would join in developing it further. (If you need a statement on this directly from Athanasios, as he's the primary author, let us know.) In the meantime, could you please check out the plane and shed some light to some Yasim parameters. You can grab it from http://www.avatarzenekar.hu/files/sf25b.tar.bz2 The biggest issue with the FDM is that the plane does not seem to have enough drag -- it easily goes over Vne, and it's impossible to land without spoilers unless you stop the engine (and even then it takes forever). Compared to the Grob 109, I had to use an absolutely huge drag multiplier to force the bird down (150 instead of 2.5). 150 is probably a bit much -- maybe 100-120 would be enough, but I think the airframe or the wings are just not generating enough drag. Not sure if I did a good enough job with the fixed prop. The diameter should be correct, not sure about the rest. My school's falke has the 2L engine and it spins up to about 2600 when stopped. No idea about the prop's most efficient speed and horsepower values are pretty much guesses. Anyway, please let us know if this is good enough to go into the repo, and any suggestions for improvement. Some (working) 3D instrument panel would be great, but I have no idea how to make that. Any pointers on that would be very much appreciated. Since Falkes have fairly varying instrumentation, even a copy of the Grob 109's panel could be OK. Ah, and the splash screens I've made do not load. What did I do wrong? Thanks in advance. Cheers, Vik -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 答复: FG Input though socket or anyway?
No, I mean that it is possible to both overwrite properties within FlightGear directly on to use a Nasal script as an interface to overwrite those properties. You can browse the LinuxTrack source code for examples, the parts specific to FlightGear are here: http://code.google.com/p/linux-track/source/browse/#svn%2Ftrunk%2Fdoc%2Ffgfs From: jinchen...@gmail.com To: flightgear-devel@lists.sourceforge.net Date: Mon, 15 Aug 2011 09:34:16 +0800 Subject: [Flightgear-devel] 答复: FG Input though socket or anyway? Thanks! Do you have some sample for reference?Do you mean the Nasal module is the key for input? 发件人: TDO_Brandano - [mailto:tdo_brand...@hotmail.com] 发送时间: 2011年8月14日 23:29 收件人: Flightgear Devel List 主题: Re: [Flightgear-devel] FG Input though socket or anyway? There are several ways to send an input to FlightGear. The example that sprinsg most readily to my mind is the way LinuxTrack can communicate head tracking position to FGFS. Essentially either writing the values for camera position via a protocol file (look in fgdata/Protocols) or sending the data to a Nasal script that will then write the actual properties (this second solution allows toggling the head tracking while in flight).From: jinchen...@gmail.com To: flightgear-devel@lists.sourceforge.net Date: Sun, 14 Aug 2011 20:42:03 +0800 Subject: [Flightgear-devel] FG Input though socket or anyway?Hi All,We’d like to do some project that could give FG Input and Output though MCU like ARM.We could get the FDM though socket, so the MCU could get it and display.but how could we give the FG some input that does not via keyboard, joystick?It looks like that we could use serial port like http://code.google.com/p/ardupilot/wiki/FlightGear.Does anyone have some suggest for that?How we can do for the serial port? Do we have any document for that?thanks! -- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New aircraft: SF-25
On Mon, Aug 15, 2011 at 12:18 PM, Viktor Radnai viktor.rad...@gmail.com wrote: Hi all, Athanasios Goritsas (cc-d) created a nice Falke 3D model with a basic Yasim profile, based on the aircraft he flew with. I would like to develop his model further (I'm doing my PPL on the real thing atm). We would both like to see it in Git (under a GPL license), maybe more people would join in developing it further. (If you need a statement on this directly from Athanasios, as he's the primary author, let us know.) In the meantime, could you please check out the plane and shed some light to some Yasim parameters. You can grab it from http://www.avatarzenekar.hu/files/sf25b.tar.bz2 The biggest issue with the FDM is that the plane does not seem to have enough drag -- it easily goes over Vne, and it's impossible to land without spoilers unless you stop the engine (and even then it takes forever). Compared to the Grob 109, I had to use an absolutely huge drag multiplier to force the bird down (150 instead of 2.5). 150 is probably a bit much -- maybe 100-120 would be enough, but I think the airframe or the wings are just not generating enough drag. Not sure if I did a good enough job with the fixed prop. The diameter should be correct, not sure about the rest. My school's falke has the 2L engine and it spins up to about 2600 when stopped. No idea about the prop's most efficient speed and horsepower values are pretty much guesses. Anyway, please let us know if this is good enough to go into the repo, and any suggestions for improvement. Some (working) 3D instrument panel would be great, but I have no idea how to make that. Any pointers on that would be very much appreciated. Since Falkes have fairly varying instrumentation, even a copy of the Grob 109's panel could be OK. Ah, and the splash screens I've made do not load. What did I do wrong? Thanks in advance. Cheers, Vik Vik, Looks like a great start. The first thing I would do before anything else is make sure your CG is positioned reasonably. In your SF-25, the CG is much too far back; given the forward-swept wings, it looks to be about a meter behind MAC: E:\FlightGear projects\sf25byasim sf25b-yasim.xml Solution results: Iterations: 1292 Drag Coefficient: 10.955851 Lift Ratio: 291.677826 Cruise AoA: 1.469686 Tail Incidence: 2.793443 Approach Elevator: -0.014301 CG: x:-0.900, y:-0.000, z:0.284 Inertia tensor : 1831.357, -0.000, 78.171 [kg*m^2] -0.000, 2075.542, 0.000 Origo at CG 78.171, 0.000, 3856.738 The command-line YASim solver is showing CG at x=-0.9, well behind the wing's root chord position at x=-0.371. It isn't worth messing with other YASim values until CG is about right. I'd first try to locate the real CG range from a certification sheet or pilot's handbook and then use a YASim ballast element to shift some of the plane's mass forward toward the nose. Once you get CG better positioned, you'll have much better luck with other factors. After CG, a couple of other things to watch in the solver: Lift ratio is very high-- this indicates the glides-forever issue. For this plane I'm guessing you'll want a value somewhere between 100-130, but the actual value will depend on flight experimentation. Lots of YASim parameters affect that value. (Note that these YASim drag and lift numbers should not be treated as real lift/drag ratios; don't try to make them match a real L/D ratio.) Approach elevator is much too small-- this value means you'll need almost no elevator to hold an approach. Look for something in the -0.7 to -0.9 range for starters. In any case, don't try to tweak these until CG is resolved. Wing and hstab stall AoA values look really high at 30 degrees. Most conventional high-lift general aviation airfoils seem to be in the 15-18 range. If you know the airfoils used, you can get camber and stall values from the airfoil data. I have a little and rather incomplete YASim guide that might be helpful: http://ltts.crlt.indiana.edu/grn/flightgear/ -Gary, aka Buckaroo -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New aircraft: SF-25
BTW, you can get a pretty good idea of where the CG is on a plane from the landing gear position. On a tail dragger the CG will be slightly behind the main wheel. Too far back and the tail won't have enough authority to lift for takeoff, too far forward and the plane will nose over when braking, or ground loop when rolling on the ground. In this specific model it might be a little further back than most, since it has to keep the tail on the ground with the weight of the passengers. I believe the CG will be approximatively coincident with the pilot position, since in a motorglider that will be the largest variable mass. Date: Mon, 15 Aug 2011 13:18:53 -0400 From: grne...@gmail.com To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] New aircraft: SF-25 On Mon, Aug 15, 2011 at 12:18 PM, Viktor Radnai viktor.rad...@gmail.com wrote: Hi all, Athanasios Goritsas (cc-d) created a nice Falke 3D model with a basic Yasim profile, based on the aircraft he flew with. I would like to develop his model further (I'm doing my PPL on the real thing atm). We would both like to see it in Git (under a GPL license), maybe more people would join in developing it further. (If you need a statement on this directly from Athanasios, as he's the primary author, let us know.) In the meantime, could you please check out the plane and shed some light to some Yasim parameters. You can grab it from http://www.avatarzenekar.hu/files/sf25b.tar.bz2 The biggest issue with the FDM is that the plane does not seem to have enough drag -- it easily goes over Vne, and it's impossible to land without spoilers unless you stop the engine (and even then it takes forever). Compared to the Grob 109, I had to use an absolutely huge drag multiplier to force the bird down (150 instead of 2.5). 150 is probably a bit much -- maybe 100-120 would be enough, but I think the airframe or the wings are just not generating enough drag. Not sure if I did a good enough job with the fixed prop. The diameter should be correct, not sure about the rest. My school's falke has the 2L engine and it spins up to about 2600 when stopped. No idea about the prop's most efficient speed and horsepower values are pretty much guesses. Anyway, please let us know if this is good enough to go into the repo, and any suggestions for improvement. Some (working) 3D instrument panel would be great, but I have no idea how to make that. Any pointers on that would be very much appreciated. Since Falkes have fairly varying instrumentation, even a copy of the Grob 109's panel could be OK. Ah, and the splash screens I've made do not load. What did I do wrong? Thanks in advance. Cheers, Vik Vik, Looks like a great start. The first thing I would do before anything else is make sure your CG is positioned reasonably. In your SF-25, the CG is much too far back; given the forward-swept wings, it looks to be about a meter behind MAC: E:\FlightGear projects\sf25byasim sf25b-yasim.xml Solution results: Iterations: 1292 Drag Coefficient: 10.955851 Lift Ratio: 291.677826 Cruise AoA: 1.469686 Tail Incidence: 2.793443 Approach Elevator: -0.014301 CG: x:-0.900, y:-0.000, z:0.284 Inertia tensor : 1831.357, -0.000, 78.171 [kg*m^2] -0.000, 2075.542, 0.000 Origo at CG 78.171, 0.000, 3856.738 The command-line YASim solver is showing CG at x=-0.9, well behind the wing's root chord position at x=-0.371. It isn't worth messing with other YASim values until CG is about right. I'd first try to locate the real CG range from a certification sheet or pilot's handbook and then use a YASim ballast element to shift some of the plane's mass forward toward the nose. Once you get CG better positioned, you'll have much better luck with other factors. After CG, a couple of other things to watch in the solver: Lift ratio is very high-- this indicates the glides-forever issue. For this plane I'm guessing you'll want a value somewhere between 100-130, but the actual value will depend on flight experimentation. Lots of YASim parameters affect that value. (Note that these YASim drag and lift numbers should not be treated as real lift/drag ratios; don't try to make them match a real L/D ratio.) Approach elevator is much too small-- this value means you'll need almost no elevator to hold an approach. Look for something in the -0.7 to -0.9 range for starters. In any case, don't try to tweak these until CG is resolved. Wing and hstab stall AoA values look really high at 30 degrees. Most conventional high-lift general aviation airfoils seem to be in the 15-18 range. If you know the airfoils used, you can get camber and stall values from the airfoil data. I have a little and rather incomplete YASim guide that might be helpful: http://ltts.crlt.indiana.edu/grn/flightgear/ -Gary, aka Buckaroo
Re: [Flightgear-devel] New aircraft: SF-25
Hi, the correct cg for a SF25C is 0.143 .. 0.334m behind the wings tip (measured 0.52m from the center line). Regards, Maik am 15.08.2011 22:07 schrieb TDO_Brandano -: BTW, you can get a pretty good idea of where the CG is on a plane from the landing gear position. On a tail dragger the CG will be slightly behind the main wheel. Too far back and the tail won't have enough authority to lift for takeoff, too far forward and the plane will nose over when braking, or ground loop when rolling on the ground. In this specific model it might be a little further back than most, since it has to keep the tail on the ground with the weight of the passengers. I believe the CG will be approximatively coincident with the pilot position, since in a motorglider that will be the largest variable mass. Date: Mon, 15 Aug 2011 13:18:53 -0400 From: grne...@gmail.com To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] New aircraft: SF-25 On Mon, Aug 15, 2011 at 12:18 PM, Viktor Radnai viktor.rad...@gmail.com wrote: Hi all, Athanasios Goritsas (cc-d) created a nice Falke 3D model with a basic Yasim profile, based on the aircraft he flew with. I would like to develop his model further (I'm doing my PPL on the real thing atm). We would both like to see it in Git (under a GPL license), maybe more people would join in developing it further. (If you need a statement on this directly from Athanasios, as he's the primary author, let us know.) In the meantime, could you please check out the plane and shed some light to some Yasim parameters. You can grab it from http://www.avatarzenekar.hu/files/sf25b.tar.bz2 The biggest issue with the FDM is that the plane does not seem to have enough drag -- it easily goes over Vne, and it's impossible to land without spoilers unless you stop the engine (and even then it takes forever). Compared to the Grob 109, I had to use an absolutely huge drag multiplier to force the bird down (150 instead of 2.5). 150 is probably a bit much -- maybe 100-120 would be enough, but I think the airframe or the wings are just not generating enough drag. Not sure if I did a good enough job with the fixed prop. The diameter should be correct, not sure about the rest. My school's falke has the 2L engine and it spins up to about 2600 when stopped. No idea about the prop's most efficient speed and horsepower values are pretty much guesses. Anyway, please let us know if this is good enough to go into the repo, and any suggestions for improvement. Some (working) 3D instrument panel would be great, but I have no idea how to make that. Any pointers on that would be very much appreciated. Since Falkes have fairly varying instrumentation, even a copy of the Grob 109's panel could be OK. Ah, and the splash screens I've made do not load. What did I do wrong? Thanks in advance. Cheers, Vik Vik, Looks like a great start. The first thing I would do before anything else is make sure your CG is positioned reasonably. In your SF-25, the CG is much too far back; given the forward-swept wings, it looks to be about a meter behind MAC: E:\FlightGear projects\sf25byasim sf25b-yasim.xml Solution results: Iterations: 1292 Drag Coefficient: 10.955851 Lift Ratio: 291.677826 Cruise AoA: 1.469686 Tail Incidence: 2.793443 Approach Elevator: -0.014301 CG: x:-0.900, y:-0.000, z:0.284 Inertia tensor : 1831.357, -0.000, 78.171 [kg*m^2] -0.000, 2075.542, 0.000 Origo at CG 78.171, 0.000, 3856.738 The command-line YASim solver is showing CG at x=-0.9, well behind the wing's root chord position at x=-0.371. It isn't worth messing with other YASim values until CG is about right. I'd first try to locate the real CG range from a certification sheet or pilot's handbook and then use a YASim ballast element to shift some of the plane's mass forward toward the nose. Once you get CG better positioned, you'll have much better luck with other factors. After CG, a couple of other things to watch in the solver: Lift ratio is very high-- this indicates the glides-forever issue. For this plane I'm guessing you'll want a value somewhere between 100-130, but the actual value will depend on flight experimentation. Lots of YASim parameters affect that value. (Note that these YASim drag and lift numbers should not be treated as real lift/drag ratios; don't try to make them match a real L/D ratio.) Approach elevator is much too small-- this value means you'll need almost no elevator to hold an approach. Look for something in the -0.7 to -0.9 range for starters. In any case, don't try to tweak these until CG is resolved. Wing and hstab stall AoA values look really high at 30 degrees. Most conventional high-lift general aviation airfoils seem to be in the 15-18 range. If you know the airfoils used, you can get camber and stall values from the airfoil data. I have a little and rather incomplete
Re: [Flightgear-devel] New aircraft: SF-25
Vik, Based on Maik's CG information and a little nosing around for performance information online, I made an el-cheapo quick and dirty FDM: http://ltts.crlt.indiana.edu/grn/flightgear/sf25b-yasim.xml Feel free to use it, lose it, abuse it, or whatever. It's a bit tricky to takeoff and land, especially in any kind of crosswind-- it takes a fair hand on the rudder. It also likes to glide and glide once it gets close to the ground, so you'll definitely not want to approach over 50 kts or you'll never get down. I often side-slipped to help me get down. I disabled the linkage of the spoilers with the wheel brake-- According to the book, brakes are engaged only on the maximum spoiler setting, but I got tired of nosing-over when I landed. ;) You might want to restore that. I didn't try to match sink rate to real, I only tried to get the speed range within reasonable norms and bring control surfaces effects to something that felt reasonable. You might want to mess with the spoiler settings, maybe increase the drag a bit, as the handbook says they're pretty effective, and I tend to err on the understrength side. I'm not a pilot, so definitely feel free to disregard anything I did. -Gary, aka Buckaroo -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASIM Comment (was New aircraft: SF-25)
On Monday 15 August 2011 11:18:53 Gary Neely wrote: Looks like a great start. The first thing I would do before anything else is make sure your CG is positioned reasonably. In your SF-25, the CG is much too far back; given the forward-swept wings, it looks to be about a meter behind MAC: E:\FlightGear projects\sf25byasim sf25b-yasim.xml Solution results: Iterations: 1292 Drag Coefficient: 10.955851 Lift Ratio: 291.677826 Cruise AoA: 1.469686 Tail Incidence: 2.793443 Approach Elevator: -0.014301 CG: x:-0.900, y:-0.000, z:0.284 Inertia tensor : 1831.357, -0.000, 78.171 [kg*m^2] -0.000, 2075.542, 0.000 Origo at CG 78.171, 0.000, 3856.738 The command-line YASim solver is showing CG at x=-0.9, well behind the wing's root chord position at x=-0.371. I took a look at the YASim solver today, first comparing the Inertial tensor with the inertias coming out of aeromatic. Not too far apart, but the 2 yasim aircraft I looked at were both 50% higher than the aeromatic numbers. Then I took a look at the -g switch and was rather shocked at the curves yasim generates. It generates CL, CD and L/D. My plot software computes force as (lift^2+drag^2)^0.5. Lift and drag are perpendicular by definition so this gives the total force in the lift/drag plane. I made 3 plots with Tat's A6M2 and Helijah's Katana and Gloster-Meteor models: http://www.jentronics.com/fgfs/temp/yasim/yasim-A6M2.png http://www.jentronics.com/fgfs/temp/yasim/yasim-katana.png http://www.jentronics.com/fgfs/temp/yasim/yasim-glostermeteor.png And then I loaded some data I had from a NACA 4 digit 0015 airfoil into the same plot definition: http://www.jentronics.com/fgfs/temp/yasim/naca0015.png I was pretty shocked to see the YASim charts drag numbers all seem to fall off at stall. This is counterintuitive to me, I expect drag to increase at stall, that is what keeps the speed low during the stall. Also, the lift/drag (L/D) ratio is actually the tangent of the angle the aerodynamic force is acting in. On the real airfoil it rapidly approaches 0 after the stall because the force is acting nearly parallel to the free stream velocity and drag dominates the ratio. This seems not to be the case with the YASim models. Thanks, Ron -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: Generic Protocol Error -- Error opening serial device COM27 The system cannot find the file specified.
OK so I tried to trick FG several different ways, none of which really work, I tried to get it to send data to one serial port and receive it on another that sort of works but after about a minute or so FG just stalls and stops sending data, and basically stops responding to all command inputs. Another method I tried was to have it send data out on through a UDP and accept data in on a COM port, that basically had the same effect. My last option is to try to have it send and receive to two different sockets, I really hope that works. However I think this has issues to, does FG have to be the server when receiving data? Because I couldn't get it to actually connect to the socket unless I turned off the app I was using to transmit data to FG on the socket and of course once I turned the app off FG was able to connect to the socket/port but then the app couldn't connect at all, so I'm guessing FG has to be a the server when receiving data??? It doesn't really look like FG can transmit and receive data at the sametime at all on windows anyway you slice it, I mean every single thing I try it fails or has some goofy error. One last thing is there a way to ensure that FG is sending out its outputs in floating point format, because I'm not sure it is, I have the generic file setup for binary mode, but I'm not convinced that FG is transmitting data as floats, I think it might actually be transmitting data as integers or something else. I make this observation because the data I did get cause an action in my algorithm which didn't make sense. The auto pilot switched to flight mode while still on the ground, it wasn't susposed to do that until it reached 1800 feet, so thats why I'am assuming that the output it received from FG as the altitude couldn't have been in floating point format it must have been an integer or maybe a double, or something but whatever it was it wasn't a float. I looked at the perferences file in the FG directory, and I changed all the double types to float, should that do it? I loaded it under the configuration option in the advanced options menu, but when I started FG back up and hit the / key and looked at the outputs the values still said double. On Mon, Aug 8, 2011 at 11:17 AM, Curtis Olson curtol...@gmail.com wrote: Press the / key or it should also be a menu option. On Mon, Aug 8, 2011 at 10:12 AM, Derrick Washington ddwas...@gmail.comwrote: As far as I can tell this will require some code modifications if you want to use direct serial communcation. Yeah I figured that, hmmm I'm not very familiar with FG's source code at all, and I downloaded the exe, can any of you make a suggestion as to what I might attempt to correct? What properties are you importing into FlightGear? You can open up the property browser and check to see if they are being changed as you expect. I included the xml file I am using in the email, and I'm afraid I don't know how to open up the property browser, but I'll look at the documentation and check. On Mon, Aug 8, 2011 at 10:27 AM, Curtis Olson curtol...@gmail.comwrote: Right, as you noticed, it doesn't appear that the generic interface code is setup to transmit and receive at the same time. You can't open up the same device twice, so you two command line options won't work either. As far as I can tell this will require some code modifications if you want to use direct serial communcation. Another option might be to write a thin glue layer that talks to FlightGear over the network, and talks to your hardware over a serial port and then does all the appropriate data translation as required. What properties are you importing into FlightGear? You can open up the property browser and check to see if they are being changed as you expect. Curt. On Mon, Aug 8, 2011 at 9:21 AM, Derrick Washington ddwas...@gmail.com wrote: So I tried it with the joystick unplugged and nothing changed, FG will transmit, and it will receive just not at the same time, no matter how I try to trick it, I can't even get it transmit on one port and receive on another (using serial). Is it possible that someone can create a fix for this? On Sun, Aug 7, 2011 at 5:44 PM, Derrick Washington ddwas...@gmail.comwrote: OK So I believe I've got it to work on COM27 by using the \\.\COM27syntax. I still have a problem sending and receiving at the same time, FG will not allow me to open up multiple generic serial protocols to the same COM port for in and out, only one at a time and bi directional doesn't seem to be supported. On Sun, Aug 7, 2011 at 12:39 PM, Gene Buckle ge...@deltasoft.comwrote: On Sun, 7 Aug 2011, Frederic Bouvier wrote: Gene, Unless you've got 26 other serial ports on that machine, I'd strongly suggest researching what caused Windows to assign COM27 to your device. It's NOT typical behavior. You can assign any number you want to a COM port when it is driven by a
