Re: [Flightgear-devel] Which navradio code is considered standard?
Am 22.11.2012 20:44, schrieb ThorstenB: On 22.11.2012 10:08, Adrian Musceac wrote: I've gone ahead and used the new radio code for navaids, but I have a question: which navradio code is considered standard? newnavradio or navradio? navradio is the current/old standard, newnavradio is the new module. Most aircraft use navradio, few newnavradio. I'm not sure if there is a plan to switch/replace the old radio at some point, and whether the new module was compatible with the old etc. But for now, both are there. TorstenD is the expert here. The plan was to replace navradio by newnavradio. Due to an unhandled exception in my real-life's main loop, I have never been able to finish the transition and I will most likely not be able to soon. So please consider navradio as standard. Please, don't add too much code to the old navradio.?xx files but try to encapsulate new functionality within own classes and files and make them as reusable as possible. 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] Which navradio code is considered standard?
On Thursday, November 22, 2012 21:44:03 ThorstenB wrote: navradio is the current/old standard, newnavradio is the new module. Most aircraft use navradio, few newnavradio. I'm not sure if there is a plan to switch/replace the old radio at some point, and whether the new module was compatible with the old etc. But for now, both are there. TorstenD is the expert here. cheers, Thorsten Ok, here is a comparison using the classic navradio code before and after adding radio propagation calculations: Before: http://wiki.flightgear.org/images/e/e0/Vor_no_itm.png After: http://wiki.flightgear.org/images/c/c6/Vor_itm.png Test performed using C172p trying to receive DVA VOR/DME. The distance is approx 80 km with no line of sight (hills, small mountains, valleys). In both cases the aircraft is on ground, tuned to the frequency of the VOR/DME station. In the first case we have reception and needle deflection, in the second case, as we can clearly see to the right, the radio link budget is simply insufficient to clear the obstacles, despite the high power of the station. No reception, no needle deflection. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Which navradio code is considered standard?
On 23 Nov 2012, at 13:47, Adrian Musceac wrote: Ok, here is a comparison using the classic navradio code before and after adding radio propagation calculations: Suggestion: make a runtime switch, to build the 'new' nav-radio when the old one is asked for - this can be done via some logic in the instrument manager. This of course assumes the visible interface, i.e read / written properties, for the new code matches the old, possibly by adding some backwards compatibility properties. (Switch would be a bool prop like /sim/radios/use-new-radios) If there's a problem making the new code fit the old property API, then you have a bigger issue, but updating all the aircraft XML seems ridiculous - the current code exposes some slightly strange properties, but emulating them in the new code should not be a problem. So, make it a drop-in replacement, and make the drop-in automatic via an option. For the current release, we'll leave the default as the old code, and after the release is out, flip the default to be the new code, for testing by Git users. Comments? James -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Which navradio code is considered standard?
On Friday, November 23, 2012 15:56:01 James Turner wrote:
Hi James,
Suggestion: make a runtime switch, to build the 'new' nav-radio when the
old one is asked for - this can be done via some logic in the instrument
manager. This of course assumes the visible interface, i.e read / written
properties, for the new code matches the old, possibly by adding some
backwards compatibility properties.
(Switch would be a bool prop like /sim/radios/use-new-radios)
Obviously, I should have explained myself this issue: actually the change to
the navradio.cxx and newnavradio.cxx codebase is very small, only adding a
function to set some properties which are then dealt with by the radio
subsystem. I looks somewhat like this:
if( fgGetBool( /sim/radio/use-radio, false ) ) {
signal_quality_norm = computeSignalQuality(is_loc);
}
where I'm just using a new and rather simple function to get the signal
quality. The rest of the complicated stuff is happening inside the radio
subsystem. This can be enabled at start with --prop:/sim/radio/use-radio
as long with a set of other properties which are all explained detailed in
README.radio inside the minidocs.
If there's a problem making the new code fit the old property API, then you
have a bigger issue, but updating all the aircraft XML seems ridiculous -
the current code exposes some slightly strange properties, but emulating
them in the new code should not be a problem. So, make it a drop-in
replacement, and make the drop-in automatic via an option. For the current
release, we'll leave the default as the old code, and after the release is
out, flip the default to be the new code, for testing by Git users.
Comments?
Of course, no change whatsoever is needed. The classic navradio code as well
as newnavradio already determine the signal strength by some other means, I'm
just using more realistic calculations, that's all. No aircraft XML or
anything else to be updated, just a start-up switch and some other switches
which turn on detailed simulation of antennas, ground clutter attenuation and
other stuff. I took care to write a small guide for the minidocs.
The strange properties you noticed are just internals from the radio
subsystem, and can be used by someone who wants to do radio specific analysis.
If you want to take a look at the code, I'll upload a new branch to my
gitorious clone tonight.
Cheers,
Adrian
James
---
--- Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Which navradio code is considered standard?
Hi, I've gone ahead and used the new radio code for navaids, but I have a question: which navradio code is considered standard? newnavradio or navradio? Right now the new radio code is used inside newnavradio and works the same for VOR and ILS (i.e. no directional antennas yet for LOC/GS, will follow soon). Tested ok for all VOR stations in range, might need some tweaks to default values. Should I also add it to navradio.cxx? Which one will be used in the future? Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Which navradio code is considered standard?
On 22.11.2012 10:08, Adrian Musceac wrote: I've gone ahead and used the new radio code for navaids, but I have a question: which navradio code is considered standard? newnavradio or navradio? navradio is the current/old standard, newnavradio is the new module. Most aircraft use navradio, few newnavradio. I'm not sure if there is a plan to switch/replace the old radio at some point, and whether the new module was compatible with the old etc. But for now, both are there. TorstenD is the expert here. cheers, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Which navradio code is considered standard?
On Thursday, November 22, 2012 21:44:03 ThorstenB wrote: navradio is the current/old standard, newnavradio is the new module. Most aircraft use navradio, few newnavradio. I'm not sure if there is a plan to switch/replace the old radio at some point, and whether the new module was compatible with the old etc. But for now, both are there. TorstenD is the expert here. cheers, Thorsten Right, classic navradio is done too, but there's a small problem there. Localizer and glideslope would be in reality two different radio stations, with glideslope using frequencies upwards of 300 MHz and different propagation characteristics, antenna configurations etc. Right now ILS is treated as a LOC station only. If glideslope is added as a separate station in the future, it should be no problem, just a couple of lines to rewrite. Ok, so now when flying say 20 km from a VOR station we are tuned into, but we have a range of mountains between or a really big hill and we are nap of the earth, we won't be able to hear the VOR (nor an ILS for that matter), making flying in mountain areas more interesting. The directional radiation pattern used for LOC/GS equipment is a rather crude yagi with 4 elements. This can of course be replaced with something more realistic. Since my old merge request was mothballed for 6 months, I fear that my own branch and fg/next are diverging too much, even if I struggle to keep it updated. There are lots of improvements that I still have to make, but the old radio code which is now in fg/next should really be replaced with the new one which solves some serious issues and brings a lot of improvements. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
