Board index FlightGear Development Canvas

Garmin gns530

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Garmin gns530

Postby cbendele » Wed Jul 23, 2014 5:39 pm

Hi,

after a long hiatus (3 years!) I felt like doing some flightgear aircraft modeling again. 3 Years ago when I started the panel for my Bo, I couldn't find a nice, modern, panel mount IFR GPS. The King GPS we have is ancient, and the Garmin 196, while nicely modelled, Is a VFR handheld. So I decided to start with this:

Image

I know the GNS530 is already kind of outdated as well, but together with its smaller sibling, the GNS430 it's still much more widespread than its successor (GTN650/750). Also the GTN650/750 use touch screen interfaces, which I'm not really a fan of.

Right now this is very much work in progress. It's also the first time I wrote more than 5 lines of nasal, so I was basically learning the language while I wrote this. And the code looks it, I'm afraid (it's horrible!). Still, I think it's far enough to present it here and let people try it and send critique and suggestions.

Right now it is only available by public git from
Code: Select all
git clone http://git.webcb.eu/GNS530.git


If there is actual demand I might make a tarball every now and then, but I think most people here probably can use git.

How to try it out

  • clone the git repo into your Aircraft/Instruments-3d folder
  • add the gns530.xml file into your 3d model.
  • add the following code to your aircraft-set.xml (or aircraft-base):
    Code: Select all
        <nasal>
            ...
            <fg530>
                ## <file>Aircraft/Instruments-3d/GNS530/ND.nas</file>[/s] ## dependency on ND.nas removed on July 27th 2014
                <file>Aircraft/Instruments-3d/GNS530/GNS530.nas</file>
            </fg530>
        </nasal>
  • right now there are no requirements for the electrical system (the instrument is always on). This will change soon, and I'll update this line then.

What works (Updated July 27th 2014)

  • COMM/NAV stuff, both using manual tuning with the left hand buttons and rotaries and automatic tuning by pressing the [ENT] button whenever a COM, NAV or ILS frequency is selected by the cursor in any of pages that are already implemented
  • From the NAV page group the DefaultNav, Map and NAVCOMM pages exist:
    • The DefaultNav and Map pages don't look quite right yet, since I still use modes already present in the ND framework. I'll look into adding new modes that look like the respective pages of the real gns 530 later (I'll have to dive into the ND code first).
    • The NAVCOMM should work as advertised. If there is an active flightplan in the route manager, it shows frequencies for the departure, destination and alternate airports and allows autotuning by selecting one of the
      frequencies and pressing the [ENT] button. If there is no active flightplan, the three nearest airports are displayed instead.
  • The NRST page group shows the nearest Airports, Fixes (Intersections), VOR's and NDB's.
    • Autotuning works where appropriate (VOR and Airport COMM frequencies)
  • CDI, ENT and RNG buttons work where appropriate
  • nothing else yet

next steps (not necessarily in that order)

  • Create the Direct To page, both for manual entering of destination and for pressing the "Direct to" [-D->] button when
    any item on one of the "NRST" pages is selected
  • create FPL page that allows looking at the route manager flight plan and activating any leg/waypoint (creating flightplans/routes will not be supported for quite some time)
  • fix power control and require voltage at some bus
  • implement night lighting
  • create WPT pages so more detailed informations can be displayed for the items from the "NRST" page group
  • create dedicated views for the ND framework so the DefaultNav and Map pages look appropriate
  • make a "menu" page for the DefaultNav and Map pages so display of various info can be enabled/disabled (airports, intersections, vor's...)
  • also make most of the buttons work (OBS, CLR (go to DefaultNav) ...
  • clean up or even refactor large parts of the nasal code

what will probably not be implemented any time soon (if ever)

  • PROC and VNAV page groups (only once everything above is 100% finished, which might never actually happen)
  • remaining NRST pages (Nearest Center, Nearest FSS and Nearest Airspace, I don't even know how to get at that information from the flightgear nav database)
  • AUX page group (mostly device setup and database update stuff)
  • Most pages Menu's (except for DefaultNav and Map) which allow for detailed customization for many pages and views

further comments
I'm having some problems with the "instrumentation/nav/slaved-to-gps" property.
Whenever the slaved-to-gps property is set true, the selected-radial is set to the current route leg (or 0° if there's no active route). I'm not sure if it's flightgear doing this or one of the instruments I use (the ND framework?) If it is flightgear itself, there should be a possibility to disable that feature, since no mechanical HSI that I know of actually does this (glass cockpits probably do). Maybe somebody can comment on this?

Finishing up, I want to thank the guys that are creating the ND framework that I make use of in my instrument.

I'm looking forward to any comment (even nagative critique),

Christian
Last edited by cbendele on Sun Jul 27, 2014 8:01 pm, edited 3 times in total.
cbendele
 
Posts: 50
Joined: Fri Jan 14, 2011 10:08 am
Callsign: D-ETRA
Version: 3.0
OS: Archlinux

Re: Garmin gns530

Postby Hooray » Wed Jul 23, 2014 6:47 pm

Hi !

Those screen shots are looking pretty good.
I haven't yet looked at the code - I need to clone the repo first, because the git URL apparently cannot be viewed using just a browser ?
First of all, I'd like to know if you're already using Canvas ? If not, that's probably the first thing you should consider doing.
There quite some overlapping work here with ongoing efforts.

I suggest to move your thread over to the Canvas sub forum, if you agree that this is the way to proceed ?

EDIT: Ok, just cloned your repo and looked at your code - it's NOT horrible at all, it's OOP and even using Canvas, good job there!
Regarding how to proceed, I'd suggest to check out these:

http://wiki.flightgear.org/Howto:Coding ... #Objective
http://wiki.flightgear.org/Garmin_GPSMap_196
http://wiki.flightgear.org/Canvas_MFD_Framework

I think the main change will be splitting up the whole thing to work in terms of 1) buttons/switches, 2) modes and 3) pages - as per the GPSMap196 and Canvas EFB discussions we've had recently: http://wiki.flightgear.org/Canvas_EFB_Framework

Given the quality of your work, we can also add you to the canvas-hackers team clone so that you can directly continue your work there, to ensure that it is in line with overlapping efforts (MFD, EFB, ND, MapStructure etc)

PS: You may also want to update the upcoming newsletter accordingly, you can also upload screen shots there.
Last edited by Hooray on Wed Jul 23, 2014 7:05 pm, edited 1 time in total.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

Postby cbendele » Wed Jul 23, 2014 6:57 pm

Hi,

yes, I am already using canvas exclusively. The ND stuff I use is actually projected to a sub canvas (see lines 54ff of GNS530.nas).

It's okay to move this thread to whatever sub forum you consider appropriate.

One of the next things I want to do is looking into this:
http://wiki.flightgear.org/Canvas_ND_Fr ... ure_Layers
and adding ND modes that actually look like on the real gns 530 instead of just using approximations already present.

Christian
cbendele
 
Posts: 50
Joined: Fri Jan 14, 2011 10:08 am
Callsign: D-ETRA
Version: 3.0
OS: Archlinux

Re: Garmin gns530

Postby Hooray » Wed Jul 23, 2014 7:03 pm

Yes, I edited my posting accordingly after reviewing your code (see above).

right, I noticed your ND workaround already - it's a clever and simple method you're using there - but I would agree that it would be more flexible to simply instantiate your own ND, or even use MapStructure directly.

The ND code itself can also be easily customized/styled, and you can also easily add custom ND types.
The link you posted is not just ND specific, it's about mapping layers in general - that can be used anywhere, including the ND.

Overall, this is more than just a pretty good start, and in a much better shape than most Canvas code we're seeing, including even the ND code :D
So I wouldn't call this a "hack" at all.
But like I said, I would prefer to see this coordinated with related efforts - especially in terms of extracting a generic "MFD" framework for instruments that deal with MFD instruments, and concepts like 1) buttons/switches, 2) modes, 3) pages

Animations should probably be using the ND method, i.e. SVG elements animated via Nasal callbacks (timers/listeners): http://wiki.flightgear.org/Canvas_Animation_Framework
Caching can be implemented using MapStructure's SymbolCache.

To be honest, the best thing would be coordinating this with the extra500/Avidyne Entegra R9 developers, because that's the de-facto role model for a "complex" instruments - but we haven't really seen them being very responsive with regard to MapStructure/ND collaboration - however, your work is clearly very much overlapping with their's now - and both instruments could greatly benefit from each other, even without any MapStructure/ND involvement. If that's something you'd like to explore, I'd suggest to get in touch with D-LEON and D-EKEW: http://wiki.flightgear.org/Avidyne_Entegra_R9

EDIT: Here's a stub for the new instrument: http://wiki.flightgear.org/Garmin_GNS530
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

Postby cbendele » Wed Jul 23, 2014 7:25 pm

My starting hypothesis was that there are exactly two pages in the gns530 that actually need animated graphics. All other pages are either text only (most pages) or static maps (mosty the "Airport Runways" page in the WPT group). So I thought it might be a good idea to cut the animated graphics code completely from the gns530 code and put it into the ND framework. The remaining code should then not need any animation stuff or SVG stuff at all.

Would you suggest using SVG elements to create the many different lists of text (nearest airports, VORs, etc..., textual representation of flightplan, ...)?

I will look into the latest gpsmap196 and avidyne code tomorrow and see if I can make heads or tails of it. Otherwise I'll call for help. I'll also look into custom ND types.
cbendele
 
Posts: 50
Joined: Fri Jan 14, 2011 10:08 am
Callsign: D-ETRA
Version: 3.0
OS: Archlinux

Re: Garmin gns530

Postby Hooray » Wed Jul 23, 2014 7:38 pm

whatever you do animation-wise, should probably be encapsulated using a handful of helpers - that's the main mistake people are currently making - otherwise, it will be a lot of tedious work to update all animation handling code later on once we add some dedicated/more optimized animation handling support (whenever that may be).

The ND "framework" isn't much of a framework at all when it comes to "animations" - there's still a lot of dumb code in place that's doing inefficient stuff, it just happens to be more optimized than the average code that people tend to come up with for the same purpose :lol:

For anything that resembles "widgets", I'd prefer to use the new widget framework and a custom style/interaction helpers (i.e. mouse-less)): http://wiki.flightgear.org/Canvas_Widgets

The GPSMap196 changes have never been committed by F-JJTH, so I would not look at the code in fgdata for the time being, because it is very much inferior to your own code frankly.
The wiki article provides a link to a canvas-hackers clone where we added a basic prototype for "page" handling - but even that is fairly simple and crude.
The Avidyne Entegra R9 approach is more proper, but unfortunately much less aircraft/instrument agnostic, i.e. highly use-case specific - but the way the classes are structured is basically correct design still, even though they fail to provide proper encapsulation for modes & switch-handling IIRC.

Overall, the main challenge remains thinking in terms of building blocks and frameworks that are simple and generic enough to satisfy all existing use-cases.
We have a number of people doing heavily related work without any collaboration, or even just coordination, going on here unfortunately. And obviously, skills, experience and expertise vary greatly. Unfortunately, some of the most skilled contributors are least willing to collaborate efficiently, while some of the most active contributors have yet to wrap their heads around important Nasal/Canvas concepts. All this is further complicated by the fact that some people write exceptionally good code that is never generalized and committed, while others write pretty poor code, that is directly committed to fgdata. So there's that, too ...

Organizing this whole mess takes up a lot of energy, and usually turns out to take away all the "fun" for people unfortunately.
But there's at least a dozen people here, with varying Nasal/Canvas expertise, that are doing heavily redundant work due to lack of coordination and collaboration, sometimes it's even up to 60-80% of their work/time that could be saved by communicating up-front and getting in touch with people who've done similar things. Unfortunately, that's something that still has to happen ... Thus, thanks for getting in touch and showing a willingness to team up with others, it's really appreciated!
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

Postby cbendele » Sun Jul 27, 2014 11:52 am

Hi,

Last night and this morning I significantly refactored the nasal code of everything I had implemented. I abstracted out most of the list related stuff, created a base class for the Page Groups and tried to use hashes and foreach/forindex loop wherever possible. Line-count went down from about 1250 before the refactoring to about 880 after the refactoring while I even added about 50 lines worth of new features.

Hooray is probably not really going to be happy, since I'm still doing very much my own thing. I am trying to work into the right direction, though. While the whole list stuff is still part of the larger PageGroup class, it is consciously written in a way that should make it easy to pull it out into its own class or module. I did look into the code of some of the mentioned other efforts (I got me the Cancas Hackers Team Clone). I felt, however, that the main effort I need for my GNS 530 implementation is the whole flexible scrollable list in fixed canvas text fields, with flexible configuration, including "cursors"... I didn't really find anything related to that in the code that I say. Most other thoughts seem to revolve either around fixed display / soft-button user interfaces and the whole pages / modes stuff which only plays a secondary role in the GNS530 code, or concentrates much more on graphics and picture animation.

If somebody can point my nose at some existing code that does the whole scrolling list thing in a way that I could reuse, I'd be happy to look at it and maybe extend it so that I can use it instead of my own implementation.

Next steps for me:
- Implement the Direct-To Page
- Add custom modes to the ND
cbendele
 
Posts: 50
Joined: Fri Jan 14, 2011 10:08 am
Callsign: D-ETRA
Version: 3.0
OS: Archlinux

Re: Garmin gns530

Postby Hooray » Sun Jul 27, 2014 12:00 pm

That all sounds pretty good to me. For starters, I'd just try to use standalone "base" classes that do not contain any instrument-specific assumptions.
Once you have those in place, it would be a good idea to move them to a separate Nasal file and merely include them via io.include()
Those will be the main steps to help establish some kind of "framework" that others can more easily reuse.
Your gns530 would obviously then inherit from your new base classes and implement the corresponding interfaces for page/mode and switch handling.

Regarding the UI parts you mentioned, those should probably be based on the existing ScrollList widget in $FG_ROOT/Nasal/canvas/gui/widgets
Note that keyboard handling isn't currently available/implemented - but you could certainly use a virtual Canvas-based keyboard for starters.

Extending the ND will be mainly a matter of adding any custom MapStructure layers that you require - styling etc can be easily supported using the MapStructure method, too

Based on looking at your recent commits/code, here's some more specific feedback:

  • I'd consider generalizing the instrument such that it can also be just run/tested/developed using a standalone Canvas GUI dialog, analogous to the GPSMap196 using an overlay/skin - that will ensure that you can easily test things, without being aircraft specific - while also being able to easily run multiple independent instances in each dialog:
    Image
  • making the ctor configurable such that view/size are customizable would make sense
  • button/switch handling will benefit from being better generalized, i.e. to get rid of huge nested conditionals, see the GPSMap196 code in the canvas-hackers clone for examples
  • your structure and classes look pretty good to me - once they're fully declarative, I'd consider moving pages out into separate files, too - e.g.. NRST.page, DTO.page, NAV.page and then just use io.include("NRST.page") - see GPSMap196 for examples
  • fields like left/left2 etc could probably be better expressed as vectors, too ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

Postby cbendele » Sun Jul 27, 2014 1:00 pm

Re: ScrollList widget:
Hmmm.... what git branch should I be using? I was looking for something like a scrolling list widget, but didn't find anything, and a grep for "ScrollList" in $FG_ROOT/Nasal/canvas brings no results. There's a ScrollArea, but that seems, again, graphics-centric and not text-centric. I'm using branch master, which is also the default branch, I think.
I don't know what you mean about keyboard handling. The GNS-530 doesn't have a keyboard. It's operated using a pair of rotary encoders and a handfull of fixed-function buttons (no soft-buttons like many CDUs/MFDs/EFBs).

I'll look at the GPSMap196 button handling again. Maybe I can further clean up my mess :D

I'm not too sure about using a vector for left/left2 etc. I actually like that I have the position of the column and/or its primary function somehow encoded in the key, that I also use in the list configuration hash (like those in line 439ff).
Still, I'll reconsider this before I actually pull out the list class from the PageGroup class it is in now, and make the columns freely configurable by passing the configuration hash / vector to the ctor. If I ever do that. If I actually decide to use the ScrollList widget mentioned above, this point might be moot anyway.

I'm not sure what view/size you want to make customizable. It's a function of the 3d modell contained in the ac3d file anyway, right? Or do you refer here exclusively to a standalone Canvas GUI version that is yet to be implemented?
cbendele
 
Posts: 50
Joined: Fri Jan 14, 2011 10:08 am
Callsign: D-ETRA
Version: 3.0
OS: Archlinux

Re: Garmin gns530

Postby Hooray » Sun Jul 27, 2014 3:08 pm

well, those were just tips based on our experience with the ND code: people usually add too many hard-coded assumptions, such that the instrument ends up supporting only a single instance or single aircraft, using fixed property paths and fixed resolutions (view/size).

We still have to get rid of some of those hard-coded assumptions in various *.symbol files - simply because those contain "magic constants" based on the original 1024x1024 resolution - which will no longer work/look properly once someone uses a different resolution - for instance, in the map dialog. But MapStructure itself is aircraft agnostic - thus, it makes sense to make such settings customizable - we've seen that being a real issue when it comes to supporting different center/off-center modes once resolutions change, because setTranslation() calls assume 1024x1024 being the case.

Likewise, developing your instrument such that it works even without a particular aircraft is a good practice to maintain lose coupling - and supporting multiple instances is also much more straightforward that way - i.e. opening 10 GNS530 dialogs, you'd end up with 10 independent instances. Similarly, the customized ND could then be directly instantiated as part of the GNS530 code - rather than referencing an existing ND.

Besides, I'd suggest to get rid of the settimer() call and use maketimer() instead.

Splitting up the whole thing into 1) base classes and 2) pages would be a good thing to help enforce some kind structure/separation, i.e. so that people can improve individual pages, without having to touch the files containing base classes and vice versa. That will also reduce the chance of having merge conflicts. At that point, we could adopt the same base classes in the GPSMap196 or similar instruments - so that things will automatically evolve properly, without copy & paste going on (the GPSMap196 also isn't a typical MFD with "soft" LSKs - but a generic MFD framework can obviously be used to model also such instruments).
Another thing that would be useful here is a dedicated tab widget, and an instrument-specific style for the GNS series.

Looking at the code, we could probably reduce this to roughly 600 lines easily - and splitting up the whole thing into 1) base classes 2) instrument code and 3) pages will lower the barrier to entry when it comes to maintaining the instrument.

BTW: The ScrollArea code should be easy enough to adapt for your needs - and I don't think it's too focused on graphics - you can manage any canvas group with it, including osgText nodes. For an example, refer to $FG_ROOT/Nasal/console/:
Image

And like I said previously: once you start touching the ND/MapStructure code, it would probably be a good idea to commit directly to fgdata via the canvas-hackers team clone - just sent me your gitorious handle and we'll set up access for you.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

Postby cbendele » Sun Jul 27, 2014 3:34 pm

Likewise, developing your instrument such that it works even without a particular aircraft is a good practice to maintain lose coupling

Right, I agree. Right now, I don't see where I make any assumptions about the aircraft at all. And even in the long run, the only thing I can think about is that I will expect some voltage being supplied at some property to bind the whole thing into an electrical system. But that can easily be made configurable by passing that properties path to the ctor or however...

- and supporting multiple instances is also much more straightforward that way - i.e. opening 10 GNS530 dialogs, you'd end up with 10 independent instances. Similarly, the customized ND could then be directly instantiated as part of the GNS530 code - rather than referencing an existing ND.

Well, I can see how that would work from a strictly nasal point of view. But to get 10 instances there would also have to be 10 3d models of the instrument case and buttons somewhere in the panel (WTF? No airplane needs that many NAV/COMMs or GPS!). You're always talking about dialogs here, but for me, an instrument is primarily part of a hopefully nice looking and very functional virtual cockpit. The only reason I could even think about for basically having the canvas "standalone" without being embedded in a VC instrument is if somebody would build a real cockpit, say, with flight illusion stuff or the like, and would basically have a solid version of the device (3d printer anyone?). Then you would probably need an efficient way to get the canvas out onto a dedicated display for that instrument...

The other stuff:
* Directly instantiating the customizes ND instead of referencing the existing one is definitely on the todo list
* I'm on the maketimer() vs. the settimer() I understand now settimer is considered deprecated? It's still in many examples on the wiki, I think, otherwise I wouldn't have used it.
* Splitting up code into files, specifically base classes, instrument code and page group code like you suggest is definitely on the todo list
* If you can point my nose onto some specific parts where you would start for reducing this to roughly 600 lines I'd be happy :D . I'm not firm enough in nasal and the various existing API's (only started less than a week ago) to see my way through that. In some cases, though, I believe more verbosity good for maintainability and comfort of use. Like the thing about having hashes and "plain language" labels for the list columns as opposed to a vector where I would have index numbers instead...

Christian
cbendele
 
Posts: 50
Joined: Fri Jan 14, 2011 10:08 am
Callsign: D-ETRA
Version: 3.0
OS: Archlinux

Re: Garmin gns530

Postby Hooray » Sun Jul 27, 2014 4:06 pm

  • if added, the electrical system should probably be based on galvedro's work
  • hard-coded resolutions: I mean stuff like .moveTo(440+(20*i), 453).lineTo(450+(20*i), 453).lineTo(450+(20*i), 473).lineTo(440+(20*i), 473).close() that could possibly break once someone uses different size/view values ?
  • WRT having 10 instances - the point is not that there's actually an aircraft requiring that many, but to maintain a generic design that allows independent instances to co-exist, most other canvas instruments originally didn't support independent instances, let alone a "cockpit-less" standalone mode. And while the use-case may seem far-fetched, the design is usually more generic if the whole thing supports both use-cases, i.e. 1) independent instances and 2) a standalone GUI dialog mode - maintenance, testing and development are greatly simplified that way
  • another valid scenario is FGCanvas, i.e. running a separate fgfs instance that shows certain canvas-based instruments - as long as people design "instruments" just for cockpits, there'll inevitably a ton of implicit dependencies that we'll need to fix later on
  • generalizing the ctor sounds like a good idea, not just in terms of size/view, but also WRT to the placement/name that is currently hard-coded ?
  • maketimer is recommended these days, because it provides more options, and because it's harder to "mis-use" it, i.e. "leaking" etc
  • event handling (button_clicked) is one of the lowest-hanging fruits to get rid of ~100 lines of code, i.e. key/button and switch handling, the GPSMap196 should have some prototyped code doing this sort of thing in a more generic fashion, without having huge conditionals all over the place
  • another candidate would be your new/ctor which is doing some things procedurally - nothing wrong about that, but you mentioned the GNS430, too - if you were using the GPSMap196 method, you could simply load an "overlay" (skin) and then use a SVG file to pre-load various elements (screen, window, lists, scrollbar, central title, dropdown etc) - people wanting to support other/similar devices, would then merely edit the SVG file, without necessarily having to touch any Nasal code - that is "kinda" how the ND evolved over time: we have a huge "styles" hash that simply looks up SVG elements and animated them dynamically - people wanting to add new styles, can do so easily by editing the SVG file and adding ~5 lines of code for each element
  • performance-wise, the update() method and its way of computing a nearest list, could benefit from some MapStructure APIs, such as the geo.positioned delta() stuff
  • the khz/mhz adjust functions could probably be unified and just parameterized to cater for differences (looks mostly like copy & paste now?)

Overall, your code is looking really good - so please don't get this wrong, but making it more expressive, also means that maintenance will become easier over time.

Regarding your comments in the code, the terrain layer is something that omega95 is exploring - once it is a MapStructure layer, it can be used anywhere.

Once the separation is in place, the whole thing will be much less than ~500 lines probably - and people could help contribute to different parts of it, such as adding a GNS430 mode, or extending the base classes to support similar instruments like the GPSMap196.

PS: index numbers can also be intuitive:
Code: Select all
var PAGES = [....];
var PLAN = 0;
var NAV = 1;
var NRST = 2;

PAGES[NRST].update();
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

Postby janrippl » Sun Jul 27, 2014 6:08 pm

707 + GNS 530 + OK-AS =Image 8)
From 2014/19/04 I flying under VA Pan Am (http://www.panamvirtual.org/) My olds Callsings its OK-AS, CEF4200, V4A2184 and FAC2184... My Favorite aircraft in FlightGear and real life is Boeing 707 (in FG B707 version by Marc Kraus).
janrippl
 
Posts: 100
Joined: Mon Oct 21, 2013 6:55 pm
Location: Mokriny 188, As 352 01, Karlovy Vary, Czech republic
Callsign: PAA006
Version: 3.0.1
OS: Lubuntu 14.04

Re: Garmin gns530

Postby Hooray » Sun Jul 27, 2014 8:02 pm

Looking at the GNS530 manual, I am not convinced that we should directly use the full ND here - we could just as well port some existing ND features (compass rose, CDI etc) to become MapStructure features instead, and then just use a conventional MapStructure map with a few custom layers there:

Image Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Garmin gns530

Postby cbendele » Sun Jul 27, 2014 8:38 pm

Hmm... wouldn't you end up with a reimplementation of the ND anway?

The only reason why I keep pushing the custom ND type down my todo list is that it means firing up a vector graphics app and editing an SVG picture. I'm horrible that way, I'd rather write hundreds of lines of code to draw lines on the screen out of my head than firing up inkscape or whatever and clicking together a picture with the mouse. I hate that kind of thing. It's worse than writing documentation, and writing documentation is pretty bad, innit :D

btw, the left picture you posted is from a RealityXP, a payware GNS-530 model for MS FSX. It looks quite close to the original. Where did you find the right picture? It looks like a flight simulation model as well, but I've never seen it. Also, I don't like the way it looks at all.... [EDIT: right, look at the page source, it's some SimFlyers simulation addon? Anyway, I don't much like it. I hope my own version gets closer to the original, although I don't want to aim as high as the RealityXP one, which really simulates every single detail, even those that don't really make sense in a simulated environment.]

EDIT: lol... did you notice the radial-from-vor on the SimFlyers picture is a negative number?

I split up the code into separat files and got rid of ND.nas by creating the ND in the NAV object.
cbendele
 
Posts: 50
Joined: Fri Jan 14, 2011 10:08 am
Callsign: D-ETRA
Version: 3.0
OS: Archlinux

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 4 guests