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 free-space loss function exactly for that. Again, ITM is not "pseudo-realism", it is a well known and researched algorithm, which very recently has suffered even more improvements. Can provide details if necessary, I have followed for quite a while the IEEE Broadcast society newsletter detailing these improvements. > 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. It's impossible to achieve 100% percent realism, it's possible to get very close. > > 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. 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
