Re: [Flightgear-devel] [OT]: Range of radios
On Tue, Feb 13, 2007 at 05:49:48PM +, Steve Hosgood wrote: [...] > >So, Holger, if you arrange that all "radio transmission" packets in FG/MP > >carry the transmitter's wattage and the location of the source, you can work > >out the straight-line distance from yourself (call it 'd'), and then do > >something like: > >pkt = get_packet(); > >d = sqrt(sqr(my_x - pkt->x) + sqr(my_y - pkt->y) + sqr(my_alt - > >pkt->alt)); > >if (sqrt(pkt->transmitter_power)/d < my_receiver_sensitivity) > > /* I can't hear this guy */ > > chuck_packet(pkt); > >else > > decode_packet(pkt); > >This sort of thing would maybe allow ATC (who might have more sensitive > >radios) to hear people that the local Cessna pilots can't hear. And that > >might > >be quite realistic. The problem with a more sensitive radio is that real radio communication is unidirectional and my implementaion using VoIP is bidirectional based on conference rooms (a star topology). The range decision is made on the position of the plane towards the position of the tower. If this range is outside a specified range calculation (see your formula :-) and perhaps a threshold detection) the "plane"-client hangs up the "line". For the ATC this means that he can hear _every_ voice traffic on his frequency (he has an infinite sensitive radio). Because frequencies are often more than one time occupied (world wide) the "virtual frequency" is a combination of ICAO and frequency. > >To improve things, you might like to make sure that the straight-line > >distance 'd' between yourself and the transmitter does not get close to > >ground. You'd have to factor in curvature of the earth and any mountains if > >you wanted to get it right. If the straight line gets within a couple of > >wavelengths of ground, you start getting attenuation and multipath > >distortion > >and all sorts of stuff(*). For a first cut, ignore all that and just use 'd'! > >Notice also how you could arrange to degrade packets if they get received > >very close to your receiver's sensitivity (you could add noise, distortion > >etc) which again would add to realism. My code suggestion above just models > >an > >unrealistic sharp cutoff when the signal gets too weak, but IIRC aviation > >radio is AM deliberately because that's *not* how AM radio behaves as it > >nears > >the sensitivity limit. Ok, I see... your formula and a threshold detection for eliminating flapping should be a good practice. Thanks! Holger > >Steve. > >(*) The BBC (amongst others) have done a load of work in this area to do > >with > >predicting service-areas of radio and TV transmitters. Some of it is on the > >net. > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear remote "modules"
Ralf Gerlich writes: > Rob Ratcliff wrote: > > You could use an event distribution (Pub/Sub) paradigm based on > > something like the CORBA Notification Service (Event Service), the > > CORBA property service, the newer Data Distribution Service > (DDS) or > > something like the High Level Architecture (HLA). A CORBA ORB TAO > > supports communication across shared memory or sockets depending on > > where the clients and services are running. I know that TAO is used > > quite a bit for real time control systems communication for > the military. > > Do you know the order of magnitude of the real time deadlines > for the subsystem where TAO has been used? ICE from zeroc is interesting http://zeroc.com/ Cheers Norman - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear remote "modules"
On Tuesday 13 February 2007 02:21, Martin Spott wrote: > Did you already find one that matches ? > > Martin. If you want an example: Designing multimedia applications on real-time systems with SMP architecture Abstract Large real-time multimedia systems such as flight simulators have adopted multiprocessor architecture to handle the large amount of events and computations. Existing realtime scheduling algorithms designed for single-processor systems such as Rate Monotonic (RM) and Earliest Deadline First Algorithm (EDF) have very poor performance on multiprocessor systems. On the other hand, most online scheduling algorithms for multiprocessor systems have poor schedulability conditions for real-time applications. In this paper, we study different ways to design real-time applications on SMP machines. This one is interesting too: Implementation of a flight trainer simulator using a microprocessor based network: a system architecture selection report Abstract After a general introduction concerning flight simulator development problems and the goals of the study, functional and development requirements are specified and the needed computing capacity is evaluated. (The same methodology can be applied to any real-time embedded computer system.) Typical benchmarks are introduced and analytical expressions on the time spent on communication are explained for cases of common memory, Multibus II and VME. The conclusions indicate the preferred solution, why it was selected and intentions for continuation of this work in the immediate future. The methodology presented and the resulting solution provide a simple way for combining existing hardware elements to achieve a low-cost implementation. Did _you_ find any report that matches? If you did but can't access it, I can try and access it at my university. Ampere - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT]: Range of radios
On 02/13/2007 09:31 AM, Holger Wirtz wrote: > What I need is a simple number which should describe the > maximum range og a COM1. For example 5 km? oder 20 km??? As others have pointed out, the simple answer is "line of sight". See algorithms below. > COM1 in a Cessna is not as one of an Airbus. Both are limited by the line-of-sight rule, and by interference. Getting a "better" radio for your Cessna will not help at all. Contrary to what others have said, attenuation due to air / cloud / rain / snow is negligible at VHF frequencies. http://www.tapr.org/ve3jf.dcc97.html Except as noted below, a range of 500 km should be no problem for a modest aircraft radio (e.g. KX-165) ... in a line-of-sight situation. http://www.seaerospace.com/king/kx165.htm http://www.isghq.com/calc/path_lossmain.php 1) The most relevant /fundamental/ limitation to usability is frequency congestion. It does not matter if the receiver sensitivity is 2 microvolts or half that or a hundredth of that, if there is 10 microvolts of hash on the frequency. The re-usability of UNICOM frequencies /depends/ on the line-of-sight requirement, to avoid congestive interference from innumerable other users who are out of sight. High-altitude ATC sector frequencies are reusable, but the multiplicity factor is much, much less. A stuck mike can be considered an extreme form of congestion if you like. 2) The most relevant non-fundamental issue is local interference, e.g. from bad brushes in the aircraft alternator. Improving the specifications of the radio (better Tx power and/or better Rx sensitivity) will not help at all; the only thing that will help is to get rid of the interference. In an interference situation, ATC will be able to hear you, even if you are unable to hear them ... which is why pilots are trained to transmit "in the blind" periodic reports of their position and intentions. === Here's a quick and dirty way to tell if two aircraft are in range of each other: For each aircraft, calculate the distance to the horizon, based on the aircraft's height above the terrain. This gives you a "coverage circle". If the two circles overlap, you are in range. That is, if the sum of the radii exceeds the distance between the planes, you're in range. At the next level of fanciness, ask for the Cartesian coordinates of each airplane, interpolate 10 evenly-spaced points on the line between them, and check to see that each point is above the terrain. Ynlike the Q&D algorithm, this can -- roughly -- deal with the case where there is an isolated mountain or something between the two locations. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear remote "modules"
Ralf Gerlich wrote: >Hi, > >Rob Ratcliff wrote: > > >>You could use an event distribution (Pub/Sub) paradigm based on >>something like the CORBA Notification Service (Event Service), the CORBA >>property service, the newer Data Distribution Service (DDS) or something >>like the High Level Architecture (HLA). A CORBA ORB TAO supports >>communication across shared memory or sockets depending on where the >>clients and services are running. I know that TAO is used quite a bit >>for real time control systems communication for the military. >> >> > >Do you know the order of magnitude of the real time deadlines for the >subsystem where TAO has been used? > > > See http://www.cs.wustl.edu/~schmidt/PDF/words-02.pdf for some info on subject JW - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flightgear remote "modules"
Hi, Curt has pointed out some of the problems in using a non-real time operating system for real-time simulation but there are standards,software and hardware for this (see POSIX 1003.1d etc,real time linux,solaris,vxworks etc) although as has been mentioned portability is an issue. Also distributed systems are now "well-founded" (see various Beowulf papers,PVM,MPI etc) so there is scope there. Maybe the property lists could be promulgated using a simple "directory" style database (eg LDAP if it has the performance needed) as most modules will probably write properties to be read by other modules so simultaneous writing of a particular property will not be a problem. Maybe all this is a bit "academic" and I have been interested to read comments so will ferret around a bit and see what can be done. I am retired now but spent >30 years in Nuclear Physics doing real-time data acquisition,analysis and display on distributed systems and have some experience in graphics,networking,security etc but I dont want to spoil the fun for the youngsters!!! cheers Jim p.s. What really need is to get away from Von Neumann control flow architecture and have massively parallel dataflow machines - werent they called analogue computers?! - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear remote "modules"
Hi Ralf, I don't know the deadlines, but I know Doug Schmidt (author of Tao) would. His email is: [EMAIL PROTECTED] Malcolm Spence (of OCI that provide commercial support to this free and open source ORB) would have a good idea as well or could find out. His email is: [EMAIL PROTECTED] There are some benchmarks of various messaging systems and ORBs available at: http://www.atl.external.lmco.com/projects/QoS (The MW_Comparator allows you to compare the performance of many of the ORBs.) There are a ton of references available at: http://www.cs.wustl.edu/~schmidt/TAO.html that might have some information useful to you. Rob Ralf Gerlich wrote: Hi, Rob Ratcliff wrote: You could use an event distribution (Pub/Sub) paradigm based on something like the CORBA Notification Service (Event Service), the CORBA property service, the newer Data Distribution Service (DDS) or something like the High Level Architecture (HLA). A CORBA ORB TAO supports communication across shared memory or sockets depending on where the clients and services are running. I know that TAO is used quite a bit for real time control systems communication for the military. Do you know the order of magnitude of the real time deadlines for the subsystem where TAO has been used? Cheers, Ralf - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear remote "modules"
Hi, Rob Ratcliff wrote: > You could use an event distribution (Pub/Sub) paradigm based on > something like the CORBA Notification Service (Event Service), the CORBA > property service, the newer Data Distribution Service (DDS) or something > like the High Level Architecture (HLA). A CORBA ORB TAO supports > communication across shared memory or sockets depending on where the > clients and services are running. I know that TAO is used quite a bit > for real time control systems communication for the military. Do you know the order of magnitude of the real time deadlines for the subsystem where TAO has been used? Cheers, Ralf - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ILS service volume issues
On 02/10/2007 12:48 PM, John Denker wrote: > ... other service volume issues. > > The code has no understanding of how azimuth affects the > localizer. I fixed this. There are now six localizer courses: -- one front course -- one back course (reverse sensing) -- four false courses (two of which are reverse sensing) This greatly increases the realism of the LOC service volume. Now there is the possibility that the instrument student will get fooled by a seemingly-usable but deceptive LOC signal when outside the service volume ... which is a very real possibility in real life. This is rolled up in the same patch that fixes the ESV (extended service volume) range issue. http://www.av8n.com/fly/fgfs/navradio.diff There remain lots of warts and FIXMEs in navradio.cxx. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT]: Range of radios
Hello *, ok - that was one of my typical "need only one parameter" question :-) I see that this is not so easy as I thaught... but it is not an insolvable problem. I think I will put a more or less complex formula insite my range detection. Thanks all! Holger -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT]: Range of radios
Just a resend of a failed posting from earlier: I (Steve Hosgood) wrote: Anders Gidenstam wrote: On Tue, 13 Feb 2007, Holger Wirtz wrote: I know that exact range answers are depending from more parameters than only the output power... What I need is a simple number which should describe the maximum range og a COM1. For example 5 km? oder 20 km??? Hi, I think VHF transmissions are mostly limited to line of sight unless something unusual is going on.. You're right, Anders though the tricky bit is modeling the interactions between radios fitted in different classes of 'plane. Which is what I believe Holger is trying to do here. I'm not an expert either - expect at least three more people to pounce on my maths below :-) Here goes anyway It might be easiest to use an analog of real world parameters to get this sort of thing working right. Transmitters are typically rated in watts, receiver sensitivity is typically given in uV. The power received by a receiver is proportional to the power of the transmitter and inversely proportional to the square of the distance. The *voltage* received (which is what you want to know) is proportional to the square-root of that, i.e proportional to the square root of the transmitter power and inversely proportional to the distance itself. I think. So, Holger, if you arrange that all "radio transmission" packets in FG/MP carry the transmitter's wattage and the location of the source, you can work out the straight-line distance from yourself (call it 'd'), and then do something like: pkt = get_packet(); d = sqrt(sqr(my_x - pkt->x) + sqr(my_y - pkt->y) + sqr(my_alt - pkt->alt)); if (sqrt(pkt->transmitter_power)/d < my_receiver_sensitivity) /* I can't hear this guy */ chuck_packet(pkt); else decode_packet(pkt); This sort of thing would maybe allow ATC (who might have more sensitive radios) to hear people that the local Cessna pilots can't hear. And that might be quite realistic. To improve things, you might like to make sure that the straight-line distance 'd' between yourself and the transmitter does not get close to ground. You'd have to factor in curvature of the earth and any mountains if you wanted to get it right. If the straight line gets within a couple of wavelengths of ground, you start getting attenuation and multipath distortion and all sorts of stuff(*). For a first cut, ignore all that and just use 'd'! Notice also how you could arrange to degrade packets if they get received very close to your receiver's sensitivity (you could add noise, distortion etc) which again would add to realism. My code suggestion above just models an unrealistic sharp cutoff when the signal gets too weak, but IIRC aviation radio is AM deliberately because that's *not* how AM radio behaves as it nears the sensitivity limit. Steve. (*) The BBC (amongst others) have done a load of work in this area to do with predicting service-areas of radio and TV transmitters. Some of it is on the net. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT]: Range of radios
Martin Spott wrote: > Anders Gidenstam wrote: > >> On Tue, 13 Feb 2007, Holger Wirtz wrote: >> > > >>> What is the normal range for the Voice-COM-Equipment in a plane? >>> > > >> I'm no expert in this area but isn't most aviation radio communication in >> the VHF frequency range? I think VHF transmissions are mostly limited to >> line of sight unless something unusual is going on.. >> > > There's _always_ something usual going on - it's called "atmosphere" :-) > > As long as you're flying at several thousand feet over flat terrain > you're likely to be "in sight" of the station for quite some distance. > But even at good weather more than 60 nm - which I consider as a good > average for the given demand - is not very realistic, > > Martin. > Hi Range of radio comms, assuming Line-of-Sight path, is a function of transmitter power, aerial gain and distance. If you google path loss calculations you'll come up with several good references. If you assume 25w transmitter power (IIRC is 17dBW), 3dB transmitter aerial gain and 0dB receive (aircraft) aerial gain and plug those into the formula then you'll get a reasonable figure... this ignores such "atmospheric" phenomonen as rain attenuation, ducting etc. Cheers Dene NZWN - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT]: Range of radios
Anders Gidenstam wrote: > On Tue, 13 Feb 2007, Holger Wirtz wrote: > > What is the normal range for the Voice-COM-Equipment in a plane? > I'm no expert in this area but isn't most aviation radio communication in > the VHF frequency range? I think VHF transmissions are mostly limited to > line of sight unless something unusual is going on.. There's _always_ something usual going on - it's called "atmosphere" :-) As long as you're flying at several thousand feet over flat terrain you're likely to be "in sight" of the station for quite some distance. But even at good weather more than 60 nm - which I consider as a good average for the given demand - is not very realistic, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT]: Range of radios
Am Dienstag, 13. Februar 2007 15:31 schrieb Holger Wirtz: > power... What I need is a simple number which should describe the > maximum range og a COM1. For example 5 km? oder 20 km??? No such constant number. It highly depends on - elevation of the ground station - height above ground of the aircraft - terrain IIRC there is a rough approximation for the range of a VOR: range in NM equals 1.2 times sqrt( altitude in feet) That leads to 50 NM at 2000ft 75 NM at 4000ft 120 NM at FL100 170 NM at FL 200 I live some 10 NM from EDDH with nearly undisturbed line of sight and the tower is barely receivable with an icom handheld. So I think starting with a range of 10 NM on ground is reasonable. Greetings, Torsten - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT]: Range of radios
On Tue, 13 Feb 2007, Holger Wirtz wrote: > I think I will present a beta-release of the VoIP-Com-Package for FG the > next weeks. For realism purposes I have a simple question: > What is the normal range for the Voice-COM-Equipment in a plane? I think > that a COM1 in a Cessna is not as one of an Airbus. I know that exact > range answers are depending from more parameters than only the output > power... What I need is a simple number which should describe the > maximum range og a COM1. For example 5 km? oder 20 km??? Hi, I'm no expert in this area but isn't most aviation radio communication in the VHF frequency range? I think VHF transmissions are mostly limited to line of sight unless something unusual is going on.. See t.ex. http://en.wikipedia.org/wiki/VHF Cheers, Anders -- --- Anders Gidenstam mail: andersg(at)gidenstam.org WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear remote "modules"
On Monday 12 February 2007 19:10, Curtis Olson wrote: > On 2/12/07, leee wrote: > > On Monday 12 February 2007 17:54, Jim Campbell wrote: > > > Hi, > > > Curtis has already hinted as to how the following may be done with his > > > "remote" FDM. > > > To my mind flightgear can be broken down into distinct plugin > > > "modules". There is the FDM, the "external world" visualisation,the > > > cockpit input and output (ie joystick,pedals,switches and displays) and > > > possibly a motion system. These can be interconnected with some inter > > > process communication scheme. All of the modules could be run on a SMP > > > hardware (e.g dual dual-core cpus) or on separate computers. There has > > > been some discussion on multi-threading which would handle the first > > > (via shared memory IPC perhaps) but without an operating system that > > > can migrate threads to other networked processors then I think a more > > > flexible approach may be "self-contained" modules communicating by > > > passing "properties" over TCP. The "remote" FDM is already a > > > possibility and there is an example of a remote joystick but how easy > > > would it be to break up the rest of flightgear? Any ideas anyone? > > > cheers > > > Jim > > > > I too think that this would be the best approach for making FG MPP > > compatible. > > > > The greatest cpu hog, so I believe, is the graphics subsystem but even > > though > > the other subsystems don't require as much processing power they are > > still limited in the resources they get. For example, while I was doing > > a couple > > of tests for what appears to be an A/P problem I noticed that the rate of > > the > > controllers were varying even though I'd specified a period. This > > is certainly going to result in some unpredictable behaviour across > > different systems and I wouldn't be surprised if some of the other > > subsystems are equally limited in their rates. > > This is all very interesting stuff to think about and discuss, but it's > also very difficult stuff too. As soon as you start splitting out modules > into separate processes/threads/cpu's, timing issues start becoming very > critical. Often times, things that are very simple and straightforward to > implement in a single thread, become extremely difficult and cantankerous > when trying to move to distributed architecture. > > As Lee points out, the limiting factor is the graphics rendering which used > to take upwards of 90-95% of the work load last time I did some profiling. > > The AP timing is a problem ... but that's more a side effect of too many > cooks in the stew I think. At one point I had setup the AP to run along > with the FDM loop so the two were tied together and ran at the same update > rate with the same dt. That was changed (and I think was changed a long > time ago) so the AP runs at graphics update rates ... as you point out, > these are not necessarily consistant and will definitely change across > different installations. But this particular problem is fixable within the > current context of FlightGear. > > Personally, I think the most sane approach with the highest chance of > succeeding will be to pick some particular submodule that really makes > sense to run on another machine or in a separate process and figure out how > to split that off. > > Otherwise you are probably going to be wrestling with a complete > reachitecting of the entire FlightGear structure. Things like the property > system work great in a single thread application, but start to break down > when you split modules off into separate computers ... how do you > effeciently and robustly replicate the property system across a distributed > set of PC's, especially if you want any remote module to be able to change > any property at any time? Might be a fun project for someone's phd thesis > if they are specializing in distributed systems. :-) > > Curt. I agree that the approach you suggest, of starting with a single subsystem/module is probably the best way to start tackling this issue. I think that there are two aspects to this issue - performance and mpp capability - perhaps they could be viewed as two sides of a single 'coin'. Ultimately, mpp is inevitable because it is the only realistic way of achieving potentially un-limited processing power and we are seeing the general acceptance of this principle with the current generation of multi-core x86 processors. Even these, however, are only a relatively early step in that direction and I think that the arrival of the cell processor represents the next step after that. As the hardware continues to develop in this direction high-performance software has to follow it if it's not to be left behind. Although FG doesn't need to be mpp capable right now, in a few years it will and now is probably a good time to start thinking about it if a _good_ solution is to be found by the time that it's needed. LeeE ---
Re: [Flightgear-devel] Flightgear remote "modules"
Curtis Olson wrote: > > > Otherwise you are probably going to be wrestling with a complete > reachitecting of the entire FlightGear structure. Things like the > property system work great in a single thread application, but start > to break down when you split modules off into separate computers ... > how do you effeciently and robustly replicate the property system > across a distributed set of PC's, especially if you want any remote > module to be able to change any property at any time? Might be a fun > project for someone's phd thesis if they are specializing in > distributed systems. :-) > You could use an event distribution (Pub/Sub) paradigm based on something like the CORBA Notification Service (Event Service), the CORBA property service, the newer Data Distribution Service (DDS) or something like the High Level Architecture (HLA). A CORBA ORB TAO supports communication across shared memory or sockets depending on where the clients and services are running. I know that TAO is used quite a bit for real time control systems communication for the military. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [OT]: Range of radios
Hi all, sorry that I had breaking off my activities for voice communication for FlightGear the last months... I was ill and had pretty much to work. Ok, I have anymore much to work... I think I will present a beta-release of the VoIP-Com-Package for FG the next weeks. For realism purposes I have a simple question: What is the normal range for the Voice-COM-Equipment in a plane? I think that a COM1 in a Cessna is not as one of an Airbus. I know that exact range answers are depending from more parameters than only the output power... What I need is a simple number which should describe the maximum range og a COM1. For example 5 km? oder 20 km??? Thanks, Holger -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] incorrect altimetry
Dave Perry wrote: > On Mon, 2007-02-12 at 21:18 -0500, John Denker wrote: > > >> > When will you put this in cvs? >> >> Ha, funny joke. >> >> > If you want to do the one-for-all function, the sooner the better. > > I hope I did not offend by poking, reading, and questioning. I know I > like it when someone reads seriously and carefully what technical papers > I have written. Thanks again for the effort. It took a while for your > vision to sink in. > > Regards, > Dave > > I think the point is that John doesn't have CVS write access... :-) Since the experts seem to agree that this is a good patch: Can somebody take care of committing it? If not, I'd do it, but then it wouldn't be until at least mid-april Cheers, Durk - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
