[Flightgear-devel] RFD: FlightGear and the changing state of air navigation

[David Megginson]

The airspace system is in the process of changing drastically, and I'm
following it this summer by finally biting the bullet and installing an IFR
GPS (Garmin GTN 650 <https://buy.garmin.com/en-CA/CA/p/67884>) and ADS-B
transponder (Garmin GTX 345 <https://buy.garmin.com/en-CA/CA/p/140949>) in
my Piper Warrior II.

What this means that for the first time in the 15 years since I started
flying in real life, I won't be able to use FlightGear to practice the IFR
approaches I'm flying in real life.

Note that this isn't just a matter of throwing up a canvas showing some GPS
waypoints and a magenta line. Modern navigators are astoundingly-complex
devices — probably an order of magnitude more lines of code than FlightGear
itself — and even their basic flight planning algorithms and databases
(e.g. fly-by waypoints vs fly-over waypoints, open vs closed approach
procedures, transitions into RNAV approaches, etc.) are far beyond the
scope of anything we've tried, and we'd also need an up-to-date database
far more complex than the ones we have now. Once you get to the extra
features, like FIS-B weather or TIS-B traffic info over ADS-B, or TAWS
(terrain alerting), we're probably in way over our heads trying to emulate
even the simplest general-aviation IFR GPS.

I don't have an easy solution — even with our amazing team of volunteer
developers, I doubt we have the capacity to pull this off — but then I
wonder whether that means that the usefulness of FlightGear will also
gradually taper off. Maybe we'll be able to connect to external simulators
for these units, and just accept not seeing them in the 3D cockpit.

Thoughts?


Cheers, David

p.s. If you have access to an iOS device or Windows PC, you can download
the GTN emulators from this links to see how complex even basic devices
are: https://itunes.apple.com/ca/app/garmin-gtn-trainer/id479670018?mt=8 |
http://www8.garmin.com/support/download_details.jsp?id=9256

[legoboyvdlp R]

One thing that is very important moving into the future is the RF approach
(radius to fix). Please read this:
https://en.wikipedia.org/wiki/Performance-based_navigation#RNAV_and_RNP_specific_functions
One example of an RF-style approach is
Loading Image...; please also read
this:
https://bruceair.wordpress.com/tag/radius-to-fix/.

This style of RNAV approach is becoming more and more common, and
FlightGear cannot yet simuolate it.
Jonathan

On Mon, Jul 3, 2017 at 2:17 AM, John Denker via Flightgear-devel <

Executive summary: This is reeeeeeally important.

Post by David Megginson
The airspace system is in the process of changing drastically, and I'm
following it this summer by finally biting the bullet and installing an

IFR

Post by David Megginson
GPS (Garmin GTN 650 <https://buy.garmin.com/en-CA/CA/p/67884>) and ADS-B
transponder (Garmin GTX 345 <https://buy.garmin.com/en-CA/CA/p/140949>)

in

Post by David Megginson
my Piper Warrior II.
What this means that for the first time in the 15 years since I started
flying in real life, I won't be able to use FlightGear to practice the

IFR

Post by David Megginson
approaches I'm flying in real life.[snip]
I don't have an easy solution — even with our amazing team of volunteer
developers, I doubt we have the capacity to pull this off — but then I
wonder whether that means that the usefulness of FlightGear will also
gradually taper off. Maybe we'll be able to connect to external

simulators

Post by David Megginson
for these units, and just accept not seeing them in the 3D cockpit.
Thoughts?

1) A year and a half ago some efforts were made in this direction. Then
On 01/26/2016 07:51 AM, Laurent wrote [..........]
Subject: G1000 implementation based on HTML/Phi
2) As I tell my students in real life: Don't get intimidated or hypnotized
by the huge number of features. 90% of the value comes from 10% of the
features. Actually that's becoming more and more of an understatement.
With rare exceptions, you can ignore the features you're not using.
This is relevant to FG in the sense that it is not important to implement
all the features. Most can be left out in the short term, and some can
be left out forever.
3) Somebody should approach Garmin and see if they want to cooperate.
They might want to. They might even release an open-source version
of their simulator. If they don't want to go that far, they might
release an opaque blob with a documented API that FG could call.
This is reeeeeally important.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Michael]

And in terms of comm's that I'd like to look (I need some research first
though): CPDLC. In this case huge DB updates should not be needed.

Post by legoboyvdlp R
One thing that is very important moving into the future is the RF approach
https://en.wikipedia.org/wiki/Performance-based_navigation#
RNAV_and_RNP_specific_functions
One example of an RF-style approach is https://bruceair.files.
https://bruceair.wordpress.com/tag/radius-to-fix/.
This style of RNAV approach is becoming more and more common, and
FlightGear cannot yet simuolate it.
Jonathan
On Mon, Jul 3, 2017 at 2:17 AM, John Denker via Flightgear-devel <

Executive summary: This is reeeeeeally important.

Post by David Megginson
The airspace system is in the process of changing drastically, and I'm
following it this summer by finally biting the bullet and installing an

IFR

Post by David Megginson
GPS (Garmin GTN 650 <https://buy.garmin.com/en-CA/CA/p/67884>) and

ADS-B

Post by David Megginson
transponder (Garmin GTX 345 <https://buy.garmin.com/en-CA/CA/p/140949>)

in

Post by David Megginson
my Piper Warrior II.
What this means that for the first time in the 15 years since I started
flying in real life, I won't be able to use FlightGear to practice the

IFR

Post by David Megginson
approaches I'm flying in real life.[snip]
I don't have an easy solution — even with our amazing team of volunteer
developers, I doubt we have the capacity to pull this off — but then I
wonder whether that means that the usefulness of FlightGear will also
gradually taper off. Maybe we'll be able to connect to external

simulators

Post by David Megginson
for these units, and just accept not seeing them in the 3D cockpit.
Thoughts?

1) A year and a half ago some efforts were made in this direction. Then
On 01/26/2016 07:51 AM, Laurent wrote [..........]
Subject: G1000 implementation based on HTML/Phi
2) As I tell my students in real life: Don't get intimidated or hypnotized
by the huge number of features. 90% of the value comes from 10% of the
features. Actually that's becoming more and more of an understatement.
With rare exceptions, you can ignore the features you're not using.
This is relevant to FG in the sense that it is not important to implement
all the features. Most can be left out in the short term, and some can
be left out forever.
3) Somebody should approach Garmin and see if they want to cooperate.
They might want to. They might even release an open-source version
of their simulator. If they don't want to go that far, they might
release an opaque blob with a documented API that FG could call.
This is reeeeeally important.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Torsten Dreyer]

Post by legoboyvdlp R
One example of an RF-style approach is
https://bruceair.files.wordpress.com/2012/07/image.png; please also read
https://bruceair.wordpress.com/tag/radius-to-fix/.
This style of RNAV approach is becoming more and more common, and
FlightGear cannot yet simuolate it.

In the old fashioned world of non-glass-no-gps-cockpits, this used to be
called a DME-ARC. Much fun to practice and perfectly flyable inside
FlightGear :-)

[David Megginson]

Thanks, everyone, for the responses.

Torsten: yes, DME arc transitions still exist, and I enjoy flying them both
in FlightGear and in real life. There are two important differences for the
radial-to-fix transitions (as I understand so far, still studying up the
new-to-me RNAV procedures):

1. You can fly them around any fix, not just a DME/TACAN (typically
colocated with a VOR). Granted, you could do that in FlightGear now simply
by using the GPS distance, but ...
2. The CDI actually gives you (and the autopilot) guidance for where you
should be flying, so you're not manually estimating your course based on
the DME/GPS distance while flying 90° to the navaid bearing.

It's the second one that will trip us up for using FlightGear as a way to
practice modern IFR procedures.


Cheers, David

Post by Torsten Dreyer

Post by legoboyvdlp R
One example of an RF-style approach is
https://bruceair.files.wordpress.com/2012/07/image.png; please also read
https://bruceair.wordpress.com/tag/radius-to-fix/.
This style of RNAV approach is becoming more and more common, and
FlightGear cannot yet simuolate it.

In the old fashioned world of non-glass-no-gps-cockpits, this used to be
called a DME-ARC. Much fun to practice and perfectly flyable inside
FlightGear :-)
--
Torsten Dreyer
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Thorsten Renk]

Post by Stuart Buchanan
with perhaps some help from the Shuttle team

(...)

Post by Stuart Buchanan
The CDI actually gives you (and the autopilot) guidance for where you
should be flying, so you're not manually estimating your course based on
the DME/GPS distance while flying 90° to the navaid bearing.
It's the second one that will trip us up for using FlightGear as a way
to practice modern IFR procedures.

Admittedly I didn't get what the problem is.

Are you wondering about the math to give you a guidance target for flying
around a given point? Or are you wondering how to render the 'fly-to'
indicator?

The first basically is the same as the Shuttle HAC intercept where Rdot
(the derivative of the radius to the center point) in combination with R
can be used as error for guidance and the second depends on your
particular instrument - the Shuttle HUD shows a corresponding indicator
(and so does the PFD) - but I suspect the instrument of choice of a GA
aircraft will display it differently.

So this should be possible to code by any aircraft maintainer without much
fuss as far as I can see.

* Thorsten

[Stuart Buchanan]

Hi Thorsten,

Post by Thorsten Renk

Post by Stuart Buchanan
with perhaps some help from the Shuttle team

(...)

Post by Stuart Buchanan
The CDI actually gives you (and the autopilot) guidance for where you
should be flying, so you're not manually estimating your course based on the
DME/GPS distance while flying 90° to the navaid bearing.
It's the second one that will trip us up for using FlightGear as a way to
practice modern IFR procedures.

Admittedly I didn't get what the problem is.
Are you wondering about the math to give you a guidance target for flying
around a given point? Or are you wondering how to render the 'fly-to'
indicator?

I was more thinking about the experience the team has in writing complex
in-aircraft UIs using Canvas. From what little I know of the G1000, it has
multiple pages of data with data entry for flightplans etc. I'm sure there is
a lot that has been learned by the Shuttle team that can be passed on
as "best practise".

The Route Manager should be able to handle most of the "magenta line"
tasks, but it may be that the more complicated routing such as the RF
approach, fly-by vs fly-over requires some new autopilot coding as you
describe.

-Stuart

[Stuart Buchanan]

Hi All,

I don't have an easy solution — even with our amazing team of volunteer
developers, I doubt we have the capacity to pull this off — but then I
wonder whether that means that the usefulness of FlightGear will also
gradually taper off. Maybe we'll be able to connect to external simulators
for these units, and just accept not seeing them in the 3D cockpit.

I think there has been some development in this area for some time, but it's not
clear how complete it is in terms of going beyond a PFD displaying basic flight
information digitally.

For example zakh on the forum has been developing a Garmin G1000 clone called
the zkv1000:

https://forum.flightgear.org/viewtopic.php?f=14&t=32056

The DA-42 model uses some form of G1000 as well - which may be an older
version of the zkv1000.

I agree with John that this is something we need to address, as our GA
aircraft will otherwise become more and more old-fashioned.

I'm more optimistic than David - I think we _do_ have the capability to
write this - for example just look at the complexity of the Shuttle model.

I'd really love it if the c172p/c182 team were to develop a G1000-equipped
variant of their aircraft. I suspect they are a tight enough team to
achieve it,
with perhaps some help from the Shuttle team who now have a huge amount
of experience developing canvas displays. This is well outside my area of
expertise, but I'd be happy to provide assistance if I can.

-Stuart

[Thorsten Renk]

My experience is, that Canvas is a real huge framerate eater.
Space-Shuttle, Extra 500, and the Airbus-Family in developement in the
forum gives me framerates in a single-digit range.
Compared with the good, old-fashioned aircraft we speak about factor of
5-10 difference in framerates.

Speaking for the Shuttle, that has very little to do with canvas as such.
There are 11 MDUs on the Shuttle flightdeck, and the way the Shuttle
avionics works, they typically display close to a hundred values each, so
that's of the order of ~1000 different parameters that need to be
simulated, fetched and displayed _per update cycle_ (and yeah, most
parameters you see are really simulated and not just unchanging text). If
you compare that with showing ~30 different parameters for a simple GA
craft, it's naively ~30 times slower for obvious reasons.

Try that kind of stunt with a good old-fashioned cockpit, and you'll be
lucky to still see single digits... Conversely, displaying the amount of
information the analogue gauges of a C-182 hold on a canvas is probably
cheaper than doing it by animating 3d mesh.

Add to that complexity hundreds of working switches in the Shuttle cockpit
(all by necessity different objects slowing down rendering), the ADI ball
which is special in that it has to display a true 3-axis rotation not
needed for aircraft and a detailed 3d cockpit, and you see the real
framerate eaters.
Blaming canvas for the sheer complexity of the Shuttle is pointing the
finger the wrong direction.

Structured in a reasonable way (i.e. minimizing property I/O in update
cycles, avoiding canvas pitfalls which trigger high performance needs etc.
) canvas is pretty fast (kind of reminds me of the old 'Nasal is slow'
discussions... it's still the same things which are slow, except canvas
hides it behind some abstraction - understand property I/O, and it'll run
fast)

* Thorsten

[geneb]

Post by Thorsten Renk

Post by Thorsten Renk
Speaking for the Shuttle, that has very little to do with canvas as such.
There are 11 MDUs on the Shuttle flightdeck, and the way the Shuttle

avionics works,

Post by Thorsten Renk
they typically display close to a hundred values each, so that's of the

order of ~1000 different parameters that need to be simulated,

Post by Thorsten Renk
fetched and displayed _per update cycle_ (and yeah, most parameters you

see are really simulated and not just unchanging text).

Post by Thorsten Renk
If you compare that with showing ~30 different parameters for a simple GA

craft, it's naively ~30 times slower for obvious reasons....
I'm aware of that the Space Shuttle is one of the most complex machines ever
built, and you simulate a whole lot of it.
But don't underestimate the complexity of todays avionics for GA!

This may help folks understand what the G1000 is all about.
http://static.garmincdn.com/pumac/190-00498-07_0A_Web.pdf
Writing a G1000 isn't that hard. Writing a *feature complete* G1000 is a
metric f***ton of work. ;)

Post by Thorsten Renk
Canvas is more than some happy little SVG-objects, which must be drawn- those
happy little drawn SVG-Objects must be driven somehow, and that's done by
nasal. And those fancy nasal-scripts must simulate or use properties, so that
we get those features mentioned above - and all this together costs.
Heiko

Heiko, what video card are you using?

g.

[Thorsten Renk]

Post by geneb
This may help folks understand what the G1000 is all about.
http://static.garmincdn.com/pumac/190-00498-07_0A_Web.pdf
Writing a G1000 isn't that hard. Writing a *feature complete* G1000 is
a metric f***ton of work. ;)

Browsing that, I still stand by my statement that this doesn't have more
than 50 unique parameters you need to update per cycle - for most pages
significantly less.

All the config pages have lots of items - but you only need to update them
when they change. All the fancy airport and weather charts absolutely do
not need updates per-frame - your airport isn't going anywhere or changing
in a hurry - you can just draw the whole layer _once_ before you bring it
on-screen and then use a global transform to move it as the plane moves
and run lazy updates on the edges. Precipitation you can update whenever
FG updates precipitation (every few minutes). Most maps can be done as
cheap raster images rather than vector data (the Saab Viggen just
downloads them on the fly for instance).

So yeah, it's a lot of work to code all these displays which someone has
to do, but there's no reason to assume it'd be hopeless performance-wise.

* Thorsten

[Stuart Buchanan]

Hi All,

Pulling a number of comments together.

Post by Thorsten Renk
Canvas is more than some happy little SVG-objects, which must be drawn-
those happy little drawn SVG-Objects must be driven somehow, and that's done
by nasal. And those fancy nasal-scripts must simulate or use properties, so
that we get those features mentioned above - and all this together costs.

I do think we need to be realistic here: The G1000 is a fairly significant
piece of computer hardware that we're going to emulate. It's not going to be
"free" particularly for those on older hardware that's already struggling.

However, hopefully we can offload a chunk of the logic (route management,
autopilot/flight director) to the core, and do things like offline generation
of terrain maps to minimize the impact.

Post by Thorsten Renk
The sad truth is, a lot of FG simmers are stuck using hardware 10
years behind! We shouldn't loose sight of that. On the other hand,
we should be looking forward! But expecting a 1080 for every user is
a stupid illusion...
Many people are frustrated, because we keep on growing into more
hardware requirements. This is sad, but unavoidable. In my humble
opinion anway! I'd love to support WinXP hardware, but I'd much more
love to have the latest eye candy on my screen at no cost at best.

I think we do a pretty good job of supporting older hardware. If anything, the
core itself is getting more efficient, and we have had releases with non-trivial
performance improvements.

The flip side is that aircraft models are becoming more advanced, and
we introduce features such as the OSM buildings that require more powerful
hardware. The latter are always optional, and I put a lot of effort into
ensuring that when such features are off they have no impact on users.
For example, if you disable OSM buildings, they won't even be downloaded
by Terrasync.

Complex aircraft models are a trickier topic. It may be that users of older
hardware simply won't be able to run a G1000-equipped C182T, and will
have to run an older steam-gauge version.

-Stuart

[David Megginson]

To make the discussion a little more concrete, here's an example. When
you're flying an IFR approach with a GPS navigator, you can use RNAV for
the transitions, but need to switch to the ground ILS transmitter for the
actual approach (they both use the same CDI on many planes, so it's easy to
miss). The GTN 650 that I'm installing in my plane will switch CDI mode
automatically under certain conditions, but it's not guaranteed.

In the past, I could practice the hell out of these kinds of details in
FlightGear (tuning, twisting, and identifying all the navaids, adding
crosswind corrections, etc) so that they were habits when I flew them for
real, but I can't practice RNAV procedures like this (or many others).

Cheers, David

Post by Stuart Buchanan
Hi All,
Pulling a number of comments together.

Post by Thorsten Renk
Canvas is more than some happy little SVG-objects, which must be drawn-
those happy little drawn SVG-Objects must be driven somehow, and that's

done

Post by Thorsten Renk
by nasal. And those fancy nasal-scripts must simulate or use properties,

so

Post by Thorsten Renk
that we get those features mentioned above - and all this together costs.

I do think we need to be realistic here: The G1000 is a fairly significant
piece of computer hardware that we're going to emulate. It's not going to be
"free" particularly for those on older hardware that's already struggling.
However, hopefully we can offload a chunk of the logic (route management,
autopilot/flight director) to the core, and do things like offline generation
of terrain maps to minimize the impact.

Post by Thorsten Renk
The sad truth is, a lot of FG simmers are stuck using hardware 10
years behind! We shouldn't loose sight of that. On the other hand,
we should be looking forward! But expecting a 1080 for every user is
a stupid illusion...
Many people are frustrated, because we keep on growing into more
hardware requirements. This is sad, but unavoidable. In my humble
opinion anway! I'd love to support WinXP hardware, but I'd much more
love to have the latest eye candy on my screen at no cost at best.

I think we do a pretty good job of supporting older hardware. If anything, the
core itself is getting more efficient, and we have had releases with non-trivial
performance improvements.
The flip side is that aircraft models are becoming more advanced, and
we introduce features such as the OSM buildings that require more powerful
hardware. The latter are always optional, and I put a lot of effort into
ensuring that when such features are off they have no impact on users.
For example, if you disable OSM buildings, they won't even be downloaded
by Terrasync.
Complex aircraft models are a trickier topic. It may be that users of older
hardware simply won't be able to run a G1000-equipped C182T, and will
have to run an older steam-gauge version.
-Stuart
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Thorsten Renk]

Post by David Megginson
In the past, I could practice the hell out of these kinds of details in
FlightGear (tuning, twisting, and identifying all the navaids, adding
crosswind corrections, etc) so that they were habits when I flew them for
real, but I can't practice RNAV procedures like this (or many others).

Then I guess you just need to sit down and code this into your simulated
plane/instrument. I still don't think this is particularly hard to do -
dependent on how many details you want it may become tedious after a
while...

There are a gazillion of automatic and crew-initiated mode transitions in
the Shuttle, the AP and guidance requirements during launch do not even
resemble these on final, and yet you can do a whole RTLS abort sequence on
autopilot where the system automatically transits from mode to mode,
selects different navigation sources, decides whether to send you on
S-turn phases to deplete energy before guiding you into the HAC not not,
selects maximum flown bank angle dependent on abort vs. nominal flight
rules, reads out what you have selected as aim points, brake options and
so on and flies accordingly, etc...

All this can be done if you're interested in doing it, and if you get
stuck at some point, I'm sure I can help you out ;-)


* Thorsten

[David Megginson]

Thorsten -- that's exactly what I did 15+ years ago, when I found places
that FlightGear didn't do a good job simulating real life (e.g. magnetic
compass errors, VSI lag, VOR scalloping, turbulence, etc. etc.). Instead of
just making one-off tweaks like the consumer sims did, we (as a team)
emulated entire systems like the vacuum, pitot-static, and electrical
systems, so that failures would be realistic.

In the RNAV age, we need to do the same thing; it's just that it's a bigger
job. FlightGear will still be great for people who want to practice the
mechanical parts of flying (e.g. crosswind wheel landings in a Cub), but
will slip further and further behind for people who want to use it for real
IFR practice.


Cheers, David

Post by Thorsten Renk

Post by David Megginson
In the past, I could practice the hell out of these kinds of details in
FlightGear (tuning, twisting, and identifying all the navaids, adding
crosswind corrections, etc) so that they were habits when I flew them for
real, but I can't practice RNAV procedures like this (or many others).

Then I guess you just need to sit down and code this into your simulated
plane/instrument. I still don't think this is particularly hard to do -
dependent on how many details you want it may become tedious after a
while...
There are a gazillion of automatic and crew-initiated mode transitions in
the Shuttle, the AP and guidance requirements during launch do not even
resemble these on final, and yet you can do a whole RTLS abort sequence on
autopilot where the system automatically transits from mode to mode,
selects different navigation sources, decides whether to send you on
S-turn phases to deplete energy before guiding you into the HAC not not,
selects maximum flown bank angle dependent on abort vs. nominal flight
rules, reads out what you have selected as aim points, brake options and
so on and flies accordingly, etc...
All this can be done if you're interested in doing it, and if you get
stuck at some point, I'm sure I can help you out ;-)
* Thorsten
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Ludovic Brenta]

Post by David Megginson
Thorsten -- that's exactly what I did 15+ years ago, when I found places
that FlightGear didn't do a good job simulating real life (e.g. magnetic
compass errors, VSI lag, VOR scalloping, turbulence, etc. etc.). Instead of
just making one-off tweaks like the consumer sims did, we (as a team)
emulated entire systems like the vacuum, pitot-static, and electrical
systems, so that failures would be realistic.
In the RNAV age, we need to do the same thing; it's just that it's a bigger
job. FlightGear will still be great for people who want to practice the
mechanical parts of flying (e.g. crosswind wheel landings in a Cub), but
will slip further and further behind for people who want to use it for real
IFR practice.

David, what makes you think that the FloghtGear community is incapable
of
such a programming effort? Thorsten has aptly explained that this is
not
more difficult than some of the existing systems and the da42 already
has
the beginnings of a Garmin 1000 cockpit. Why not expand on that and add
features as needed, possibly sharing that cockpit among different
aircraft?
What is the cause for your pessimism?

[David Megginson]

The display is hard, but it's the easy part.

Getting the algorithms right, and keeping the data up to date every 7 weeks
(we have only a tiny sliver of that data currently), is going to be much
more of a challenge. I expect that it's probably an order of magnitude more
complicated than our current flight dynamics (etc.), so we'd have to grow
our contributor base, and find funding to pay at least Curt (and maybe a
couple of others) full time to manage the project. Note that that's what
has happened for other complex FOSS projects, like office suites and
browsers, which generally end up working through a foundation, rather than
our current relaxed circle-of-friends arrangement.

The reason it's so much harder now is that the software *is* the product
for GPS navigators, FMSs, etc. (unlike with older avionics, where the
hardware was the main thing). That means that emulating even a simple unit
like the GTN 650 or GNS 430W is almost difficult as building one, so we're
trying to keep up with armies of full-time software developers at Garmin,
Avidyne, etc.

There are other options. Garmin and Avidyne will never open-source an
emulator, because that would be the same as open-sourcing their products
(the same way that Apple open-sourcing an iOS emulator would mean
essentially open-sourcing iOS). However, if they were to provide an
emulator that runs on tablets *and* has a two-way communication protocol
(so that it can both take position information *from* the sim and provide
CDI/steering information *to* the sim), we could use that.

And if we wanted to build a tablet-based emulator ourselves, we could at
least join forces with the FSX and X-Plane communities to do it to grow up
the pool of talent.


Cheers, David

Post by Ludovic Brenta

Post by David Megginson
Thorsten -- that's exactly what I did 15+ years ago, when I found places
that FlightGear didn't do a good job simulating real life (e.g. magnetic
compass errors, VSI lag, VOR scalloping, turbulence, etc. etc.). Instead of
just making one-off tweaks like the consumer sims did, we (as a team)
emulated entire systems like the vacuum, pitot-static, and electrical
systems, so that failures would be realistic.
In the RNAV age, we need to do the same thing; it's just that it's a bigger
job. FlightGear will still be great for people who want to practice the
mechanical parts of flying (e.g. crosswind wheel landings in a Cub), but
will slip further and further behind for people who want to use it for real
IFR practice.

David, what makes you think that the FloghtGear community is incapable
of
such a programming effort? Thorsten has aptly explained that this is
not
more difficult than some of the existing systems and the da42 already
has
the beginnings of a Garmin 1000 cockpit. Why not expand on that and add
features as needed, possibly sharing that cockpit among different
aircraft?
What is the cause for your pessimism?
--
Ludovic Brenta.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Thorsten Renk]

Post by David Megginson
Getting the algorithms right, and keeping the data up to date every 7 weeks
(we have only a tiny sliver of that data currently), is going to be much
more of a challenge.

Well, if it's commercial data, you'll probably have to buy it and plug it
in. And if it's Public Domain, we can probably just download it.

* Thorsten

[David Megginson]

Thorsten: There's no public-domain source right now, so we'll have to make
it happen somehow. It's for sale only bundled with specific devices, AFAIK.

Stuart: Great if we can make it work, but the buttonology is an important
part of training, so we'll need to support that somehow (if we want to be
used for IFR training). For the route manager, we might have to make some
tweaks, including fly-by vs fly-over waypoints.

D

Post by Thorsten Renk

Post by David Megginson
Getting the algorithms right, and keeping the data up to date every 7 weeks
(we have only a tiny sliver of that data currently), is going to be much
more of a challenge.

Well, if it's commercial data, you'll probably have to buy it and plug it
in. And if it's Public Domain, we can probably just download it.
* Thorsten
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[David Megginson]

On Tue, 4 Jul 2017 at 11:48 John Denker via Flightgear-devel <

It may sound strange at first, but it makes sense if you think
about it: Some of the suckiest features of the Garmin UI are
the ones that most need to be simulated.

I think we should generalise that to a motto for all simulations. If we
want an easy UI, we can just have a button that says "Fly plane to
Seattle", and then sit back and watch it go. :)

BTW, are you the John Denker of "See How It Flies" fame?


Cheers, David

[Stuart Buchanan]

Hi David, John,

Post by David Megginson
Thorsten: There's no public-domain source right now, so we'll have to make
it happen somehow. It's for sale only bundled with specific devices, AFAIK.

According to the Route Manager wiki page, we already have support for
SID/STAR data provided from Navigraph, which is released on the AIRAC
cycle, and costs a pretty small amount (9 EUR for a single download of FMS data,
or 90 EUR per year)

Given the relatively low cost, I don't think that we as an organization want
to get into trying to digitize data ourselves just to make it open-source or
public domain. Particularly given the low cost of a download.

We might want to digitize the STAR/SIDs for the
default airport with each release so there are some approaches available
for those who don't want to purchase the data.

Post by David Megginson
Stuart: Great if we can make it work, but the buttonology is an important
part of training, so we'll need to support that somehow (if we want to be
used for IFR training). For the route manager, we might have to make some
tweaks, including fly-by vs fly-over waypoints.

Yes, I expect there will be some tweaks requires for the Route Manager for
fly-by, fly-over, those radius turn things. But that's really just an extension
of what is already there.

Post by David Megginson

Post by David Megginson
the buttonology is an important
part of training, so we'll need to support that somehow

Yes indeed!
Seriously, folks, you don't want to be an a situation where you
need to start the missed approach segment, and you can't remember
how to make the nav system do that.
In some cases, including some critical cases, the buttonology is
quite counterintuitive. A simulated display that would "look pretty"
in a static snapshot is not sufficient. Those who haven't flown
with such a thing should please not underestimate how complicated
the buttonology is, or how important it is for training.

Just before I saw this I was going to quote your comment above
that 10% of the function provided 90% of the value and we shouldn't get
hung up about implementing all the features immediately :).

As someone who hasn't flown these devices, I didn't appreciate that this
was part of the 10%!

Nevertheless, the buttonology is just logic within the instrument. It's
a complicated instrument, but still something that's tractable.

-Stuart

PS - I like the phrase "buttonology"

[David Megginson]

Post by Stuart Buchanan
According to the Route Manager wiki page, we already have support for
SID/STAR data provided from Navigraph, which is released on the AIRAC
cycle, and costs a pretty small amount (9 EUR for a single download of FMS data,
or 90 EUR per year)

Excellent start! Do they have approaches and enroute available as well? (A
STAR is a standard published transition from enroute to approach, but not
the approach itself.)


Cheers, David

[James Turner]

Jumping in, I am on holiday until the 16th, and won't be looking a the computer much.

But, we already have a ton of this code - sids, stars, approaches, tagging missed approach segments, fly-over vs fly-by waypoints.

Yes we need some better data sources, especially with direct routing replacing airways in many areas, and having airspace data would help the map displays, but the current API is specifically designed to support G430, G1000 and similar class devices. Adding RNAV approaches is eminently doable, see the the RNavController base class which the GPS/FMS layer uses to allow new waypoint / route segments to define how they are flown and drive CDIs

Kind regards,
James

Sent from my iPad

Excellent start! Do they have approaches and enroute available as well? (A STAR is a standard published transition from enroute to approach, but not the approach itself.)

[Thorsten Renk]

The reason it's so much harder now is that the software is the product
for GPS navigators, FMSs, etc. (unlike with older avionics, where the
hardware was the main thing). That means that emulating even a simple
unit like the GTN 650 or GNS 430W is almost difficult as building one,
so we're trying to keep up with armies of full-time software developers
at Garmin, Avidyne, etc.

If that kind of reasoning were true, no one would ever come up with
anything like a credible Shuttle sim (or in fact any glass cockpit).
Luckily, unlike the real software, the simulated one doesn't have to deal
with actual reality internally. Which is why it's much simpler to code
simulated avionics than the real thing.

3) Terrain - Slightly trickier. Depending on the resolution required,
we could do some terrain sampling and colour a canvas?

The Harriers by FGUK on the repo have maps where terrain queries build a
color-encoded rough image of the terrain. If you want a 3d impression via
wireframe grid, we can do that like the Shuttle does the ADI ball -
dependent on the resolution, this may be among the more expensive options.

4) Weather - This looks much more challenging. Not sure if we could do
this.

AW already forwards T-storms to the WXRadar code (from where it was never
picked up I guess), but I think the GUI canvas map shows them already.
Including other precipitation areas is straightforward if needed.

as entering a
route via a simulated touchscreen doesn't sound like a fun way to
spend a Sunday afternoon!

Again, it can be done if someone cares. It probably doesn't really give
you a realistic impression since trying to hit tiny clickspots precisely
with the mouse is a bit more involved than the real procedure... I use the
3d-cockpit keyboards to talk to the Shuttle in orbit when I have time to
correct my bad keystrokes, but I always use the virtual keypad when I have
to act under pressure during an abort scenario.

So, I think most of the fundamentals are there - it's "just" a case of
combining them into an
instrument that mimics the GTN 650.

Yep - just needs someone who's interested in doing it.

* Thorsten

[David Megginson]

Post by Thorsten Renk

The reason it's so much harder now is that the software is the product
for GPS navigators, FMSs, etc. (unlike with older avionics, where the
hardware was the main thing). That means that emulating even a simple
unit like the GTN 650 or GNS 430W is almost difficult as building one,
so we're trying to keep up with armies of full-time software developers
at Garmin, Avidyne, etc.

If that kind of reasoning were true, no one would ever come up with
anything like a credible Shuttle sim (or in fact any glass cockpit).
Luckily, unlike the real software, the simulated one doesn't have to deal
with actual reality internally. Which is why it's much simpler to code
simulated avionics than the real thing.

That's true of mechanical and electronic systems; it's not true of software
systems where the software drives user interfaces (rather than quietly
monitoring and adjusting internal processes, as is the case in most of the
shuttle software, or an autopilot's internal software).

Granted, we don't have to actually simulate decoding the GPS satellite
signals and iterating towards a location solution, but we do have to
simulate everything else — including RAIM failures or equivalent — because
(unlike, say, combustion in a cylinder or vanes in a vacuum pump) it is
actually visible to the pilot and reacts directly to pilot input.


Cheers, David

[David Megginson]

Think of it as analogous to simulating Android or Microsoft Word — the only
way to simulate using them is to basically reproduce the whole thing.

D

On Tue, 4 Jul 2017 at 13:21 Thorsten Renk <

Post by Thorsten Renk

The reason it's so much harder now is that the software is the product
for GPS navigators, FMSs, etc. (unlike with older avionics, where the
hardware was the main thing). That means that emulating even a simple
unit like the GTN 650 or GNS 430W is almost difficult as building one,
so we're trying to keep up with armies of full-time software developers
at Garmin, Avidyne, etc.

If that kind of reasoning were true, no one would ever come up with
anything like a credible Shuttle sim (or in fact any glass cockpit).
Luckily, unlike the real software, the simulated one doesn't have to deal
with actual reality internally. Which is why it's much simpler to code
simulated avionics than the real thing.

That's true of mechanical and electronic systems; it's not true of
software systems where the software drives user interfaces (rather than
quietly monitoring and adjusting internal processes, as is the case in most
of the shuttle software, or an autopilot's internal software).
Granted, we don't have to actually simulate decoding the GPS satellite
signals and iterating towards a location solution, but we do have to
simulate everything else — including RAIM failures or equivalent — because
(unlike, say, combustion in a cylinder or vanes in a vacuum pump) it is
actually visible to the pilot and reacts directly to pilot input.
Cheers, David

[Thorsten Renk]

Post by David Megginson
That's true of mechanical and electronic systems; it's not true of software
systems where the software drives user interfaces (rather than quietly
monitoring and adjusting internal processes, as is the case in most of
the shuttle software, or an autopilot's internal software).

If you truly believe that and that it takes an army of programmers to
write something that acts like a real GPS UI, I suggest we stop the
discussion right here and all go back to things we enjoy coding and you
just go and buy a commercial sim.

Because there's just no point in wasting your time with something that
can't be done.

Best,

* Thorsten

[David Megginson]

Not impossible; just harder. After all, the OpenOffice team *did* succeed
in building a complete office suite, for example, and the Firefox team
(which, granted, started with the ancient Mozilla code base) succeeded in
building and maintaining a modern browser. But it will be harder that what
we've done before, and — especially if we want to support more than one GPS
navigator / FMS at a realistic level — will probably require a different
kind of organisation than we have now, and maybe some outside funding.

*Step one* was to convince people that this is a far, far harder problem
than they realised (something I didn't fully understand until I dove into
the docs and GTN simulator); if we're past that, then *step two* is to have
a discussion about what, if anything, we want to do about it. We've come up
with several options already, and I'm sure there are more out there.

Note that I haven't even started on TAWS-A/B, TIS-B, FIS-B, Nexus radar via
satellite, and all the other things that are becoming realities even in the
simplest of contemporary airplanes. I didn't want to scare people *too*
much.

If the final choice is that FlightGear is just a vintage/VFR aviation
sim/game, and pilots have to go elsewhere for IFR practice, then that's
cool, too. But I don't want to give up quite yet.


Cheers, David

Post by Thorsten Renk

Post by David Megginson
That's true of mechanical and electronic systems; it's not true of software
systems where the software drives user interfaces (rather than quietly
monitoring and adjusting internal processes, as is the case in most of
the shuttle software, or an autopilot's internal software).

If you truly believe that and that it takes an army of programmers to
write something that acts like a real GPS UI, I suggest we stop the
discussion right here and all go back to things we enjoy coding and you
just go and buy a commercial sim.
Because there's just no point in wasting your time with something that
can't be done.
Best,
* Thorsten
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Richard Harrison]

Modern navigators are astoundingly-complex devices — probably an
order of magnitude more lines of code than FlightGear itself

Complex yes; but not that complex; it is important that the emulated
device operates exactly as the actual device, but (for example) it's not
as important if there are slight differences in the route that it chooses.

If you have a perfect knowledge of the device being simulated mostly
it's a coding exercise; as FG already has most of the support required
to build the pages, animate the buttons, and control the logic.

The difficult part of emulating any device is understanding it[1]
sufficiently to be able to build the pages - most of these devices are
still page oriented.

In 2007 I built a considerable portion of an EX5000 emulator[2] - took
me months, but the hardest part was understanding how it worked,
emulating it from the documentation alone. Then there was the the
navdata which required an ARINC-424 importer, the terrain data, the
approach plates using a Jeppesen product, and finding a performant way
of rendering the terrain data, together with figuring out how to make
the buttons and other events work dynamically with the pages.

The MFD framework that is used on the Shuttle is more than capable of
supporting a most of the requirements; Canvas is capable of rendering
the displays.

So it's possible to do this; but I'm not volunteering to do it; although
if anyone does undertake it I will be happy to help with getting a
framework together - it's the pages and the logic that will require
understanding of the device, understanding that I don't have (and don't really
want to acquire)


-------------
[1] Using the freely available Garmin trainers would be a good place to
start to build an emulator
http://www8.garmin.com/support/download_details.jsp?id=9256 - rather
than the documentation
[2]Loading Image...

[Stuart Buchanan]

Hi David,

Not impossible; just harder. After all, the OpenOffice team did succeed in
building a complete office suite, for example, and the Firefox team (which,
granted, started with the ancient Mozilla code base) succeeded in building
and maintaining a modern browser. But it will be harder that what we've done
before, and — especially if we want to support more than one GPS navigator /
FMS at a realistic level — will probably require a different kind of
organisation than we have now, and maybe some outside funding.

One thing I've notice in the last couple of years is that aircraft
development has
moved on from being a "one man show" to being a team effort, with tightly knit
teams working together to produce really high quality work. Examples are the
updated c172p, Shuttle, J3Cub and I'm sure I'm forgetting some. I think this is
a (very positive!) reaction to the amount of work required for high
fidelity models,
and has allowed much more rapid development, which has created a positive
feedback loop, as well as allowing specialization.

I think that model bodes well for developing a complex system like this, and
can develop organically.

I don't think we need a different type of organization, or outside funding

Step one was to convince people that this is a far, far harder problem than
they realised (something I didn't fully understand until I dove into the
docs and GTN simulator); if we're past that, then step two is to have a
discussion about what, if anything, we want to do about it. We've come up
with several options already, and I'm sure there are more out there.

I would suggest that identifying a particular piece to develop as a
"reference model"
in the same way that the c172p is the "reference aircraft" would be a good start
as it would allow us to focus on getting one thing right.

You obviously have a vested interest in simulating the GTN 650 :)

My ill-informed view is that doing the G1000 (NXi) would be more useful, as it's
fitted to the Cessna 172, 182, Caravan, Mustang, and Piper Archer, many of
which we already have as airframes in FG.

The G1000 also has the advantage that zakh has already done some of the
work already for the zhk1000 (https://sebmarque.hd.free.fr/git/seb/zkv1000).

Note that I haven't even started on TAWS-A/B, TIS-B, FIS-B, Nexus radar via
satellite, and all the other things that are becoming realities even in the
simplest of contemporary airplanes. I didn't want to scare people too much.
If the final choice is that FlightGear is just a vintage/VFR aviation
sim/game, and pilots have to go elsewhere for IFR practice, then that's
cool, too. But I don't want to give up quite yet.

I think you're being far too pessimistic about this. I think the FG
team (in the
very wide sense) has the skills and infrastructure to do this, and
with sufficient
interest could have a respectable G1000 implementation within 12 months.

I'm happy to volunteer my time to make this happen - I think it's sufficiently
valuable.

-Stuart

[Stuart Buchanan]

Post by Stuart Buchanan
My ill-informed view is that doing the G1000 (NXi) would be more useful, as it's
fitted to the Cessna 172, 182, Caravan, Mustang, and Piper Archer, many of
which we already have as airframes in FG.
The G1000 also has the advantage that zakh has already done some of the
work already for the zhk1000 (https://sebmarque.hd.free.fr/git/seb/zkv1000).

BTW - if you're looking for an idea of what's already been implemented, have
a look at the DA-42. It uses an older version of the zhk1000.

-Stuart

[Thorsten Renk]

Step one was to convince people that this is a far, far harder problem
than they realised (something I didn't fully understand until I dove
into the docs and GTN simulator); if we're past that, then step two is
to have a discussion about what, if anything, we want to do about it.

I'm halfway through coding a decent simulation of a Space Shuttle -
forgive me if I'm not really impressed by the challenge of coding a fancy
GPS. I do believe spacecraft are a little more complex (especially after
reading through a few thousand pages on how it all works), but feel free
to differ...

Look - the discussion is exceedingly weird. You want this device, Heiko
has at least considered it - yet somehow I who isn't really interested
seem to end up convincing you that while it may be tedious to code, it's
entirely within the grasp of a few people who are interested while you
keep arguing how horrible the task is, even to the level of outside
funding and Heiko keeps arguing how much framerate the device he hasn't
coded yet is gonna eat.

Convincing you people that you can just go ahead and code what you want
because it can be done and we know how to do it to have is not a good use
of my time - so I'll just stop it. And if you want a GPS, convincing
people that we can't really do it doesn't seem like a good use of your
time to me - but to each his own I guess.

If anyone wants to code it and needs pointers or explanations how the
Shuttle code does it, you know how to get in touch.

Cheers,

* Thorsten

[Thorsten Renk]

Post by David Megginson
Thorsten -- that's exactly what I did 15+ years ago, when I found places
that FlightGear didn't do a good job simulating real life (e.g. magnetic
compass errors, VSI lag, VOR scalloping, turbulence, etc. etc.). Instead of
just making one-off tweaks like the consumer sims did, we (as a team)
emulated entire systems like the vacuum, pitot-static, and electrical
systems, so that failures would be realistic.

Not sure I share your view of what a realistic electrical system does or
that it is a good idea to make failure modes other than sensors general
rather than airplane-specific, but that's a side note.

Post by David Megginson
In the RNAV age, we need to do the same thing; it's just that it's a bigger
job. FlightGear will still be great for people who want to practice the
mechanical parts of flying (e.g. crosswind wheel landings in a Cub), but
will slip further and further behind for people who want to use it for
real IFR practice.

I still don't see what your point is.

* after looking into the G1000 manual, it's my considered opinion that it
is possible to use canvas to render it with decent performance on
mid-range modern hardware (not on 10 year old computers though), that I
have a decent picture how it needs to be organized and that the Shuttle
MDU code (using Richard's framework to organize everything into pages and
the optimization techniques we've learned to use for the pages themselves)
exemplifies this

* the example of the CDI switchover you gave is a subset of what the
spacecraft automated systems solve all the time - it's easy to code GNC
based on 'modes' and define conditions to enter/leave the modes

* the example of the radius to fix is again the same as the Shuttle HAC
intercept/ follow

=> so there's example code for what you need which can be studied and
adapted to the specific airplane (I don't think a general AP for all
planes ever really worked, and things like RNAV to ILS sure depend on the
specific airplane/AP). In addition, I can help anyone who wants to start
coding it with the design.

So if your point is that the people interested in using FG for IFR
practice need a jump-start to get coding - I believe we have that, there's
code examples and experience available. You can basically start by looking
into Richard's MFD canvas wrapper and go from there.

If the point is that you believe the whole community should focus on this
and make it a priority, I have to disagree - to me and my FG use cases a
modern GPS is at best a 'nice to have' feature waaay down my priority list
(apart from spaceflight, I'm mainly interested in the VFR experience).
Personally I'd rather see FG re-structured to support more than one JSBSim
FDM - but I'm not expecting everyone to jump in to support this either.
Let's agree we can all have different perspectives on what FG needs
urgently next.

And if your point is that I should mainly be doing this because I know how
- after spending a year hacking the Shuttle avionics in, I sure don't want
to start the same with a G1000... so sorry, it's gonna be someone else's
turn :-)

* Thorsten

[Stuart Buchanan]

Hi David,

Post by David Megginson
To make the discussion a little more concrete, here's an example. When
you're flying an IFR approach with a GPS navigator, you can use RNAV for the
transitions, but need to switch to the ground ILS transmitter for the actual
approach (they both use the same CDI on many planes, so it's easy to miss).
The GTN 650 that I'm installing in my plane will switch CDI mode
automatically under certain conditions, but it's not guaranteed.

The FG Route Manager provide the RNAV function
(http://wiki.flightgear.org/Route_manager), plus logic to connect it as an
autopilot source. Switching the CDI to an ILS at the end of the route is pretty
straightforward: just put a Nasal listener on
/route-manager/signals/finished and
then check for a decent ILS signal.

From a quick glance looking at the GTN 650 and seeing what it does, and thinking
of how each of the main pages would map to FG function, I think we've
got most/all
of the underlying generic function and data sources required. "All"
that is required
is connecting them together into a coherent instrument.

Here's the list of main pages and how they would map:
1) Map - We already have mapping solutions, and the canvas one would
seem to get most of the way there
2) Traffic - Again, we've already got AI objects displayed on in-sim
maps, so this is done
3) Terrain - Slightly trickier. Depending on the resolution required,
we could do some terrain sampling and colour a canvas?
4) Weather - This looks much more challenging. Not sure if we could do this.
5) Default Nav - this is just some straightforward property display
6) Flight Plan - This is a UI interfacing the FG Route manager.
Frankly, I suspect we'd
probably just bring up the existing Route Manager dialog at this
point, as entering a
route via a simulated touchscreen doesn't sound like a fun way to
spend a Sunday afternoon! :)
7) Proc - Setting the STAR/SID to use. We already have this function
in the Route Manager.
There is an issue with getting the underlying data, though there are
tools to upload Navigraph into
the Route Manager.
8) Nearest - This is just a lookup into our existing airport and fix DBs.

So, I think most of the fundamentals are there - it's "just" a case of
combining them into an
instrument that mimics the GTN 650.

James Turner would hopefully have useful input, but given he hasn't responded
already I suspect he's on holiday.

-Stuart

[geneb]

Heiko, what video card are you using? g.

Not a fancy one: a Nvidia GTX 640M. But gives me for for most aircraft
20-30fps with custom shaders set to 4-5.
Highest setting is absolutely too much, and not working.

Ouch. :) If you can, find a used GTX 780ti - you'll be amazed at the
improvement. (FG goes like a scalded cat on a GTX 1080...)

g.

[chris]

Sorry Gene! Pushed the wrong buton... :-/ Here we go again...

Heiko, what video card are you using? g.

Not a fancy one: a Nvidia GTX 640M. But gives me for for most aircraft 20-30fps with custom shaders set to 4-5.
Highest setting is absolutely too much, and not working.

Ouch. :) If you can, find a used GTX 780ti - you'll be amazed at the improvement. (FG goes like a scalded cat on a GTX 1080...)

Well the 1080 is a total bummer to all hardware ever built! Completely
crazy!

The sad truth is, a lot of FG simmers are stuck using hardware 10
years behind! We shouldn't loose sight of that. On the other hand,
we should be looking forward! But expecting a 1080 for every user is
a stupid illusion...

Many people are frustrated, because we keep on growing into more
hardware requirements. This is sad, but unavoidable. In my humble
opinion anway! I'd love to support WinXP hardware, but I'd much more
love to have the latest eye candy on my screen at no cost at best.

Looking on the german FG forum, it's quite noteable, that most users
are running on ancient hardware, and are complaining that latest FG
is running slow. Well, this is certainly true, but inavoidable, I
would think. As software develops, the same goes for hardware...

I too like to avoid unnessessary eloctro-junk piling up in
Ebony-coast, but progress can't be braked by poor hardware... In
that case, you're simply a little slow...

Well, my 2 cents on this one!

P.S.
I'm still very much out of use these days. I try to keep up-to-date
with the list, but I must admit, I'm more than a little behind...

Best to all of you!
chris

[Thorsten Renk]

It isn't just the PFD and MFD showing artificial horizon, speed,
altitude, climbspeed, engine datas, electrical, fuel, navigational data
like VOR/ ILS/ GPS and much more.
The modern avionics also offers 3d-images of the surrounding terrain,
TCAS, further maps like airport diagrams, airspaces, approach plates -
all with search functions!; information about weather in real time by
satelite, autopilot, transponder, COM/NAV, audio panel and much more....
It is amazing!

You're unfortunately missing the point I've been trying to make. The
Shuttle has ~50 avionics pages implemented which you can bring on screen,
doing all sorts of things from showing temperature readings to orbital
rendezvous targeting - but I didn't multiply my numbers by 50.

I didn't, because for performance that's irrelevant, there could be 500
pages and it wouldn't hit performance more - you don't pay for the 49
pages you do not see on an MDU, you pay only for the one that is currently
displayed (unless your code is badly structured).

Now, the Shuttle avionics is staggeringly stupidly designed in displaying
a thousand parameters _at once_. It's not done like that any more,
information is reduced to the essentials in modern avionics, screens are
no longer crammed with small alphanumerics.

So everything else equal your GA display problem is going to be a factor
10 smaller than mine because you have only one display and not 11, and
it's going to be another factor 3-5 smaller because you don't try to
display 100 parameters at once but just 20-30.

Which is to say, if I can do a 1000 unique parameters per update cycle,
you ought to be able to display a GPS much faster if you code it the same
way.

Also note that if you display 30 unique items on your display at any given
time, you don't actually need to pay update cost for 30 of them but only
for those which change in the current frame. I've started to extend the
canvas API to support this for text, but it also can be done for other
elements. Also, property I/O can much be accelerated by using setprop()
rather than props.nas as canvas does (the code just gets ugly then...)

Canvas is more than some happy little SVG-objects, which must be drawn-
those happy little drawn SVG-Objects must be driven somehow, and that's
done by nasal. And those fancy nasal-scripts must simulate or use
properties, so that we get those features mentioned above - and all this
together costs.

Again, apart from the first sentence, that's a red herring. I can run
_much_ more demanding Nasal scripts involving thousands of trigonometry
operations per frame (numerical orbit fast-forwarding for instance)
without a performance hit - because running Nasal is cheap
performance-wise. Only things like property I/O or terrain queries are not.

So yes, you need to drive the SVG elements (I wouldn't draw them by hand,
I would do it procedurally wherever possible) and the I/O cost of driving
them if you have structured your code well is pretty much the number of
unique parameters you display and change in the current update cycle.

Which in my case is unfortunately ~1000, and in your case is likely ~20-50.

The fact that there are people code canvas like there's no tomorrow and
update 10 elements where an update of the group position would do the
trick at a fraction of the cost doesn't mean that canvas or Nasal are slow
- it means inefficient code is slow, and that's just as true for C++.

Nasal as such is fast, and compared with the cost of rendering the
terrain, rendering a canvas display is fast on the GPU (you can test by
rendering but not updating a canvas display), and unless you're doing
something very inefficient, calculating a display but not writing it to
the property tree is fast (you can test this by disabling the write
commands).

It's the property I/O which you need to structure well, and then canvas
will run fast. And of course the complexity of your underlying simulation
costs - if you run a thermal model underneath to get real temperature
reading, it costs more than inventing the numbers. But that has nothing to
do with canvas.

* Thorsten

[David Megginson]

An external app certainly one of the options. For now, the GTN emulators
are available only for Windows and iOS, but they'd be helpful for people
who have that hardware (even though they'd also mess up our scans,
switching from the virtual panel to another app and back). I wonder if it's
possible to get two-way communication, so that the emulator can drive the
CDI and A/P in the simulator.

And for earlier points, (a) Thorsten — I'm not putting this forward as a
feature request but as a chance for discussion (I've been with the project
on and off since the late 1990s, and this feels different from other
problems we've solved); and (b) Stuart — agreed that the GTN 650 isn't the
best starting point, despite my personal situation. The GNS 430/430W is by
far the most common GPS navigator out there in light GA aircraft (I think
Garmin has sold over 100,000 units of the 430 and its 530 big sister),
while the G1000 is typical in the smaller trickle of brand-new GA planes
being produced every year.

D

On Tue, Jul 4, 2017, 5:05 PM Heiko Schulz via Flightgear-devel <

Post by Thorsten Renk

Post by Thorsten Renk
I'm halfway through coding a decent simulation of a Space Shuttle -

forgive me if I'm not really impressed by the challenge of coding a
fancy GPS.

Post by Thorsten Renk
I do believe spacecraft are a little more complex (especially after

reading through a few thousand pages on how it all works), but feel free
to differ...
If you alone can do something, where several hundred and more people
worked over years on it, I'm sure you can present us a working G1000
next week tuesday.
Should be no big deal for your, right?
From Nasa [1]: "The shuttle's primary flight software contains about
400,000 lines of code. For comparison, a Windows operating system
package includes millions of lines of source code. "
Don't expect a G1000 or a G750 with much less code lines than the
primary flight software of the shuttle!
While I understand that you are really proud and excited of your work on
your Spacer Shuttle, you still sound a lot bigheaded.

Post by Thorsten Renk
it's entirely within the grasp of a few people who are interested

while you keep arguing how horrible the task is,

Post by Thorsten Renk
even to the level of outside funding
and Heiko keeps arguing how much framerate the device he hasn't

coded yet is gonna eat.
While you at least has a point showing that just talking will us never
bring us were want to be,
I think it is more than important to discuss where could be problems
and which tasks and issues we need to solve. There is nothing wrong about.
Looking at the commercial sims, I found Realitity XP, which simulates a
GTN750 Touch.
Believe it or not, but to make it work in X-Plane you have to download
the Garmin GTN Trainer [2].
So this trainer together with data provided by X-Plane drives the whole
thing.
So if there is a way to connect this trainer with FlightGear, it could
be a bit more easily for us ....
Cheers
[1]
https://www.nasa.gov/mission_pages/shuttle/flyout/flyfeature_shuttlecomputers.html
[2]
http://reality-xp.com/support/trainingcenter/userguides/manuals/Reality%20XP%20GTN%20Touch%20XPlane.pdf
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Wayne Bragg]

Fun facts:

FlightGear's

Space Shuttle

cockpit.xml = 31894
cockpit-detailed.xml = 10339
total lines of xml = 114122
total lines of nasal = 49930
0555
c172p

c172p.xml = 8463
total lines of xml = 52158
total lines of nasal = 2915

f15

f15-common.xml = 2147
f15a.xml = 4616
f15c.xml = 2089
total lines of xml = 42627
total lines of nasal = 10555

ja37

JA37-Viggen.xml = 3720
AJ37-Viggen.xml = 4559
total lines of xml = 69404
total lines of nasal = 15114

[Thorsten Renk]

But it uses somehow more power than a simple steam gauge, or the
old-fashioned way making a glas cockpit by using .ac-objects and
textures.

Displaying the same amount of parameters, I believe canvas is faster than
simple steam gauges and animations. Of course that's the rub because
you're comparing apples and oranges.

Correlation isn't causation - it is true that many advanced aircraft are
performance-hungry and it is true that many use canvas, but it is not true
they are slow because they use canvas, they are slow because they are
advanced and need to simulate many details.

An average computer should be able to display these with averagenumbers.
And a GTX 1080 isn't an average GPU right now yet....

If you believe the GPU has much to do with the rendering speed of canvas
displays, you haven't read anything I've written. And by now I've also a
10 year old machine running on a nouveau driver for FG performance testing
purposes, so I believe I am in a good position to gauge performance impact.

But please believe what you like :-)

* Thorsten

[Thorsten Renk]

Post by Thorsten Renk
If you alone can do something, where several hundred and more people
worked over years on it, I'm sure you can present us a working G1000
next week tuesday.
Should be no big deal for your, right?

I believe Stuart's time scale of a man year is fairly realistic.

Post by Thorsten Renk
From Nasa [1]: "The shuttle's primary flight software contains about
400,000 lines of code. For comparison, a Windows operating system
package includes millions of lines of source code. "
Don't expect a G1000 or a G750 with much less code lines than the
primary flight software of the shuttle!

I wasn't aware we were trying to re-do Windows or MS Word though. The
G1000 manual I saw didn't include such functions. And I didn't say I coded
PASS, I said I coded a decent Shuttle simulation - that includes a lot
more than 'just' the avionics.

That's just more apples to oranges comparisons. What's the point here?

Anyone seriously believes _having_ the canvas API and the route manager
already one still needs 'millions of lines of code' to get a viable GPS?

Post by Thorsten Renk
While I understand that you are really proud and excited of your work on
your Spacer Shuttle, you still sound a lot bigheaded.

If you think it's big-headed that I point to where your picture of
performance consumption is wrong, based on my by now lengthy experience in
testing canvas displays on different machines, or that I think a GPS is
not rocket science (sorry, couldn't resist), then yeah, I probably am.

But given other people's posts here I am in good company ;-)

Cheers,

* Thorsten

[Thorsten Renk]

Post by Thorsten Renk
While I understand that you are really proud and excited of your work on
your Spacer Shuttle, you still sound a lot bigheaded.

Actually, taking an hour to make up my mind what to think of this:

There was absolutely no need for a personal attack, and I'm going to
suggest you try an apology.

I tried to realistically estimate the amount of work needed, people who
have been working on guidance or displays in FG (like Richard for
instance) seem to agree with my estimates, and I tried to do what Stuart
asked, i.e. sketch where canvas burns performance and what best practices
to distill from that. The tools have have available in FG today aren't
those of 15 years ago (see below) and at least I personally tend to give
more weight to the opinion of people with recent coding experience in the
areas involved.

I stand by my statement that since we're not writing software for a real
hardware device but just a simulation of one, this is _a lot_ less work
than a real GPS.

Not only do we never need to extract any information from real satellite
signals, but we also utilize TONS of existing work - for instance a canvas
display call goes through the canvas API, that calls Shiva (or how it's
called) - which we didn't write - that in turn calls OSG (which we didn't
write), this calls OpenGL code (which we didn't write), that ultimately
calls GPU driver functionality (which we didn't write),... if you sum all
that, we are likely effectively utilizing 'millions of lines' of code (or
a lot anyway) - we just don't have to write it all ourselves.

Anyway, I entered the discussion at the point where Stuart called for the
experience of the Shuttle devel team, but I have no intention to be
insulted for trying to help out with a project I'm not even personally
interested in, so I'll leave it here.

Best,

* Thorsten

[David Megginson]

For the record, I am grateful for the work Thorsten has done on the
Shuttle, and I think he has every right to brag.

D

Post by Thorsten Renk

Post by Thorsten Renk
While I understand that you are really proud and excited of your work on
your Spacer Shuttle, you still sound a lot bigheaded.

There was absolutely no need for a personal attack, and I'm going to
suggest you try an apology.
I tried to realistically estimate the amount of work needed, people who
have been working on guidance or displays in FG (like Richard for
instance) seem to agree with my estimates, and I tried to do what Stuart
asked, i.e. sketch where canvas burns performance and what best practices
to distill from that. The tools have have available in FG today aren't
those of 15 years ago (see below) and at least I personally tend to give
more weight to the opinion of people with recent coding experience in the
areas involved.
I stand by my statement that since we're not writing software for a real
hardware device but just a simulation of one, this is _a lot_ less work
than a real GPS.
Not only do we never need to extract any information from real satellite
signals, but we also utilize TONS of existing work - for instance a canvas
display call goes through the canvas API, that calls Shiva (or how it's
called) - which we didn't write - that in turn calls OSG (which we didn't
write), this calls OpenGL code (which we didn't write), that ultimately
calls GPU driver functionality (which we didn't write),... if you sum all
that, we are likely effectively utilizing 'millions of lines' of code (or
a lot anyway) - we just don't have to write it all ourselves.
Anyway, I entered the discussion at the point where Stuart called for the
experience of the Shuttle devel team, but I have no intention to be
insulted for trying to help out with a project I'm not even personally
interested in, so I'll leave it here.
Best,
* Thorsten
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[S. Gebran]

If HLA is stable enough, part of the code needed to implement such
features could be done externally and partially independent of core
development. I see it as a more pragmatic approach than having it in
core or nasal.

Semir Gebran(CaptB)

Post by David Megginson
Thoughts?
Cheers, David

[David Megginson]

Should there maybe be a separate project to build an embeddable GPS
navigator with different faces/UIs (and a default standalone front end)? As
others have mentioned, a lot of the backend logic is the same, like doing a
gradual transition from RNAV to Localiser on intercept to avoid a sudden
jolt in the A/P, or calculating a turn past a fly-by waypoint. Again, that
would be a way to join forces with other Sim dev communities.

D

On Wed, 5 Jul 2017 at 14:31 Heiko Schulz via Flightgear-devel <

Post by David Megginson
The GNS 430/430W is by
far the most common GPS navigator out there in light GA aircraft (I

think

Post by David Megginson
Garmin has sold over 100,000 units of the 430 and its 530 big sister),
while the G1000 is typical in the smaller trickle of brand-new GA planes
being produced every year.

We have already an empty GNS 430 3d-model in the EC 135 P2 and EC 130 B4
helicopter.
Somewhere in the forum we have the link to a non-canvas(?) GNS 530.
Maybe a starting point for some.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Flightgear-devel mailing list
https://lists.sourceforge.net/lists/listinfo/flightgear-devel