Re: [Flightgear-devel] Real-Time Radio Propagation
Hi Adrian, On Wed, Dec 12, 2012 at 10:12 PM, Adrian Musceac wrote: As most of you know, the main performance issues come from having to repeatedly sample terrain elevation for a large number of points. This is done though and osg::NodeVisitor, which traverses all nodes within the scenegraph which have a certain mask set (in our case, it's SG_NODEMASK_TERRAIN_BIT) Unfortunately, not only the terrain surface has this mask set, but also random objects, random trees, and 'random' buildings. They all share this mask, so an _get_elevation_ call will have to traverse through litterally thousands of nodes which are not related to the terrain surface. In order to improve the performance of the _get_elevation_ method, I have added a new mask, SG_NODEMASK_SURFACE_BIT, which is set only for the surface geometry loaded by the BTG loader. Of course, some other minor code had to be modified, especially for groundcache et al. Very minor modification, basically taking into account of this new nodemask. The BVH bounding boxes stuff has been accounted for (I think I didn't miss anything) I haven't looked at your code, and I'm sure you've already taken care of this, but: The use of the SG_NODEMASK_TERRAIN_BIT by the random trees and buildings is probably due to my ignorance when writing the code, and I certainly agree that the trees shouldn't have this bit set. The v2.8.0 random buildings were a simply geometry built at runtime, and IIRC people were enjoying landing helicopters on the top of them. However, the current git random buildings use a shader instantiation approach very similar to the trees. I think that means that the shouldn't be considered with the FG_NODEMASK_TERRAIN_BIT either, as the geometry itself isn't placed correctly in the scenegraph. Therefore, I think they shouldn't be considered in the get_elevation_m/groundcache/bounding box code. I think the random objects _do_ need to be included so they can be included in collision calculations. On the more general subject, I have two comments, both as a layman so take with a suitable pinch of salt! 1) I think the most important attribute of the radio code is that one can complete a published approach. I assume that approaches are specifically designed and built such that there in sufficient signal strength within some volume around the perfect approach. My concern with any advanced model is that invalid/inaccurate terrain/elevation input into the model might mean that we get too low a signal, and some approaches might no-longer be possible to fly due to (incorrectly) low signal strength. Adrian: Is that a reasonable concern, or are approaches designed such that there is always line-of-site between the station and the aircraft on the approach (and therefore any terrain interaction is irrelevant within the approach volume)? 2) Assuming we're only interested in terrain effects, then it would seem that the signal strength at a given point (lat/lon/alt) for a given station is invariant. Would it be possible to avoid the runtime hit by calculating it offline for all points within reasonable range of the station? One might be able to create a bitmap storing the minimum signal altitude (i.e. the altitude below which there is no signal due to terrain), the maximum signal strength, the altitude that occurs, etc. and then use these as parameters into a straightforward function to determine the signal strength at the current altitude. One could then overlay the published approach volumes and thereby ensure that aircraft within the approach volume receive valid signal strength. -Stuart -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Friday, December 14, 2012 13:09:54 Stuart Buchanan wrote: Hi Adrian, I haven't looked at your code, and I'm sure you've already taken care of this, but: The use of the SG_NODEMASK_TERRAIN_BIT by the random trees and buildings is probably due to my ignorance when writing the code, and I certainly agree that the trees shouldn't have this bit set. Hi Stuart, I am much more ignorant than you are when it comes to the way trees are created :) I have modified the code in simgear now, so that they don't have the bit set. Also, I noticed they have the SG_NODEMASK_CASTSHADOW_BIT | SG_NODEMASK_RECEIVESHADOW_BIT bits set (for Rembrandt), but they don't cast shadows, probably due to their geometry, you probably know better. Should I remove them? The v2.8.0 random buildings were a simply geometry built at runtime, and IIRC people were enjoying landing helicopters on the top of them. However, the current git random buildings use a shader instantiation approach very similar to the trees. I think that means that the shouldn't be considered with the FG_NODEMASK_TERRAIN_BIT either, as the geometry itself isn't placed correctly in the scenegraph. Therefore, I think they shouldn't be considered in the get_elevation_m/groundcache/bounding box code. Same goes for random buildings, which thanks to texture mapping are now not so random :) To my surprise, they also didn't cast shadows. Now I understand why. Should those bits go too? Can Fred give his input too on this issue? About bounding boxes, perhaps there's a way to have that too, but again, I'm very ignorant on your method which relies on shaders. I think the random objects _do_ need to be included so they can be included in collision calculations. Agreed. As it is now, I have added a new bit only for terrain surface, SG_NODEMASK_SURFACE_BIT , and the rest of terrain objects which do have bounding boxes will keep the SG_NODEMASK_TERRAIN_BIT. When performing scenery elevation calls, I believe the best way is to add another parameter which can toggle SG_NODEMASK_TERRAIN_BIT on and off. The speedup in this case is pretty important, there are fewer nodes to be traversed. I think Thorsten's weather would benefit from this as well, since it needs to sample only the surface (elevation, type of terrain). On the more general subject, I have two comments, both as a layman so take with a suitable pinch of salt! 1) I think the most important attribute of the radio code is that one can complete a published approach. I assume that approaches are specifically designed and built such that there in sufficient signal strength within some volume around the perfect approach. Normally yes, I am not a pilot, but I assume that there would be no approach charts that would tell you there is localizer/gs signal behind the local mountain. Same goes for VOR etc. The published volume is one thing, but if terrain features come into play, the signal may or may not go, and that's the most interesting part of it, it adds a little uncertainty when you are at low altitude, in mountainous areas, at the limit, etc. I just had a very satisfying flight yesterday using the code, and it made me understand why there are so many VOR's in some areas, and how you need to tune from one to the other as you go through terrain at lower altitudes. I should add that I fly in SRTM terrain mostly, and I have very accurate radio signal predictions. My concern with any advanced model is that invalid/inaccurate terrain/elevation input into the model might mean that we get too low a signal, and some approaches might no-longer be possible to fly due to (incorrectly) low signal strength. The reverse is likely. The values will be most unforgiving with SRTM/high definition DEM, and most forgiving in low res terrain. Fortunately, I have a property which can be set by the user, depending on the type of terrain which is flying. This is the elevation resolution the code should expect. In low res terrain, this property can be set to 200-300 meters between profile points, and then you won't even notice the CPU footprint. Adrian: Is that a reasonable concern, or are approaches designed such that there is always line-of-site between the station and the aircraft on the approach (and therefore any terrain interaction is irrelevant within the approach volume)? I believe all approach charts respect terrain, and judging from nav.dat, there is a good reason some VOR's use greater power, or some ILS stations pump greater power in their antennas etc. To do otherwise and not keep the terrain in mind would be foolish, and I don't think the guys publishing the charts are fools. 2) Assuming we're only interested in terrain effects, then it would seem that the signal strength at a given point (lat/lon/alt) for a given station is invariant. Would it be possible to avoid the runtime hit by calculating it offline for all points within
Re: [Flightgear-devel] Real-Time Radio Propagation
Hi Adrian, you are doing an excellent job at marketing your product ;-) As I do not have the time to proof you wrong, you deserve the chance to proof me wrong! I'll shut up now and stop objecting against merging your code. I won't be able to merge it myself before we enter the feature freeze but probably someone with commit rights takes care of it. I hope I find some time to test the LOWI approach which had the chance to do in RL recently... (http://data.x-plane.com/Docs/LOWI.pdf) Thanks, Torsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
Am 13.12.2012 16:28, schrieb geneb: Um, no he's not. He just happens to be a contributor like the rest of us. :) There is no herder for the Free Range Cats that make up the FlightGear project. :) How disappointing ;-) Frankly, I think your addition to FlightGear is fantastic and a needed feature for the non-entertainment side of the house. If the gamers don't like the small frame rate hit, they can just turn it off. But being called a gamer, _that_ is discouraging! Greetings Torsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Friday, December 14, 2012 18:09:04 Torsten Dreyer wrote: Hi Adrian, you are doing an excellent job at marketing your product ;-) As I do not have the time to proof you wrong, you deserve the chance to proof me wrong! I'll shut up now and stop objecting against merging your code. I won't be able to merge it myself before we enter the feature freeze but probably someone with commit rights takes care of it. I hope I find some time to test the LOWI approach which had the chance to do in RL recently... (http://data.x-plane.com/Docs/LOWI.pdf) Thanks, Torsten Hi Torsten, Sure, no problem. I hope you will find it useful in the future too, otherwise I would have kept it for myself :) Thanks for all your help last year and your patience for my noobishness in Flightgear inners. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On 14 Dec 2012, at 16:09, Torsten Dreyer wrote: As I do not have the time to proof you wrong, you deserve the chance to proof me wrong! I'll shut up now and stop objecting against merging your code. I won't be able to merge it myself before we enter the feature freeze but probably someone with commit rights takes care of it. However I still have code quality objections, unrelated to the performance of the code! (And also unrelated to the accuracy of the simulation - I have no problem with adding advanced computational systems so long as their optional, which this is) I will take a look next week at merging the changes locally and then seeing how much re-structuring is needed to make me comfortable, but right now the lack of object-orientated design and over/mis-use of properties is just not something I want to add more of, to the codebase. As I said to Adrian offline, I know there's plenty of code already checked in, of a similar quality / design / pattern to his submission, but I'd like to set a higher standard for new code than what we had previously. James -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On 14 Dec 2012, at 17:27, James Turner wrote: As I said to Adrian offline, I know there's plenty of code already checked in, of a similar quality / design / pattern to his submission, but I'd like to set a higher standard for new code than what we had previously. And it case it wasn't clear - I realise Adrian can't possibly know this stuff magically - that's why I'm happy to make the time, to make the changes myself! It would of course be easier to have these discussions when the code is at the prototype stage, but that's a harder issue to solve. James -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Fri, 14 Dec 2012, James Turner wrote: On 14 Dec 2012, at 17:27, James Turner wrote: As I said to Adrian offline, I know there's plenty of code already checked in, of a similar quality / design / pattern to his submission, but I'd like to set a higher standard for new code than what we had previously. And it case it wasn't clear - I realise Adrian can't possibly know this stuff magically - that's why I'm happy to make the time, to make the changes myself! It would of course be easier to have these discussions when the code is at the prototype stage, but that's a harder issue to solve. James, maybe now would be a good time to write up something that covers coding guidlines for the wiki? g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Thursday, December 13, 2012 01:03:45 Vivian Meazza wrote: Don't we need radar altitude for buildings etc. for radar altimeters, but probably not trees? A radar altimeter needs to sample both the terrain and hard objects on it. However, I watch this work with interest: I think it might make it worth reviewing the AG radar that I abandoned due to the impact on frame rate, and lack of realistic range because not enough tiles were loaded, Vivian Vivian Yeah... to be discussed. I don't know much about trees, except that they are nodes made out of a couple of vertices (I think Stuat can correct me on this). But you're right about the buildings and radar alt. I suggest changing the signature of FGScenery::get_elevation_m to include a flag: surface only, and set the traversal mask accordingly. I will do just that today and report the results. I want this to be retro- compatible and no changes to other code that relies on get_elevation_m. Like I mentioned last night, not having to traverse all the random buildings, trees and whatnot speeds the intersect visitor result quite a lot, if only terrain elevation is desired. Any comments? Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
Hi replying to multiple posts here, I'll try to collect and answer to some arguments. First: I totally agree that our current nav/comm radio implementation is far from being realistic w.r.t. propagation of the radio signal close to or on the ground. This should be improved. I spent an hour or two reviewing your code and I still think your implementation should not be merged into the code base. Let me explain why. - Realism Your algorithm takes into account many factors responsible for radio probagation. Most of those factors are unknown in our data set and we have to use assumptions for their values. The less data we have and the more assumptions we have to use, the more unrealistic the algorithm's result become. My definition for realism is: Does the simulator compute the same value as I would expect in the same situation in real life? I strongly doubt the algorithm together with our limited set of data can provide this. In some cases, the used algorithm is plain wrong as we know by definition (ICAO rules) the propagation of the radio signal. - Performance The most important limiting factor for radio propagation on VHF and up is question line of sight or obscured by terrain. Your approach is to perform terrain samples along the line between the sender and receiver which is expensive. My idea for the newnavradio was to traverse the scenegraph along the straight line between sender and receiver and probe for ground intersection. This is basically the functionality as the probe for ground elevation, which could be reused. The difference of performance impact is dozens or even hundrets of scenegraph traversals compared to just one. - Landcover Landcover contributes only neglible compared to terrain obscucarion to the loss of signal strength. - Coding style * You copied parts of the terrain sampler from advanced weather. Better reuse existing code, probably modify so it suits both usecases. * Using long chains of if/else or switch/case makes code hard to read and is usually a good indication for a flaw in the software design. * I prefer named constants instead of numbers to imporve readability. Summary You obviously spent a lot of time implementing the itm algorithm as a subsystem and I feel sorry if it is discouraging for you or other potential contributers that I (and I am just speaking for myself) do not support this contribution. My apologies for not speaking up earlier. This implementation only adds a pseudo-realistic radio propagation simulation due to lack of real data at the cost of cpu intensive calculations and a complex new subsystem that has to be maintained over the time. The same pseude-realism could be achived by implementing an approximation for signal attenuation for line of sight and obscured propagation paths (probably as simple as distance-squared and distance-to-the-power-of-something). Neither your implementation nor my suggestion provides a realistic prediction of the radio signal quality, both are more or less approximations. It's the gain/pain ratio that differs significantly. Please forgive my my clear words - it's not my intention to offend anybody. Regards, Torsten Oh - one last thing: Committing code just because somebody spent much time writing it or not committing would be discouraging should never be a reason to do so. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
Hi Torsten, Regardless of the fact that you support or not the inclusion of this new radio code, I have to clear up some statements which are wrong. See below. I spent an hour or two reviewing your code and I still think your implementation should not be merged into the code base. Let me explain why. - Realism Your algorithm takes into account many factors responsible for radio probagation. Most of those factors are unknown in our data set and we have to use assumptions for their values. The less data we have and the more assumptions we have to use, the more unrealistic the algorithm's result become. My definition for realism is: Does the simulator compute the same value as I would expect in the same situation in real life? I strongly doubt the algorithm together with our limited set of data can provide this. In some cases, the used algorithm is plain wrong as we know by definition (ICAO rules) the propagation of the radio signal. The Longley Rice algorithm also known as the Irrregular Terrain Model is not plain wrong, since it is used in many applications that perform signal prediction on irregular terrain, with good accuracy. As far as I know, only Splat! is open-source, but a lot of commercial software uses this model, which has valid results between 40 MHz and 20 GHz. To call the algorithm plain wrong is a mistake in my opinion. The unknown factors and the assumptions you are referring to are mostly about radio gear: output power, receiver sensitivity, antenna gains. I have spent a lot of time reseaching avionics radio products to gain specs in order to cover these unknowns. - Performance The most important limiting factor for radio propagation on VHF and up is question line of sight or obscured by terrain. Not quite true. According to frequency, radio signals can be significantly diffracted over obstructions. The Longley-Rice model makes a clear distinction between these propagation models: Line of Sight, Single Horizon Diffraction, Double Horizon Diffraction, and Tropospheric Scatter. At frequencies below 140 MHz, signals behave very differently to what you call line of sight. True line-of-sight also has to take into account Fresnel zones, and can only be talked about at 1.5 GHz and up. Your approach is to perform terrain samples along the line between the sender and receiver which is expensive. True, but there is no other way to use the ITM algorithm to obtain a good result. I need to obtain a terrain profile, which is the reason for the performance issues. I have also written a simplified function which does not take terrain into account, for use on very long distances where terrain would not be a factor anymore. My idea for the newnavradio was to traverse the scenegraph along the straight line between sender and receiver and probe for ground intersection. This is basically the functionality as the probe for ground elevation, which could be reused. The difference of performance impact is dozens or even hundrets of scenegraph traversals compared to just one. You are correct. However your results would not be the same, and would be more inaccurate to those generated by ITM calculations. - Landcover Landcover contributes only neglible compared to terrain obscucarion to the loss of signal strength. Correct on lower VHF frequencies, incorrect as we move up into UHF. Can provide results and research papers to prove this. As far as the signal is line-of-sight, only intrusion into the first Fresnel zone is of interest. When diffraction over terrain edges are involved, I can assure you landcover plays a big role. - Coding style * You copied parts of the terrain sampler from advanced weather. Better reuse existing code, probably modify so it suits both usecases. * Using long chains of if/else or switch/case makes code hard to read and is usually a good indication for a flaw in the software design. * I prefer named constants instead of numbers to imporve readability. I will not discuss coding style here, only functionality. This implementation only adds a pseudo-realistic radio propagation simulation due to lack of real data It is the most realistic radio simulation that can be obtained. Please explain more about lack of real data, so I know what to research further. at the cost of cpu intensive calculations and a complex new subsystem that has to be maintained over the time. It's true, it's CPU intensive, and quite complex. Are you thinking only about recreational usage of Flightgear, or other purposes as well? I'm thinking of other applications besides recreational usage, but in any case, enabling this subsystem causes a 3-5 FPS drop on my 5 year old machine. The same pseude-realism could be achived by implementing an approximation for signal attenuation for line of sight and obscured propagation paths (probably as simple as distance-squared and distance-to-the-power-of-something). No. I have written a
Re: [Flightgear-devel] Real-Time Radio Propagation
In some cases, the used algorithm is plain wrong as we know by definition (ICAO rules) the propagation of the radio signal. Um... I would like to understand this statement. The algorithm has a physics model in. I am no expert in radio propagation, but after doing a bit of reading, by usual FG standards it seems to be a fairly sophisticated one. Which may still yield the wrong result now and then - but how can we know reality by definition? I understand how to judge the quality of a physics model by comparison with a measurement, but I don't understand how to judge the quality by comparing with a definition. I mean, if a signal doesn't propagate physically, then you can define whatever you like, it's not going to make it happen. Is it possible to educate me here? Does the simulator compute the same value as I would expect in the same situation in real life? I strongly doubt the algorithm together with our limited set of data can provide this. I think that's not a fair question to ask. Does any rendering scheme produce the light we would expect in the same situation in real life? Just barely sometimes, usually not. Does YaSim produce correct stall behaviour as we would expect in real life? I sort of doubt this. Isn't 'Is this better than the existing (or proposed) alternative?' rather than 'Is this 100% correct?' the more relevant question? Suppose we'd implement your counter-proposal implementing a single LOS check - how easy would it be to come up with test cases in which this yields wrong results? Judging by Adrian's posts, he seems to know quite well where LOS doesn't work. This may be difficult to do in practice, but at least conceptually the most realistic code is the one which gets most comparisons with reality right. So we'd really move away from single case evidence to a study of ~20 or so test cases in which we know the true result to say what is more realistic, otherwise at least I find this incredibly hard to judge. This is basically the functionality as the probe for ground elevation, which could be reused. The difference of performance impact is dozens or even hundrets of scenegraph traversals compared to just one. Somewhat related to the above - *if* the radio propagation model could be shown to be more realistic - what framerate loss would this be worth as compared to a faster, less realistic model? And does this question matter at all if this is implemented optionally - should not the user decide this? Neither your implementation nor my suggestion provides a realistic prediction of the radio signal quality, both are more or less approximations. It's the gain/pain ratio that differs significantly. I'm sorry, I don't see that from what you have written. Is there evidence to suggest that a LOS algorithm would be an approximation *of the same quality* as far as realism is concerned? I do appreciate that it is a much faster approximation. Oh - one last thing: Committing code just because somebody spent much time writing it or not committing would be discouraging should never be a reason to do so. I don't think I said that. I sure didn't mean it. My point is - suppose someone wants to write an ICBM simulation. Given the civil aviation nature of FG, that code has pretty much zero chance of being committed. It would be fair to let the person proposing to do this know that fact up front, and not wait a year till the code is developed and in a merge request. Making someone spend a lot of time if it can be known up front that the contribution is going to be rejected is unfair. Being unfair sends a discouraging message to others. That's what I am saying. (With regard to Adrian's code, I am well aware that factors like style, performance,... are also relevant). * Thorsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Thu, 13 Dec 2012, Adrian Musceac wrote: Please forgive my my clear words - it's not my intention to offend anybody. No offence taken. I understand your pain/gain argument and we agree to disagree on that. The pain is now taken care of, the gain is present. You are one of the project leaders, not me, so I must submit to whatever decisions you take. Um, no he's not. He just happens to be a contributor like the rest of us. :) There is no herder for the Free Range Cats that make up the FlightGear project. :) Frankly, I think your addition to FlightGear is fantastic and a needed feature for the non-entertainment side of the house. If the gamers don't like the small frame rate hit, they can just turn it off. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Wed, 12 Dec 2012 23:03:45 -, Vivian wrote in message 001201cdd8bc$f5eb6b30$e1c24190$@lineone.net: Don't we need radar altitude for buildings etc. for radar altimeters, but probably not trees? ..at some stage, tree canopies will be dense enough to mask the ground, or give double reflections, or some such. A radar altimeter needs to sample both the terrain and hard objects on it. ..tree canopies dense enough to mask the ground, are probably hard enough to make radar vendors scare their clients from touching or ignoring them. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Thu, 13 Dec 2012 16:29:49 +0200, Adrian wrote in message 201212131629.50248.kanto...@gmail.com: On Thursday, December 13, 2012 15:04:16 Renk Thorsten wrote: Somewhat related to the above - *if* the radio propagation model could be shown to be more realistic - what framerate loss would this be worth as compared to a faster, less realistic model? And does this question matter at all if this is implemented optionally - should not the user decide this? Hi Thorsten, Torsten, all, Regarding the performance, you are correct, the user can decide on what to spend the CPU cycles. But for the sake of documenting this issue, I have performed a test: The test is performed in standard condition: on ground, all terrain finished loading, visibility set to 40 miles, LOD range bare 6 meters, 3 stations tuned, each at limit of loaded terrain, approx 100 km medium distance to them. First image shows subsystem enabled, second shows subsystem disabled. I have highlighted with red the relevant areas in the images. As always, click for details. http://wiki.flightgear.org/File:Radio-perf7b.png Radio subsystem enabled. http://wiki.flightgear.org/File:Radio-perf9b.png Radio subsystem disabled. Notice DME indication has appeared. In both cases, the FPS observed was 39. In long flight tests, the FPS difference is more like 3-5 from disabled to enabled. Now, regarding terrain influence, modes of propagation, and clutter influence on diffraction at different frequencies, you can observe the details on the upper left of the images. I won't get into details anymore, because I have done that already in a couple of messages. If anyone wishes to add more information on the subject of performance, I invite you to use the wiki page: http://wiki.flightgear.org/Talk:Radio_propagation I'm open to any other technical questions regarding the radio propagation algorithms used. ..maybe add a commandline suggestion so we can hope to compare apples with apples and pears with pears etc? Without a commandline suggestion, you pile up all sorts of irrelevant factors such as which runway you took off from etc, whereby you may load a different set of tiles, _etc_. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Thursday, December 13, 2012 12:44:00 Torsten Dreyer wrote: Hi - Performance The most important limiting factor for radio propagation on VHF and up is question line of sight or obscured by terrain. Hi again Torsten, Apologising for keeping this subject up, but I rather enjoy technical discussions, especially based on tested mathematical models and data gathered in the field. Here is what technical knowledge has to say about line-of- sight at VHF (or even higher frequencies): ### Terrain features, and buildings, usually attenuate signals. (NB in some circumstances knife edge diffraction can enhance propagation beyond the horizon)### (from http://goo.gl/1la6M ) You can read more about Longley Rice there, especially the part where Longley Rice has been adopted as a standard by the FCC. Now for real data gathered by me in the field, which is consistent with ITM plots generated for the same locations. Case #1: Have one radio repeater station on 145 MHz, completely obstructed by a mountain edge. Distance between repeater site and mountain edge: ~40 km. As determined by me, acceptable and readable signal was present as low as 500 meters below the mountain edge: single horizon diffraction case. The mountain edge had no vegetation. Case #2: Have one radio repeater station on 440 MHz, completely obstructed by a mountain edge. Distance between repeater site and mountain edge: ~50 km. As determined by me, acceptable and readable signal was present as low as 300 meters below the mountain edge: single horizon diffraction case. The mountain edge had no vegetation. In both cases, no line of sight was ever present between the mobile station and the fixed station, and reflection was not possible. All signal was received from diffraction. Double horizon diffraction is possible too, depending on many factors, including how much power are you pumping into the transmitter. Sidney Shumate's improvements to the ITM, published in the latest IEEE Broadcast society newsletters, make this model the most reliable for irregular terrain. Unfortunately his modifications have a non commercial clause, but you can download, compile and test against the classic versions. Diffraction results will coincide with physical data gathered even more. I think we can close the optical line-of-sight debate now. Cheers, Adrian Regards, Torsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Wednesday, December 12, 2012 09:16:50 Renk Thorsten wrote: My suggestion is to include this feature, leave it off, and let anyone interested turn it on. +1 There may be many reasons to reject code, but they roughly fall into two categories: 1) the idea itself which is coded is not acceptable or 2) the actual implementation is not acceptable (unstable, degrading performance,...). Adrian has invested a fair share of time to make it work, and he introduced the project early on in this list. I think fairness asks that any argument of type 1) against including the code should have been given earlier. Otherwise the message sent to possible future contributors is quite negative. That said, I think doing realtime radio signal propagations is much more that we need and much more than we want. At least unless we are multi-threading and have a spare CPU for those computations. Personally I don't need such a feature, since I'm not so much interested in IFR. However, I think in many situations we do have spare CPU capacity (I usually do - with lots of shader work on, GPU speed seems the limiting factor), and I also think it should be up to the user how he wants to burn his hardware performance - VFR sightseeing people like me want detailed shaders, IFR people may want to turn terrain eye candy off but spend the framerate for radio signal propagation. So including the code as optional feature seems entirely fine to me, I don't think there's such a well-defined 'we' with the same wishlist. So I would also suggest to include it unless there are issues about stability, performance degradation if not running, which I'm not qualified to judge. * Thorsten Hi Thorsten, everybody, Thanks for the support messages. I have worked pretty hard to get this feature as stable and performant as possible. Regarding performance of the radio subsystem, I would like to make a technical statement. As most of you know, the main performance issues come from having to repeatedly sample terrain elevation for a large number of points. This is done though and osg::NodeVisitor, which traverses all nodes within the scenegraph which have a certain mask set (in our case, it's SG_NODEMASK_TERRAIN_BIT) Unfortunately, not only the terrain surface has this mask set, but also random objects, random trees, and 'random' buildings. They all share this mask, so an _get_elevation_ call will have to traverse through litterally thousands of nodes which are not related to the terrain surface. In order to improve the performance of the _get_elevation_ method, I have added a new mask, SG_NODEMASK_SURFACE_BIT, which is set only for the surface geometry loaded by the BTG loader. Of course, some other minor code had to be modified, especially for groundcache et al. Very minor modification, basically taking into account of this new nodemask. The BVH bounding boxes stuff has been accounted for (I think I didn't miss anything) Right now, I've modified the _get_elevation_ method to use only this new mask. The performance difference is almost twice as fast, if not more. However, since this might introduce unwanted changes in parts of the code that rely on having radar altitude also from buildings etc., I can write a new function to be used specifically for sampling terrain. I have performed a regular test, with the following parameters: terrain load distance set to 60 km (LOD bare), 3 stations tuned in (2 VOR, 1 VOR-DME), 10 or more minutes of flight. Result here: http://wiki.flightgear.org/File:Radio-perf2.png (enlarge for details). As you might notice, the radio subsystem is not the CPU cycle hungry monster it used to be. The amount of tiles loaded is shown on the map. With less view distance and less terrain, the system will be very CPU friendly but also give innacurate results. Keep in mind that are various other methods to reduce even further the CPU footprint: sample fewer points for an elevation profile, poll a station less often (what polling time would be reasonable for a mean speed of 200 kts?) and disabling landcover influence. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
Adrian wrote -Original Message- From: Musceac [mailto:kanto...@gmail.com] Sent: 12 December 2012 22:12 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Real-Time Radio Propagation On Wednesday, December 12, 2012 09:16:50 Renk Thorsten wrote: My suggestion is to include this feature, leave it off, and let anyone interested turn it on. +1 There may be many reasons to reject code, but they roughly fall into two categories: 1) the idea itself which is coded is not acceptable or 2) the actual implementation is not acceptable (unstable, degrading performance,...). Adrian has invested a fair share of time to make it work, and he introduced the project early on in this list. I think fairness asks that any argument of type 1) against including the code should have been given earlier. Otherwise the message sent to possible future contributors is quite negative. That said, I think doing realtime radio signal propagations is much more that we need and much more than we want. At least unless we are multi-threading and have a spare CPU for those computations. Personally I don't need such a feature, since I'm not so much interested in IFR. However, I think in many situations we do have spare CPU capacity (I usually do - with lots of shader work on, GPU speed seems the limiting factor), and I also think it should be up to the user how he wants to burn his hardware performance - VFR sightseeing people like me want detailed shaders, IFR people may want to turn terrain eye candy off but spend the framerate for radio signal propagation. So including the code as optional feature seems entirely fine to me, I don't think there's such a well-defined 'we' with the same wishlist. So I would also suggest to include it unless there are issues about stability, performance degradation if not running, which I'm not qualified to judge. * Thorsten Hi Thorsten, everybody, Thanks for the support messages. I have worked pretty hard to get this feature as stable and performant as possible. Regarding performance of the radio subsystem, I would like to make a technical statement. As most of you know, the main performance issues come from having to repeatedly sample terrain elevation for a large number of points. This is done though and osg::NodeVisitor, which traverses all nodes within the scenegraph which have a certain mask set (in our case, it's SG_NODEMASK_TERRAIN_BIT) Unfortunately, not only the terrain surface has this mask set, but also random objects, random trees, and 'random' buildings. They all share this mask, so an _get_elevation_ call will have to traverse through litterally thousands of nodes which are not related to the terrain surface. In order to improve the performance of the _get_elevation_ method, I have added a new mask, SG_NODEMASK_SURFACE_BIT, which is set only for the surface geometry loaded by the BTG loader. Of course, some other minor code had to be modified, especially for groundcache et al. Very minor modification, basically taking into account of this new nodemask. The BVH bounding boxes stuff has been accounted for (I think I didn't miss anything) Right now, I've modified the _get_elevation_ method to use only this new mask. The performance difference is almost twice as fast, if not more. However, since this might introduce unwanted changes in parts of the code that rely on having radar altitude also from buildings etc., I can write a new function to be used specifically for sampling terrain. I have performed a regular test, with the following parameters: terrain load distance set to 60 km (LOD bare), 3 stations tuned in (2 VOR, 1 VOR-DME), 10 or more minutes of flight. Result here: http://wiki.flightgear.org/File:Radio-perf2.png (enlarge for details). As you might notice, the radio subsystem is not the CPU cycle hungry monster it used to be. The amount of tiles loaded is shown on the map. With less view distance and less terrain, the system will be very CPU friendly but also give innacurate results. Keep in mind that are various other methods to reduce even further the CPU footprint: sample fewer points for an elevation profile, poll a station less often (what polling time would be reasonable for a mean speed of 200 kts?) and disabling landcover influence. Don't we need radar altitude for buildings etc. for radar altimeters, but probably not trees? A radar altimeter needs to sample both the terrain and hard objects on it. However, I watch this work with interest: I think it might make it worth reviewing the AG radar that I abandoned due to the impact on frame rate, and lack of realistic range because not enough tiles were loaded, Vivian Vivian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices
Re: [Flightgear-devel] Real-Time Radio Propagation, Was: Sqlite location
On Tuesday, December 11, 2012 00:40:16 Torsten Dreyer wrote: Hi, let me chime in here with a personal note, hoping it's not offending anybody. Hi Torsten, and thanks for your detailed message. Let me explain below why realistic radio propagation should be inside Flightgear, and aleviate some of the fears about performance (leaving aside the fact that I would leave the system disabled by default, except for those who are really interested, like flying in an area which requires realistic radio factors). Although I like having accurate and detailed computation of our real-world simulation, I'm not really a friend of the radio propagation code with the level of detail given. Please let me explain why that is the case: The radio stations used for aviation purpose certainly follow the same physical laws as any other radio station does. However, their performance have to adhere to some specific rules, mostly set up by the ICAO. Service volumes is on of these rules, a straight ILS final track is another etc. If real life's environment disturbes the performance of the radio stations, the operator has to work hard to override these environmental impacts. As we usually do not have any detailed information about how the radio station is set up (and I doubt, we will ever get those), it's close to impossible to correctly model radio probagation of a specific station. Well, it certainly is possible to take into account terrain, free-space loss, diffraction over mountain edges and other such stuff the ITM algorithms allow for. All I know is that now, sitting on the ground 88 km away from a VOR station, with hills in between, I have needle deviation. Impossible. Please consider that having realistic radio navigation according to terrain would be as far as I know a unique feature for any flightsimulator I've seen. To refuse to add such a realism enhancing feature would be quite illogic to me. Adding envirionmental factors besides terrain and terrain cover and the factors of aircraft installations will result in a wide range of uncertainty, spoiling all the detailed computation of the radio signal propagation. Terrain, terrain landcover, and frequency of station are exactly the factors involved in my calculations, the rest comes from published data and equipment specs available all over the web. If needed, I can bring on board a specialist, but I'd rather await request. If needed by a research project, any station can be tuned like in the real world, and evaluated within the simulator. As a pilot, I am usually just interested in the factor, if I am within the service volume of a radio station. If so, I'd expect a clear and correct indication, probably with the well-known system errors applied. If I am outside the service volume, the systems may show something, but I do not really care about what exactly an ILS indicator (as an example) is showing. I will make my case with just two screenshots, available from the wiki article, re: published volumes. http://wiki.flightgear.org/images/e/e0/Vor_no_itm.png no real radio http://wiki.flightgear.org/images/c/c6/Vor_itm.png realistic radio Or consider for DME equipment, which is very much more affected by terrain than VOR, due to the 10x times higher frequency: http://wiki.flightgear.org/File:Vor-no-dme.png :VOR with no DME due to propagation over edge of mountain for lower VHF freqs. http://wiki.flightgear.org/File:Vor-dme.png :VOR with DME measurement, once obstruction was cleared. From real life experience, I can say that barely two stations behave the same if you are outside their published range. Sidelobes of a localizer may appear at on site and may not at another site. False glideslopes appear here but do not show up somewhere else. It depends heavily on the local setup of the base equipment (and to some degree on aircraft installations). However, I have seen the shoreline effect of ADF stations deflection my ADF needle heavily and I have seen effects of nearby thunderstorms and lightning on the instruments. I'd love to see these effects modeled. If I remember correctly, Flightgear used to be used also in university projects, ARINC, etc. Has that changed? The ILS with it's two components is modelled rather simplistic right now. But still it's not possible to receive if obstructed by terrain, trees, buildings etc. Also, the fact that GS uses a higher, therefore more prone to terrain/clutter interference than LOC, is included. How would you feel to make an approach 10 km with a mountain turn like some airports in Swiss, and have ILS indication even while behind the mountains? That said, I think doing realtime radio signal propagations is much more that we need and much more than we want. At least unless we are multi-threading and have a spare CPU for those computations. Thanks to your patient advice and a lot of time spent tuning the system, I can say this: with 3 stations tuned in, the
Re: [Flightgear-devel] Real-Time Radio Propagation, Was: Sqlite location
On Tue, 11 Dec 2012 14:20:58 +0200 Adrian Musceac wrote: My suggestion is to include this feature, leave it off, and let anyone interested turn it on. I can't comment on the actual code, but from the repeated detailed descriptions of what it actually does, I think it would be a very great pity if it weren't seriously considered for inclusion. More than that, I can't see why it shouldn't be turned on by default (assuming the performance hit isn't significant) - isn't realism and accuracy what FlightGear is all about? I know that I've sometimes added what most people would think as silly details my models, things that possibly almost nobody has ever noticed... but it all helps to model reality which is the end objective after all! Cheers, AJ -- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation, Was: Sqlite location
I'm not a developer here, I just maintain one of the mirror sites. I would like to comment here a bit. Over the years I've seen several folks who contributed lots to the project leave after disputes over one thing or another. I'd hate to see this lead to something like that! I personally agree with these points, and the final one in particular: snip Please consider that having realistic radio navigation according to terrain would be as far as I know a unique feature for any flightsimulator I've seen. To refuse to add such a realism enhancing feature would be quite illogic to snip I know you are a pilot, fellow amateur radio operator and one of the leaders of the project. So please don't say that you would refuse a realism increasing option, which would not even have to be on by default, and which is not present in any other flightsim that I know of. It would be illogic, and would limit the options of using Flightgear in other environments, like research projects, university, aeronautical radio. It would also make a discouraging statement vs. contributing to Flightgear. snip My suggestion is to include this feature, leave it off, and let anyone interested turn it on. Regards: jj http://kingmont.com -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation, Was: Sqlite location
My suggestion is to include this feature, leave it off, and let anyone interested turn it on. +1 There may be many reasons to reject code, but they roughly fall into two categories: 1) the idea itself which is coded is not acceptable or 2) the actual implementation is not acceptable (unstable, degrading performance,...). Adrian has invested a fair share of time to make it work, and he introduced the project early on in this list. I think fairness asks that any argument of type 1) against including the code should have been given earlier. Otherwise the message sent to possible future contributors is quite negative. That said, I think doing realtime radio signal propagations is much more that we need and much more than we want. At least unless we are multi-threading and have a spare CPU for those computations. Personally I don't need such a feature, since I'm not so much interested in IFR. However, I think in many situations we do have spare CPU capacity (I usually do - with lots of shader work on, GPU speed seems the limiting factor), and I also think it should be up to the user how he wants to burn his hardware performance - VFR sightseeing people like me want detailed shaders, IFR people may want to turn terrain eye candy off but spend the framerate for radio signal propagation. So including the code as optional feature seems entirely fine to me, I don't think there's such a well-defined 'we' with the same wishlist. So I would also suggest to include it unless there are issues about stability, performance degradation if not running, which I'm not qualified to judge. * Thorsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation, Was: Sqlite location
Hi, let me chime in here with a personal note, hoping it's not offending anybody. Although I like having accurate and detailed computation of our real-world simulation, I'm not really a friend of the radio propagation code with the level of detail given. Please let me explain why that is the case: The radio stations used for aviation purpose certainly follow the same physical laws as any other radio station does. However, their performance have to adhere to some specific rules, mostly set up by the ICAO. Service volumes is on of these rules, a straight ILS final track is another etc. If real life's environment disturbes the performance of the radio stations, the operator has to work hard to override these environmental impacts. As we usually do not have any detailed information about how the radio station is set up (and I doubt, we will ever get those), it's close to impossible to correctly model radio probagation of a specific station. Adding envirionmental factors besides terrain and terrain cover and the factors of aircraft installations will result in a wide range of uncertainty, spoiling all the detailed computation of the radio signal propagation. As a pilot, I am usually just interested in the factor, if I am within the service volume of a radio station. If so, I'd expect a clear and correct indication, probably with the well-known system errors applied. If I am outside the service volume, the systems may show something, but I do not really care about what exactly an ILS indicator (as an example) is showing. From real life experience, I can say that barely two stations behave the same if you are outside their published range. Sidelobes of a localizer may appear at on site and may not at another site. False glideslopes appear here but do not show up somewhere else. It depends heavily on the local setup of the base equipment (and to some degree on aircraft installations). However, I have seen the shoreline effect of ADF stations deflection my ADF needle heavily and I have seen effects of nearby thunderstorms and lightning on the instruments. I'd love to see these effects modeled. That said, I think doing realtime radio signal propagations is much more that we need and much more than we want. At least unless we are multi-threading and have a spare CPU for those computations. This is certainly just my personal point of view. Greetings, Torsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
